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 ... 11 12 13 14 15 16 17 [18] 19 20 21 22 23 24 25 ... 49
341
Building the "Steel" (instead of "Metal") floor build now.  I should have it up within the next few hours on /bleedingedgebuilds.

342
see some minor improvements, but noting really that stopped jittering completely
It does seem like the wheels have no traction and they jitter because of that. Now gearing down could help, but that also means that its gonna be way slower and more terrible to drive.

I will say it again. The pit lit part of the arena is the only part where you can drive the bots on, and they wouldnt jitter

You are right!  The arena floor was set to generic "Metal", while the pit is "Steel".  The only difference between the two materials is that "Metal" was set to use the minimum friction coefficient of the material, while "Steel" used the average.

I'm not seeing a difference in the jittering (which doesn't appear too bad on my computer), but am seeing a noticeable difference in traction.  Beta definitely has more traction with the Steel floor.  Maybe we need a "friction" slider in the physics tab?  :bigsmile:

I should have a bleeding edge build up with the change in the next 10 hours...


343
kix,

I just posted a new 09January bleeding edge build.  I think this one fixes the jitter for Beta.  All I did was changed the Default Velocity Solver Iterations in Physics Settings from 4 to 10.  Let me know what you think!

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

344
Speaking about hammers, I tried to make a sawbot and this happened:
  [ Quoting of attachment images from other messages is not allowed ]
Could you please fix it?
Saws dont work. Idk when will the official fix happen, but atm a "fix" would be to attach the saw on a wheel

Hmm.  I hadn’t really thought about saws.  For now can you designate a small piece of the arm as “rubber” to prevent the generation of a blur cylinder on the arm?  Once this is done the saw itself can be built as normal.

Edit - Sawbots work fine.  They just follow the spinner rules, which means they don't really "saw" so much as "hit".

Edit #2 - I just noticed that telemetry isn't coming through properly for the spinner.  This is my first go at an overhead saw on an arm and I need to do a little digging to figure out why the telemetry isn't coming through correctly.  I did get the spinner up to speed and it sent one of the orange cones flying.  I haven't checked to see if it is doing damage correctly yet.

Here's Beta modified as a sawbot:


345
kix,

I spoke too soon.  I just tried increasing the Physics Velocity Solver Iteration Count from 4 to 10.  I'm seeing a small increase in CPU usage, and the jittering has mostly stopped.  I'll try to get this out to you for testing tomorrow.

346
kix,

I tried lowering Beta by lifting the wheels up 5 mm.  Sure enough, the bouncing stopped.  The issue is that the wheel joints have more compliance than they do in real life.  In the game, putting 50 kg or so sideways on the joint pushes the axle about 1 cm.  In real life the defection would be more like 0.001 cm.  To resolve this, the physics system overshoots slightly, causing a bounce effect.

Lowering the robot isn't a good solution, however, as it has the side effect of reducing the robots traction.  The lowered version of the robot accelerates significantly more slowly than the version you sent to me.

Unfortunately, I don't have a really good way to deal with this short of creating a "Magic Movement" system like exists in RA2 and RA3.  I really really don't want to do that.  I tried, and still have the code in place, but it completely changes the way robots drive. It complicates everything from driving to handling to weapons to component breakage.  I can try tweaking friction coefficient and the spring constant for the joints, but I don't know how far I can go without throwing off all other motion-related things in the game.


347
We might be bumping up against a limitation of the physics engine.  The tradeoff seems to be between having spinners that feel nice and weighty, but are unstable, vs spinners that spin reliably without issues but don't have the gyroscopic effects.  We can always increase the "kick" when it hits something, so maybe it is a tradeoff we can live with?
I'm for unstable spinners, because they are more realistic.

The good:

I love the fact that we get crab walking and gyroscopic tilt for free as a result of the simulation.

The bad:

I hate the fact that spinners automatically unbalance themselves because of rounding errors.  Even if a spinner is perfectly balanced, if angular momentum gets too high a spinner will teleport from place to place as the restoring impulse overshoots every tick.

