Robot Rumble 2.0 - Robot Combat Simulator - Under Development

[WhamettNuht]

I would say the painter might be a good idea for a lot of this to be honest. I think it might help with a lot of the damage system woes at the moment as we won't have to worry about decals falling off ect. We can all appreciate it for the raw, solid parts that fall off.

Speaking of the damage system, to go with Badnik's idea, I was thinking about a 'Size threshold'? I dunno how it would work but as an example, a lot of detailing I do is making bolts with a half sphere scaled to -0.2, -0.1, -0.2. A lot of CC decals are set to 0.001 or 0.01 aswell. Would there be a way of telling the system to ignore parts under a certain size threshold and instead to only break off the parts they are connected to that are over this threshold? Just an idea!

Very happy to see an update though. The mirroring (from what I've briefly tried) is funky!

[CodeSilver23]

i feel like what needs to be done (if possible) is to find a certain energy threshold where damage will begin to occur. two robots bumping into each other at low speeds typically doesn't cause damage, and neither do many low-power attacks with weapons. if there's a way to make it so all damage calculated below this threshold is zero, i think that should be the way to go.

weapons shouldn't always cause damage because then a heavy bar dragging slowly across a chassis will do quite a lot more damage than in real life, and no one likes that.

Genius.

[cjbruce]

i feel like what needs to be done (if possible) is to find a certain energy threshold where damage will begin to occur. two robots bumping into each other at low speeds typically doesn't cause damage, and neither do many low-power attacks with weapons. if there's a way to make it so all damage calculated below this threshold is zero, i think that should be the way to go.

weapons shouldn't always cause damage because then a heavy bar dragging slowly across a chassis will do quite a lot more damage than in real life, and no one likes that.

I’m putting together a rough cut on this:

1. When takeDamage() is called, it has a short delay before it can be called again.
2. When takeDamage() is called, 1/2 of the component’s maxHealth is subtracted.  If this results in a negative number, then the damage is zero.
3. When takeDamage() is called, the damage is limited to a maximum of 0.34 x the maxHealth off the component.

All of the above means that it will take three good hits to break anything.

[cjbruce]

My Panic Attack has been functionally destroyed by this update.
The chassis turns into a janky mess when the bot is being simulated, and the weapons put a ridiculous amount of torque on the whole thing. It's so bad it can't even self-right.  [ Quoting of attachment images from other messages is not allowed ]  

If you want to compare it how it is now to how it's supposed to work, its fight with Flipster in the first Parsec Rumble 1.0 video is a good example.
(Just opening that bot file in an earlier version would kinda work, but I de-wheelfixed the weapons in the hope that it would at least fix the torque issue. It didn't.)

I think I have a good permanent fix for this.  I put each robot on its own layer.  Any parts on this layer can’t collide with each other.  I’ll try to get the fix out today or tomorrow.

[kix]

i feel like what needs to be done (if possible) is to find a certain energy threshold where damage will begin to occur. two robots bumping into each other at low speeds typically doesn't cause damage, and neither do many low-power attacks with weapons. if there's a way to make it so all damage calculated below this threshold is zero, i think that should be the way to go.

weapons shouldn't always cause damage because then a heavy bar dragging slowly across a chassis will do quite a lot more damage than in real life, and no one likes that.

I’m putting together a rough cut on this:

1. When takeDamage() is called, it has a short delay before it can be called again.
2. When takeDamage() is called, 1/2 of the component’s maxHealth is subtracted.  If this results in a negative number, then the damage is zero.
3. When takeDamage() is called, the damage is limited to a maximum of 0.34 x the maxHealth off the component.

All of the above means that it will take three good hits to break anything.

Anything else like small micro-bouncing that deteriorate component's hp by a tiny but continuous bit?
Also What i noticed, the fallen off parts are kinda like in slow mode, they actually can slow down a bot if they are on the wedge of the bot

[cjbruce]

I’m putting together a rough cut on this:

1. When takeDamage() is called, it has a short delay before it can be called again.
2. When takeDamage() is called, 1/2 of the component’s maxHealth is subtracted.  If this results in a negative number, then the damage is zero.
3. When takeDamage() is called, the damage is limited to a maximum of 0.34 x the maxHealth off the component.

All of the above means that it will take three good hits to break anything.

Anything else like small micro-bouncing that deteriorate component's hp by a tiny but continuous bit?
Also What i noticed, the fallen off parts are kinda like in slow mode, they actually can slow down a bot if they are on the wedge of the bot

#1 and #2 should take care of continuous bouncing damage.

Thanks for pointing out the slow motion of broken down objects.  I put in a speed limiter to prevent broken off parts from flying off at ridiculous speed as their colliders’ collisions are suddenly enabled while overlapping their original robot.  I should probably disable the speed limiter after a short period of time has passed.  Maybe 0.5 seconds or so will do the trick. 

[kix]

I’m putting together a rough cut on this:

1. When takeDamage() is called, it has a short delay before it can be called again.
2. When takeDamage() is called, 1/2 of the component’s maxHealth is subtracted.  If this results in a negative number, then the damage is zero.
3. When takeDamage() is called, the damage is limited to a maximum of 0.34 x the maxHealth off the component.

All of the above means that it will take three good hits to break anything.

Anything else like small micro-bouncing that deteriorate component's hp by a tiny but continuous bit?
Also What i noticed, the fallen off parts are kinda like in slow mode, they actually can slow down a bot if they are on the wedge of the bot

#1 and #2 should take care of continuous bouncing damage.

Thanks for pointing out the slow motion of broken down objects.  I put in a speed limiter to prevent broken off parts from flying off at ridiculous speed as their colliders’ collisions are suddenly enabled while overlapping their original robot.  I should probably disable the speed limiter after a short period of time has passed.  Maybe 0.5 seconds or so will do the trick. 

Yeah 0.5 secs will be good.
A question, why is damage multiplier locked? why cant we use a multiplier of 10%? Just wondering

[cjbruce]

Yeah 0.5 secs will be good.
A question, why is damage multiplier locked? why cant we use a multiplier of 10%? Just wondering

No reason in particular other than in the final game continuous sliders in settings can be a little weird.  I’m assuming that once everything is tweaked to the point where we are all happy we can just replace it with a button that says “Invulnerable Robots”.

[kix]

Yeah 0.5 secs will be good.
A question, why is damage multiplier locked? why cant we use a multiplier of 10%? Just wondering

No reason in particular other than in the final game continuous sliders in settings can be a little weird.  I’m assuming that once everything is tweaked to the point where we are all happy we can just replace it with a button that says “Invulnerable Robots”.

Yeah seems okay, i kinda do want to experiment with multiplier because for PR2.0 i want to have damage but not the one where everything will self ko easily

[CodeSilver23]

Issue: Gyro is a pain in the ass now.

[cjbruce]

New build is building right now.  While we wait:

[Bug Fix] Flames no longer do damage directly. Instead they add heat by calling the takeHeat() method. Eventually this will result in damage.

[Bug Fix] Self collisions are no longer possible for a robot. Self collisions were causing robots to randomly launch themselves around.  Each robot is now on its own separate collision layer.

[Bug Fix] The speed limiter for broken parts is now disabled after 0.5 seconds.

[Changed] The Damage Multiplier slider in settings now allows for continuous adjustment from 0% to 200%. [EDIT]

[Changed] Any time takeDamage() is called,

// Subtract 50% of the max health of the component from the damage.
// This should prevent any damage that is ridiculously small from accumulating.
// If the result is less than zero, set the damage to 0.0f.

[kix]

Thats grat, damage multiplier untouched i guess

[cjbruce]

Thats grat, damage multiplier untouched i guess

Fixed!  It is now a continuous slider.

[kix]

Thats grat, damage multiplier untouched i guess

Fixed!  It is now a continuous slider.

Ok my life is complete, i also guess forward heading might be borked

[CodeSilver23]

What about gyro?

[CyarSkirata]

I think I've figured out what visually broke on Panic Attack, with the chassis scaling.
There are weird seams on it, so I think what's happened is that the outer layer of the chassis scaled properly to 08/09/08, but the inner layer stayed at 1/1/1.

[cjbruce]

The 20December2019 build is up!

See previous for the bug fixes!

[CodeSilver23]

What about gyro?

What about gyro?

[kix]

What about gyro?

What about gyro?

Works fine for me

[kix]

Ok so a quick update: 10% damage is a godsend for me, maybe even 15, but im more comfortable with 10.
Note: The parts that are broken off still feel like they have moon gravity, and they still are immovable, tho its nice to jam up opponents weapons with shrapnel.