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] 10 11 12 13 14 15 16 ... 49
161
Hmm.  I swore I had fixed this.

162
How fast can you dish out a fix?

12 hours?

163
Drat!  I missed that!

164
New build is up! 27February2020:

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

TONS OF NEW COMPONENTS!

[Updates in the February 27th Build]

[Added] Added 3 new arenas.  They were all built using the Arena Modding Tool:

-School Tournament Arena

-Parking Lot

-The Twisted Circus

[Added] First batch of new Weapon's components + modifications to pre existing ones in accordance to new component factors. Many more new weapons + extras to come!​

[Added] New component types and category buttons for weapons (piercing/spinning/swinging/misc) and extras (lighting/decorative/misc).​

[Added] Added the option to copy values from other components in the materials section of the botlab.​

[Added] Now components can be set as scalable, materiable and tintable from the inspector.​

[Added] Hotkeys added:
-Increase/decrease scale factor.
-Toggle local/absolute movement of components.
-Toggle on/off movement of components attached to the selected component when scaling it. Changed the hotkey system a bit:
-By defalue hotkeys don't activate if the mouse left mouse button is held, this is to avoid problematic behaviours that can occur if some hotkeys are activated when dragging stuff. -Even hotkeys that attached to buttons and other interactables now get raycasted to see if they are covered, before they could be activated when the screen was covered by popups creating problems. This check can be deactivated for non problematic functions.

[Added] Added hotkeys for the materials and controls tabs. Fixed the move through tabs hotkeys not activating. Now component/material/brushes lists use an actual scroll rect and have scroll bars.

[Replaced] Replaced existing spinner damage with an entirely new damage model.  Take a look!

[Removed] Removed all other forms of damage.

[Tweaked] Reduced the axle mass of all of the motors to .00001 kg. The axle mass is no longer a useful quantity. Any mass here artificially inflates the mass of the robot without any benefit.  You should notice that the mass of your existing robots has dropped slightly.  Yay!​

[Bug Fix] Fixed the teleporting spinner bug. This was caused by the massOfBrokenOffObject was incorrectly computed, causing a spinner's mass to erroneously be set to 0, even when it had parts remaining.​

 [Bug Fix] The erroneously low MOI and KE values in the telemetry display have been fixed.​

​[Bug Fix] Fixed all (???) instances of components not breaking off all of their children with themselves.​

[Bug Fix] Fixed the problem with the new A40-300 having transmission components attach at 90°.

[Bug Fix] Amended: A40-300 motor's attachment has been fixed to pure 0 to eliminate wobble. Brushless motors attachment points have been enlarged to make them easier to attach to.​​​

[Bug Fix] Amended the A40-300 motor. Now spins in the right direction. I managed to fix where the gearbox attaches aswell, but I should probably mention this is due to the boxes now attaching to the hinge joint NOT the actual attachment point. If you also tilt the motor to an angle non-90 then attach a gearbox, the gearbox attaches at a 90 degree angle.

[Bug Fix] Fixed visibility of "Developer Only" components so that they now only show in the editor instead of in the built game.​​



A FEW CAVEATS ABOUT THIS BUILD

Damage System - The new damage system is in place for SPINNERS ONLY.  Nothing else causes damage right now.
AI - Still mostly broken.  For the most part all the AI does is turn on its weapon at the beginning of the match and keep driving at the nearest opponent.  Once the new damage system has been straightened out we will redesign AI around the new approach to damage.
House Robots - Once the game is mature enough we will be replacing all of the house robots with ones built in the robot workshop.  Any bugs that exist in the current robots will be completely replaced by entirely new bugs at that time.

165
It turns out the mass of the objects broken off are being incorrectly calculated.  Sometimes this results in the mass remaining to be zero even when there is stuff still attached.  I need to rework this.

I'm still hoping to get a build out in the next few hours...

166
Sorry for the delay!  I’m trying to get one out today.

I’m not satisfied with spinner imbalancing.  It is creating a really bad teleporting wobble when you knock something off the spinner.  So far my fixes have created more problems than they have solved.  I do have one more thing to try though.

Found a bug.  Now I need to trace it to its core and squash the bug.

I'm really hoping to get this build out today!

167
The AMT won’t take a whole lot of Unity knowledge.  You should be able to handle it if you are comfortable in any 3D modeling tool like Blender.
No chris thats false, the animations are pita, i can PM you the hell

Sorry about that!

I stand corrected.  I haven’t tried it myself.

168
The AMT won’t take a whole lot of Unity knowledge.  You should be able to handle it if you are comfortable in any 3D modeling tool like Blender.

169

There are two parts to designing a competitive robot in RA2. One part is the actual theory and engineering that goes into designing an effective competitive robot. The other part is using highly convoluted and arcane glitches to construct said robot, allowing you to make designs that would otherwise be impossible. Snapper loading is one of those glitches.

Here's a pretty well-sited 2008 boomer video of Sage (the boomer up above) using snapper loading to place objects:

The tl;dr of this is that snapper loading (particularly snapper loading + eFFe) allows you to create robots with intersecting parts, e.g. cram lots of weapons together or have weapons going through a plow, etc. Afaik RR2 allows everything to intersect, so none of this matters and there is no problem.

Thank you for this!

Just for the record, we do intend to start creating restrictions on part placement at some point.  For example, you shouldn’t be able to place a motor inside another motor.

The sloading question was actually a great question at its core.  Although the word “sloading” is specific to RA2, I foresee a similar issue arising with RR2.  It all comes down to how we handle it though.  Maybe an option in settings to allow components to intersect that is off by default?

170
Sorry for the delay!  I’m trying to get one out today.

I’m not satisfied with spinner imbalancing.  It is creating a really bad teleporting wobble when you knock something off the spinner.  So far my fixes have created more problems than they have solved.  I do have one more thing to try though.

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

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

173
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

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

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

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

177
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,

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

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

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

Pages: 1 2 3 4 5 6 7 8 [9] 10 11 12 13 14 15 16 ... 49