Search results

I fixed several problems. First, the timing was totally wrong. The behavior system was ticking at a fixed speed of 100ms (each 100ms the update methods of all relevant nodes was called). However, this actually did not happen each 100ms. In addition, the move input event took its delta time value...

I see two alternatives here: 1. A system mostly equal to what we have. Here, the AI sends movement events (basically the same that a normal player could do) and the physic engine (aka world) react and moves the minion if possible. To make things easier for AI developers, there should be of...

From your list, I vote for Tooltips ;-) They would help to use the BT editor a lot, I think. But its not time critical, so just do what is most fun for you :-D

Status update after long time ;-) I finally pull requested the behavior tree + editor to the develop branch. I have got the editor to work with NUI. You now can define your own nodes in modules, which will automatically found and are available in the palette. Maybe I will add a small tutorial...

Ok, I removed all nui related stuff in this branch: https://github.com/synopia/Terasology/tree/behavior_no_nui But since, Immortius merged nui into develop already, I tidy up some code and pull requested the behavior branch ;-) maybe we should discuss code related issues there.

Hey, first thanks for the feedback. 1) My suggestion was, to make BT nodes something like a API for modules for AI stuff. So, mods should have their "normal" code (in this case the pathfinding algorithm) and several behavior nodes, that are used by the BT. I dont want another module for all...

Btw, the jumping is because there is a block in the movement direction. This is a really clever idea, to make minions jump over block or climb stairs. But its not working properly, if the bbox is wrong ;)

The "walking-in-air" is exactly the problem with the current minion-move-code I mentioned early. Its a bit confusing how to setup the correct bounding boxes for the entities, especially with different meshs. I think, there is a bug in the associated code too - but I did not looked at it very...

I always reformat my code before committing. This should be a simple setting in idea. Just to make sure: Is LF linux or windows style?

I can try to write down, what I think should work, but I cannot prove it right now: 1. Checkout the BT branch https://github.com/synopia/Terasology/tree/behavior 2. ./gradlew fetchModulePathfinding 3. ./gradlew fetchModuleLightAndShadowResources 4. build & start Terasology Since I am using...

Hey, sorry for answering this late. The Miniion module was the the first one I looked into, when I started developing for Terasology. In Pathfinding module you will even find some classes or methods, that are more or less taken from the Miniions. My biggest problem with this module is, its not...

Looks cool ;-) Maybe an alternative approach would be using a Sobel kernel to find the edges. I used one in my pathfinder, but dropped it, since i needed something else ;-)

The L&S module is untouched quite a long time. It should not contain any assets - they should be moved to LASR. So the LASR module may be used as a dependency by other modules without bringing new code / modifying things in the game world. The code in L&S is mostly outdated. All classes...

Hey, great to see, someone took over this topic ;-) The original BlockSelection code was quick and dirty to just get some blocks highlighted somehow. I have another render component, which uses this class internally. I suppose, I can drop this and replace it by your changes. Will do that soon ;-)

First things first, happy new year to everyone. In my behavior tree example I already use a component (system) to handle some very basic support for jobs. There I use block components to assign jobs to specific blocks. The job component system keeps track of all open jobs. As for the behavior...

PR: You are absolutely right. Consider my code as proof of concept. I am totally fine, if none of the code is ever merged (only, if there is a proper replacement, of course :geek:). MigLayout: Again, you are right with the strings. I personally have no problems with this. I used MigLayout once...

Next update: Moved BT code to engine. Currently its a branch (behavior) in my own github fork. Its not ready to be PR'ed. Rewrote most BTEditor code to NUI (yes, its working so far - however its not yet finished). Build some supporting classes for NUI (ZoomableLayout (will be renamed probably)...

My weekly update, not as big as last ones: Added generic property editor for nodes. I built the code on the existing TeraEd property editor, but I made so many changes, I moved everything into my own package. Editor can now open/edit different trees from different minions. Introduced prefabs...

I think a chunk entity would be nice for other things, too. For example the pathfinder could use it, to store current state of the navigation graph, since the navgraph is build on chunks. Maybe all jobs located in a chunk may be collected and stored in the chunk entity, for faster access. I can...

Ok, found some time to explain the video a bit. What you see is me playing around with minions, mazes and the behavior tree implementation. The four used tools (all have scissor icon) are: Red spawner: Just spawns the next red model (pawn, fool, king, knight, queen, rook). Assign Walk to job...