Inactive Miniion

Mike Kienenberger

Active Member
Contributor
Architecture
GUI
Sorry. I should have mentioned that a) I was using a flat world and b) that movement (as Synopia and I talked about earlier on this thread) is buggy. Sometimes it works (and looks great). Sometimes it doesn't. Rather than try to do more to fix it exhaustively in Minions, the plan is to use Synopia's movement behavior. I haven't done that yet. Often, to quickly test Minion changes, I insure that the zone selection is directly under the minion location as they will not try to move if they are within 5? blocks of the block they are working with.

Some of the known issues with movement that I have seen are:

1) I'm abusing the CharacterMovementComponent velocity to store a movement direction. While this works, it really needs to be in a separate Component as CM is intended to store movement output state, not movement input state.

2) "Teleport to fix problems" code in the minions movement code doesn't work right and probably causes more problems than it fixes. At first I commented it out, and that reduced the number of flawed movement issues, but I thought I had adjusted it.

3) Minions sometimes jump. Minions sometimes don't jump. I'm not sure why this is. Often restoring the same game file will result in two different behaviors after loading. Jumping minions excel at travelling while walking ones don't :) I guess one possible quick fix would be to try setting jump = true in the Character or CharacterMovement component (Don't remember which one had it). Or you might also get things working simply by saving the game and reloading it a few times.

To be fair to the original developers, I don't think the bugginess was "designed in" but is a result of the underlying systems used for Movement changing in incompatible ways since the module was last worked on.
 

synopia

Member
Contributor
Architecture
GUI
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 deeply.

I am now at home again, have coffee & beer and will checkout the minion stuff. Im hanging around in irc, too.
 

Mike Kienenberger

Active Member
Contributor
Architecture
GUI
Yeah, I completely ignored the walking-in-air part as I knew it was a Physics Collision-Collider bounding box problem. But even if they were adjusted to be visibly on the ground, the movement code still has all of the original flaws I mentioned.
 

synopia

Member
Contributor
Architecture
GUI
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 ;)
 

Mike Kienenberger

Active Member
Contributor
Architecture
GUI
In my opinion, the bounding box issue is completely separate. It's a visual error and doesn't affect game logic. It'd be a good thing to fix, but it's a lower-priority issue.

When the movement code is working well, I have seen a Minion which has fallen into a hole jump up the same blocks I did to get out, and then hop over to their work zone and begin work.
 

Mike Kienenberger

Active Member
Contributor
Architecture
GUI
Crops / Minions and pieces of engine all fixed up to support the ChangingBlocks module, which animates crop blocks and all kinds of other things.
 
Top