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 [2] 3 4 5 6 7 8 9 ... 49
21
We do.  We just started using Discord last week and it has been great so far.

22
Thank you!  I get it about burnout.  How would you guys feel about a parsec tournament with the developers?  We could come up with a list of improvements while we are at it.

23
There's a thing I've noticed is the fight is even easier to get crashed.

Drat.  Can you show me how to replicate it?

24
This build is intended to be the summer tournament build.  CodeSilver, kix, would you mind taking a look at it with an eye for how it will play on Parsec/online?

After this build we are going back into development and adding new features and breaking things. :)

25
The final(???) bleeding edge build is out before the next Alpha:

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

This one has quite a few changes, mostly to support particles when you hit things with a spinner.  There are a few performance and stability improvements as well.

[Added] Sparks now occur for hits on Steel, Hardox, and Titanium.

[Added] Shard particles now occur for Wood, Plastic, and Metal.

[Added] Spark and shard particles vary depending on whether the hit was a glancing blow or a solid hit.

[Added] Added UTS for all materials. This is only used for bite. Hard materials are easier to bite. UHMW is very difficult to bite into.

[Added] Spinner hits discriminate between "Good Hit" and "Glancing Blow". Good hits push target in direction of spinner. Glancing blows push robots directly apart. [TODO] This will need testing and tweaking for all softer materials. Right now it is likely that small, fast drum spinners will not be able to damage UHMW at all. [TODO] Damage has not been implemented.

[Changed] Rewritten the Armour Materials List into a more logical order.

[Added] New armours: Cardboard, MDF, HDPE, Carbon Fiber, Expanded Steel, Decoration - Vinyl, Decoration - Faux Fur, Blueprint

[Tweaked] Reduced the default ambient temperature of all motors to 21 degrees. It was previous set for 40 degrees for testing purposes. 21 degrees matches the temperature of most indoor arenas. The reduction in ambient temperature will increase the heat dissipation of motors.

[Bug Fix] Titanium now has the correct density (4500 kg / m^3).  It was previously set to be denser than steel.

[Added] "Remove Plate" material now works!  If you add the "Remove Plate" material to a plate, its collider is removed.  You can now make slots in your chassis.

[Added] Colliders are automatically disabled for certain armors.  These include "Decoration", "Remove Plate", "Vinyl", "Faux Fur", and "Blueprint".  If you set objects to have these materials, everything will pass right through them.  This reduces the physics CPU load significantly for highly decorated robots.

[Changed] Small performance improvements done to the botlab highlight system.  The highlighter is now cleaner looking and more performant. 

[Changed] Check out the cool blue chassis builder!  This was a side benefit of the new shader we are using in the botlab.

[Bug Fix] Fixed a bug where not all of the child colliders in a spinner were being disabled. This was causing problems with some weapons, leading to some spinners being out of balance and not able to get up to speed.

[Tweaked] Default Physics Tick Rate is now set to 300 ticks/second instead. This is based on the game needing to support 8000+ RPM spinners.  The faster you set the tick rate, the higher speed the game will allow spinners to go.  The cost is that high physics tick rates are significantly more demanding on your CPU.  My MacBook Pro can only handle around 300 ticks/second in an AI battle.

[Bug Fix] Motor max RPM is now limited by the physics tick rate in GameSettings. The formula is max RPM = 27 x physics tick rate. This completely prevents the instability that occurs when RPM = 30 x tick rate.  NOTE - This means you need a fast computer to run a 14,000 RPM beetleweight spinner!

[Added] Added warning in spinner telemetry if spinner speed is too fast for the physics tick rate.


26
Part of our target audience is school computer labs and laptops.  With the optimizations in the newest build my Macbook Pro can handle it.  I need to test out school Windows 10 laptops.

We are putting the game on our local community college computers in a few weeks. I’ll know more then...

27
Eureka!  The instability occurred because Physics Tick Rate was set at 100 ticks/second.

So:

