This build is designed to help solve the problems we are having with driving and other physics weirdness like robots spontaneously deciding to lean over on their side for no apparent reason. The root cause has been an improperly computed location of the center of mass, particularly for wheels that are attached directly to motors. This problem has made beetleweights completely impossible. Beetleweights appear to be driving correctly now.
For this bleeding edge build I have included COMTrackers that visualize the location of the center of mass of each rigidbody. Any time you add a motor and attach something to it, you are adding an additional rigidbody.
Please give it a try and let me know if you are still seeing issues.
[Added] Added COMTracker.cs to track the location of all the centers of mass of every rigidbody on a robot.
[Added] Added COM_Controller.cs. This script should correctly compute the COM of a rigidbody based on the center of mass of each of its Component_Info components. This can be done repeatedly at runtime. I still need to do extensive testing to make sure the script works in all cases. If it does, then it should be possible to apply the script to things that have lost parts due to damage, as well as broken pieces lying around the arena.
[Added] Added COM_Controller to rigidbodies spawns when a component breaks off.
[Added] COM_Controller.recomputeCOM() is now called on the original rigidbody when a component breaks off.
[Added] Added more hotkeys (now hotkeys can be shift/ctrl + key): -close pause menu, hotkey screen and help screen with the same keys for opening those screens. -Toggle workbench with B key. -Toggle music with N key. -Cycle through music tracks with ctrl + N. -Confirm on popups is enter, cancel in popups is backspace or escape. -You can move through the botlab sections using the right and left Arrow.
[Removed] Removed the makeup mass code from SpinnerMassReducer. By using the COMTracker spheres, I noticed that the center of mass was not in the right location, and could completely throw off the balance of a robot.
[Changed] Set the axle mass of various motors to 0.000001 kg: AmpFlow A40-300 37 mm Geared 37 mm Ungeared 22 mm Geared
Working on it. I’m trying a million little things to solve the problem at its source without luck.
In the end I might have to go back and manually fix the center of mass of wheels after the entire assembly is created. I know this will work for wheels but would not fix any similar problems that might arise for weapons.
How do I edit the file in Unity? Can I just import the .exe or do you have to send me the project file?
You pretty much need to have the project, and then compile it to a working game
Id help but given my limited unity knowledge i probably would look at it with more questions than answers
I found a problem with the location of the center of mass of wheels. For some reason wheels have center of masses that are off-center. This is causing all sorts of wobble once the wheel rotates, and is even causing some robots to spontaneously flip over on their sides or back.
Robots that use the largest wheels are the least affected. Beetleweights are completely unplayable.
We are working on a fix now.
Could this fix the jittering on low tick and oscillation on high tick?
I noticed something (or lack thereof) where I had a bot that lost half of its weapon. It didn't spaz around like it should have. Here's a video: [ Quoting of attachment images from other messages is not allowed ]
Which one lost half of its weapon?
I took out the center of mass recalculation code because I’m still working on spinner and wheel physics and I need to eliminate some variables.
My big issue right now is that we are doing a hack to improve drivability. The hack is not scaling to smaller robots. This manifests as the problem you see in Beetle Crab where the robot will spontaneously float up on its side. Beetleweights are in a bad place right now if they have an active weapon. I need to nail this down to make driving consistent across weight classes.
The eggbeater (player 1) lost half of its weapon but didn’t spaz around like it should have. Condo the fact that half of the eggbeater weighs 11 kg, it should have jumped around like crazy.
Did you not read this line? Chris: I took out the center of mass recalculation code because I’m still working on spinner and wheel physics and I need to eliminate some variables
idk if there's anyone here who could be bothered anymore, unfortunately
I think there's a Battlebots-skinned version of the Robogames arena floating around that might help flippers do something though. I've been using it for a while for stock matches and it works fine.
No hazards, but it has BB-like ring-out zones (though they don't instantly eliminate robots)
Now that hotkeys are a thing, how about giving me ideas on what features you want to have available on keyboard and with what key to activate it. They can be stuff that already has a button assigned to it but would benefit from a keyboard shortcut for experienced players, but also stuff that is only usable through keyboard as they would be impractical in the UI or needs to work together with the mouse.
The hotkeys for functions that are on different sections of the botlab can have the same key, for example snap to grid in the shape creator can have the same key as the snap function when adding components to the robot.
Question: Is there a way to make it so two motors spin one weapon? For an example, I have a design that has two motors driving the same bar spinner, each with a separate belt drive going from the motor to the spinner.
As cjbruce said, the robot is saved as a tree structure and that makes this specific feature pretty tricky to implement as I have to rework quite a bit the system to allow for this. I have had this feature in mind however, and I would be interested in implementing this, but I still haven't found a satisfactory way of doing that.
Hotkeys that i really want that would help with building: Delete key would delete a part. Undo button and a hotkey for it (idk which one)
As for the motors, in my opinion, thats not really a massive worry, however i would like the option to attach multiple belts on a motor
Question: Is there a way to make it so two motors spin one weapon? For an example, I have a design that has two motors driving the same bar spinner, each with a separate belt drive going from the motor to the spinner.
Wtf, lets not go off topic. The heavier parts might be a woke lvl 7 gamer idea. If it really improves the stability, release it so people test on a separate copy
The buggy spinners started midway through the fight, when nobody was even in the pit. I could still drive the robot fine. We got this to happen a second time, but nothing after that. We don’t have a consistent method of triggering the glitch. P2 was the main source of the problem. At some point the bar started teleporting off of the axle and was able to clip through the floor and other robots. The same thing happened to P1 later, but not quite to the same extent.
Here's the bot file for Infrared. I'm not sure what physics stats we were using though, as this was on Kix's computer.
I think I got it! When the last component is broken off an axle, the mass of the remaining axle is set to 0.000001 kg. I incorrectly determined what the "last component" meant. When the colored bars were broken off of Infrared, the game thought that they were the last component, and had set the mass remaining to 0.000001 kg. What you see in the video is the underlying steel bar that is teleporting all over the place because it has almost no inertia (mass). I fixed it in the system, and should have a new build up today.
For Infrared, I also noticed that the colored bars are attached directly to the axle and not to the underlying steel bar. This means that the colored bars will break off as a separate piece, kind of like a thin strip of plastic. The manual fix is to attach the colored pieces to the underlying steel bar and mark them as "decoration" material. I'm not sure if there is a way to automatically attach the entire strip to the underlying bar and mark them as "decoration".
Ok so we stumbled upon this. Something is wrong with collisions, also the fact that physics is unoptimised, casuing the whole match to run at low fps at 500tick (my cpu usage was at maybe 30%)
Just a quick update from me on the first pass of the new Arena handling system. The very basic framework for all the systems are in place now so soon enough you should be seeing all new arenas using the new system!
As I said before I am expecting the first internal release to be ready for February and have started on the documentation to help even Unity Novices get the most out of the tool, so hopefully the first public release won't be too far away (no promises though).
Alongside all this I've updated the UI for the arena selection in order to add in the ability to scroll through the list in preparation for the no doubt countless stages you guys will come up with!
>Looks at top secret. >Laughs in non-malicious intention
Show Posts
