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 ... 40
1
ya but can you sload in this game

Pardon my ignorance, but what does it mean to “sload”?

Boomer ra2 term that is obsolete and not useful


bruh rude

I am curious what it meant though.  I assume from the context that it was something people did to improve the game. 

Even though the act of "sloading" might not be relevant to RR2, it is helpful for me to understand what the original problem was that people were trying to solve.

2
A problem I’ve run into while building is that the 3-inch wheels have almost no health (0.05 hp). This makes it extremely difficult to make low or smaller robots, since the wheels come off at the slightest touch. The 4-inch wheels have hundreds of times more health than the 3-inch and can withstand a much more realistic amount of hits, so I’m not sure if this lack of HP is intentional or not.

That is intentional.  The 3 inch wheels were meant as temporary stand-ins for the foam wheels used in US antweight kits like the Fingertech Viper.  They weigh almost nothing.  If you wanted to use one with an actual heavyweight, it would just be a foam decoration, completely ripping off at the slightest touch.

3
We would need to figure out the UI for parallel vs series batteries.  For example, if someone were using LiPo batteries and wanted 33.3 volts with enough capacity to last the match, they might want:

9S / 4P

That means a total of 36 cells to get the required voltage and Amp-Hour capacity.  Oof.  We are going to have to think about how the UI is going to work for this...

For reference, we will need to build something like the Team Tentacle Amp-Hour calculator into the game:

http://runamok.tech/squid/newtorquecalc.htm

4
I'm thinking that the right way to do this might be something like the following:

1. A user picks and places their motors.
2. A little table appears in the upper left corner containing all of the electronics that need to be placed.  If it has been placed already it should be grayed out.

For example, a robot like Tombstone with 2 drive motors and 1 weapon motor would have the following:

1. The user places the two drive motors (2 x A40-300) and the weapon motor (1 x ME0708).
2. The table in the upper left would include the following components:

Battery Pack (24 volts minimum)
1 x power switch
1 x radio receiver
3 x high power Electronic Speed Controllers

Once all of the necessary electronic components are place, the "TEST" button would light up.

EDIT - PS, for those of you how know Tombstone, it doesn't actually use a speed controller for the weapon motor.  It uses a high current relay instead.  Every time they tried to run the motor with a speed controller it fried the speed controller right away.  I think Ray Billings might have mentioned something like 1800 Amps of current were drawn when the motor started.

5
I was actually thinking of the Speed Controller. Afterall, that is the main central hub where all of the robot is connected to. If that goes, then all motors, batteries, and receivers have nothing to feed off of.

Ahh.  I see.  We use separate speed controllers for each motor on our robots.  We can combine speed controllers, but the maximum I am familiar with are 3-channel speed controllers.  This would work for three motors, but many designs use more than three motors.

6
I think he meant cb just for simplicity's sake, the distribution system got me thinking. I assume that we will be able to power individual motors with individual receivers, and batteries, so if a weapon battery bursts and eventually dies, the weapon will just stop functioning, same goes with receiver

A typical electronics setup would be
Radio transmitter-> radio receiver

Motors are not powered by the receiver.  They are powered by speed controllers (ESCs).  The speed controllers for each motor get power from a single battery system, and a control signal from the radio receiver. 

If you knock out the radio receiver, the robot shuts down.  If you knock out power, the robot shuts down.  If you knock out anything else, you will only disable one motor.

7
I haven't gotten there yet, but I'm thinking axe damage might have to be based on impulse.  Axes have maybe 1% of the KE of a spinner.
Yeah well considering that axes mostly do internal damage and mostly dent armor in, maybe that could be taken into consideration?

I was going to email about this, but might aswell mention it here haha!

I was thinking robot health should now be determined by the health of the control board. Obviously once armour panels have been knocked off, any direct hits would cause massive damage and immobilize a robot instantly (therefore giving crushers/axes/spikes/drills a fighting chance) but I thought this could then be worked around by players just hoarding a bunch of armour shapes around their control boards (which I know isn't unusual for real life robots, but even so). So on top of damage health, what about 'Impact' health? The more velocity & KJ's a control board is put under from impacts according to the parts around it, the more damage it takes? Therefore flippers, hammers, rammers, ect. also have a fighting chance.

And of course heat damage from any flamethrowers/CO2 vents ;)

If we still want to get rid of the health bars aswell, we could always do a variation of the LED component which changes colour/flashes according to the control boards health? (So Green=Good health, Amber=Sustained Damage, Red=Low Health, Flashing Red=Health Warning, Off=Robot immobilized). It wouldn't be too dissimilar to how robots IRL require power LED's.

Maybe it is just semantics, but robots don’t typically have a “control board”.  Do you mean the radio receiver?  This is and the battery/electrical distribution system would be the single points of failure in our robots,

8
I’m getting happy with spinner vs spinner damage now.  Circumvolution wins unless Tombclone takes off its wheels.

9
Parts can still break off.  This includes the spinner itself.

My plan for spinners is that upon a hit, both the spinner and the target take damage.

If the target is invulnerable, then all of the damage goes to the spinner.

