Bots in a Viscous Medium How to get the bug:
Set the friction settings to "Thick Fluid" and run a sim. The bots vibrate back and forth insanely. This shouldn't be happening.
What I think is happening:
With fluid dynamics, the friction increases with speed. If the bot sits there not moving, then they stay still. The problem comes if they try to move. It seems that the friction when moving is enough to overpower the bot's forward motion and actually force it backwards. Friction shouldn't be greater than the force that the friction is resisting.
Viscosity GlitchHow to get the bug:
Set the friction settings to "Thick Fluid" and run a sim. The bots should vibrate back and forth. Start a new sim but this time change the friction settings to "Sandpaper" or "Metal" or "Teflon". The viscosity is still the same as "Thick fluid". The bots still vibrate back and forth like they're in a thick fluid.
What I think is happening:
The viscosity isn't getting reset when the friction settings are changed to solid. You can see this if you change the friction settings to custom and look at the viscosity.
Overflow Bug How to get the bug:
Set the friction settings to "Thick Fluid" and run a sim. The bots should vibrate back and forth. Start a new sim but change the settings to "Custom Physics" and change the viscosity. It goes down to 0.01. A couple of seconds after you hit the "Start sim" button, the program gives an overflow error and exits.
What I think is happening:
I haven't got a clue, but I'll bet it's linked with the above bug.
Zoom Overflow How to get the bug:
While in a sim, unlock your view so you can see areas outside the field and then zoom out. Keep zooming out, and the program will eventually give an overflow error.
What I think is happening:
This is one of the simpler bugs. The area that you are viewing becomes so big that you get an overflow. I reccomend restricting the maximum possible view.
Shootval Bug - Uh oh - major, major bug here!!!
The number in .shootval is the energy cost for a shot, no matter what kind of shot is being fired. If a bot does this, for example:
.aimdx .shoot store
628 .shootval store
(ie. Icarus)
... then the bot will have to pay a whopping great energy cost of 628!
Bots should only have to pay an energy cost of the number in .shootval when they fire -1 shots and -6 shots, not for any other types of shots.
VirusesOK, viruses could really do with a debugging
Some of the strange behaviors I've been noticing:
- Rather than be fired forwards viruses fly off at random angles (although I think Nums did this on purpose)
- No matter what number is put into .vshoot, the viruses always have the same range
- Viruses loose their condition when fired (I think Nums did this on purpose too) and are getting themselves inserted into the middle of genes. One of my viruses hit a veg and was inserted directly into the middle of the reproduction gene - directly before the START of the first gene. This resulted in the veg going cancerous.
- Genes cannot make themselves into viruses. If the gene number of the current gene is stored into *.mkvirus (ie. with *.thisgene) then the virus will not appear.
'Touch' sensesThese don't work at all
Here's what should happen:
These sysvars are supposed to detect collisions with other bots
- If a bot is hit/touched from the front, *.hitup should readback 1
- If a bot is hit/touched from the back, *.hitdn should readback 1
- If a bot is hit/touched from the left, *.hitsx should readback 1
- If a bot is hit/touched from the right, *.hitdx should readback 1
Delgene.delgene doesn't work at all
If you store a gene number into .delgene then that gene should be deleted, but this doesn't happen
.thisgene works fine though, so the problem isn't in the gene numbering as I originally thought