100 ticks/sec = spinners break at 3000 RPM
200 ticks/sec = spinners break at 6000 RPM
300 ticks/sec = spinners break at 9000 RPM
400 ticks/sec = spinners break at 12,000 RPM
500 ticks/sec = spinners break at 15,000 RPM

Edit:  I suppose we need to design the game so it runs well at 300 ticks/second.  The right answer is probably still to limit the actual RPM to 2500 or so, then fake it above that value.  Things that would need to be faked:

RPM
kinetic energy
angular momentum
motor back EMF / back torque
air drag

It is ironic to me that in order to run the game so that it will handle the cheapest spinner robots (beetleweight spinners at 15,000 RPM), you have to have a more expensive CPU.

28
kix,
I have been fighting with stability for Green Banana’s 7000 RPM spinner.  I can’t get it to remain stable.  I’m at my wits end, and suspect that I might need to make some drastic changes to spinner physics to make it work.

Ugh.

Edit: min's Poison Arrow is mostly stable.  It has a lot of gyro lift, but it doesn't self-destruct like Green Banana.  As far as I can tell, the biggest difference is that Green Banana has a very small spinner.  Poison Arrow has a wide drum.  Two thoughts:

1. It takes less radial force to apply a stabilizing torque to a wider drum.

...or...

2. Things are wonky because 3000 RPM coincides with 50 revolutions per second.  At a 100 fps physics tick rate that means that the spinner rotates 180 degrees, computes physics collisions and restoring forces, rotates 180 degrees, computes physics collisions and restoring forces, etc...  At 3000 RPM, the physics forces are always one direction, then 180 degrees opposite, then back to the original direction.  This is the perfect recipe for resonance and exploding spinners.  It is even worse at 6000 RPM.  At this speed the weapon is always in exactly the same position, but with a massive speed.  This means it is always going to experience a huge force in one direction.

To permanently fix the problem I suspect that I will have to somehow keep the real speed of the spinner below 2500 RPM or so, while having a "virtual speed" that goes higher.  It is a mess conceptually.  It breaks physics.  I don't like it.  Agh.

29
WhamettNuht has been busy making particle effects for everything.  The goal is to clearly communicate the distinction between a glancing blow and a good hit.  I can’t wait to show you guys!

30
Spinners rip right through soft materials, scraping them up but never grabbing hold.  UHMW would have fewer hit points, but you need to take a deeper bite to get a good hit.

31
“Good Hits” haven’t been released yet.  They will be coming in the next build.

32
Somewhere in the range of 8:1 to 12:1.

I think I'm okay with slower driving.  I'm old. :)

Also, I didn't mention it before, but temperatures will be higher in this build.  I increased the room temperature to 40 degrees. I simultaneously increased the temperature limit of the windings to 155.  You should have a lot more room before your windings overheat.
Ya it should be. As spinner bites became a thing, everytime a spinner hits the floor the temp gets much higher. Especially for verts, sometimes a vert has to hit the floor over 5 times to self-right, although those are small bites, the temp goes up pretty fast. Not sure if it's a thing but I'll just post it here.


95 degrees is 60 degrees away from the limit.  That is pretty typical for most motors nowadays.  It should be fine, unless you are seeing smoke...

33
kix, I'm testing now with Green Banana and Bloodspill.  It is a really good combination of robots and has allowed me to focus on how two robots should behave when they hit each other. 

Some numbers:

A "satisfying" collision impulse for these two robots is somewhere between 50-80 Newton-seconds.  A weak impulse is around 10 Newton-seconds.  Above 120 Newton-seconds and the two robots go careening around the arena uncontrollably/unrealistically.

Our sweet spot for satisfying hits is around 60 Newton-seconds.

The problem was how to visually distinguish between "good hits" and "glancing blows".  If they both look the same, players won't know when they have really connected vs just scraping up some armor ineffectually.  I think I've hit upon a difference:

Good hit = robots get pushed away in the direction of the spin

Glancing blow = robots get pushed away from each other radially

All hits can now involve around 60 Newton-seconds of impulse, enough to be satisfying but not enough to break the game.  Glancing blows will be better for self-righting a vertical spinner.  Good hits will cause damage.