Otherwise, damage will be distributed based on the current health of the spinner and the target.  If the spinner has more health than the target, then the target will take a larger fraction of the energy as damage.  The opposite is also true.  If the spinner has very little health, it will take most of the damage and will very likely break off.

Here's what I have:

float selfRatio = target.health / (selfDO.health + target.health);
                float targetRatio = selfDO.health / (selfDO.health + target.health);
                float selfActualDamage = selfDO.takeDamage(damage * selfRatio);
                float targetActualDamage = target.takeDamage(damage * targetRatio);

In practice the above damage model is pretty terrible.  A big heavy spinner will absolutely dominate a spinner made out of smaller pieces without taking any damage itself. 

My Tombclone is just mercilessly destroying Circumvolution.  I don't like that.  I want to reward people for building beautiful creations that work well, not the big dumb box with ton o' health.

Back to the drawing board...

10
I haven't gotten there yet, but I'm thinking axe damage might have to be based on impulse.  Axes have maybe 1% of the KE of a spinner.

11
ya but can you sload in this game

Pardon my ignorance, but what does it mean to “sload”?

12
Parts can still break off.  This includes the spinner itself.

My plan for spinners is that upon a hit, both the spinner and the target take damage.

If the target is invulnerable, then all of the damage goes to the spinner.

Otherwise, damage will be distributed based on the current health of the spinner and the target.  If the spinner has more health than the target, then the target will take a larger fraction of the energy as damage.  The opposite is also true.  If the spinner has very little health, it will take most of the damage and will very likely break off.

Here's what I have:

float selfRatio = target.health / (selfDO.health + target.health);
                float targetRatio = selfDO.health / (selfDO.health + target.health);
                float selfActualDamage = selfDO.takeDamage(damage * selfRatio);
                float targetActualDamage = target.takeDamage(damage * targetRatio);


13
Ok so i did some testing

so the bots can spin up to 346mph then the bot lifts off like a plane and the disc gets bent

Underneath, this bot can technically reach 450mph, however the game just does its thing

Might test damage at higher/lower speeds to see if damage is dynamically calculated, because i fear it may not be the case

In the existing build the maximum damage that can occur is 34% of a particular part%u2019s health.  This eliminates one-hit kills.  For the next build I would like to set the maximum to 100% of the part health, but damage not propagated to the parent.  This way you can always knock off just the one part and whatever is attached to it.
ey
The thing i notice is that small weak hits do knock out parts that are pretty tough, also weapons seem to fall out relativley easy

Edit: One more thing i notice is that the motors are boosted if on a hinge or another motor/pneumatic burst/linac. Basically they spin up faster

I need to get rid of the existing impulse damage code.  I haven’t done that yet.  Pretty much all of the damage that is occurring is impulse based.  A few posts back I wrote some numbers down which quantifies this.  Spinners should be the main damage source.  They operate based on kinetic energy rather than impulse.

14
Ok so i did some testing

so the bots can spin up to 346mph then the bot lifts off like a plane and the disc gets bent

Underneath, this bot can technically reach 450mph, however the game just does its thing

Might test damage at higher/lower speeds to see if damage is dynamically calculated, because i fear it may not be the case

In the existing build the maximum damage that can occur is 34% of a particular part’s health.  This eliminates one-hit kills.  For the next build I would like to set the maximum to 100% of the part health, but damage not propagated to the parent.  This way you can always knock off just the one part and whatever is attached to it.

15
Working on spinner vs spinner damage now.  A high part count spinner like Circumvolution has the advantage against a single spinning bar.  More stuff to break off =more survivable.

16
Yes.  I need to check the notes, but spinners becoming unbalanced has been a thing for a few builds.

17
PS, Cyar, I’m tracking down the improper spinner breakage bugs in Circumvolution.  I think I have fixed them all.  Now that they are fixed a new problem has arisen.  When three out of the four quarters break off the weapon becomes so unbalanced that it teleports all over the arena.  I have a few potential fixes in.  We’ll see.

Hmm. Hopefully something does work.

Got it:

1. Bug Fix - I think I found and fixed all of the cases where a component breaks off but doesn't taken all of its children with it.
2. Bug Fix - When a spinner becomes so unbalanced that its remaining bits teleport all over the arena, those pieces now break off instead.

18
PS, Cyar, I’m tracking down the improper spinner breakage bugs in Circumvolution.  I think I have fixed them all.  Now that they are fixed a new problem has arisen.  When three out of the four quarters break off the weapon becomes so unbalanced that it teleports all over the arena.  I have a few potential fixes in.  We’ll see.

19
I've been thinking of composing some music loops for the game now that I have a bit of extra storage space for Cubase projects. Is there anything in particular you'd like?

Thank you for the offer!  Let me think about this a bit.

20
The puncture damage system needs to be updated.  It should be a relatively easy fix.

Does this mean you want me to come up with some spikes + crusher components aswell? ;)

I think so.  I don’t like the fact that any old shape can cause puncture damage.  I think it leads to the situation that Cyar has been pointing out where the robots fall apart but there is no clear reason why. 

Just like spinner hits very clearly cause spinner damage, hardened tips should be the only things causing puncture damage.

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