Something wrong with tie physics

[PurpleYouko]

I spent a little bit of time yesterday tinkering with a couple of my old MBs, more specifically Inchworm and his decendant Inchworm2 (I know it is a crappy name but WTF)

It soon became apparent that something is messed up with the way he moves in V2.36 (all versions)  :blink:

He should move by fixing one end then expanding and contracting then fixing the other end.
Rotation should be done by moving one end in an arc around the "fixed" end.
What actually happens is that both ends kind of slide sideways in a big arc around a point about three or four robot diameters beyond the fixed end of the MB.

Check out my poor little Inchworm2 and you will see what I mean.

I had better go in and figure out what is going on here I think.

[Numsgil]

Be careful when you do figure it out that you don't 'fix' it wrong.

It may be that physics are working more correctly than they were before, and the old versions were based on incorrect physics.

That said, I don't think I've even touched ties, so it's not my fault (:grin:).

[Shen]

It seems like the bounceback from a stretched/compressed tie overrides the fixpos. Maybe the tie physics are just after the fix code like that velocity bug was. (Not that I can program to save the world)

[PurpleYouko]

There are actually a couple of issues I think.

1) The main one I think is that fixpos appears to be slightly messed up. "fixed" stuff appears to be able to move a little. Try fixing the veggies and watch the way impacts make them move a bit.

2) There is a routine in the multi-bot section which transfers about 50% of any applied acceleration on a robot, to its tied partner. This should only work for direct accelerations such as .up, .dn etc. but appears to be working with all accelerations including those imparted on the robots by ties.

The whole thing is most likely to be a case of a single line of code being in the wrong place with respect to another one.
I don't think I will need to touch the actual physics. Just fix it so that "fixed" bots really are fixed

On a slightly different note, thinking about the way that some accelerations are auatomatically transferred across ties has made me start to work out how MBs can actually be moved as a whole.
We might need a whole new command system to communicate instantly throughout the bot. I will let you know if I come up with a workable method. I have the beginnings of such a system going round in my mind right now but it hasn't completely congealed yet.  :wacko:

[PurpleYouko]

Well that was easy.  :D

It seems that in the old physics system, no acceleration was added to robots if they were "fixed"

I deleted a whole bunch of that code when I simplified the physics module for 2.36 in order to make it run faster and be more realistic.
Trouble is that now accelerations added by tie physics and collisions, are acted on even by "fixed" robots.
The answer was just to make movement conditional on being "NOT Fixed"

Simple really.

Now to move onto bigger and better things  :D

[Numsgil]

I was thinking that the commands that lock onto ties and memory locations should be able to be changed during the execution of the DNA.

Like:

Lock onto tie 5
Lock onto memory location .up
store 10 there

Lock onto tie 6
Lock onto memory location .up
store 10 there

lock onto memory location .dx
store 5 there

All during one cycle.

That allows communication of multible bots to each other, provided that they have a tie to each other.  I still favor the idea of communicating to a bot seperated by several bots  through several intervenous ties.

That is, if A->B->C, then A has to communicate through B to get to C.  It can't just go 'hey, C!'.

[PurpleYouko]

I quite agree there. A should never be able to comunicate directly with C. It should be like nerves firing implulses. Each nerve ending (bot) has to be directly involved.

I also like the idea of multiple comunications per cycle. Could bog the program down on complex bots though. We could set up a tie comunication stack that is activated directly during DNA parsing then a single loop to update all memlocs of tied bots. Probably the quickest way.

However that wasn't precisely what I was referring to.
What I am aiming to acheive is for a single bot to be able to mass-move the whole MB in one step.
Imagine the situation where a large MB (eg. Hexagonis) wants to move somewhere. It has one head that decides the direction and speed so this head has to somehow tell the whole lot of them to move in a specific direction.
It can't just send a message for everyone to move "up" as they are all facing different ways.
What is needed is a system whereby the impulse to move "up", as defined by the head, is translated through the whole MB such that they all accelerate in the same direction at the same time. This isn't so much a comunication as it is each bot simply matching the vector of acceleration of all tied bots. This way only one "up" command needs to be issued by one bot in order for the whole MB to move.

[Numsgil]

trefmyX tells velocity of a tied bots from your own point of view, so that might be a good place to start.

I also think there are several different types of ties that we should make, that change the ways they cause connected bots to move.

Like:
springs, (stretchy, like what we have)
bones (don't stretch at all)
clamped springs (like those things on doors that stop them from slamming.  Velocity decreases as you get closer to natural length)

[PurpleYouko]

That was kind of the way I was thinking when I implemented ".stifftie" some while back. It was intended to damp ties out somewhat and was partly successful. I didn't really go far enough though.

[Numsgil]

Try letting stifftie go to like 32000.  I'm curious what happens (I haven't looked at the code yet for it...)

[PurpleYouko]

I can't remember why I limited it to 40 right now but there was a perfectly valid reason. I think it was something to do with maximum speed (which was 40 back then)
I would have to go back and check. It also could be that stifftie will work better now that physics is fixed.