My challenge is that I would like to keep the good stuff but get rid of the bad stuff.  In Roller's case, the moment you turn on the spinner the robot starts hopping around.


348
I'm getting increasingly suspicious that Mac and PC simulate the game completely differently.
The problem I have is that even without turning on the weapons of Roller or un-fixed Panic Attack, they just can't steer well enough to so much as manoeuvre around the arena.

It is possible, though I suspect that it might be more related to CPU/GPU load than PC vs Mac.

On my computer if I keep Roller's weapon off I can drive around slowly.  It skids around more than I would like, but it is okay.  It gets all bumpy within a second after I turn on the weapon.

Both versions of Panic Attack that you sent me drive perfectly fine.  A little slow, but they are big robots.

The version of Mental Breakdown that kix sent me a while ago drives like an absolutely maniac.  Super-maneuverable.  It overshoots like crazy when the computer AI is driving.

349
So it appears that once angular momentum gets over approximately 2 kg * m^2 / second, things get wonky.  I've confirmed this on Mental Breakdown and Roller.  Mental Breakdown tops out at around 5, and Roller tops out at around 7.  It looks like I need to enforce mass reduction to make sure these levels aren't reached.

350
CyarSkirata,

I just had a look at Roller.  I think it is having problems with having so much mass being off-center from the robot.  I suspect that small rounding errors are throwing it off balance which cause the entire robot to wobble and shake.  The problem went away as I reduced the mass of the spinner below 10%.

We might be bumping up against a limitation of the physics engine.  The tradeoff seems to be between having spinners that feel nice and weighty, but are unstable, vs spinners that spin reliably without issues but don't have the gyroscopic effects.  We can always increase the "kick" when it hits something, so maybe it is a tradeoff we can live with?

351
I noticed this glitch in the 03January build:

EDIT: The robot that is gyrodancing has no spinning weapons.

By any chance is this working correctly in the 08January build?

352
Damage is at 50
Pushout is 0
Impulse is 100
Minimum mass is 50
That's the best way I could get all of my non-bugged spinners to be at least be useable, since they're mostly at extremes one way or the other.

As for the speed thing, the problem for me is with Circumvolution. 16kg flywheel, does less than 2000 RPM, but it's got such a large diameter that the teeth do 152mph. The way it's built they have no problems engaging with the target bot, but they just don't seem to impart much energy despite the whole wheel stopping.
I occasionally get a good throw, but mostly it just does little bounces. And where it used to lever the robot forward as it accelerated, it just doesn't now.

Have you tried 100% pushout? I'm a little uncomfortable setting it to 0%, for fear that we might have the situation where 2 spinners get locked inside each other.  Then again, that is unlikely as long as we keep the bite threshold low.  The "Good Hit" threshold is currently set to bite > 1 mm.

I haven't mentioned it before, but I have been tweaking one more number.  It represents how quickly the minimum mass is reached.  In the 2019 builds a 1000 RPM spinner would have 50% of its original mass.  In the 08January2020 build, a 200 RPM spinner would have 50% of its original mass.  I suspect the quicker mass drop is what is causing Circumvolution to no longer lever the robot forward upon sudden acceleration.

353
Okay, so... In this build, my verts work quite well, but there are issues. Note, this is with the sliders set to what feels like the best middle ground for my bots.

Awesome!  What are your slider settings?

Circumvolution seems to have too little gyro (large lightweight flywheel), I have a 30kg drum that seems to restrict its bot's mobility a tad too much, and smaller lighter drums seem too fragile.

Ugh.  High speed is the bane of the physics simulation.  The faster the things spin the more cheating (mass drop) we have to do, and the larger the discrepancy between robots.

Then of course there's Roller, which along with un-wheelfixed Panic Attack still has crippling problems even when idle.

I will take a look at Roller again.  It might be that the robot is so old that it is beyond fixing...

Front and overhead horizontals seem better than they have been, but... maybe a little too hindered for mobility.

My shell and ring do better in this build than a lot of previous ones. They feel about right at the moment, the weapons being powerful but still as vulnerable as they should be to being rushed.

