Code center > Suggestions

Tie Forces

<< < (5/7) > >>

Numsgil:

--- Quote ---Slightly off topic but is this "math error" why the bots will sometimes fall downward if their tie is exactly horizontal and why they seem to like rotating mbs so much?

This does make me curious how the bots will behave once we get the physics working right.
--- End quote ---
Very possibly.  Physics in older versions are very screwy.  They all didn't work through the same channels.  Some moved bots through acceleration, some just poofed them there, etc.

The new physics are a little less strict in what can happen.  Bots can overlap for a cycle or two, bots can dissapear under the screen for a few cycles, etc.  But it gains in robustness what it loses in accuracy.

Numsgil:
Yes, they will stop rotating, but that's because theres drag on the individual bots.  Go into the code and get rid of everything but tie drag, and they'll never stop.  Of course, you'd have to uncomment Carlo's code, but I think you see my point.

Remember, I'm not as concerned about orbitting bots as I am with getting the physics right for bots to be able to swim.

I think I solved the problem.  We'll see what turns up.  I end up with:

Drag force on a bot is: A/12*length^2 (a^2+2ab+3b^2)


Had to use Maple to integrate the thing, then simplify.

Botsareus:
OK , you beat me to the post of  some incurgment so if it works:CONGRADULATIONS! NUM!  :D


Yes, they will stop rotating, but that's because theres drag on the individual bots. Go into the code and get rid of everything but tie drag, and they'll never stop. Of course, you'd have to uncomment Carlo's code, but I think you see my point.

Possible Solution:

We can see the change in angle due to tie, movment velosity changes to rotation velosity  due to tie. Velosity is reduced as it is supposed to.

Now all you need is the exact formula for convirting velosity into rotation. Since on wider radios the angle changes less drasticaly anyway. It might be change in position per cycle (without applying linkfource) as the radios, then mesure the circumefrance segmant from the original angle to the angle resolting due to ties.

Endy:
Glad you figured it out, although my brain refuses to make much sense of the math :wacko:

Would it be possible for MB's to be moved a bot at a time rather than all at once? I'm not sure of the programming constraints, but it still seems DB has problems moving large MB's in torroidal mode. Should also make it more realistic since bots couldn't abuse the edges anymore

Botsareus:
We can use the clone bot method , when half a bot exsist on bouth sides of the screen, a bot is cloned into two (or four in rear cases) to simulate bouth edges of the screen. Integrating them to work as 1 and applying the whole consept to the errays is another story.


Here is how it looks with a MB:

O---C| end of screen

C clone = } we get beggining of screen|}--O

resulting in a bot O----C}-----O were C} = O , C  and } are seporate bots when painted , painted only half way.

Tie senerio

O--a--|end of screen
beggining of screen|---b--O

--a-- and --b-- are the same tie used twice, witch is basicaly what num will explain in the next post (although I think we should clone bots as well, wana illabirate?):

Navigation

[0] Message Index

[#] Next page

[*] Previous page