Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - cjbruce

Pages: 1 ... 9 10 11 12 13 14 15 [16] 17 18 19 20 21 22 23 ... 49
301
Just solved a lingering bug with spinners that caused the game to crash back to the main menu during a fight.  I don’t know how much of a problem it was for you guys but it was driving me nuts not being able to fight two spinners against each other.

I think that is the last of the crashing bugs.

302
Can you fix the telemetry?

I can try!  Can you point me to a few .RR2Bot files with the symptoms?  The more, the better!

303
The 17January2020 build is out:

https://robot-rumble.itch.io/builds

[Added] Added Hotkeys and Hotkeys selection screen in the Robot Workshop.  What hotkeys would you like to see to speed up your workflow?

[Bug Fix] Fixed the incorrect calculation of the location of the center of mass for components that are scaled in the workshop.  This was causing robots like S3 to tip over immediately, as well as the robot Rainbow Circus 2 to tip over once its shell had been removed.

[Bug Fix] Fixed a problem that would allow you to delete both mirrored components if one of the two was selected, but wouldn't allow it if the other was selected instead.

[Bug Fix] Once robots are Out Of The Arena (pitted or otherwise), the robot is marked as disabled and the control signals are automatically set to zero. This should prevent the crazy situation where spinning weapons still spun in the pit, turning the arena pit into a blender that kept throwing pieces everywhere.  See kix's video from a few posts back.

[Bug Fix] I had incorrectly assumed that only one object could be attached to an axle, and all other objects must then be attached to that. This resulted in me setting the mass of the entire rigidbody to 0.000001 kg even when there were other components still remaining. I now check to make sure all components are truly gone before setting the rigidbody mass to zero. This should fix the bar spinner teleportation on Infrared we saw in kix's video.

304
I was hoping to get an Alpha build out today. 

Right now I'm trying to track down a crashing bug that occasionally happens when Infrared and Circumvolution collide.  For some reason the 08January, 12January, and current builds crash to the Main Menu when the two robots collide in a certain way.  I haven't been able to replicate the crash in the Unity Editor, so I'm going to need to do some more digging...

305

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".

306
Thanks!  It is an ongoing effort by mostly GTM community members.

307
Cyar,

Thank you!  I'll take a look today.

308

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.

Would you mind sending the .RR2Bot files for P2 and P3?  I want to see if there is something weird going on...

309
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%)

I love it!  This is so great!

I'm probably suffering from "Developer Eyes Syndrome" and can't see everything that you guys see, but I see 2 things here that need fixing:

1. The spinners should have come to a stop.  Either or that or they should have broken off.  For whatever reason that didn't happen and the now-invisible blur cylinders were still spinning and working their magic.

2. The lag is due to the fact that there is a literal pile of colliders on top of each other, all interacting.  The only way to minimize this is to reduce the number of interacting colliders.

Have you guys found a reliable way to reproduce #1?  It looks like P2 and P3's spinners didn't come to a stop, even though they were out of the arena.  Is this correct?  Were the weapons still turned on for P2 and P3?

I think I have found and fixed the "Pit Blender" problem.  It turns out that when a robot is disabled, it would lose player input and maintain the existing state of the control signals.  Super scary when this happens in a real-life competition -- you have to wait until the batteries die on the robot.

In any case, this will be fixed in the next release.

310
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%)

I love it!  This is so great!

I'm probably suffering from "Developer Eyes Syndrome" and can't see everything that you guys see, but I see 2 things here that need fixing:

1. The spinners should have come to a stop.  Either or that or they should have broken off.  For whatever reason that didn't happen and the now-invisible blur cylinders were still spinning and working their magic.

2. The lag is due to the fact that there is a literal pile of colliders on top of each other, all interacting.  The only way to minimize this is to reduce the number of interacting colliders.

Have you guys found a reliable way to reproduce #1?  It looks like P2 and P3's spinners didn't come to a stop, even though they were out of the arena.  Is this correct?  Were the weapons still turned on for P2 and P3?

311
I've just done some testing with a crusher, and I can confirm that gearing anything down further than a total of about 100/1 results in the entire robot being incapable of rotating faster in battle (not in the test area) than the speed of the geared object itself.

Would you mind sending an .RR2Bot file, or is it possible to replicate this with Panic Attack?

Edit: Panic Attack is really difficult to edit because the robot is so dense.  Could you send an .RR2Bot file that shows the problem?

312
I can’t wait to see the level editor!  So cool!

313
And about breakable armor plates, can’t you just treat the plates as components?

The chassis is special because it is the only component with separate armor plates.  It will need its own special set of rules for breakage.  Next week! :)

314
The spark slider didn't make it into today's Alpha build (coming soon!), but please remind me when I get back from my game dev hiatus next week!