34
Somewhere in the range of 8:1 to 12:1.

I think I'm okay with slower driving.  I'm old. :)

Also, I didn't mention it before, but temperatures will be higher in this build.  I increased the room temperature to 40 degrees. I simultaneously increased the temperature limit of the windings to 155.  You should have a lot more room before your windings overheat.

35
I just tried Aftershock.  The 10S you are using is pretty high for drive.  According to the Robot Wars wiki Aftershock uses 6S for drive.  I wouldn't be surprised if you had overheating problems.

I swapped out the 10S for 6S, and it drives okay.  I tried messing with the gear ratio a bit, and I'm mostly happy with it.

I'm also really curious to see how it drives using analog sticks on a game controller rather than a keyboard.

36
New bleeding edge build is out (29May2020):

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

Updates:

[Added] Added Ultimate Tensile Strength (UTS) to ArmourMaterial. This is a material property that can be found online for any given material. It will be used together with the spinner's current KE to determine the amount of bite required for a "good hit".  The idea is that harder armors require less bite.  You would have to bite really deeply into UHMW in order to get a good hit.

[Changed] Revised the motor thermal model to make overheating less likely. All motors in the game are now assumed to use NEMA Class F silicone insulation in their windings, rated to 155 degrees.  This is based on testing with my Tombclone and the ME0708. The electrical system now includes both temperature-dependent and temperature-independent resistance. This paves the way for a more complete electrical model of the battery, ESC, and connecting wiring.

[Temporarily Removed] Good Hits - Right now all hits in SpinnerCollisionHandler.cs are hard-coded to be glancing blows. Glancing blows need to be calibrated first. Then good hits. Then code needs to be implemented to distinguish between the two. NOTE - The mathematical framework for determining the difference between a glancing blow and a good hit is already in place. Hopefully it will be ready to go in the next commit or so.

[Bug Fix] Angular momentum and moment of inertia were incorrectly reported after the MOI adjustment implemented in the most recent build. This drastically reduced the amount of impulse applied to the two objects when a spinner hit.  Min and kix, I believe this was the cause of the "weakened hits".  They should be restored to more than their previous amount of oomph.  I will be adjusting them again now that there is a plan for spinner bite.

[Bug Fix] Updated telemetry for spinners to eliminate instances of infinity and NaN. Now things should correctly display with their actual values and update to zero when the motor is destroyed.

[Tweaked] Increased speed at which high speed spinner collider becomes active to 300 RPM (5 revolutions per second). Hopefully this eliminates the problem min was seeing with his robot.

[Bug Fix] Ready button not appearing in Test Arena

[Bug Fix] Main Menu button not working in Test Arena

[Bug Fix] Slider Values in setting menu not updating

[Bug Fix] Settings not saving in Main Menu

[CHANGE] Updated Workshop to use new settings menu

[CHANGE] Slider Values now display whole numbers only

[Bug Fix] Aspect Ratio mismatch to Resoution

[Bug Fix] Resolution being downscaled on scene transition

[CHANGE] Only allow 16:9 Resolutions (for now)

37
Crashes?  Uhoh!  Where are crashes occurring?  Can you replicate them reliably?

38
Hits are coming soon!

This morning I scratched out a strategy/math for computing the required amount of bite at a given speed.  Shower = less bite required for a good hit, also more bite

As the weapon spins up, a deeper bite is required, but less bite will be available.

Beyond a certain critical RPM and forward speed it will be impossible to bite and the weapon will not do any damage.

39
Was still playing May 26th and found something interesting.
  [ Quoting of attachment images from other messages is not allowed ]  

This is an interesting case.  I had assumed that anything that doesn't have limits would be a spinner and would get a high speed spinner collider.

I need to think about how to handle this case.  Maybe increase the speed at which the high speed collider becomes active...

40
No worries!  You definitely have given me a few more things to chew on.  There is no thermal or electrical model for the battery or ESC.  I need to decide how far to go with this before it isn’t fun.

The Maytech motors are so tiny!  Wow!

Pages: 1 [2] 3 4 5 6 7 8 9 ... 49