Woohoo!  Physics for the win!

On the whole, impact seems pretty good for heavier weapons, but I feel like speed isn't imparting as much energy as it really should compared to mass, making the heavier spinners objectively better right now than the faster ones.

My first guess is that this is related to spinner bite.  Fast spinners suffer from bite problems, and you really have to drive fast at an opponent to get a good bite.  That being said, spinners need to feel good in the game regardless of what spinners are like in real life.

On a side note: when Wheely Big Cheese is inverted and fires its flipper, it launches itself close to three metres into the air. I'm wondering if this has to do with its wheels (which for authenticity and balance I never wheelfixed) being made lighter?

I'm not sure.  The makeup mass added to the chassis should offset the light wheels.  However, we are working within the limitations of a discrete physics engine at 200 ticks per second.  This can create weird interactions between rigidbodies.  I.e. For an inverted robot the chassis pushes the wheels up, then a short time later the wheels pull the chassis up.  If you have a chain of more than 2 rigidbodies (srimech -> chassis -> wheels) stacked on top of each other this whole process can get really wonky with large impulses.

354
ok driving is still an issue:

This one looks like the wheel joints aren’t stiff enough to hold up the robot.  Not sure what the fix is, but I would need to play with it.
This is what we refer to when the bots bounce. Way early builds didnt have the issue at all.

Gotcha!  I thought the bouncing problem was related to vertical spinners.

Would you mind sending me that .RR2Bot file?  I don't have any similar robots to test with.

355
Great feedback here!

By any chance are you using settings similar to kix?  I would like to settle on some values for these things so we can move on to other stuff.

Also, would someone mind asking the rest of the folks on Discord?  More opinions = better.

356
Badger, welcome back!

  Sorry about that!  I suspect that you have some old .RR2Bot files that the newer versions of the game can’t load.  I like the idea of clearing out the app data folder.

357
ok driving is still an issue:

This one looks like the wheel joints aren’t stiff enough to hold up the robot.  Not sure what the fix is, but I would need to play with it.

358
The 08January2020 build is up!

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

359
Stuff in the 08January2020 Build:

[Bug Fix] Disabled the extra gravitational torque added to spinners. This was originally added to compensate for the weight reduction that happened as spinners gained speed. Now that Makeup Mass is a thing, it is doubling the effective weight of the spinner and shifting the center of gravity so that wheel grip is adversely affected.

[Tweaked] Reduced duration of sparks to a single hit.

[Changed] Sparks are only emitted on glancing blows.

[Changed] Restored spinner collision impulse response to its previous value, 100% conversion of angular momentum into linear momentum. The only exception to this is when a part breaks off, in which case the linear impulse is dependent on how much energy is lost.

[Added] Clamped spinner mass reduction factor: massReductionFactor = Mathf.Clamp(RPMsPerMassReduction / currentRPM, minimumMassReduction, 1.0f);

[Added] Set default minimum mass reduction to 10%.

[Added] Sliders and settings support for "Spinner Pushout", "Spinner Impulse", and "Minimum Spinner Mass". This should allow playtesters to tweak the settings for driving and impact feel.

Spinner Pushout: This is the amount of radial impulse (push) applied when the spinner blur cylinder (no longer visible) overlaps something.  A big value pushes the spinner and the object apart more violently.

Spinner Impulse: This is the amount of tangential impulse (kick) applied when the spinner blur cylinder overlaps something.  A big value kicks the target forward and spinner backward.

Minimum Spinner Mass: This is the minimum percentage of mass a spinner can be reduced to.  Larger values increase gyroscopic effects.  Too much gyroscopic effects make robots unstable.  Please note that this instability is due to the limitations of a computer's physics engine.  In real life gyroscopic effects tend to make things more stable.

360
Shoot!  Sorry about that.  I have a new build coming soon.  It has 3 new physics sliders.  These are going to be temporary.  Once we have tested driving and impacts on a bunch of different robots I am planning on removing the sliders.  Or swapping them out for something else.  Like damage effects. :)


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