The 12January2020 Alpha Build is up on itch.io:


https://robot-rumble.itch.io/builds


Here's what I have for the Alpha Build.  Basically it incorporates all the changes in the past few day's worth of Bleeding Edge Builds.  I also fixed the banging arena auger:

[Updates in the January 12th Build]

[Changed] Changed the arena floor material to "Steel".   This increases the traction of most robots.

[Added] Added sliders for physics tick rate. This can be used to tweak physics smoothness versus game frame rate.​  High end machines can support smooth play at 500 physics ticks per second.  Low end machines might need to reduce this to 100 physics ticks per second.

[Added] Added a Physics Mass Wheel Ratio Slider.  Default Wheel Mass Ratio is now set at 10%.​​  This is going to be using for testing driving behavior on a wide variety of robots.​

[Bug Fix] Fixed bug where spinner mass was still very large when all parts were broken off an axle. This was causing gyro dancing and uncontrolled behavior for many robots.  Now the mass is reduced to a very small amount. 

[Bug Fix] Raised height of Arena Auger so it didn't continuously bash itself into the floor, causing a continuous loud "bang" "bang" "bang" sound.​

315
EDIT: Can we get an sparks slider? Atm I kinda miss the sparks on low impact.

Yeah baby! :)

Sparks are so satisfying!  I know they aren't always realistic, but stupid and over the top are what we live for in robot combat!

316
I think the cool spinning axle is causing the glitching.

Sort of.  The root cause was the fact that the axle masses were outrageously high (4kg, making each wheel about 10% of the mass of the chassis) and spinning.  If the axle mass wasn't so high then when the wheel broke off the resulting mass would have been so small that the spinning axle wouldn't have created gyro dancing issues.

I think we might need the axle masses to be unrealistically large, but I can't be sure until we have had a chance to test different values on lots of different robots to see if it affects drivability.  Unity recommends that the mass ratio between two jointed rigidbodies not exceed 10:1.  If the wheel/axle combination is smaller than what Unity suggests that the resulting simulation might get unstable.  I put in a new physics slider on the next build to test this out.

For now, lets test to see if we need the extra axle mass.  Set the slider all the way to 1% and see if robots still drive okay.  If so then we can set the axle masses to more realistic values (around 1 kg for an Ampflow A40-300).

317
But then you don’t get the cool spinning axle with nothing on it!  :smile:

You might be right.  Lets see how this feels.  If we don’t like it we can always change it.

318
I tried the circus bot again, but this time multiple in the arena at once.
So, 4 was the engine wanting to commit suicide. 3 went well until collision; then the frames drop. 2 was fine. Frame drops only happens when components went clipping into each other.
This is run on the bleeding edge released today.

Excellent.  This helps bracket the problem down.  I would like to get the game to the point where it defaults to 300 physics ticks per second and runs at 60 fps on a  midrange laptop with 4 AI driven opponents with 50 colliders each.  It is going to take a lot of optimizing to get there, but I think it is possible.

Unrelated but something that has also been a thing. AI on own robots being reset to the default of the game after installing a new version of the game (drag & drop over the previous version). This is a bit annoying since some of my bots just no long use their hammer or flipper until I give them their AI again.

Ah yes.  The AI rewrite.  It will happen, I promise!  Right now the AI system is just as bad as physics.  It takes just as much CPU time.  That is my fault, and I intend to fix it.  The fix will include reimagining how AI is saved and loaded.

319
The problem with the gyrodancing didn't go away. I'm thinking that if the motors stopped after a wheel is torn off, then the glitch will be fixed.
EDIT: The problem is fixed, apparently I mistook the gyro created by the wheels for the glitch.

Awesome!  There is still pretty significant gyro caused by the remaining wheel due to the extra 4 kg mass added by the remaining wheel's axle.

I'm thinking maybe we need another slider to play around with the ratio of wheel mass / chassis mass.  Currently, with the extra 4 kg added to the axle, wheel mass is between 4-5% of chassis mass.

My hypothesis is that as you raise the percentage of wheel mass to chassis mass:

Pros: Joint stiffness would increase, reducing the annoying bounciness of wheels.
Cons:  Wheel gyroscopic effects would also increase, throwing the robot out of balance and potentially causing it to gyro dance on its side once the wheel gets going fast enough.

Only one way to find out.  Its slider time!!! :)

320
The new 12January2020 bleeding edge build is up.  This one sets the mass of the remaining axles when everything else is broken off to 0.00001 kg.

http://www.robot-rumble.com/bleedingedgebuilds/

I need to switch over to contract work to make money for the company this week.  I would like to use this build as an Alpha.  Please let me know if this is good enough to play with for a while! :)

Pages: 1 ... 9 10 11 12 13 14 15 [16] 17 18 19 20 21 22 23 ... 49