Nice work there! Very impressed.
It's cool that you are trying to make it a simulator, rather than just a game.
I see that the wheels are very smooth, how did you achieved that? Did you use one of the standard colliders or something else?
Oooo! Nuts and bolts too!
Nice ampflow model as well.
Loving the details :)
Thanks for the info!
I have tried as well to make a robot combat game, didn't go very far, but I did encounter the problem of the wheels, I used a method where I have the collision model of the wheel not completely fixed to the wheel itself, but I used a configurable joint to make it like a shock absorber radially, so it doesn't jump because of the not completelly smooth collision mesh.
But I'm sure you can find a much better and less messy solution than that!
I love the Idea of using the real controllers!
unity is a good dev environment, i use it, I will check it out,maybe i will use it in a GTM event. Will the rumbles allow more bots that RA2?
EDIT:Looked at it, good start, cant wait to see more,Looks in lots of ways better that RA1 ,RA2 and almost RA3 graphic wise.
Also, nice , that may be the best online fighting game, there are some but none this style, You should also port to tablets, I only know 1 other bot fighting game that is inactive, I would love to see that on tablets.
Also, You can Make AI to make the other bots move with these simple lines of code if you want to try.
Sweet! Thanks for the AI script! I have been wondering how to handle identifying a particular game component. I suppose player1 and player2 would have their own tags?I think you would tag the everybody"Player" and only give the script to the AI players. So th'all kill each other. Did you test the lines i sent you?
When you say "more robots", do you mean more robots that are pre-made and ship with the game, or are you referring to a user's ability to create and store more of their own creations?
Someone give this guy a medal.
Just keep plugging away at it my dude, frequent updates are a must to keep projects like this from dyingSomeone give this guy a medal.
Thanks for the vote of confidence, but I don't want to overpromise and underdeliver!
I figure I need to get everything in the "Priority One" list done before October. If that happens, then I should be in good shape to turn out an actual shippable product sometime in the next few years. 2 months to get the basic game working, then 2 years to polish it. :)
Just keep plugging away at it my dude, frequent updates are a must to keep projects like this from dyingSomeone give this guy a medal.
Thanks for the vote of confidence, but I don't want to overpromise and underdeliver!
I figure I need to get everything in the "Priority One" list done before October. If that happens, then I should be in good shape to turn out an actual shippable product sometime in the next few years. 2 months to get the basic game working, then 2 years to polish it. :)
If you ever need development help, many of the people on the forum have lots of knowledge and experience, and I'm sure they'd be happy to help.
You could use the part of my code for facing the player in you game and just have other animation do the walking.
- An intelligent scoring system that attempts to model the (entirely subjective) judging at our actual competitions. This might prove to be the trickiest part, as it is mostly based on how "exciting" a particular competitor is if no one is knocked out. Does anyone have any ideas on how to do this?
*record scratch* say whaatYou could use the part of my code for facing the player in you game and just have other animation do the walking.
For this version of the game, I am looking to control movement through the physics engine, rather than directly via the transform. I think a mobile version might benefit from simplified transform-based movement though -- it is further down on the list, but still definitely an option I would like to explore. I'm pretty sure I could bust out a top-down version of a mobile game relatively quickly once the full PC version is done.
I'm hoping to put out an announcement on the game in the next week or two. Still waiting on a few details... :)
*record scratch* say whaat
do you understand how long i have been begging to see this happen? so many mobile developers out there and nobody has had even the slightest impulse to try a robot combat game for mobile devices! it has the potential to blow the **** up, i'd think! imagine the online multiplayer... /swoon
i think the most intuitive way to allow controls to be handled would be to allow you to kind of 'drag and drop' useable buttons for your robot onto your screen kind of like how one would customize the button placement for a mobile emulator on their screen. but again that would take a certain amount of know-how to do (not trying to imply that you don't have that kind of know-how, but i have no doubt in my mind that creating a game in any respect for a mobile platform is no easy venture)
ha! now that's some way to think about it, you're absolutely right though. especially considering you've only got so much space you can allow yourself for buttons on a mobile screen before you've run out of space to see what the hell you're doing, it does it's own work keeping outlandish and unrealistic design in check.
I've found that everybody has their own preferred control scheme regardless of game. For controlling robots I've toyed with Tank-controls, Single-stick and even car-style (RT drives, LS steers). If it's something you can afford to develop people will likely enjoy having the option.
ha! now that's some way to think about it, you're absolutely right though. especially considering you've only got so much space you can allow yourself for buttons on a mobile screen before you've run out of space to see what the hell you're doing, it does it's own work keeping outlandish and unrealistic design in check.
- An intelligent scoring system that attempts to model the (entirely subjective) judging at our actual competitions. This might prove to be the trickiest part, as it is mostly based on how "exciting" a particular competitor is if no one is knocked out. Does anyone have any ideas on how to do this?
i would imagine a system that would record the speed of both bots upon impact when it's a non-weapon hit and speed/damage upon weapon hit, maybe even including something like a 'sparks' system that would sway judge opinion in favor of those who generate more sparks from their hits, but also to make things fair for flippers and shovers a counter-point system that reverses judges favor through hazard impact and slams (flips, too) as well. sounds complicated but probably possible if fine tuned juuust right
- An intelligent scoring system that attempts to model the (entirely subjective) judging at our actual competitions. This might prove to be the trickiest part, as it is mostly based on how "exciting" a particular competitor is if no one is knocked out. Does anyone have any ideas on how to do this?
i would imagine a system that would record the speed of both bots upon impact when it's a non-weapon hit and speed/damage upon weapon hit, maybe even including something like a 'sparks' system that would sway judge opinion in favor of those who generate more sparks from their hits, but also to make things fair for flippers and shovers a counter-point system that reverses judges favor through hazard impact and slams (flips, too) as well. sounds complicated but probably possible if fine tuned juuust right
I would comment to not forget F= MA. While you can do shortcuts of how much damage a weapon does and assume a lot of things if one bot is much lighter than another and/or if you scale the weapons at all to the scale of the bot size then please don't forget to scale the amount of damage it can do in collisions, ramming and weapon contacts.
Also on your movement, if you do dot products to decide if a bot can move towards a foe or not, you are not taking into account if one or more motive wheels have been removed or damaged. If they planned for redundancy in having more than usually 4 wheels and that using dot product checks and the opponent is at nearly right angles will cause pretty strong errors in the movement.
Finally, the dot product method assumes always the same level which can be an assumption you can take if you plan on always having flat arenas but will be a problem if you later change mind to have ramps, bumps, multi level options.
Sorry if I have missed things in diving in midstream and seeing some possible issues.
Starcore
IMO you should get a working prototype of 2 bots interacting in an arena before even worrying about anything else, like bot building, points systems or damage models. Walk before you run, so to speak.
As the online multilayer of RA2 is non existend people had to rely on AI to host tournaments. We never really had a choice to say we prefer AI over PvP as we haven't experienced PvP in a propper way yet
If the focus of the game is multiplayer, it will die off pretty quickly due to a lack of sustainable userbase. While multiplayer functionality would be great, I think the focus should be AI combat. It should also be possible for users to make the AI control their own bots.
If the focus of the game is multiplayer, it will die off pretty quickly due to a lack of sustainable userbase. While multiplayer functionality would be great, I think the focus should be AI combat. It should also be possible for users to make the AI control their own bots.
one is the dreaded RA3. THey both had multiplayer, but they were all full of bugs.
i am voting for multiplayer.
RA3 multiplayer is a bit of a mess. It's buggy, occasionally laggy, and you can only play with people on the same continent as you with no option to change servers. It is still far better than RA2 online via Gameranger though.one is the dreaded RA3. THey both had multiplayer, but they were all full of bugs.
i am voting for multiplayer.
I personally haven't tried RA3 yet. How is the online multiplayer experience?
I'm afraid of underestimating how difficult it is do this well.
I expect that there would be a lot of robot parts that appear to randomly teleport when a packet arrives that is delayed by 300 ms and the robots are forced to shift their positions to the new spot. Even with interpolation, there could be weirdness as robots rotate into position under the control of a linear interpolation function instead of the user's input.
RA3 multiplayer is a bit of a mess. It's buggy, occasionally laggy, and you can only play with people on the same continent as you with no option to change servers.
The only reason why we have so much AI is because online play is horrible.
Not that there's anything wrong with making it easy to AI a robot, or having AI'ing options. The Starcore AI pack robots were (IIRC) designed as sparing partners for multiplayer.
Another option I toyed with back in February was to create a point-and-click control scheme. Robots would fight with AI, but you would tell them where to go and who to attack.thats gonna be hard to do, have you ever tryed to AI in RA2?
This might be the worst of all worlds though: it would lack the immediacy of direct controls, would still suffer from syncing issues as robots automagically lerp() to new positions and rotations, and require someone else to be online to battle.
But there is a multiplayer game worse than RA3 worse than RA2, rumble bots,
You can conceptualise and post cool ideas all day, but if you can't implement those ideas into a game it's all for nothing.
Good news!Nice! I look forward to following the game's development!
We are thrilled to announce that we have put together the core team for "Robot Rumble 2.0". tashic, tomgsx, and I will be working together on the project, and have set a launch date target of mid-2019. Starcore has graciously offered his guidance in the development of AI, and we are hoping to make this a big part of the game at launch.
Thank you for all of your kind words of support, and we hope to make this game something that we can all be proud of and enjoy for years to come.
-The Robot Rumble 2.0 Core Development Team
Thanks for the update, the logo looks good. Glad to hear that you're tackling this in a modular manner
Can you comment on if you're taking moddability into account during development? One of this things that has kept RA2 relevant for so long is how much of the game can be modified without touching the actual source code, or in other words how little of the game is hardcoded.
@tashic is attempting to make a mesh builder that allows you to "cut out parts" on a virtual bandsaw and weld them together to make whatever you want.
The other one looked a million times better, but okay.
New one is just some text on a black background. The other one had some character to it. It actually looked like a logo rather than something kinda generic.The other one looked a million times better, but okay.
I appreciate the honesty! What was it you liked about the first logo that is missing from the new one?
Pretty much this. The other one could be an icon for the game as well as the logo so it's got a better branding rather than just some text that you don't instantly see is textured, rather than just plain grey.New one is just some text on a black background. The other one had some character to it. It actually looked like a logo rather than something kinda generic.The other one looked a million times better, but okay.
I appreciate the honesty! What was it you liked about the first logo that is missing from the new one?
Pretty much this. The other one could be an icon for the game as well as the logo so it's got a better branding rather than just some text that you don't instantly see is textured, rather than just plain grey.New one is just some text on a black background. The other one had some character to it. It actually looked like a logo rather than something kinda generic.The other one looked a million times better, but okay.
I appreciate the honesty! What was it you liked about the first logo that is missing from the new one?
Seems like it'd be a good loading bar as well. Though I think having the laser cut out the name would be cooler, though I understand that's more complicated
oh-- and do keep in mind with your question: this is a community built around a game where the most functional part of it's playability is the customization and building, so that's what your answer is going to be. i'm kind of a unicorn here in this sense because i'm more about competition than idle tinkering, and that not being the strong point of the game this commuinity is built around means that people like me (who do exist and likely don't post here because of the lack of mano y mano combat as a strength of the game) could absolutely be a target market of sorts for your game has it the technical capability to implement a solid online battle system. do keep in mind that you can certainly expand your target market outside of the average ra2 player if you pay enough mind to improve on the things where ra2 was weak, rather than just building a stronger ra2 (which limits your community to those of us who are already here, and god forbid that's all!)
makes sense? :approve:
Hey man, that's an outstanding start you guys have right there. My one gripe is just a visual one, and it's one that it shares with a lot of modern games. The lighting is a bit much. I understand that you want everything to appear real and shiny, but the lighting is almost giving the camera a haziness to it. I'd consider trying a bit less shine.
Downloaded it for myself, the special FX are definitely giving me some input lag + framerate drops. The 3D model work is coming along nicely though.
I've got this if that means anything:Downloaded it for myself, the special FX are definitely giving me some input lag + framerate drops. The 3D model work is coming along nicely though.
Sounds good. What kind of a machine are you running on?
I'm curious to see if there is a big difference between running the game with an integrated GPU vs a dedicated card.
The 3D models are all @tashic's work. He's awesome. :smile:
I've got this if that means anything:Downloaded it for myself, the special FX are definitely giving me some input lag + framerate drops. The 3D model work is coming along nicely though.
Sounds good. What kind of a machine are you running on?
I'm curious to see if there is a big difference between running the game with an integrated GPU vs a dedicated card.
The 3D models are all @tashic's work. He's awesome. :smile:
(https://i.imgur.com/r5PA8rl.png)
It's basically a toaster.
I tried the "2P test" mode which ran far smoother than the other game modes. Maybe you could have that be the low graphics setting and the effects used in the other game modes be the high graphics setting.
also it looks good so far considering it's basically the engine tashic had a few months ago with a couple of additions
what are the controls for the second bot in 2P? both the wsad and arrow keys drive the P1 robot.
Running good on my HD7950 (but then. It is 3gb)
Some feedback.
I would like to agree with kill and say that the post-processing is way too much. The shine and lens effects are really distracting. I image at some point it should be possible for these to be togglable.
What sort of framerates are you expecting? I'm supposedly getting 25fps on my 980ti in 1080p windowed which seems a bit low.
I was puzzled by the low FPS and it turns out that the game isn't putting almost any load on my GPU unless I click out of the game. Then it shoots to over 250fps and 100% GPU load.Some feedback.
I would like to agree with kill and say that the post-processing is way too much. The shine and lens effects are really distracting. I image at some point it should be possible for these to be togglable.
What sort of framerates are you expecting? I'm supposedly getting 25fps on my 980ti in 1080p windowed which seems a bit low.
Good to know. For the next revision I think I will get rid of the "lens dirt" and turn the bloom way down. I'm thinking we can also get rid of the ambient occlusion. It is a nice effect, but I don't think it really adds that much when the scene is so full of hard edges. Motion blur is cool too, but I think we have a better way to do motion blur that doesn't require any post-processing.
If you don't mind my asking, in the "2 Player" mode, are you seeing 60 fps? This scene doesn't have any post-processing at all.
Newest build is pretty good. I noticed that my framerate improved when I was right in the corners, like directly in the spotlights, and worsened in the middle of the arena.
640X480Running good on my HD7950 (but then. It is 3gb)
Thanks for the info! I'm hoping that older dedicated GPU cards will be able to handle the max settings. This will give us more room to play around with particles.
What screen resolution are you running?
I'm gonna download because I want that lava pit.
This already looks better than ra3 guys. Amazing job. Need to test it when I get home
I signed up just to post. I'm pretty excited about the development and time you guys have put into this. I'm a web dev but you guys make me want to learn unity so I can help. Keep up the good work.. seriously so stoked for this.
I will say I think your latest build had some issues. When starting in 1p i couldn't control carbide. Original sin and eruption did their own thing as if it wanted to have a UI but didn't know what to do. the workshop didn't do anything for me either.
I signed up just to post. I'm pretty excited about the development and time you guys have put into this. I'm a web dev but you guys make me want to learn unity so I can help. Keep up the good work.. seriously so stoked for this.
I will say I think your latest build had some issues. When starting in 1p i couldn't control carbide. Original sin and eruption did their own thing as if it wanted to have a UI but didn't know what to do. the workshop didn't do anything for me either.
So, the next things you need to add, ordered from easiest to hardest-
Recognition of OOTA's/Pittings (Will allow for more strategy)
Limited battery life/flipper gas (Eruption can just flip forever right now)
Fix the Warehouse's cameras (I tried a test fight and couldn't see anything)
Smoke/fire effects for damaged components (Good visual indicator, plus adds some flair)
Ability to rip off components (I know it's possible because they fly off when you disable an opponent, but I haven't been able to rip off a single wheel or anything like that)
1 more robot, then support for up to 4 AI's at once (The dream is of course to be able to do massive multi-bot rumbles at some point.)
Softbody physics (yeah this is never happening)
This version is just nice. There is some stuff to do tho.. most of it is already said soo..
If you need arenas i can make some (you will need 3ds max skills tho)
Ive been messing in botlab and made this... (Still wishing for that sketchup mode of building. Maybe add an extenstion to port designs from 3dsmax or sketchup to the game)
[ This attachment cannot be displayed inline in 'Print Page' view ]
Right now is in very early development so you can expect bugs and issues as a lot of things we are still figuring out.
But good to see we are getting some attention!
Also what about the workshop didn't feel right? Again, still in development and things aren't really explained to the player at the moment.
Welcome to the forum
We are thrilled that you are excited about it! It helps to have people excited about the project when there is so much work left to do.
I think one of the lessons learned on this particular build is to not enable any functions that shouldn’t be tested. At this point the “1 Player” menu option is redundant, and we haven’t bothered to get rid of it, as it doesn’t do anything that the “2 Player” mode does. Likewise for the “2P Test” menu option. We use it to test out new ideas that will eventually be migrated into the game.
The BotLab is partially functional at this point. You can create 3D meshes and assemble the meshes you have created in any size and orientation. It is pretty neat that it works, but it isn’t obvious how it works at this point. Once all of the functionality exists, we will need to do a lot of UI/UX work and testing to make robot building as smooth and intuitive as possible.
We will try to post our development here, but I encourage you to sign up for the mailing list on www.robot-rumble.com to receive news and updates. We will also be using the mailing list to sign people up for beta testing when we are ready for it. It is still pretty early in the development cycle, but I am hoping to be ready for beta in about 12 months.
Right now is in very early development so you can expect bugs and issues as a lot of things we are still figuring out.
But good to see we are getting some attention!
Also what about the workshop didn't feel right? Again, still in development and things aren't really explained to the player at the moment.
Could have just been my system but I was unable to do anything. I understand the development stage, but I felt like I should have been able to at least click and drag to model as it seems others have been able to do?
I like the idea of the pneumatic system having its own individual components. it feels like those parts could be adapted to serve in a similar fashion in crusher/hydraulic systems as well.
This is looking really, really promising. Keep up the good work you guys!
edit: downloading the windows build exe and trying to run it gives me this error:
(https://i.imgur.com/JeKBXzB.png)
seems like you forgot to package the rest of the files with it
This is looking really, really promising. Keep up the good work you guys!
edit: downloading the windows build exe and trying to run it gives me this error:
(https://i.imgur.com/JeKBXzB.png)
seems like you forgot to package the rest of the files with it
Crashes on startup for me every time I try to run it. If I had to guess at the cause I'd say it might be that I have sh**ty integrated intel HD graphics on my laptop, but I can't be certain. I could well have ****ed up the install somehow. Here's the popup I get. I can also send you the crash logs if you'd like.
[ This attachment cannot be displayed inline in 'Print Page' view ]
I absolutely love the game, so far. I don't know if it actually emulates real life, but I found that the person taking the initiative to move towards the opponent, when they have the same wedge (Eruption vs Eruption), always loses the wedge war. It lead to me losing to Eruption (as Eruption) over and over again until I realised all I had to do was not move, which shouldn't be what anyone should come to the conclusion to. I don't know how much useful this feedback is, honestly, considering the game is in the early stages of development and the pre-built bots are just a demo. Not to mention that I was using a bot against an exact copy of itself. I just thought I'd mention it, anyway. It did make me cry out in joy when I saw this, tho:
(https://i.gyazo.com/db062167e5f73f8d4692084a162e4f5f.jpg)
Edit: After doing Original Sin v Eruption, that could be the way the wedge war works, in this game. Hopefully, this is just because the game is too early in development.
In all honesty, I never get my hopes up too much whenever I see anything like this pop up because the projects usually get abandoned, after a while. Either that or progress on them is made at the pace of a snail dragging a boulder. Nevertheless, I wish you an incredible amount of luck with this project. I really appreciate that you're working on this.
Great progress so far!
I've taken some time to test it thoroughly and here are some notices
- So anytime a select a camera, W and S move the camera setting, and if i press space (weapon button) it selects the camera, which is annoying. Could you remap the camera buttons to f1, f2 & f3 (like in ra2)
- AI Eruption doesn't self right
- Eruption's flipper is too op in damage, or bots are fragile af
- Carbide deals no damage, or force, which makes me think if there is enough weight on spinner for force to flung enemies
Some wishes:
- Immobile countdown timer
- Maybe a component maker, something like a chassis maker
- Material for maker (Steel, alu, etc..., great for comp maker)
- Camera that follows you and AI (Something like Action cam in ra2)
- RA2 like attach point system (maybe add a button to enable/disable it)
All in all great progress and i wish you the best!
7. Which key gets follow camera control? This should be really easy to do.Prolly 4, as it would then be 1,2,3,4
Ability to rip off components (I know it's possible because they fly off when you disable an opponent, but I haven't been able to rip off a single wheel or anything like that)
- Maybe a component maker, something like a chassis maker
- RA2 like attach point system (maybe add a button to enable/disable it)
I've just downloaded the linux version and this is what I get.
[ This attachment cannot be displayed inline in 'Print Page' view ]
Wow, This is really cool! I had a lot of fun throwing carbide around the arena
However, am I the only one experiencing severe input lag? It seems to take about a second for the game to register my inputs. Idk if its just my low spec laptop or whether it was an intended feature to simulate IRL robot controls maybe?
Wow, This is really cool! I had a lot of fun throwing carbide around the arena
However, am I the only one experiencing severe input lag? It seems to take about a second for the game to register my inputs. Idk if its just my low spec laptop or whether it was an intended feature to simulate IRL robot controls maybe?
We haven't included any input lag in the simulation. What are the specs for your laptop? Are you using keyboard controls?
The game works great on my 2013 11" MacBook Air, but I am curious to see how low we can go with acceptable performance. I am hoping to target midrange phones and WebGL. Phones will probably be okay, but I'm struggling to get WebGL working, not sure why at this point. We might have to wait for the Steam launch before looking into the WebGL version again.
Seems cjbruce hasn't posted about it here yet but there's a new build out, with breakable components, new components for the bot lab, and a prototype version of the arena builder, among other things. I'm only posting about it because I want to offer some feedback:
- The new immobility countdown flickers a lot, which is irritating, and if multiple robots aren't moving then it switches between them rather than each robot having an individual countdown
- The text is wonky on some of the buttons (esp. in the arena builder). Dunno if that's just coz I'm playing in 720p windowed mode though.
- The sound balance feels off - some sounds are too loud, others are too quiet. Dunno if it's just me.
- Eruption's flipper apparently has a limited amount of CO2 but I don't see that indicated anywhere in the UI - if the blue gauge is CO2, then it's not depleting
- If you click "Help" in the Robot Lab, it spawns a fully-finished robot that then sinks through the table. You can spawn them indefinitely and fill the lab with them. Amusing, but probably not intended?
Still looks great and feels great, though. Rome wasn't built in a day, as they say. Keep up the good work!
Link to the latest build:fixed
https://robot-rumble.itch.io/builds
What badger said.Oh yeah, that was one of the bugs I forgot, Eruption always spawns facing backward.
Also the start points seem a bit odd. Like robots often start facing away from each other but sometimes not. I tried a match with original sin in the sumo ring and the physics pushed me out right when I spawned. I could also see the path that AI was planning to take. I assume that's just a debug feature that isn't normally supposed to be visible.
But other than that, great work. I'm looking forward to seeing the robot and arena editors in a more developed form. Looks very promising
What does the bar under the HP bar represent? Would be useful for it to show CO2 levels on Eruption or spinner speed on CarbideOn Carbide, at least, it appears to represent motor temperature or something. If you have the weapon spinning for too long, the bar starts to fill with red, and you have to release the weapon button to get it to lower again. I don't know what happens if the bar fills all the way up but I'm guessing the weapon just stops working.
Gave the newest build a shot, it's starting to look like a very solid base for a full game. I've found some bugs and I have some suggestions.
Bugs:
Some z-fighting with the dummy bot, particularly on the warehouse stage. At one point the mesh floor on the warehouse briefly displayed over the dummy bot's decal.
Suggestions/Compaints:
Eruption's flipper feels super anaemic.
Carbide's spinner feels like it's very slow, but with a ton of torque.
Everything feels like it has way too much HP. Except once an AI Carbide's blade fell off just by hitting my Eruption, with no non-HP damage being cause to my Eruption.
It's difficult to figure out what's doing damage when Original Sin's opponent is taking damage. Is it impact with the arena wall? Contact with the wedge arm things? It feels inconsistent.
What does the bar under the HP bar represent? Would be useful for it to show CO2 levels on Eruption or spinner speed on Carbide
Eruption's limited CO2 supply is realistic, but not very fun at all, especially with how weak its flipper is. Maybe give a debug option to allow unlimited flips?
Part of what made RA2 so long-lasting was the fact that component data was stored in a user-editable format, allowing for customization. Would it be possible to read robot data from text files, allowing the user to edit carbine's spinner speed or eruption's flipper power, for example?
I had a couple more bugs and inconsistencies but I've forgotten them now. Oh well. ¯\_(ツ)_/¯
Edit: I also managed to flip the DB out of the sumo arena without the DB being killed or the round ending
(https://i.imgur.com/zGRbda1.jpg)
What badger said.
Also the start points seem a bit odd. Like robots often start facing away from each other but sometimes not. I tried a match with original sin in the sumo ring and the physics pushed me out right when I spawned. I could also see the path that AI was planning to take. I assume that's just a debug feature that isn't normally supposed to be visible.
But other than that, great work. I'm looking forward to seeing the robot and arena editors in a more developed form. Looks very promising
What badger said.Oh yeah, that was one of the bugs I forgot, Eruption always spawns facing backward.
Also the start points seem a bit odd. Like robots often start facing away from each other but sometimes not. I tried a match with original sin in the sumo ring and the physics pushed me out right when I spawned. I could also see the path that AI was planning to take. I assume that's just a debug feature that isn't normally supposed to be visible.
But other than that, great work. I'm looking forward to seeing the robot and arena editors in a more developed form. Looks very promising
Also might be nice if the dummy bot was invertible, so it can better serve its purpose as a punching bag. Just my personal opinion
What does the bar under the HP bar represent? Would be useful for it to show CO2 levels on Eruption or spinner speed on CarbideOn Carbide, at least, it appears to represent motor temperature or something. If you have the weapon spinning for too long, the bar starts to fill with red, and you have to release the weapon button to get it to lower again. I don't know what happens if the bar fills all the way up but I'm guessing the weapon just stops working.
Heck yeah, 500 posts
It was just something I happened to notice while playing the latest build. What clinched it was when I started turning and the bar started filling up faster, because I had three motors running instead of one. Controlling overheating sounds like an interesting game mechanic (and should make it harder for people to make unrealistic bots with tonnes of weapon/drive motors ;) )What does the bar under the HP bar represent? Would be useful for it to show CO2 levels on Eruption or spinner speed on CarbideOn Carbide, at least, it appears to represent motor temperature or something. If you have the weapon spinning for too long, the bar starts to fill with red, and you have to release the weapon button to get it to lower again. I don't know what happens if the bar fills all the way up but I'm guessing the weapon just stops working.
Heck yeah, 500 posts
You are correct on all counts! Nice detective work! (and a little bit scary) :smile:
It was just something I happened to notice while playing the latest build. What clinched it was when I started turning and the bar started filling up faster, because I had three motors running instead of one. Controlling overheating sounds like an interesting game mechanic (and should make it harder for people to make unrealistic bots with tonnes of weapon/drive motors ;) )What does the bar under the HP bar represent? Would be useful for it to show CO2 levels on Eruption or spinner speed on CarbideOn Carbide, at least, it appears to represent motor temperature or something. If you have the weapon spinning for too long, the bar starts to fill with red, and you have to release the weapon button to get it to lower again. I don't know what happens if the bar fills all the way up but I'm guessing the weapon just stops working.
Heck yeah, 500 posts
You are correct on all counts! Nice detective work! (and a little bit scary) :smile:
What does D.B. stand for
Good game, but fix and simplify the bot lab. Make a mobile port too please! I would love to play on the go.
What does D.B. stand for
:bigsmile:
No one is quite sure, but we are open to suggestions.
Good game, but fix and simplify the bot lab. Make a mobile port too please! I would love to play on the go.
The BotLab is our biggest push right now, in addition to cleaning up the physics for each robots. We are tuning dynamics, and once with have dialed things in we will need to figure out how to translate all of the hand-built stuff into the BotLab.
A mobile port is firmly in the "nice to have" category until we can get a solid version up an running for Windows/Mac/Linux. Rethinking everything for mobile will take some work, and our team is pretty small.
That being said, here's a video of me fighting an AI robot on an iPhone 7 Plus:
https://www.youtube.com/watch?v=AXSi9qrPtWw (https://www.youtube.com/watch?v=AXSi9qrPtWw)
@Ra2Winner999
Please don't make multiple posts in a row. Instead, edit your previous post and add whatever you want to say onto it.
@cjbruce
I don't mean to be pushy, but is there an ETA for the next build's release? I'm really looking forward to it.
Good to hear, will there be any tweaks to Eruption's flipper in the next build? That's what I'm really looking forward to!
Great to hear! Another question, are you planning on having AI bots be part of the .exe of the game (like how it is now) or separated out into their own files, like how RA2 does it?Good to hear, will there be any tweaks to Eruption's flipper in the next build? That's what I'm really looking forward to!
Yup! Way more powerful, with a much improved range of motion. :smile:
Please keep in mind that Carbide, Original Sin, and Eruption only exist in these early development builds. We don't have permission to use them in the final game. Right now we are using them to prove out the physics and AI tactics, and we have the goal of being able to build and test a solid functional replica of a wide range of real-life robots in the BotLab. All of the parameters for a CO2 flipper should be tweakable in the BotLab, such as hinge range of motion, piston diameter, stroke length, buffer tank volume, etc.
Great to hear! Another question, are you planning on having AI bots be part of the .exe of the game (like how it is now) or separated out into their own files, like how RA2 does it?Good to hear, will there be any tweaks to Eruption's flipper in the next build? That's what I'm really looking forward to!
Yup! Way more powerful, with a much improved range of motion. :smile:
Please keep in mind that Carbide, Original Sin, and Eruption only exist in these early development builds. We don't have permission to use them in the final game. Right now we are using them to prove out the physics and AI tactics, and we have the goal of being able to build and test a solid functional replica of a wide range of real-life robots in the BotLab. All of the parameters for a CO2 flipper should be tweakable in the BotLab, such as hinge range of motion, piston diameter, stroke length, buffer tank volume, etc.
Since RW is dead now, if you ask nicely you might be able to get permission from the builders of at least Eruption and Carbide to use their bots, maybe after a rename/recolour to avoid copyright issues w/ Mentorn. I know the builder of Eruption used to post on GTM pretty regularly so I'd be surprised if he were against the idea. Just thinking since it would be a shame for the work that's gone into modelling and implementing these bots to go to waste.
Looking very interesting! Any tweaks to weaponry (Eruption's flipper power, carbide's spinner speed etc)?
Note that we will most likely be removing Eruption, Carbide, and Original Sin from the game, as they all have restrictive licensing agreements.What's the chance you can leave in "Generic Bar Spinner", "Generic UK style Flipper" and "Generic 4WD Wedge bot"?
Cant wait for the new build! any pics of the flail bot
Note that we will most likely be removing Eruption, Carbide, and Original Sin from the game, as they all have restrictive licensing agreements.What's the chance you can leave in "Generic Bar Spinner", "Generic UK style Flipper" and "Generic 4WD Wedge bot"?
Eruption - The flipper is 4 times more powerful than before. It is maybe a tad too overpowered, but it is more fun now. :)You'll regret that.
I feel like the force curve on Eruption's flipper is a bit off, I think maybe either the force is applied over too long a period, or maybe the force doesn't peak quickly enough (awful pic below to explain what I mean), both leading the flipper to feel a bit unsatisfying and unrealistic. That and Eruption's flipper is very inconsistent; sometimes feeling barely less anaemic than before and other times exploding like the gif Guldenflame posted above, or sometimes behaving in a way anywhere between those two extremes. I personally think it would be a good use of time to polish the feel of eruption's flipper and iron out the explosion bug, even if Eruption is not long for this game, as I'm sure it would serve you well if you chose to create another AI flipper or a component that allows the user to create flippers in the botlab.
Awful pic:
[ This attachment cannot be displayed inline in 'Print Page' view ]
I downloaded this yesterday, but couldn't get it run properly. It's fine in the menus but when I enter a battle I get huge amounts of lag (like 2 seconds after I press a button) is there a simple fix for this?
What I did manage to play I thought it was pretty fun and the physics were pretty realistic and I'd love to see this continue in future
threw the link over to my buds at ARC and one of them discovered that if you have a bot on the very top of Eruption's flipper and fire it, Eruption will explode. he was able to reproduce it pretty consistently.
In addition to the glitches that Badnik mentioned there's also some kind of glitch with Eruption's self righting when controlled by a player. It tends to glitch out and launch the bot around and usually out of the arena even from the opposite side of the ring.
Gonna echo Badnik's praise though. This is the first build I've played of the game and the combat is already fun and addictive as hell. The botlab looks incredibly promising too. Will be watching how things develop extremely eagerly :thumbup
I downloaded this yesterday, but couldn't get it run properly. It's fine in the menus but when I enter a battle I get huge amounts of lag (like 2 seconds after I press a button) is there a simple fix for this?
What I did manage to play I thought it was pretty fun and the physics were pretty realistic and I'd love to see this continue in future
Thanks for the feedback! I am curious as to your system specs. I have been tuning combat to run between 30-60 fps on a 2013 Macbook Air laptop with 8 GB of RAM. The game is CPU-limited on my laptop, with physics taking the vast majority of the CPU time.
Yeah well there's your problem. You can't expect a 3 year old celeron (with no dGPU) that was weak when it was released to play basically any 3-D game released in the past decade or more. Not an issue with the game I'm afraid. Try it on a desktop if you have access to one.I downloaded this yesterday, but couldn't get it run properly. It's fine in the menus but when I enter a battle I get huge amounts of lag (like 2 seconds after I press a button) is there a simple fix for this?
What I did manage to play I thought it was pretty fun and the physics were pretty realistic and I'd love to see this continue in future
Thanks for the feedback! I am curious as to your system specs. I have been tuning combat to run between 30-60 fps on a 2013 Macbook Air laptop with 8 GB of RAM. The game is CPU-limited on my laptop, with physics taking the vast majority of the CPU time.
It's an Acer Aspire ES1-512 (2015 or 2016) with 4 GB of RAM
The processor is an Intel Celeron N2840 if any of this helps
Yeah well there's your problem. You can't expect a 3 year old celeron (with no dGPU) that was weak when it was released to play basically any 3-D game released in the past decade or more. Not an issue with the game I'm afraid. Try it on a desktop if you have access to one.I downloaded this yesterday, but couldn't get it run properly. It's fine in the menus but when I enter a battle I get huge amounts of lag (like 2 seconds after I press a button) is there a simple fix for this?
What I did manage to play I thought it was pretty fun and the physics were pretty realistic and I'd love to see this continue in future
Thanks for the feedback! I am curious as to your system specs. I have been tuning combat to run between 30-60 fps on a 2013 Macbook Air laptop with 8 GB of RAM. The game is CPU-limited on my laptop, with physics taking the vast majority of the CPU time.
It's an Acer Aspire ES1-512 (2015 or 2016) with 4 GB of RAM
The processor is an Intel Celeron N2840 if any of this helps
threw the link over to my buds at ARC and one of them discovered that if you have a bot on the very top of Eruption's flipper and fire it, Eruption will explode. he was able to reproduce it pretty consistently.
Nice catch! I will definitely take a look at this.
Yeah well there's your problem. You can't expect a 3 year old celeron (with no dGPU) that was weak when it was released to play basically any 3-D game released in the past decade or more. Not an issue with the game I'm afraid. Try it on a desktop if you have access to one.I downloaded this yesterday, but couldn't get it run properly. It's fine in the menus but when I enter a battle I get huge amounts of lag (like 2 seconds after I press a button) is there a simple fix for this?
What I did manage to play I thought it was pretty fun and the physics were pretty realistic and I'd love to see this continue in future
Thanks for the feedback! I am curious as to your system specs. I have been tuning combat to run between 30-60 fps on a 2013 Macbook Air laptop with 8 GB of RAM. The game is CPU-limited on my laptop, with physics taking the vast majority of the CPU time.
It's an Acer Aspire ES1-512 (2015 or 2016) with 4 GB of RAM
The processor is an Intel Celeron N2840 if any of this helps
It is good to know though. @Olister92, thank you for sharing!
I am toying with the idea of supporting really old hardware. This comes with other advantages, like being able to throw unlimited numbers of robots in the ring together. Right now I am tweaking everything for two robots, and am pushing physics to the maximum.
If we were willing to give up a bunch of physics fidelity by going to a "magic mobility" system where the forces on an object are drastically simplified like in RA2, we could get by on RA2-like hardware. I'm not convinced that it would be worth it though. The current high-fidelity physics should be able to handle arbitrary shapes created in the BotLab. If you want a pneumatics system, you build it from scratch. All of the hinges and sliding joints are modeled individually. You couldn't do this in RA2, where everything was made of prebuilt components.
I would be curious to see how a Windows computer with a Geekbench single CPU score around 2400 performs. Any takers? :)I have a Surface Book with i7-6600u. Can't really find an accurate score for it but I can benchmark for you.
I would be curious to see how a Windows computer with a Geekbench single CPU score around 2400 performs. Any takers? :)I have a Surface Book with i7-6600u. Can't really find an accurate score for it but I can benchmark for you.
I could also throttle down my desktop if that helps.
I would suggest that the bottleneck for the Acer laptop is the integrated graphics, not the CPU for this particular workload
Nice game!! It's so addictive and here are some of my suggestions.
1.Maybe it can be added something like weapon designing. Build the shape of the blade, the var, the flipper and the axe etc. whatever we like, and choose the material to attach to their weight. I think it could be of great fun. Also the paint job should be various as well so players can create their own best-looking robots.(such as typing words in different shapes)
2.The spinners should be more powerful, it's always embarrassing to see Carbide ripping Original Sin apart and then died incredibly.
3.When a robot end up with no life, it might be more real if it stops moving and been counted down, with the other side spinning around.
It's Nightmare!
I had a quick play with the new build, my feedback:
- Eruption's flipper feels really nice now. Great work on tweaking that!
- Both spinners, however, do not. Their blades/drums are going orders of magnitude too slow. Is this a limitation of the unity engine?
- Carbide's bar is rotating off-center and it looks really derpy
- PLEASE make the Esc key open the pause menu, not close the game!
- I like the addition of the drumbot
- I think the inactivity timer is really well implemented, both mechanically and visually. Great work there.
Good to see some progress. I haven't messed around in the botlab at all, are the bots made there useable in battle yet?
man. this is nuts.
made a sexy robot
[ This attachment cannot be displayed inline in 'Print Page' view ]
some really neat features in here. im very impressed with what you guys have done, it's far and away the most complete robot builder i've seen besides ra2. I hope the work continues, I can't wait to see where it goes. especially interested in the bot creator. got some very good things so far, I'm especially happy with the custom shapes you can make, ra2 needed a feature like this.
incredible work so far. bot lab has got me excited
i have some bug issues with fighting however, not sure if others are having this. saw phil able to drive his bot but when I try to do a match it always ends immediately after the countdown, and says player 1 has won.
[ This attachment cannot be displayed inline in 'Print Page' view ]
this happens even if I set both players to cpu. I may be doing something wrong but if it's a bug I thought I'd let you guys know.
please don’t be as clueless as robotfan99I thought you were more clueless. Guess I was wrong then.
:realmad(please don’t be as clueless as robotfan99I thought you were more clueless. Guess I was wrong then.
/sarcasm
Can we get Linux builds? I'd like to test this.
To everyone who has given feedback, thank you! We are frantically trying to put everything together for an Alpha release.
We have been talking to lots of real-life roboteers to get permission to use their robots in our game. We have some bad news and some good news on this front.
The Bad:
Display rights to all of the Robot Wars robots are owned by the BBC. Both they and Battlebots are rightfully protective of their intellectual property. This means that we do not have permission to use Carbide, Eruption, or Original Sin in our commercial release. All three robots will be removed from the game.
The Good:
Many of the roboteers themselves are really excited to share their unlicensed designs. We have permission from several of the teams to use their other designs from the live circuit. We should be able to get a few of these designs into the next few builds.
To everyone who has given feedback, thank you! We are frantically trying to put everything together for an Alpha release.
We have been talking to lots of real-life roboteers to get permission to use their robots in our game. We have some bad news and some good news on this front.
The Bad:
Display rights to all of the Robot Wars robots are owned by the BBC. Both they and Battlebots are rightfully protective of their intellectual property. This means that we do not have permission to use Carbide, Eruption, or Original Sin in our commercial release. All three robots will be removed from the game.
The Good:
Many of the roboteers themselves are really excited to share their unlicensed designs. We have permission from several of the teams to use their other designs from the live circuit. We should be able to get a few of these designs into the next few builds.
Cool, will it be steam?
To everyone who has given feedback, thank you! We are frantically trying to put everything together for an Alpha release.
We have been talking to lots of real-life roboteers to get permission to use their robots in our game. We have some bad news and some good news on this front.
The Bad:
Display rights to all of the Robot Wars robots are owned by the BBC. Both they and Battlebots are rightfully protective of their intellectual property. This means that we do not have permission to use Carbide, Eruption, or Original Sin in our commercial release. All three robots will be removed from the game.
The Good:
Many of the roboteers themselves are really excited to share their unlicensed designs. We have permission from several of the teams to use their other designs from the live circuit. We should be able to get a few of these designs into the next few builds.
Cool, will it be steam?
Yup - Steam will be our primary distribution platform. We are working on putting together everything we need for the Steam page right now, but we won't publish the Steam page until we have a complete BotLab where you can build robots and put them into game.
To everyone who has given feedback, thank you! We are frantically trying to put everything together for an Alpha release.
We have been talking to lots of real-life roboteers to get permission to use their robots in our game. We have some bad news and some good news on this front.
The Bad:
Display rights to all of the Robot Wars robots are owned by the BBC. Both they and Battlebots are rightfully protective of their intellectual property. This means that we do not have permission to use Carbide, Eruption, or Original Sin in our commercial release. All three robots will be removed from the game.
The Good:
Many of the roboteers themselves are really excited to share their unlicensed designs. We have permission from several of the teams to use their other designs from the live circuit. We should be able to get a few of these designs into the next few builds.
Cool, will it be steam?
Yup - Steam will be our primary distribution platform. We are working on putting together everything we need for the Steam page right now, but we won't publish the Steam page until we have a complete BotLab where you can build robots and put them into game.
Make it $9.99 early access (trust me, do not say $10.00 it looks expensive while $9.99 looks cheap) to bribe them into buying, note that you should change the price to $19.99 when 1.0 is released.
do what you need to do man. it's easy to cave into even small pressures on projects like this. you're never going to be short on people offering their two cents. I hope that you can take as much time as you can to make a quality game, but I also know that deadlines and costs and such can be very burdensome.To everyone who has given feedback, thank you! We are frantically trying to put everything together for an Alpha release.
We have been talking to lots of real-life roboteers to get permission to use their robots in our game. We have some bad news and some good news on this front.
The Bad:
Display rights to all of the Robot Wars robots are owned by the BBC. Both they and Battlebots are rightfully protective of their intellectual property. This means that we do not have permission to use Carbide, Eruption, or Original Sin in our commercial release. All three robots will be removed from the game.
The Good:
Many of the roboteers themselves are really excited to share their unlicensed designs. We have permission from several of the teams to use their other designs from the live circuit. We should be able to get a few of these designs into the next few builds.
Cool, will it be steam?
Yup - Steam will be our primary distribution platform. We are working on putting together everything we need for the Steam page right now, but we won't publish the Steam page until we have a complete BotLab where you can build robots and put them into game.
Make it $9.99 early access (trust me, do not say $10.00 it looks expensive while $9.99 looks cheap) to bribe them into buying, note that you should change the price to $19.99 when 1.0 is released.
Thanks for the tip! I’m not sure about Early Access yet. At this point we are limited more by time than funding. If we were to do Early Access, I would like to keep its time period short.
https://robot-rumble.itch.io/builds (https://robot-rumble.itch.io/builds)
https://robot-rumble.itch.io/builds (https://robot-rumble.itch.io/builds)
Lovely, thank you.
I'll test it as soon as itch.io's downloads start working again - seems their service is having some issues right now.
https://robot-rumble.itch.io/builds (https://robot-rumble.itch.io/builds)
Lovely, thank you.
I'll test it as soon as itch.io's downloads start working again - seems their service is having some issues right now.
Seems itchio/hwcdn was having issues with either my double NAT or my ISP. Had to download (slooowly) while proxying through another network. ( If you want a better CDN, hit me up on DM, that's my line of work :) ).
So, tested this for a few minutes on Gentoo Linux (Kernel 4.14.10), with my integrated Intel HD Graphics 530 (GL 4.5, GLES 3.2) and Intel i7-6700k and 32GB of RAM. I know, the graphics aren't great, but other games work okay at full HD on low graphics (I play Talos Principle on this machine quite a bit, @30FPS).
What works:
- game launches! full screen only, can't seem to window it (tried alt-enter)
- 1v1 combat launches
- botlab launches
What doesn't work:
- any sort of performance (menus are sluggish, combat view is around 5FPS)
- smoke (?) particles during combat - they get rendered with a white background
- building a robot - I get stuck on 'collision mode' selection, when I click any of the buttons I get a textured box but no wireframe and can't advance to next step
Player.log: https://q3k.org/u/9f1843023508c15946e0bd26ef9e4aa8f052a9bb140bf408be46ef58e7423872.log
If you tell me how I can get this resized to a window, I'll get you some screenshots / recordings. Oh, and any chance you could also release a 64-bit Linux build?
Thanks for the Linux build!
This is awesome
Will be able to create our own arenas for the game?
Looking good! I'm excited to see what building and driving is gonna like with the new botlab.
Luckily for me, the latest version of unity still targets Vista. ;) Just make sure there is a x86 build. You should probably edit your open post. You have not touched it in a little less than a year.
I don't think developers should be held hostage to ancient standards by people who refuse to upgrade to at least semi-recent software/hardware. There's no good reason to be running a 32 bit OS (or any version of Vista for that matter) in 2018.go to hell im running xp why dont you buy me a new computer big boy
You're running on an operating system that is no longer getting security patches. This is the equivalent of living in a house with no lock on the front door. Actually, it's more like living in a house with a hole where a front door should be, with huge neon signs pointing to the hole saying "FREE STUFF IN HERE". You don't need to buy a new PC to upgrade the operating system to a newer, safe version.I don't think developers should be held hostage to ancient standards by people who refuse to upgrade to at least semi-recent software/hardware. There's no good reason to be running a 32 bit OS (or any version of Vista for that matter) in 2018.go to hell im running xp why dont you buy me a new computer big boy
but it is 64 bit
im signing up to test
how soon after signing up for the mailing list should i expect an email that gets me through to download the alpha :heart_smiley:
The Alpha Build is live!
Alpha Trailer: https://youtu.be/pjOqj6xXuI4 (https://youtu.be/pjOqj6xXuI4)
Download the Alpha Build on itch.io: https://robot-rumble.itch.io/builds (https://robot-rumble.itch.io/builds)
Sign up for the closed beta on our website: http://www.robot-rumble.com (http://www.robot-rumble.com)
The Alpha Build is live!
Alpha Trailer: https://youtu.be/pjOqj6xXuI4 (https://youtu.be/pjOqj6xXuI4)
Download the Alpha Build on itch.io: https://robot-rumble.itch.io/builds (https://robot-rumble.itch.io/builds)
Sign up for the closed beta on our website: http://www.robot-rumble.com (http://www.robot-rumble.com)
Wow! This looks amazing! Good job everyone.
I would love to sign up for the beta but my laptop is too crappy and I have to save money for a new one
Hey, i tried to lower the resolution but even though i changed it in the settings, nothing changed and when I quit and came back into the game, it was still on the old one. Do you know how to change it?
The Alpha Build is live!
Alpha Trailer: https://youtu.be/pjOqj6xXuI4 (https://youtu.be/pjOqj6xXuI4)
Download the Alpha Build on itch.io: https://robot-rumble.itch.io/builds (https://robot-rumble.itch.io/builds)
Sign up for the closed beta on our website: http://www.robot-rumble.com (http://www.robot-rumble.com)
Wow! This looks amazing! Good job everyone.
I would love to sign up for the beta but my laptop is too crappy and I have to save money for a new one
Thank you!
Just curious, but how old is the laptop, and can it load the game? I’m trying to get a handle on how far back we can go before the game is unplayable.
Hey, so I played the most recent version this morning and I really love what you’ve done so far. The physics feel really accurate and I love the realistic sound effects. The bot builder works really well and I had fun making a couple of designs. However I do have some thoughts for improvements based on what I’ve played:
-Unless I’m missing something, I couldn’t find a way to stop spinner robots overheating once the weapon was activated, so I always broke down after a few seconds (the smoke particle effect looks really nice btw)
-Royal Robby really needs balancing adjustments imo. I know that the axe does crazy amounts of damage, but the high ground clearance and relative slowness, make it really underpowered overall. I’d recommend making it lower to the ground and drive a little faster, whilst making the axe much less damaging. The AI also doesn’t seem to know to self-right until the immobilisation counter starts
-i feel like robots get broken too quickly, and should have either more HP or do less damage generally
-when making chassis/component shapes, an arrow would be handy to remind you which way is forwards, as I accidentally built a robot facing the wrong way XD
I understand that this is just an alpha, and it’s not meant to be perfect, but I figured you might appreciate some feedback.
(This is also way better than RA3 and it’s still only in alpha)
Great work!
This game just looks better and better with each successive update. The fact it has real live competitors makes it even better IMO - Earthquake and Manta? You sure kept that a surprise!
There's a few issues I noticed, though:
- Every now and then, both robots will suddenly just disappear from the arena. I dunno how it happens, but it seems like a fairly major thing.
- If you flip Royal Robby over, he seems to forget how to move even after he self-rights. He swings his axe back and forth when the immobility counter appears, but other than that he just sits there and lets you keep flipping him or shoving him into hazards. I've actually seen him kill himself from the recoil damage of rocking back and forth while firing.
- The picture of the Test Arena in the Arena Select menu shows the old version, without all the new hazards. Speaking of which, when you're using camera 1, it's impossible to tell that there's a spike hazard thing directly underneath the camera's location until you drive into its strike zone and it wipes out a chunk of your health. I was very confused the first time it hit me.
- On the robot selection screen, some of the robots (like Theseus) are facing in the opposite direction on the turntable. It's a small thing, but it's still worth noting.
I'll have to try the build system at some point.
The Alpha Build is live!
Alpha Trailer: https://youtu.be/pjOqj6xXuI4 (https://youtu.be/pjOqj6xXuI4)
Download the Alpha Build on itch.io: https://robot-rumble.itch.io/builds (https://robot-rumble.itch.io/builds)
Sign up for the closed beta on our website: http://www.robot-rumble.com (http://www.robot-rumble.com)
Wow! This looks amazing! Good job everyone.
I would love to sign up for the beta but my laptop is too crappy and I have to save money for a new one
Thank you!
Just curious, but how old is the laptop, and can it load the game? I’m trying to get a handle on how far back we can go before the game is unplayable.
I'm using a Fujitsu Lifebook E Series. I got it (used) after my old one burned down to write repors on it. It runs win7 and I can start up the game but combat is super laggy on my end. Maybe the Laptop isn't old but crappy as hell.
Some minor feedback from what I can tell:
I tried out the botbuilder by building a flipper.
I'm glad there were tips on how to use some of the stuff. if the botlab keeps the way it is atm they should stay in as they are really helpfull.
I couldn't build a flipper but I guess that has to do with the parts not being available in the lab as of now.
I don't know what the controlls for my bot are. I know that the spacebar spun up the weapon but that's it.
I LOVE that you can shape your own components. that's something I always wanted to have in ra2.
I still have to get used to the motor size. Belted motors would be awesome to have. I couldn't line up both drivemotors on the grid for some reason tho.
and as I said before: Combat is really laggy for me but that's my laptops fault
I'm really happy this is still a work in progress. I'm used to seeing projects announced on this forum die after a year.
If I'm honest, the gameplay itself hasn't seemed to have improved that much, with my major grips being that the wedge war is still won by sitting still and, once you lose advantage against a flipper, the AI is juggling you nonstop, with very little room for recovery. Then again, I imagine gameplay details like this aren't as important to iron out at this stage in development, I just want to make sure that they're definitely going to get ironed out, at some point.
It may be too early to forecast, but are you intending on updating the game indefinitely after the intended release in 2019? I'd hate for so much effort to go to waste on a game that doesn't get polished to perfection.
Good luck with the rest of development!
it's not my computer so i can't do much of anything without permission to do so and i'd hate to screw up the man's computer trying to upgrade it to another operating system. he's big on the whole 'if it ain't broke, don't fix it' philosophy, and the fact that certain things i want to do might not work isn't going to be the thing that changes his mind.You're running on an operating system that is no longer getting security patches. This is the equivalent of living in a house with no lock on the front door. Actually, it's more like living in a house with a hole where a front door should be, with huge neon signs pointing to the hole saying "FREE STUFF IN HERE". You don't need to buy a new PC to upgrade the operating system to a newer, safe version.I don't think developers should be held hostage to ancient standards by people who refuse to upgrade to at least semi-recent software/hardware. There's no good reason to be running a 32 bit OS (or any version of Vista for that matter) in 2018.go to hell im running xp why dont you buy me a new computer big boy
but it is 64 bit
im signing up to test
Upgrade to at least windows 7 or a lightweight linux distro if you want to be supported by any software in the future. If Microsoft doesn't bother with your OS's security anymore, there's no reason why 3rd party software developers should.
it's not on the poll and it might be too late to add it-- maybe you can put it as a separate checkbox to see what people's reactions are-- but i would personally like to be able to play online with other players regardless of any effective ui or a perfect framerate or what-not. i dont care if i have to type in a host's ip address like back in the days of RA1 if it means i can play against friends in real time online. even if it lags a little. or even if 'real-time' battling isnt possible, i'd at least like to maybe be able to watch our bots fight in real-time, maybe controlled by ai we write ourselves to give me a sense of having an effect on the outcome of my match. :popcorn
anything along these lines even remotely possible? i dont care if it's not a part of the original release, even as a future add-on i'd be more than overjoyed. i could imagine something like this pushing back a potential release date sp again, if it's something that has to sit on the back burner for a later patch and release i'm more than happy with that.
i think i'm the only person on this forum who still wishes for a rean mano-y-mano online tournament of any type. so let me know if this is a even remotely feasible request. thank you!! :heart_smiley:
What are your plans on the damage side of things? As I couldn't test it I can only assume from the trailer that causing damage is possible again (like taking wheels off). You won't bring in soft body stuff tho I guess?
another thing i noticed is that the background music fades out whenever a sound effect plays, which is really annoying once you pick up on it.
Dude this is great!
Out of curiosity, how many robots will be able to be in one match? I think everyone wanted RA2 to include more than 4 robots in one match :D
I think multiplayer could be possible with parsec
Well, it wouldn't be something you'd have to consider. It would just be a solution for those who want to play the game in pseudo-online local multiplayer if you don't actually support online multiplayer.I think multiplayer could be possible with parsec
I hadn’t heard of Parsec. Thank you for mentioning it. It says that it adds 7 ms per frame, and we are already struggling to keep things under 10 ms on a strong laptop. It might be worth a shot once we have nailed down botlab-based gameplay though.
Well, it wouldn't be something you'd have to consider. It would just be a solution for those who want to play the game in pseudo-online local multiplayer if you don't actually support online multiplayer.I think multiplayer could be possible with parsec
I hadn’t heard of Parsec. Thank you for mentioning it. It says that it adds 7 ms per frame, and we are already struggling to keep things under 10 ms on a strong laptop. It might be worth a shot once we have nailed down botlab-based gameplay though.
Someone hosts their own PC and gives other people permission to control their PC (or just certain keys.)Well, it wouldn't be something you'd have to consider. It would just be a solution for those who want to play the game in pseudo-online local multiplayer if you don't actually support online multiplayer.I think multiplayer could be possible with parsec
I hadn’t heard of Parsec. Thank you for mentioning it. It says that it adds 7 ms per frame, and we are already struggling to keep things under 10 ms on a strong laptop. It might be worth a shot once we have nailed down botlab-based gameplay though.
This is really interesting. So the way it works is you take a game that already supports local multiplayer with, say, 4 Xbox controllers, and play it through a Parsec signaling server with each person having their own controller and screen?
Has anyone tried it?
Someone hosts their own PC and gives other people permission to control their PC (or just certain keys.)Well, it wouldn't be something you'd have to consider. It would just be a solution for those who want to play the game in pseudo-online local multiplayer if you don't actually support online multiplayer.I think multiplayer could be possible with parsec
I hadn’t heard of Parsec. Thank you for mentioning it. It says that it adds 7 ms per frame, and we are already struggling to keep things under 10 ms on a strong laptop. It might be worth a shot once we have nailed down botlab-based gameplay though.
This is really interesting. So the way it works is you take a game that already supports local multiplayer with, say, 4 Xbox controllers, and play it through a Parsec signaling server with each person having their own controller and screen?
Has anyone tried it?
I was one of the first to try it for RA2 ;)
https://gametechmods.com/forums/personal-tournaments/robot-wars-online-tournement/msg740486/#msg740486
https://gametechmods.com/forums/brackets-vids-and-awards/centauri-online-tournament-sbv/
Although it's the best option to do pseudo-online multiplayer/netplay in certain games that don't allow for netplay or online multiplayer (like RA2), it's incredibly far from ideal. Tails just mentioned it because he's a bit special
Just tried it out. Pretty fun, though there's not much visual indication of damage. It took me a while to figure out if I'd won my first match because I killed them or because time ran out.
Is deformation planned?
This build looks to be a really big step forward for the game. I've been playtesting recently and have found some bugs that might need some attention.
1:Attracted to pit
This bug occurs with all bots I've tested with where the AI decides to chase a spot on the pit rather than the player
2:Disappearing Screws
TR3 is the only bot I've seen do this but it does it consistently if put in this position.
3:Stuck in Ground:
This bug only seems to affect Bubblegum due to the size of its weapon. It will also do this occasionally on solid ground if it lands right.
4:Crazy Chain
If D.B MK II rotates too violently or something gets in between the chain it responds by totally freaking out.
5:Spawn Bug
This is a very specific bug that only occurs with D.B MK II and TR3 and only occurs in this arena.
Also, I haven't gone too far into depth with the botlab but the first two designs I created seemed to have the wheels clip through the floor, thus making it undriveable despite the wheels spinning.
Hopefully this information and videos below were helpful and I can't wait to see what comes in the next update :mrgreen:
BLA BLA I QUOTED THE WRONG POSThey! thats... totally reasonable.
MENTIONS AI COMBAT BASED MULTIPLAYER AND WHAT NOT.
it's not my computer so i can't do much of anything without permission to do so and i'd hate to screw up the man's computer trying to upgrade it to another operating system. he's big on the whole 'if it ain't broke, don't fix it' philosophy, and the fact that certain things i want to do might not work isn't going to be the thing that changes his mind.You're running on an operating system that is no longer getting security patches. This is the equivalent of living in a house with no lock on the front door. Actually, it's more like living in a house with a hole where a front door should be, with huge neon signs pointing to the hole saying "FREE STUFF IN HERE". You don't need to buy a new PC to upgrade the operating system to a newer, safe version.I don't think developers should be held hostage to ancient standards by people who refuse to upgrade to at least semi-recent software/hardware. There's no good reason to be running a 32 bit OS (or any version of Vista for that matter) in 2018.go to hell im running xp why dont you buy me a new computer big boy
but it is 64 bit
im signing up to test
Upgrade to at least windows 7 or a lightweight linux distro if you want to be supported by any software in the future. If Microsoft doesn't bother with your OS's security anymore, there's no reason why 3rd party software developers should.
now starting the alpha version up, i got tjis error message. i imagine this is a byproduct of having an old computer and or operating system but if this is something resolvable i would ****ing kill to know how to fix it and get this running. im clicking the right thing to open it, right?
I downloaded the alpha on my main rig. When I tryed to start a loacal match or click on the left button at all, It just crashed the game. The bot lab is nice, although it is kind of hard to build, And the last button did not seem to work.
OS:Windows Server 2019 Windows Insider Build 17744
RAM: 8GB
CPU: AMD 3800
Also i would appriciate a 32 bit build of this as well. (I can also test on XP if you make a 32 bit)
You should consider also porting this to IOS and Android, it would be the best game in this genre for Mobile.
I signed up to be a beta tester as well. Great game!
Best Regards, Asbestosstar
Dont be so quick to judge, i think its pretty new my main rig. 3.8ghz with 4 processors. I am just wantthen you do it
a 32 bit build for my other macines. It only prolly takes 5 minutes to do.
Dont be so quick to judge, i think its pretty new my main rig. 3.8ghz with 4 processors. I am just want
a 32 bit build for my other macines. It only prolly takes 5 minutes to do.
Dont be so quick to judge, i think its pretty new my main rig. 3.8ghz with 4 processors. I am just wantSo you've returned, still dumb as ever though :P
a 32 bit build for my other macines. It only prolly takes 5 minutes to do.
will we have the power to share robots also nice game
BFE 2,0 confirmed bois!
Tried the build, and im speechless. Where do i preorder the game XD
does anyone have the link for the download with carbide and original sin? I just found out they were in the game and got removed
Would it be possible to transfer models from the earlier releases when the finished game is made?does anyone have the link for the download with carbide and original sin? I just found out they were in the game and got removed
Sorry about that! We couldn’t get licensing rights for Carbide, Original Sin, or Eruption, so we removed them from the game entirely. The early pre-alpha builds with them are no longer available for download.
Would it be possible to transfer models from the earlier releases when the finished game is made?does anyone have the link for the download with carbide and original sin? I just found out they were in the game and got removed
Sorry about that! We couldn’t get licensing rights for Carbide, Original Sin, or Eruption, so we removed them from the game entirely. The early pre-alpha builds with them are no longer available for download.
I know that's not possible to do for people who haven't downloaded the demo but for those who have...
can't we make the chassis using different shapes in this version?
Can you import RA2 designs into Robot Rumble as well as custom textures and decals?no, 2 different games
Can you import RA2 designs into Robot Rumble as well as custom textures and decals?no, 2 different games
what do you save images as in order to use them on bots in Robot Rumble?
If you put out some documentation on how RR2's bot files are structured, I'm sure someone here could cook up a converter on their own at some point, if there was any demand for such a thing. Just a thought.Can you import RA2 designs into Robot Rumble as well as custom textures and decals?no, 2 different games
We haven't really thought about doing that, and to be honest, it would be a lot of work to try to write and troubleshoot a custom converter that would probably delay RR2 quite a bit.
That being said, I'm hoping you guys like the new BotLab. Both @tashic and I are working on the BotLab right now, with the following in the works:
1. Texture painting: selecting and painting custom decals on faces.
2. Texture saving and loading: exporting UV texture maps for editing in an external program (Photoshop/GIMP), then re-importing the into the game.
3. Getting BotLab robots fighting each other.
Once these are done, I am going to attempt to tackle importing custom .obj files as shapes. If we can figure out how to do this, then users should have the ability to create a 3D model and UV map it in Maya/Blender/3DS Max/Modo/ZBrush/whatever, texture it in Substance Painter/Photoshop/GIMP/whatever, then bring it into the game as a custom shape. If we can get this working, it should be possible for users to create their own movie-quality robots that they can then share with other users via an .RR2Bot file.
I know that this doesn't address the original desire to import old robots, but I hope it will make for some MUCH nicer looking new ones.
If you put out some documentation on how RR2's bot files are structured, I'm sure someone here could cook up a converter on their own at some point, if there was any demand for such a thing. Just a thought.Can you import RA2 designs into Robot Rumble as well as custom textures and decals?no, 2 different games
We haven't really thought about doing that, and to be honest, it would be a lot of work to try to write and troubleshoot a custom converter that would probably delay RR2 quite a bit.
That being said, I'm hoping you guys like the new BotLab. Both @tashic and I are working on the BotLab right now, with the following in the works:
1. Texture painting: selecting and painting custom decals on faces.
2. Texture saving and loading: exporting UV texture maps for editing in an external program (Photoshop/GIMP), then re-importing the into the game.
3. Getting BotLab robots fighting each other.
Once these are done, I am going to attempt to tackle importing custom .obj files as shapes. If we can figure out how to do this, then users should have the ability to create a 3D model and UV map it in Maya/Blender/3DS Max/Modo/ZBrush/whatever, texture it in Substance Painter/Photoshop/GIMP/whatever, then bring it into the game as a custom shape. If we can get this working, it should be possible for users to create their own movie-quality robots that they can then share with other users via an .RR2Bot file.
I know that this doesn't address the original desire to import old robots, but I hope it will make for some MUCH nicer looking new ones.
I tried Robot Rumble 2.0, and I got some results...Dont have a sh** computer
It glitched my computer to death. Even with simple bots. :(:(:(:(:(
I don't know about you, but this game's a hazard...to my computer at least. I'll try it on a different one, but until then, utter disappointment.
This should really be under Sight News and Feedback, but an error occurred. Sorry.
If this is a bump- sorry.
I tried Robot Rumble 2.0. It literally killed my computer with glitches. Can that be fixed, please?
What exactly does the game do to your computer? And when doing what?
It will help us fix things if you can be more specific.
Also what link are you talking about?
This has to be bait haha, whose multi is thisWhat exactly does the game do to your computer? And when doing what?
It will help us fix things if you can be more specific.
Also what link are you talking about?
...So I downloaded the gamy to my tiny laptop, and every time I try to fight, or build a bot, it glitches!
Is there a way to fix the glitching?
Also, I tried to send the download of RR2 to GTM, and it reported a virus. That could be linked to the glitching.
This has to be bait haha, whose multi is thisWhat exactly does the game do to your computer? And when doing what?
It will help us fix things if you can be more specific.
Also what link are you talking about?
...So I downloaded the gamy to my tiny laptop, and every time I try to fight, or build a bot, it glitches!
Is there a way to fix the glitching?
Also, I tried to send the download of RR2 to GTM, and it reported a virus. That could be linked to the glitching.
Did the game freeze when starting a battle/going to the botlab or does it start and mess with things (physics stuff? model/texture weirdness?)?
Did your antivirus report the virus or whatever you used to upload the download did?
If the virus was in the game the antivirus should have found it before you could open the game in the first place.
Did the game freeze when starting a battle/going to the botlab or does it start and mess with things (physics stuff? model/texture weirdness?)?
Did your antivirus report the virus or whatever you used to upload the download did?
If the virus was in the game the antivirus should have found it before you could open the game in the first place.
Game glitches like there's too much movement. Other than that, graphics are GREAT!
AntiVirus reported that it found a virus before the second time I played it. I put it to work removing it, and it was removed from my game.
Screen resolution is in settings, right?
Anyway, the computer I'm trying RR on is a small Google laptop.
Only google laptops i know that exist are Chromebooks and Pixelbook.
They have Google OS and it isnt compatible with any windows program
New BotLab trailer is up!The progress in the vid shown is huge next to first release of the game, keep up the work!
https://www.youtube.com/watch?v=RD0nETeRKAg (https://www.youtube.com/watch?v=RD0nETeRKAg)
New Steam page is up!
https://store.steampowered.com/app/884180/Robot_Rumble_2/ (https://store.steampowered.com/app/884180/Robot_Rumble_2/)
Merry Christmas. :)
Texture painting is now working, and we have a few more things to do with the robot workshop before we shift focus to asset production.
I've been reading through Serge's mod to remove a bunch of built-in RA2 limitations in the thread below. There is a discussion about whether or not the game should prevent components from intersecting each other. It is currently on our list of things to implement for RR2, but we haven't done it yet. It looks like a lot of people would rather have the component clipping check disabled, and just leave things up to whoever is running the tournament to make sure that robots are legal.I think it should be like how DSL-IRL RA2 tourneys are run. With the clipping allowed, but as long as it can be done in real life and extenders/plates that intersect can be cut IRL to give slot, allow things that otherwise won't be possible due to game limitation but possible in real life, and of course, no intersecting motors or batteries with another of those
What do you think? Should RR2 check to make sure you don't have one component intersecting with another component?
https://gametechmods.com/forums/modifications/robot-arena-2-component-freedom-(remove-7-component-limit!)/ (https://gametechmods.com/forums/modifications/robot-arena-2-component-freedom-(remove-7-component-limit!)/)
PS - Serge, incredible work! :beer:
I've been reading through Serge's mod to remove a bunch of built-in RA2 limitations in the thread below. There is a discussion about whether or not the game should prevent components from intersecting each other. It is currently on our list of things to implement for RR2, but we haven't done it yet. It looks like a lot of people would rather have the component clipping check disabled, and just leave things up to whoever is running the tournament to make sure that robots are legal.I think it should be like how DSL-IRL RA2 tourneys are run. With the clipping allowed, but as long as it can be done in real life and extenders/plates that intersect can be cut IRL to give slot, allow things that otherwise won't be possible due to game limitation but possible in real life, and of course, no intersecting motors or batteries with another of those
What do you think? Should RR2 check to make sure you don't have one component intersecting with another component?
https://gametechmods.com/forums/modifications/robot-arena-2-component-freedom-(remove-7-component-limit!)/ (https://gametechmods.com/forums/modifications/robot-arena-2-component-freedom-(remove-7-component-limit!)/)
PS - Serge, incredible work! :beer:
please please please do NOT allow parts to clip. We already have one buggy game that does this when it never should have in the first place. We want to have to put thought into where components are placed, otherwise we might as well just build stuff in CAD.
PLEASE address the failings of ra2, dont mimic them for the sake of familiarity!
please please please do NOT allow parts to clip. We already have one buggy game that does this when it never should have in the first place. We want to have to put thought into where components are placed, otherwise we might as well just build stuff in CAD.
PLEASE address the failings of ra2, dont mimic them for the sake of familiarity!
Roger! I’ll take a look at it this weekend. :smile:
We’re trying to figure out the CAD->RR2 workflow in parallel to this.
please please please do NOT allow parts to clip. We already have one buggy game that does this when it never should have in the first place. We want to have to put thought into where components are placed, otherwise we might as well just build stuff in CAD.
PLEASE address the failings of ra2, dont mimic them for the sake of familiarity!
Roger! I’ll take a look at it this weekend. :smile:
We’re trying to figure out the CAD->RR2 workflow in parallel to this.
A pretty standard output from all sorts of CAD packages is a .dxf file, which is generally a 2D output of a part. Being able to import .dxf files and set the scaling/sizing on them somehow, and extrude them to a given thickness, would be an amazing and easy to use tool in comparison to the usual process of getting new parts into RA2. Like I have a lot of spinning bar ideas that I'd love to test out, but don't want to spend the money/time/effort to test them in the limited environment of real robotics. This would let me do a great apples to apples comparison.
please please please do NOT allow parts to clip. We already have one buggy game that does this when it never should have in the first place. We want to have to put thought into where components are placed, otherwise we might as well just build stuff in CAD.
PLEASE address the failings of ra2, dont mimic them for the sake of familiarity!
Roger! I’ll take a look at it this weekend. :smile:
We’re trying to figure out the CAD->RR2 workflow in parallel to this.
A pretty standard output from all sorts of CAD packages is a .dxf file, which is generally a 2D output of a part. Being able to import .dxf files and set the scaling/sizing on them somehow, and extrude them to a given thickness, would be an amazing and easy to use tool in comparison to the usual process of getting new parts into RA2. Like I have a lot of spinning bar ideas that I'd love to test out, but don't want to spend the money/time/effort to test them in the limited environment of real robotics. This would let me do a great apples to apples comparison.
Sorry for the confusion! Rather than "CAD->RR2 workflow", I should have said "3D surface modeling (Blender, Max, Maya, etc)->RR2 workflow". At some point the CAD output needs to be converted into a bunch of low poly triangles for use in the game, and rather than reinventing the wheel, I would rather leverage software created by a professional.
When I'm modeling parts for the game, I convert mechanical drawings to images, insert them as reference images in blender, then create a low-poly version using the 2D reference images. I have tried bringing in parts created in TinkerCad and Fusion 360, but the geometries created by those programs are unsatisfactory for use in the game. I'm hoping to get to the point where users can create stuff in Blender, pull it into a Unity project, export it as an asset bundle, then import it into RR2 for use in the robot workshop. I haven't tried it yet, but this should work in principle.
Regarding using RR2 to test out new spinner shapes, be wary of the limitations of the physics engine. A 6000 RPM spinner revolves at 100 revolutions per second. Right now RR2's physics simulation is running at 400 updates per second, so the spinner would spin 90 degrees in between each update. This creates all sorts of problems when it comes to collision detection and resolution. As much as I would like to have a perfect spinner simulator, RR2 isn't going to be it. Realistically speaking, I'm hoping to have something that my students can use to mock up ideas early on in their design process, to see how different robot styles might play against each other.
This looks so professionally done, can`t wait to play this
Free component-modding tools? Shut up and take my money!
Could you elaborate on the "daisy-chaining", though? I'm not sure how that's supposed to work.
I love the idea of being able to openly create components through the component tool. I feel that if this is going to be in-placed, I would love to see support/interrogation of the Steam workshop or at least have somewhere on the internet for player and mod creators to share the components they've made through this tool, for other users to download and play around with.
GTM sounds good. Steam is also good imoI love the idea of being able to openly create components through the component tool. I feel that if this is going to be in-placed, I would love to see support/interrogation of the Steam workshop or at least have somewhere on the internet for player and mod creators to share the components they've made through this tool, for other users to download and play around with.
Agreed. Assuming we can get this working, we are open to ideas on where to host the repository. Maybe gametechmods? :smile:
This looks incredible, gentlemen. Just watched the video and want to express my support. I'm excited for this.
“Daisy chaining” already works in a primitive way in the Alpha release. You can add components to an axle, but you can also “weld” anything onto any other surface. Want to make spiked wheels? Just add spikes to the surface of the wheel.ah so its like attaching two components together except without ap's so stuff can go anywhere?
“Daisy chaining” already works in a primitive way in the Alpha release. You can add components to an axle, but you can also “weld” anything onto any other surface. Want to make spiked wheels? Just add spikes to the surface of the wheel.ah so its like attaching two components together except without ap's so stuff can go anywhere?
Pretty sure it's the same build from 05/09/2018 as before. Excited for new updates and beta stuff soon though!
That's what I thought, cool. (I'm from the UK so that date I wrote is 05 Sept and not 09 May ha)
for i in range(1,100)
if i == 42 then continue
print("Considering " + i + "...")
end for
//Loop through every movable object
for(objName : movingObjs)
{
//if moving objects should be stopped
if (!on)
{
//Stop the velocity of the physics component of the moving object
CallNativeFunc(objName,"ScrollingObject","Update");
} else
{
//Otherwise re-initiate the physics component of the moving object to start the movement again
CallNativeFunc(objName,"ScrollingObject","Start");
}
}
How much freedom are we giving?
Will it be a set of defined functions which we edit the contents of?
Or will there be a lot more available?
The issue with RA2 AI is that you could modify parameters which were unrelated to movement/weaponry and make instant win AIs.
I almost feel like a drag and drop overlay might be more intuitive from a basic programming level.
I echo what Badger says. I imagine you can hide those values from the user.
The other disputed factor in RA2 was movements that were not "human reproducible" along the lines of rapidly switching a motor on and off to save power or doing fancy things such as meltybrain.
Sounds like you have a pretty good grasp of how it should we to though. I have very little preference for either language. What sort of math libraries do they include? I imagine that might be a factor in more complicated routines.
The issue with Meltybrain in RA2 is that it's ONLY possible with AI. There's no real way to do it (at least that isn't cludgy as hell) for a player-controlled bot. If you can find a way to get meltybrain to work for both player and AI driven bots, I can't see why it would be an issueI echo what Badger says. I imagine you can hide those values from the user.
The other disputed factor in RA2 was movements that were not "human reproducible" along the lines of rapidly switching a motor on and off to save power or doing fancy things such as meltybrain.
Sounds like you have a pretty good grasp of how it should we to though. I have very little preference for either language. What sort of math libraries do they include? I imagine that might be a factor in more complicated routines.
Uh oh. I had fully assumed that people would be okay with melty brain controls.
We can do something where state is only updated and made available to the AI every 0.1 seconds, so even though the AI can run at 60 FPS, it is only reading new state information at 10 FPS. Or we could do it in reverse, where state is read every 60 fps, but control signals are only applied to the motors every 10 FPS.
I fully expect that good AI controls would be able to kick a human player's butt. At least that is what I had in my head -- when competing against other players, you are putting your very best AI against their very best AI.
The issue with Meltybrain in RA2 is that it's ONLY possible with AI. There's no real way to do it (at least that isn't cludgy as hell) for a player-controlled bot. If you can find a way to get meltybrain to work for both player and AI driven bots, I can't see why it would be an issueI echo what Badger says. I imagine you can hide those values from the user.
The other disputed factor in RA2 was movements that were not "human reproducible" along the lines of rapidly switching a motor on and off to save power or doing fancy things such as meltybrain.
Sounds like you have a pretty good grasp of how it should we to though. I have very little preference for either language. What sort of math libraries do they include? I imagine that might be a factor in more complicated routines.
Uh oh. I had fully assumed that people would be okay with melty brain controls.
We can do something where state is only updated and made available to the AI every 0.1 seconds, so even though the AI can run at 60 FPS, it is only reading new state information at 10 FPS. Or we could do it in reverse, where state is read every 60 fps, but control signals are only applied to the motors every 10 FPS.
I fully expect that good AI controls would be able to kick a human player's butt. At least that is what I had in my head -- when competing against other players, you are putting your very best AI against their very best AI.
How complex is the game's AI going to be? Will it be like RA2, where the robots more or less just drive straight at each other, or will you be able to program more complex behaviours? Things like pushing opponents towards hazards, timing flips instead of hitting the button instantly, preserving CO2 when it starts to run out, trying to aim for specific points like wheels...
Basically, we've covered that the AI shouldn't be able to do anything that a human player can't. But ideally, the opposite should be true, and human's shouldn't be able to do anything that an AI can't. I know that's unlikely, but the more lifelike the AI is, the better, IMO. It would prevent what you get in RA2 sometimes, where two robots with equal wedginess just push each other slowly round in a circle for three minutes.
What if we use actual artificial intelligence?How complex is the game's AI going to be? Will it be like RA2, where the robots more or less just drive straight at each other, or will you be able to program more complex behaviours? Things like pushing opponents towards hazards, timing flips instead of hitting the button instantly, preserving CO2 when it starts to run out, trying to aim for specific points like wheels...
Basically, we've covered that the AI shouldn't be able to do anything that a human player can't. But ideally, the opposite should be true, and human's shouldn't be able to do anything that an AI can't. I know that's unlikely, but the more lifelike the AI is, the better, IMO. It would prevent what you get in RA2 sometimes, where two robots with equal wedginess just push each other slowly round in a circle for three minutes.
Caveat: We are going with miniscript for now, and I haven’t explored the language yet. Bearing this in mind, I can see two limitations at this point:
1. AI scripts are going to be limited to a single file — no includes.
2. The available inputs to the AI are whatever data we choose to include from the native code (C# in this case) side. I am totally open to taking suggestions at this point. We can choose to be more precise than just driving at the chassis origin or COM. If we want, we can choose to target the nearest motor, or get a list of all of the motors and target the farthest one. At this point we don’t have anything coded, so anything is technically possible. It is just a matter of converting ideas into reality.
What if we use actual artificial intelligence?How complex is the game's AI going to be? Will it be like RA2, where the robots more or less just drive straight at each other, or will you be able to program more complex behaviours? Things like pushing opponents towards hazards, timing flips instead of hitting the button instantly, preserving CO2 when it starts to run out, trying to aim for specific points like wheels...
Basically, we've covered that the AI shouldn't be able to do anything that a human player can't. But ideally, the opposite should be true, and human's shouldn't be able to do anything that an AI can't. I know that's unlikely, but the more lifelike the AI is, the better, IMO. It would prevent what you get in RA2 sometimes, where two robots with equal wedginess just push each other slowly round in a circle for three minutes.
Caveat: We are going with miniscript for now, and I haven’t explored the language yet. Bearing this in mind, I can see two limitations at this point:
1. AI scripts are going to be limited to a single file — no includes.
2. The available inputs to the AI are whatever data we choose to include from the native code (C# in this case) side. I am totally open to taking suggestions at this point. We can choose to be more precise than just driving at the chassis origin or COM. If we want, we can choose to target the nearest motor, or get a list of all of the motors and target the farthest one. At this point we don’t have anything coded, so anything is technically possible. It is just a matter of converting ideas into reality.
Take Google's Deep mind AI, and use it in this game, this specific AI can learn by itself, and it has taught itself how to walk, so I think it could teach itself to play RR2, but it's probably impossible to doWhat if we use actual artificial intelligence?How complex is the game's AI going to be? Will it be like RA2, where the robots more or less just drive straight at each other, or will you be able to program more complex behaviours? Things like pushing opponents towards hazards, timing flips instead of hitting the button instantly, preserving CO2 when it starts to run out, trying to aim for specific points like wheels...
Basically, we've covered that the AI shouldn't be able to do anything that a human player can't. But ideally, the opposite should be true, and human's shouldn't be able to do anything that an AI can't. I know that's unlikely, but the more lifelike the AI is, the better, IMO. It would prevent what you get in RA2 sometimes, where two robots with equal wedginess just push each other slowly round in a circle for three minutes.
Caveat: We are going with miniscript for now, and I haven’t explored the language yet. Bearing this in mind, I can see two limitations at this point:
1. AI scripts are going to be limited to a single file — no includes.
2. The available inputs to the AI are whatever data we choose to include from the native code (C# in this case) side. I am totally open to taking suggestions at this point. We can choose to be more precise than just driving at the chassis origin or COM. If we want, we can choose to target the nearest motor, or get a list of all of the motors and target the farthest one. At this point we don’t have anything coded, so anything is technically possible. It is just a matter of converting ideas into reality.
What did you have in mind?
Take Google's Deep mind AI, and use it in this game, this specific AI can learn by itself, and it has taught itself how to walk, so I think it could teach itself to play RR2, but it's probably impossible to doWhat if we use actual artificial intelligence?How complex is the game's AI going to be? Will it be like RA2, where the robots more or less just drive straight at each other, or will you be able to program more complex behaviours? Things like pushing opponents towards hazards, timing flips instead of hitting the button instantly, preserving CO2 when it starts to run out, trying to aim for specific points like wheels...
Basically, we've covered that the AI shouldn't be able to do anything that a human player can't. But ideally, the opposite should be true, and human's shouldn't be able to do anything that an AI can't. I know that's unlikely, but the more lifelike the AI is, the better, IMO. It would prevent what you get in RA2 sometimes, where two robots with equal wedginess just push each other slowly round in a circle for three minutes.
Caveat: We are going with miniscript for now, and I haven’t explored the language yet. Bearing this in mind, I can see two limitations at this point:
1. AI scripts are going to be limited to a single file — no includes.
2. The available inputs to the AI are whatever data we choose to include from the native code (C# in this case) side. I am totally open to taking suggestions at this point. We can choose to be more precise than just driving at the chassis origin or COM. If we want, we can choose to target the nearest motor, or get a list of all of the motors and target the farthest one. At this point we don’t have anything coded, so anything is technically possible. It is just a matter of converting ideas into reality.
What did you have in mind?
Not sure if this has been mentioned, but will there be basic default AI scripts for different weapon types that the player can apply straight to a robot? Just thinking for players who might find writing AI scripts to be difficult, if they’ve never done any scripting or basic programming. That said, I did look up MiniScript and it looks pretty simple to use, even compared to python.
while 1
hRaw = controlSignal
vRaw = dotProduct
spinnerOn = false
wait(0.1)
end while
I know its a buttload of extra work and also that I'm a bit late to the party but I think the most ideal way to program robots would be through a graphical language. Those tend to be much more friendly towards those that aren't familiar with programming (and would also be more familiar to people who use stuff like labview).
If you were to come up with your own icons it would probably be possible to have a 1-to-1 correspondence to miniscript (so at least a transpiler could be easy). Maybe just keep this as a suggestion for when after all the more important stuff is finished.
Quick suggestion: It might be a good idea to put the selectable bots in a list of some sort or another, instead of putting all the possible options on the screen at once. I think it'll look cleaner, and it will scale better with more bots than your current solution. Maybe look at how either RA2 or Robot Wars: Extreme Destruction do this. Slightly different implementations of the same idea.
I'm looking forward to testing the new build 👍
PS - Serge, incredible work! :beer:
Feedback:
- Default Windows desktop 64-bit.exe isn't a very friendly name for the game's .exe.
- Windows defender warned me about the file being potentially malicious. I'm sure it's a false flag but this is the first time this has happened to me, so it might be alarming enough to scare some potential players away, assuming I'm not the only one getting this
- A lot of the time both bots just refuse to move after the match starts. I noticed that this happened more frequently when playing as/against Theseus or Royal Robby.
- Both Earthquake and Manta's flippers seem to be non-functional, aside from draining gas.
- Royal Robby's axe has a nasty habit of just flinging itself into space for no reason when fired, much like the Firestorm flipper glitch in DSL2.1.
- As a minor balance note, I'd love to see Royal Robby have a lower ground clearance so he can actually get under the sides of some buts, like Terrorhurtz IRL. As of right now he's mostly useless against anything with a wedge.
Enjoying what I've played of the new build so far! Am I right in thinking there's no way to create flippers in the botlab at the moment though, or am I missing
something?
Edit: On another note, it seems that flippers in this build aren't working full stop, whether controlled by player or AI. Tested with Earthquake, Manta and TR3. Pressing the flip button decreases the gas meter, but doesn't do anything.
Thanks for responding to my feedback, the build is working a lot better now.
A few more things I've noticed:
- Human controller flipper bots seem to have their weapons still controlled by AI, as in they fire without user input
- Inverted bots only fire their weapon when the countdown starts. It would be nice for the AI to behave more like they do in RA2, where there is a toggleable 'invertible' setting, where if false the bot fires it's weapon until it is uninverted.
- Royal Robby doesn't seem to have a weapon firing sound effect
- When you're trapped under the flipper of an AI, they seem to spam fire their weapon fruitlessly until they run out of CO2 (screenshot of the positioning I'm talking about is attached). Maybe add a short cooldown for the AI firing their weapon, and only let them fire again once their weapon has fully/mostly retracted? Just a thought.
- I think you've been a bit stingy with the CO2 allowance for each bot, but that's personal preference. Maybe instead of a hard limit, the flip power (and CO2 useage) decreases non-linearly, so later flips are weaker but use less CO2 (due to the pressure having decreased as a result of running low).
Hope that helps 👍
I'm enjoying this version so far, the only problem being that the bot lab is super laggy for me, which might just be my computer.
Feedback-
Royal Robby is super glitchy, and randomly flies into space sometimes after firing the axe. Also, it seems to have way too much ground clearance, and no beta-style tail to keep it from flopping, even when dealing a not glitchy hit.
Bubblegum feels broken, since it seems like its impossible to destabilize it, and it still does RA2 damage by just grinding away and doing nothing while the opponent dies trying to kill it
Theseus' AI has absolutely no clue what to do when its flipped over and just drives around aimlessly
Sometimes robots will just sit there and do nothing after outwedging each other
gameplay seems pretty nice and i like what you got for the botlab so far (especially those scaleable shapes)
it seems D.B 2's flail tends to go a bit crazy during fights sometimes
i have 2 questions:
-what is the Temp stat bar for ? is it something related to pneumatics ?
-is this like RA2 where you need the weapon components to do damage (e.g adding spikes at the end of a bar) or can i just spin a rescaled cube shape as a bar spinner and it will still hurt sh** ?
I'm enjoying the new RR2 version. Keep it up.
I'm enjoying the new RR2 version. Keep it up.
Glad to hear, and thank you!
I'm enjoying the new RR2 version. Keep it up.
Glad to hear, and thank you!
Since I know you're in the RR2 building community, I have something to ask- What gave you the idea to make RR2?
I'm enjoying the new RR2 version. Keep it up.
Glad to hear, and thank you!
Since I know you're in the RR2 building community, I have something to ask- What gave you the idea to make RR2?
Great question! It originally started a few years ago with our school's robot combat club. We do one competition a year with 85 pound robots. Our students typically finish their robots at the last minute, and typically have never driven their robots before we put them into the arena. Since the winner of a round is often determined by the better driver, I figured we could have a huge advantage if our drivers had practiced before the actual competition.
Thus RR2 was born.
Since then the game has morphed into more than a robot driving simulator, but I still intend to use it on the first day we meet next school year to help students figure out what designs work. Right now we are working on wiring up multiplayer controls, and I am super excited for the day when we can give each student a controller and have them go 1 on 1 in an arena with controllers that are pretty close to the Spektrum DX6's that we use IRL.
Fun is important, but the core game also needs to be grounded in reality in order to be useful as a trainer.
You must be some sort of guy with superpowers, ‘cause this game you’re making is mind-blowing.
good progress, i cant drive my bots tho
ra2's successor is finally here
Apanx would undoubtedly be the first guy you should go to on that frontra2's successor is finally here
We’re trying! Hopefully by launch time we are worthy.
Speaking of that, I am looking to put together a team of RA2 AI experts to work on the usability of the RR2 AI system. My goal is to capture all of the possible inputs a player want to have for their robot’s AI.
Any recommendations on who I should ask for help?
ra2's successor is finally hereJust saying, but i may still play RA2 and host tournaments on there after RR2. Like, RR2 is great, but RA2 also feels like a good classic to me, and Idk if my laptop will lag running RR2 or not
I wire them up, but they dont move in test area or battlesgood progress, i cant drive my bots tho
Uh oh. That's not right. Are you using the latest Alpha version 2.01? What exactly is going wrong?
Hey, Kix. I can send you a download of the latest version, if you want it...i mean its pretty much the same as the one i downloaded
I wire them up, but they dont move in test area or battlesgood progress, i cant drive my bots tho
Uh oh. That's not right. Are you using the latest Alpha version 2.01? What exactly is going wrong?Hey, Kix. I can send you a download of the latest version, if you want it...i mean its pretty much the same as the one i downloaded
I wire them up, but they dont move in test area or battlesgood progress, i cant drive my bots tho
Uh oh. That's not right. Are you using the latest Alpha version 2.01? What exactly is going wrong?Hey, Kix. I can send you a download of the latest version, if you want it...i mean its pretty much the same as the one i downloaded
I'm not sure if you saw this on the other thread, but maybe this will help? Double posting the instructions here. Please let me know if this doesn't work for you, and we will do some more advanced troubleshooting.
@tashic is working on motor wiring now. It is complicated, and taking a while to sort through.
Stuff that should work right now:
1. Attach a couple of AmpFlow motors, one or the left wheel and one for the right wheel.
2. Attach wheels to the motor attachment points. You will probably need to rotate the view to get the wheels to snap to the axles.
3. Go over a few screens to the "Controls" tab. Select the motor on the left side of the screen, and click "Left Drive Motor". Select the motor on the right side of the screen and click "Right Drive Motor". The game assumes that the forward direction for the robot is forward the rusty green lathe in the back of the room.
4. Click on the game controller icon at the top of the screen to test the controls.
5. Use WASD to drive.
ra2's successor is finally hereJust saying, but i may still play RA2 and host tournaments on there after RR2. Like, RR2 is great, but RA2 also feels like a good classic to me, and Idk if my laptop will lag running RR2 or not
booted up the new demo, some bugs ive found
-manta's flipper and bubblegum in general are rather buggy and like to clip their parts into each other leading to physics weirdness
-bubblegum and crippling depression's weapons spin the wrong direction
-ai robots seem to have a problem navigating around the pit cover? like when they drive over it they seem to be stuck navigating in that one small square until another robot pushes them out
-spinner sound effects do not stop when a match is restarted, leading to the same sfx being overlayed multiple times
-ai flippers cannot self-right
-royal robby's axe retracts too fast for its own good imo
-floor spikes seem to do too much damage
-ive had matches where ballerina's weapon won't spin, for some reason. i think this has something to do with the aforementioned sfx bug
I can play the game on Internet site right? Because I haven't tried it yet as I assume I have to download for it, and I don't want to download updates a lot every time a new version comes out tbh, considering the stage of the game now. If it's Internet though, I may be able to try on late April, because RL stuffra2's successor is finally hereJust saying, but i may still play RA2 and host tournaments on there after RR2. Like, RR2 is great, but RA2 also feels like a good classic to me, and Idk if my laptop will lag running RR2 or not
I totally respect that. RA2 is awesome. It has an incredible community with unheard-of longevity.
I wouldn't give up on the laptop though. I'm doing all of my game dev on a laptop, and am targeting a 2013 MacBook Air with 8 GB of RAM as the minimum. Would you mind trying the game on your laptop and letting us know how it goes?
Apanx would undoubtedly be the first guy you should go to on that frontra2's successor is finally here
We’re trying! Hopefully by launch time we are worthy.
Speaking of that, I am looking to put together a team of RA2 AI experts to work on the usability of the RR2 AI system. My goal is to capture all of the possible inputs a player want to have for their robot’s AI.
Any recommendations on who I should ask for help?
I can play the game on Internet site right? Because I haven't tried it yet as I assume I have to download for it, and I don't want to download updates a lot every time a new version comes out tbh, considering the stage of the game now. If it's Internet though, I may be able to try on late April, because RL stuffra2's successor is finally hereJust saying, but i may still play RA2 and host tournaments on there after RR2. Like, RR2 is great, but RA2 also feels like a good classic to me, and Idk if my laptop will lag running RR2 or not
I totally respect that. RA2 is awesome. It has an incredible community with unheard-of longevity.
I wouldn't give up on the laptop though. I'm doing all of my game dev on a laptop, and am targeting a 2013 MacBook Air with 8 GB of RAM as the minimum. Would you mind trying the game on your laptop and letting us know how it goes?
Ive seen it, dw i have done it, yet to no availI wire them up, but they dont move in test area or battlesgood progress, i cant drive my bots tho
Uh oh. That's not right. Are you using the latest Alpha version 2.01? What exactly is going wrong?Hey, Kix. I can send you a download of the latest version, if you want it...i mean its pretty much the same as the one i downloaded
I'm not sure if you saw this on the other thread, but maybe this will help? Double posting the instructions here. Please let me know if this doesn't work for you, and we will do some more advanced troubleshooting.
@tashic is working on motor wiring now. It is complicated, and taking a while to sort through.
Stuff that should work right now:
1. Attach a couple of AmpFlow motors, one or the left wheel and one for the right wheel.
2. Attach wheels to the motor attachment points. You will probably need to rotate the view to get the wheels to snap to the axles.
3. Go over a few screens to the "Controls" tab. Select the motor on the left side of the screen, and click "Left Drive Motor". Select the motor on the right side of the screen and click "Right Drive Motor". The game assumes that the forward direction for the robot is forward the rusty green lathe in the back of the room.
4. Click on the game controller icon at the top of the screen to test the controls.
5. Use WASD to drive.
Ive seen it, dw i have done it, yet to no availI wire them up, but they dont move in test area or battlesgood progress, i cant drive my bots tho
Uh oh. That's not right. Are you using the latest Alpha version 2.01? What exactly is going wrong?Hey, Kix. I can send you a download of the latest version, if you want it...i mean its pretty much the same as the one i downloaded
I'm not sure if you saw this on the other thread, but maybe this will help? Double posting the instructions here. Please let me know if this doesn't work for you, and we will do some more advanced troubleshooting.
@tashic is working on motor wiring now. It is complicated, and taking a while to sort through.
Stuff that should work right now:
1. Attach a couple of AmpFlow motors, one or the left wheel and one for the right wheel.
2. Attach wheels to the motor attachment points. You will probably need to rotate the view to get the wheels to snap to the axles.
3. Go over a few screens to the "Controls" tab. Select the motor on the left side of the screen, and click "Left Drive Motor". Select the motor on the right side of the screen and click "Right Drive Motor". The game assumes that the forward direction for the robot is forward the rusty green lathe in the back of the room.
4. Click on the game controller icon at the top of the screen to test the controls.
5. Use WASD to drive.
Im the test bot area (after i press the controller icon
I did the same thing for my bot IronTail. Works great.Im the test bot area (after i press the controller icon
The first thing that comes to mind is that maybe the wheels aren’t attached to the axle correctly. Is it possible that they are affixed to the body of the motor instead? Maybe try mounting a motor vertically, then attaching a bar spinner to the axle, then calling the motor a drive motor?
(http://www.robot-rumble.com/assigningabarspinner.gif)
The following is a list of all of the inputs I think an AI would need to make decisions on which tactic to choose:
The following is a list of all of the inputs I think an AI would need to make decisions on which tactic to choose:
There should probably be a separate item between 5 & 6 that checks for the currently attainable win condition (so as to not waste processing power on edge location on closed arenas and whatnot).
But to be honest, while a list is nice and all, it's kinda hard to see the whole picture without those fitting in multiple flowcharts (immobility checker should run concurrently with the other combat functions, for example).
The following is a list of all of the inputs I think an AI would need to make decisions on which tactic to choose:
There should probably be a separate item between 5 & 6 that checks for the currently attainable win condition (so as to not waste processing power on edge location on closed arenas and whatnot).
But to be honest, while a list is nice and all, it's kinda hard to see the whole picture without those fitting in multiple flowcharts (immobility checker should run concurrently with the other combat functions, for example).
This one goes out to all of the AI programmers in the crowd. I need your help! Please let me know if I am missing anything!Maybe, for robots with CO2, how much they have left? So if they start running out, maybe they prioritise self-righting over mindlessly swinging at anything in the vicinity, and when they run out, they know to stop firing the weapon. Robots in RA2 will keep firing their pistons long after their CO2 has run out.
The following is a list of all of the inputs I think an AI would need to make decisions on which tactic to choose:
1. position and rotation of self (in 3D world space)
2. position and rotation of nearest enemy (in 3D world space)
3. position of nearest waypoint from navmesh (in 3D world space)
[Example: Distance to nearest enemy is computed using #1 and #2.]
4. list of our own motors
5. list of our own smart zones
[Example: If all of our weapon motors are gone, then switch to shoving.]
6. location of nearest edge
[Used for pushing battles.]
7. location of scoring zone
[Used for "king of the hill" arenas.]
8. time of my last good hit on enemy
[To decide if my attacks are working.]
9. self immobile time
10. self isImmobile
11. nearest enemy immobile time
If we do this right, everything that an AI needs could be derived from the above inputs.
Am I missing anything?
This one goes out to all of the AI programmers in the crowd. I need your help! Please let me know if I am missing anything!Maybe, for robots with CO2, how much they have left? So if they start running out, maybe they prioritise self-righting over mindlessly swinging at anything in the vicinity, and when they run out, they know to stop firing the weapon. Robots in RA2 will keep firing their pistons long after their CO2 has run out.
The following is a list of all of the inputs I think an AI would need to make decisions on which tactic to choose:
1. position and rotation of self (in 3D world space)
2. position and rotation of nearest enemy (in 3D world space)
3. position of nearest waypoint from navmesh (in 3D world space)
[Example: Distance to nearest enemy is computed using #1 and #2.]
4. list of our own motors
5. list of our own smart zones
[Example: If all of our weapon motors are gone, then switch to shoving.]
6. location of nearest edge
[Used for pushing battles.]
7. location of scoring zone
[Used for "king of the hill" arenas.]
8. time of my last good hit on enemy
[To decide if my attacks are working.]
9. self immobile time
10. self isImmobile
11. nearest enemy immobile time
If we do this right, everything that an AI needs could be derived from the above inputs.
Am I missing anything?
Also maybe a list of arena hazards (for avoidance and/or shoving opponents towards them)? Or does that come under "edges"?
I think the best starting point is to determine:
1. The processes that are active throughout the whole match (immobility check, enemy tracking/mobility check, win condition evaluation, obstacle evaluation that modifies the shortest path between the bots).
2. A default engagement tactic that is active only while mobile, armed, & powered.
3. The processes that are triggered by mid-match conditions (new engagement tactic when new win condition is determined, such as keeping distance when enemy is stuck, shoving when disarmed, evading when crippled/stuck/low on power, etc.).
Then from those processes you can derive the necessary data to build your functions upon:
- Positioning and mobility status for the processes in #1
- Battery, air, drive, weapon, & armor statuses for the processes in #2
- Control signals that are triggered from the processes in #2 maybe a bit from #1
My engineering background is in microelectronics so I might be over-complicating things. Someone who has a strong background in control systems, feel free to correct me. :smile:
I think it's important to understand why AI is important in RA2. It acts as a way to fairly battle bots in lieu of multiplayer. It's a bandage on the problem of the game's netcode being so bad as to be unfit for purpose. As player vs AI fights are unfair, the only way to have a fair fight in RA2 between 2 player created bots is to have an AI battle between both. The problem with this is that it leaves out a large component of what makes real battles interesting, which is the battle of driver vs driver as well as bot vs bot.Honestly, I think that maybe Parsec can work rather than an in built multi-player system
What I'm hinting at is that it might be worth looking into multiplayer over an AI scripting language. I don't want to come off as though I think I'm entitled to decide what you should/shouldn't prioritize in the game, but I think chasing this AI system might not be wise, looking through the lens of a player. RA2 already does this well, what we're missing as a community is multiplayer. Unfortunately I'd assume that multiplayer would be a lot more complex on the developer side than an AI system.
I disagree. Again, I think Parsec is just a bandaid, and not a particularly useful one looking at its lack of adoption for RA2, which would seemingly be the ideal scenario for the service. It has several issues, such as it being inherently unfair (the host has a sizeable latency advantage), being a pain in the ass both to set up the service and to set up bots and controls and relying on very solid network speeds. These issues combine to result in it barely being used in GTM as of late.I think it's important to understand why AI is important in RA2. It acts as a way to fairly battle bots in lieu of multiplayer. It's a bandage on the problem of the game's netcode being so bad as to be unfit for purpose. As player vs AI fights are unfair, the only way to have a fair fight in RA2 between 2 player created bots is to have an AI battle between both. The problem with this is that it leaves out a large component of what makes real battles interesting, which is the battle of driver vs driver as well as bot vs bot.Honestly, I think that maybe Parsec can work rather than an in built multi-player system
What I'm hinting at is that it might be worth looking into multiplayer over an AI scripting language. I don't want to come off as though I think I'm entitled to decide what you should/shouldn't prioritize in the game, but I think chasing this AI system might not be wise, looking through the lens of a player. RA2 already does this well, what we're missing as a community is multiplayer. Unfortunately I'd assume that multiplayer would be a lot more complex on the developer side than an AI system.
I disagree. Again, I think Parsec is just a bandaid, and not a particularly useful one looking at its lack of adoption for RA2, which would seemingly be the ideal scenario for the service. It has several issues, such as it being inherently unfair (the host has a sizeable latency advantage), being a pain in the ass both to set up the service and to set up bots and controls and relying on very solid network speeds. These issues combine to result in it barely being used in GTM as of late.I think it's important to understand why AI is important in RA2. It acts as a way to fairly battle bots in lieu of multiplayer. It's a bandage on the problem of the game's netcode being so bad as to be unfit for purpose. As player vs AI fights are unfair, the only way to have a fair fight in RA2 between 2 player created bots is to have an AI battle between both. The problem with this is that it leaves out a large component of what makes real battles interesting, which is the battle of driver vs driver as well as bot vs bot.Honestly, I think that maybe Parsec can work rather than an in built multi-player system
What I'm hinting at is that it might be worth looking into multiplayer over an AI scripting language. I don't want to come off as though I think I'm entitled to decide what you should/shouldn't prioritize in the game, but I think chasing this AI system might not be wise, looking through the lens of a player. RA2 already does this well, what we're missing as a community is multiplayer. Unfortunately I'd assume that multiplayer would be a lot more complex on the developer side than an AI system.
Been messing around in RR2 trying to learn the ropes of the botlab and everything, and have been having some fun trying to recreate my RA2 bots.
I did Speed Demon, and a rudimentary version of Sabre first, and put them up against each other in an AI vs AI fight (pretty cool that the AI just automatically knew how to drive them with 0 messing around too )
https://youtu.be/36hZhgJKRD8
Then this fight got me wondering if there was any way to make some kind of flipper with what's currently in the game (no pneumatics etc), so I got talking to Hoppin, and dabbling around with spin motors, and I managed to get something to work. It's super weak (kinda series 3 Firestorm levels of power) but it's enough to overturn other bots, and it should work for self righting too (though in this clip Earthquake sitting on top of me prevented that). It won't work with AI, but for player driven bots having a way to make even a super weak flipper is pretty neat I thought.
https://youtu.be/zg-ExHPmKog
My question is: Has he AId it to do the Bocuma spin?Been messing around in RR2 trying to learn the ropes of the botlab and everything, and have been having some fun trying to recreate my RA2 bots.
I did Speed Demon, and a rudimentary version of Sabre first, and put them up against each other in an AI vs AI fight (pretty cool that the AI just automatically knew how to drive them with 0 messing around too )
https://youtu.be/36hZhgJKRD8
Then this fight got me wondering if there was any way to make some kind of flipper with what's currently in the game (no pneumatics etc), so I got talking to Hoppin, and dabbling around with spin motors, and I managed to get something to work. It's super weak (kinda series 3 Firestorm levels of power) but it's enough to overturn other bots, and it should work for self righting too (though in this clip Earthquake sitting on top of me prevented that). It won't work with AI, but for player driven bots having a way to make even a super weak flipper is pretty neat I thought.
https://youtu.be/zg-ExHPmKog
Dayum even on this Sabare seems to outwedge an opponent with ease. Speed Demon looks nice too.
Been messing around in RR2 trying to learn the ropes of the botlab and everything, and have been having some fun trying to recreate my RA2 bots.
I did Speed Demon, and a rudimentary version of Sabre first, and put them up against each other in an AI vs AI fight (pretty cool that the AI just automatically knew how to drive them with 0 messing around too )
https://youtu.be/36hZhgJKRD8
Then this fight got me wondering if there was any way to make some kind of flipper with what's currently in the game (no pneumatics etc), so I got talking to Hoppin, and dabbling around with spin motors, and I managed to get something to work. It's super weak (kinda series 3 Firestorm levels of power) but it's enough to overturn other bots, and it should work for self righting too (though in this clip Earthquake sitting on top of me prevented that). It won't work with AI, but for player driven bots having a way to make even a super weak flipper is pretty neat I thought.
https://youtu.be/zg-ExHPmKog
Oh yeah... Double post, but uhh...
https://youtu.be/Ca50953QPbE
Oh yeah... Double post, but uhh...
https://youtu.be/Ca50953QPbE
WELL DONE!!!!
So awesome!
I had no idea this was even a thing!
I take it that this is Parsec? Is there something I can do to make it work better?
Oh yeah... Double post, but uhh...
https://youtu.be/Ca50953QPbE
WELL DONE!!!!
So awesome!
I had no idea this was even a thing!
I take it that this is Parsec? Is there something I can do to make it work better?
Well not even a full day and we got a new type of flipper:
https://youtu.be/SCOLfRFrhg8
Well not even a full day and we got a new type of flipper:
https://youtu.be/SCOLfRFrhg8
I've downloaded the alpha now and toyed around a little bit. Looks like good fun with quite some building options and freedom. First bot I made might be a bit too light or something? I dunno. Sometimes when just driving forward it decides to turn on its own.Yeah there is Royal Bobby (axebot)
I do wonder... Why when I choose to make a new bot was there some axe bot being spawned in the area, that could even be controlled there?
I've downloaded the alpha now and toyed around a little bit. Looks like good fun with quite some building options and freedom. First bot I made might be a bit too light or something? I dunno. Sometimes when just driving forward it decides to turn on its own.
I've downloaded the alpha now and toyed around a little bit. Looks like good fun with quite some building options and freedom. First bot I made might be a bit too light or something? I dunno. Sometimes when just driving forward it decides to turn on its own.Yeah there is Royal Bobby (axebot)
I do wonder... Why when I choose to make a new bot was there some axe bot being spawned in the area, that could even be controlled there?
Also turn on motor braking for drive, its a godsend
I've downloaded the alpha now and toyed around a little bit. Looks like good fun with quite some building options and freedom. First bot I made might be a bit too light or something? I dunno. Sometimes when just driving forward it decides to turn on its own.Yeah there is Royal Bobby (axebot)
I do wonder... Why when I choose to make a new bot was there some axe bot being spawned in the area, that could even be controlled there?
Also turn on motor braking for drive, its a godsend
Also, what do you guys think of doing electronic stability control to help drive in a straight line for keyboard control? It isn’t hard to implement, but is it too much?
I agree, playtesting will be the best option, although i am a bit scepticalI've downloaded the alpha now and toyed around a little bit. Looks like good fun with quite some building options and freedom. First bot I made might be a bit too light or something? I dunno. Sometimes when just driving forward it decides to turn on its own.Yeah there is Royal Bobby (axebot)
I do wonder... Why when I choose to make a new bot was there some axe bot being spawned in the area, that could even be controlled there?
Also turn on motor braking for drive, its a godsend
Also, what do you guys think of doing electronic stability control to help drive in a straight line for keyboard control? It isn’t hard to implement, but is it too much?
We'd probably have to give that a test, it certainly sounds interesting. Personally I'm ok with driving as is atm, even without motor braking.
I agree, playtesting will be the best option, although i am a bit scepticalI've downloaded the alpha now and toyed around a little bit. Looks like good fun with quite some building options and freedom. First bot I made might be a bit too light or something? I dunno. Sometimes when just driving forward it decides to turn on its own.Yeah there is Royal Bobby (axebot)
I do wonder... Why when I choose to make a new bot was there some axe bot being spawned in the area, that could even be controlled there?
Also turn on motor braking for drive, its a godsend
Also, what do you guys think of doing electronic stability control to help drive in a straight line for keyboard control? It isn’t hard to implement, but is it too much?
We'd probably have to give that a test, it certainly sounds interesting. Personally I'm ok with driving as is atm, even without motor braking.
Sounds good. I’ll hold off on it unless we need it. Also, be sure to try game controllers if have them.Trued with a controller. Honestly not my style, but it will be useful for irl bot builders
I agree, playtesting will be the best option, although i am a bit scepticalI've downloaded the alpha now and toyed around a little bit. Looks like good fun with quite some building options and freedom. First bot I made might be a bit too light or something? I dunno. Sometimes when just driving forward it decides to turn on its own.Yeah there is Royal Bobby (axebot)
I do wonder... Why when I choose to make a new bot was there some axe bot being spawned in the area, that could even be controlled there?
Also turn on motor braking for drive, its a godsend
Also, what do you guys think of doing electronic stability control to help drive in a straight line for keyboard control? It isn’t hard to implement, but is it too much?
We'd probably have to give that a test, it certainly sounds interesting. Personally I'm ok with driving as is atm, even without motor braking.
Sounds good. I’ll hold off on it unless we need it. Also, be sure to try game controllers if have them.
I agree, playtesting will be the best option, although i am a bit scepticalI've downloaded the alpha now and toyed around a little bit. Looks like good fun with quite some building options and freedom. First bot I made might be a bit too light or something? I dunno. Sometimes when just driving forward it decides to turn on its own.Yeah there is Royal Bobby (axebot)
I do wonder... Why when I choose to make a new bot was there some axe bot being spawned in the area, that could even be controlled there?
Also turn on motor braking for drive, its a godsend
Also, what do you guys think of doing electronic stability control to help drive in a straight line for keyboard control? It isn’t hard to implement, but is it too much?
We'd probably have to give that a test, it certainly sounds interesting. Personally I'm ok with driving as is atm, even without motor braking.
Sounds good. I’ll hold off on it unless we need it. Also, be sure to try game controllers if have them.
I have no idea what the braking does here to be honest.
As for controller, I could try getting my PS3 controller to work on PC.
Right now with the simple bit I made it's not just that it'll start to turn to a side when driving forward and backward, but sometimes it'll also start to just spin in place.
Is it just me, or does the settings menu not actually work? I tried turning down the graphics settings, to try and make the bot lab run faster than 5FPS, and it didn't do anything. I closed the game and re-opened and it was back to the default settings.Okay, so the settings menu works if you access it from the pause menu during/after a fight, but it doesn't work if you access it from the main menu. Dialling down the graphics worked for me and I can play the game properly now.
Is it just me, or does the settings menu not actually work? I tried turning down the graphics settings, to try and make the bot lab run faster than 5FPS, and it didn't do anything. I closed the game and re-opened and it was back to the default settings.Okay, so the settings menu works if you access it from the pause menu during/after a fight, but it doesn't work if you access it from the main menu. Dialling down the graphics worked for me and I can play the game properly now.
I'm using 1280x800 in windowed mode, but I don't think that's the resolution it's actually displaying at. My laptop screen is 1600x900 and the game window is definitely not 800 pixels tall. But whatever. It runs, and that's the important thing.Is it just me, or does the settings menu not actually work? I tried turning down the graphics settings, to try and make the bot lab run faster than 5FPS, and it didn't do anything. I closed the game and re-opened and it was back to the default settings.Okay, so the settings menu works if you access it from the pause menu during/after a fight, but it doesn't work if you access it from the main menu. Dialling down the graphics worked for me and I can play the game properly now.
Phew! What resolution brought things into an acceptable fps for you? My Macbook Pro runs okay at 1/2 the max resolution. My Macbook Air is only 1366x768, so it does fine at that.
I guess this had to be done
https://www.youtube.com/watch?v=gClIvmvvzbs
What went well?
What was terrible?I wouldn't say anything was terrible, but...
I cant really add what people have said, except one thing.This might require some sort of judging system to determine who wins if multiple robots are still running. "Who has the most health" isn't reliable, what with the walls causing damage - I could be the most aggressive and dominant robot and still lose because I took more damage from the walls. And of course, with indestructible components, it's possible for neither robot to sustain any damage at all. Then what?
A timer, even a simple 180 second timer
Atleast something simple for now, with cease instead of Player X wins, atleast for online eventsI cant really add what people have said, except one thing.This might require some sort of judging system to determine who wins if multiple robots are still running. "Who has the most health" isn't reliable, what with the walls causing damage - I could be the most aggressive and dominant robot and still lose because I took more damage from the walls. And of course, with indestructible components, it's possible for neither robot to sustain any damage at all. Then what?
A timer, even a simple 180 second timer
Funny, because flippers don't glitch in my game...I believe "more powerful weapon motors" is already on the to-do list, along with a lot of balancing tweaks to improve the physics etc.
Could you make the weapons spin faster, please?
Funny, because flippers don't glitch in my game...I believe "more powerful weapon motors" is already on the to-do list, along with a lot of balancing tweaks to improve the physics etc.
Could you make the weapons spin faster, please?
In the little time I've been in this I found the lack of component descriptions to be a thing. Dunno of this is already planned to be done or if it's actually in there and I'm blind, but yeah.IIRC, you can right-click on a component in the list and it'll give you a little pop-up with the description.
What went well?Overall, the gameplay was fun and exciting. Mainly, the reason in my opinion is due to everyone's unfamiliarity with the state of the meta. This has allowed for people to experiment with designs, spinners like Gaullin, Grabbers like RT 2.0, flippers, like Bocuma. Even some of the wackier stuff like Obama Gaming and Mystic's new overhead disc spinner.
What was terrible?
Just to elaborate on my issue with the pit raising up. With the way the arena is at the moment, pretty much the only way bots that aren't spinners can win fights is to either pit their opponent, or get lucky and strand them on the wall. I don't think the pit raising up would be as much of an issue if there was alternative methods for non-spinners to KO their opponent (such as OOTA zones which Hop mentioned). Additionally, the fact that the walls do so much damage currently means that you can actually lose a not insignificant amount of HP from hitting the pit release, and having to do it multiple times per match can be quite draining on your health.What went well?Overall, the gameplay was fun and exciting. Mainly, the reason in my opinion is due to everyone's unfamiliarity with the state of the meta. This has allowed for people to experiment with designs, spinners like Gaullin, Grabbers like RT 2.0, flippers, like Bocuma. Even some of the wackier stuff like Obama Gaming and Mystic's new overhead disc spinner.
During the Gaullin and Bull fight if I recall correctly, Robo and I discussed about the wedge mechanics, in how they are more complex then they appear. This was lovely to find out, because it isn't just a simple "bolt wedglets onto it" like in Ra2.
Stability of the game engine was great despite some havocs and the odd crash, given the current status of the game, this was to be expected.What was terrible?
Self damage is currently my big problem with the fights, on impacts, it appears you take too much damage to appear realistic. This is kind of an issue with vertical spinners. When they're consistently attacking an opponent, they'll be taking more damage to themselves than they deal out, this is usually because they're hitting the indestructible parts of the opponent, which I'll cover later. Another reason for this is if they're pushed into the wall. Robo was a victim of this a lot, just taking large amounts of damage by being bumped into the wall.
Weight investments, personally I find that the chassis armour feels rather weak for it's weight investment, this could be due to the previously mentioned issue, my personal designs, the fact we have a weight limit of 110kgs which the game isnt designed for currently or all of the above.
The weapon motor power seems quite lacking, I'm aware that you're aware of this issue, so I don't plan to go into much detail. But it appears you need 50kg minimum to throw something currently, I'l like to see that minimum lowered, almost a fifth I'd say.
Indestructible parts this right now is a large issue, and again, you're aware of this. Drone and Caliban were the main culprits of this in the tournament, along with RT 2.0. We've combated this temporarily with some rule changes for the new tournament which can be read here.
Controlling of undercutters, Mystic's undercutter had some major issues with control, not sure if that's his design or because the game struggles with it. Just a heads up and something to look into.
One of Robo's complaints was the pit that rose up after a certain period of time, I agree with this design flaw currently. It's a huge disadvantage for control bots. Continuing with some of the arena design issues I saw is that there should be some oota zones, it'd just be nice to have, maybe not Series 7 wall height arenas or all around the edge, I'd suggest how battlebots does it, in the corners. That'll stop Ra2 Slapshot like stuff box rushing and oota'ing the opponent which is just boring and wont lead to interesting gameplay and fights. The rolling pin is odd, I think it needs to have it's orientation changed and given some more kick to it. You might have to re-position it to prevent it flinging robots into the pit if you do decide to take this route.
Stuck on arena objects, Bocuma and some other bots got stuck into the pit button, doesn't make for fun gameplay whilst it does reflect robot fights accurately. The wall is also easy to get stuck too, or atleast it's difficult to get away from, probably due to the wall's design.
Batteries and control boards, these currently don't effect the robots and aren't actually needed for them to function.
A question I have, is where would I be able to locate the folder for pre-made custom components on Windows? An idea I had was to import CAD files into that folder and add them in, is this a possibility?
Overall, this game is great so far. Like I've said before, I'm enjoying it more than Ra2 and whilst I've described more negatives than positives, the positives have a much bigger impact on the overall player experience.
What went well?
- While the physics still need tweaking, you're off to a good start - already we're getting the kinds of big spinner hits that you don't normally see in RA2.
- I find it amazing how, even with the limited parts we have currently, we're already seeing such a great diversity of bot types, and they're effective. Bull and Bocuma are great flippers, and RT 2.0 actually pulled off a perfect grab-and-lift on at least one occasion, something you just can't do in RA2.
- While there were the occasional havoks, and at least one crash, the game seems a lot more stable than DSL. Even Obama Gaming's flails didn't cause any problems.
What was terrible?I wouldn't say anything was terrible, but...
- Component destructibility (or at least, loss of health when components are hit) needs to be a thing. It's trivial to surround your chassis with armour (or in Drone's case, weaponry) and make yourself invincible.
- Tone down the damage taken from hitting the wall in the Test Arena. Right now it's more damaging than 99% of weapons.
- Additionally, certain bots (Bocuma, Fait Accompli) seem to have an issue where they take damage from the wall even if they hit it with a component wedge instead of their chassis. Would be nice if that could get looked at.
There's probably more but it's 11pm and that's all my tired brain can think of.
I cant really add what people have said, except one thing.This might require some sort of judging system to determine who wins if multiple robots are still running. "Who has the most health" isn't reliable, what with the walls causing damage - I could be the most aggressive and dominant robot and still lose because I took more damage from the walls. And of course, with indestructible components, it's possible for neither robot to sustain any damage at all. Then what?
A timer, even a simple 180 second timer
Atleast something simple for now, with cease instead of Player X wins, atleast for online eventsI cant really add what people have said, except one thing.This might require some sort of judging system to determine who wins if multiple robots are still running. "Who has the most health" isn't reliable, what with the walls causing damage - I could be the most aggressive and dominant robot and still lose because I took more damage from the walls. And of course, with indestructible components, it's possible for neither robot to sustain any damage at all. Then what?
A timer, even a simple 180 second timer
Sorry for the newbie question, but should AI tournaments be determined by the AI, or an external referee? Could the AI be good enough? What if "damage", "control", and "aggression" were done in a reasonable way by the AI?
I cant really add what people have said, except one thing.This might require some sort of judging system to determine who wins if multiple robots are still running. "Who has the most health" isn't reliable, what with the walls causing damage - I could be the most aggressive and dominant robot and still lose because I took more damage from the walls. And of course, with indestructible components, it's possible for neither robot to sustain any damage at all. Then what?
A timer, even a simple 180 second timer
Atleast something simple for now, with cease instead of Player X wins, atleast for online events
Interesting. I didn't think about doing "Cease!" instead of directly declaring a winner for an externally judged event. Maybe an options menu that caters to either internally refereed (single player) or externally refereed (Parsec tournament) play?
Sorry for the newbie question, but should AI tournaments be determined by the AI, or an external referee? Could the AI be good enough? What if "damage", "control", and "aggression" were done in a reasonable way by the AI?
Hey! Absolutely loving the game as it is so far!
Just a few ideas and stuff I've had on how to make it absolute perfection (Apologies if I'm just spouting stuff that's already been advised/in progress!)
-In the bot builder, in addition to having the 'Snap' setting, I think it could also do with a user-variable for 'grid' size and rotation amount (To allow precise rotation of objects to be exactly 90degs, 45degs, 33.3degs, ect.)
-Some sort of 'Mirror' function... Maybe with the critical components (motors mainly) but especially with extras. Kind of like how in the old Bamzooki Creator you could place an object/limb onto the body and it would be automatically mirrored on the other side to make for easier, quicker building. Would also be especially helpful with the blueprint editor and future decal painter.
-With the blueprint editor, having the option to import vectors in the shape of a circle, triangle, and even the option to create curves would be very useful.
-The blueprint editor would also be a lot more effective with the ability to scale the vertices much like how you can scale them once they're rendered into 3d. I know it's possible to just move the vertices around but scaling would be beneficial with complex shapes and if the circles, triangles ect. got offered, would allow users to create shapes similar to that of, for example - Typhoon or Megabyte's shells. Also, smaller dots to represent the vertices for precision.
That's about all I can think of at the moment...
Hope this helps in some way! Please do keep up the amazing work as it is phenomenal!
This game is great and has some nice potential! but:
- I would like to see a first person camera position. Nothing really major, but playing with the other camera positions just doesn't feel ideal to me, but then again, that's just me
-Flippers glitch a lot in the sumo arena
What went well?Overall, the gameplay was fun and exciting. Mainly, the reason in my opinion is due to everyone's unfamiliarity with the state of the meta. This has allowed for people to experiment with designs, spinners like Gaullin, Grabbers like RT 2.0, flippers, like Bocuma. Even some of the wackier stuff like Obama Gaming and Mystic's new overhead disc spinner.
During the Gaullin and Bull fight if I recall correctly, Robo and I discussed about the wedge mechanics, in how they are more complex then they appear. This was lovely to find out, because it isn't just a simple "bolt wedglets onto it" like in Ra2.
Stability of the game engine was great despite some havocs and the odd crash, given the current status of the game, this was to be expected.What was terrible?
Self damage is currently my big problem with the fights, on impacts, it appears you take too much damage to appear realistic. This is kind of an issue with vertical spinners. When they're consistently attacking an opponent, they'll be taking more damage to themselves than they deal out, this is usually because they're hitting the indestructible parts of the opponent, which I'll cover later. Another reason for this is if they're pushed into the wall. Robo was a victim of this a lot, just taking large amounts of damage by being bumped into the wall.
Weight investments, personally I find that the chassis armour feels rather weak for it's weight investment, this could be due to the previously mentioned issue, my personal designs, the fact we have a weight limit of 110kgs which the game isnt designed for currently or all of the above.
The weapon motor power seems quite lacking, I'm aware that you're aware of this issue, so I don't plan to go into much detail. But it appears you need 50kg minimum to throw something currently, I'l like to see that minimum lowered, almost a fifth I'd say.
Indestructible parts this right now is a large issue, and again, you're aware of this. Drone and Caliban were the main culprits of this in the tournament, along with RT 2.0. We've combated this temporarily with some rule changes for the new tournament which can be read here.
Controlling of undercutters, Mystic's undercutter had some major issues with control, not sure if that's his design or because the game struggles with it. Just a heads up and something to look into.
One of Robo's complaints was the pit that rose up after a certain period of time, I agree with this design flaw currently. It's a huge disadvantage for control bots. Continuing with some of the arena design issues I saw is that there should be some oota zones, it'd just be nice to have, maybe not Series 7 wall height arenas or all around the edge, I'd suggest how battlebots does it, in the corners. That'll stop Ra2 Slapshot like stuff box rushing and oota'ing the opponent which is just boring and wont lead to interesting gameplay and fights. The rolling pin is odd, I think it needs to have it's orientation changed and given some more kick to it. You might have to re-position it to prevent it flinging robots into the pit if you do decide to take this route.
Stuck on arena objects, Bocuma and some other bots got stuck into the pit button, doesn't make for fun gameplay whilst it does reflect robot fights accurately. The wall is also easy to get stuck too, or atleast it's difficult to get away from, probably due to the wall's design.
Batteries and control boards, these currently don't effect the robots and aren't actually needed for them to function.
A question I have, is where would I be able to locate the folder for pre-made custom components on Windows? An idea I had was to import CAD files into that folder and add them in, is this a possibility?
Overall, this game is great so far. Like I've said before, I'm enjoying it more than Ra2 and whilst I've described more negatives than positives, the positives have a much bigger impact on the overall player experience.
I put a speed limiter on motors to minimize crazy physics explosions. In a few weeks we will be switching over to a new version of PhysX that supposedly improves performance for high-speed spinners. Once we have switched over, I am hoping to put spinners up to more or less full speed.(https://i.ytimg.com/vi/sbedLpUKEsM/hqdefault.jpg)
You mentioned that the max speed of spinners is limited by the refresh rate of the physics engine (or something to that effect), which in turn is limited by the minimum spec hardware that you want the game to run on. As a compromise, would it be possible to put a slider for physics refresh rate in the options, so those with more powerful hardware can put that hardware to use to improve the gameplay?
Actually, single thread performance is probably the biggest differentiator between laptops and gaming desktops. Most modern laptops have quad cores, as do most gaming PCs (over 55% of steam users are on a quad core system), however laptop CPUs are constrained by thermal/power limitations to low clock speeds, whereas desktop CPUs can boost to over 5GHz (depending on the exact chip).You mentioned that the max speed of spinners is limited by the refresh rate of the physics engine (or something to that effect), which in turn is limited by the minimum spec hardware that you want the game to run on. As a compromise, would it be possible to put a slider for physics refresh rate in the options, so those with more powerful hardware can put that hardware to use to improve the gameplay?
Possibly. I haven’t tried adjusting physics tick rate at runtime. I can look into it though.
PhysX 3.4 supposedly does some nifty interpolation for rapidly spinning objects that allows for much finer collision checking for rapidly spinning objects. Hopefully it will make high speed spinners possible without having to significantly increase the tick rate for the entire physics engine. Physics doesn’t multithread well, so high powered machines don’t tend to have significant advantages over lower powered ones. I’m hoping that the new PhysX will solve the issue entirely. Fingers crossed!
Actually, single thread performance is probably the biggest differentiator between laptops and gaming desktops. Most modern laptops have quad cores, as do most gaming PCs (over 55% of steam users are on a quad core system), however laptop CPUs are constrained by thermal/power limitations to low clock speeds, whereas desktop CPUs can boost to over 5GHz (depending on the exact chip).You mentioned that the max speed of spinners is limited by the refresh rate of the physics engine (or something to that effect), which in turn is limited by the minimum spec hardware that you want the game to run on. As a compromise, would it be possible to put a slider for physics refresh rate in the options, so those with more powerful hardware can put that hardware to use to improve the gameplay?
Possibly. I haven’t tried adjusting physics tick rate at runtime. I can look into it though.
PhysX 3.4 supposedly does some nifty interpolation for rapidly spinning objects that allows for much finer collision checking for rapidly spinning objects. Hopefully it will make high speed spinners possible without having to significantly increase the tick rate for the entire physics engine. Physics doesn’t multithread well, so high powered machines don’t tend to have significant advantages over lower powered ones. I’m hoping that the new PhysX will solve the issue entirely. Fingers crossed!
It's good to hear that there's an inbuilt solution to high RPM collisions, the future is looking bright for this game
Some way to know the approximate dimensions / reach of myself and my opponents
Time since my last collision with each other bot
Distance from and angle to each wall of the arena
I haven't looked at the new botbuilder recently but I think smartzones are important and so we need a way to check each of them
Normally distance to each robot is nice to have but that can be calculated from the x, y, z coordinates
There was another game called roboforge which had a well done AI system which I could probably refer to for more ideas, but its super old and I think has trouble running on newer computers.
I'll post more when I think of them.
One of Robo's complaints was the pit that rose up after a certain period of time, I agree with this design flaw currently. It's a huge disadvantage for control bots. Continuing with some of the arena design issues I saw is that there should be some oota zones, it'd just be nice to have, maybe not Series 7 wall height arenas or all around the edge, I'd suggest how battlebots does it, in the corners. That'll stop Ra2 Slapshot like stuff box rushing and oota'ing the opponent which is just boring and wont lead to interesting gameplay and fights. The rolling pin is odd, I think it needs to have it's orientation changed and given some more kick to it. You might have to re-position it to prevent it flinging robots into the pit if you do decide to take this route.
Maybe try the Warehouse arena? It has a pretty low wall height. It might be a good match for the current batch of flippers.
One of Robo's complaints was the pit that rose up after a certain period of time, I agree with this design flaw currently. It's a huge disadvantage for control bots. Continuing with some of the arena design issues I saw is that there should be some oota zones, it'd just be nice to have, maybe not Series 7 wall height arenas or all around the edge, I'd suggest how battlebots does it, in the corners. That'll stop Ra2 Slapshot like stuff box rushing and oota'ing the opponent which is just boring and wont lead to interesting gameplay and fights. The rolling pin is odd, I think it needs to have it's orientation changed and given some more kick to it. You might have to re-position it to prevent it flinging robots into the pit if you do decide to take this route.
Maybe try the Warehouse arena? It has a pretty low wall height. It might be a good match for the current batch of flippers.
Yeah about that. I was thinking about using it for my next tournament, but problems are apparent as it can be witnessed in this video:
https://youtu.be/Jj-f7YfPlEc
Sorry about poor quality. OBS was a pita so i had to lower bitrate
No not only that. There is also a problem where floor break and oota bots, like in the video
No game is running perfect, it happens off recording tooNo not only that. There is also a problem where floor break and oota bots, like in the video
By any chance was the game running slower than normal when you recorded this? The Warehouse arena shouldn’t be any different than the Test Arena, but if the game was having trouble keeping up with physics, that would explain the rigidbodies penetrating too far, then exploding outward to resolve the collision.
No game is running perfect, it happens off recording tooNo not only that. There is also a problem where floor break and oota bots, like in the video
By any chance was the game running slower than normal when you recorded this? The Warehouse arena shouldn’t be any different than the Test Arena, but if the game was having trouble keeping up with physics, that would explain the rigidbodies penetrating too far, then exploding outward to resolve the collision.
Suggestion, have bots be saved in the game install directory, instead of the AppData folder. Makes the game more portable and makes the files easier to find for sharing purposes.
arrow keys/wasd + shift + space for moving things around/rotating,I honestly want to see keyboard movement for more precise, movepixel like stuff
I agree with Badger here. Also if there's ever modding with lots of custom components we might want multiple installs that don't interfere with each other, though there are other ways around that.
Is there anyway I can see what features are planned for future versions? Anyway, I have some suggestions after building in the botlab for some time. A lot of suggestions and a lot of them are complex, so I don't expect you to agree with all of them or try to implement much of what's here in the near future, I know you guys are busy.
I know you guys are not nearly done with the botlab and that given time you guys will make it great, but talking about the botlab right now as it is, it's still pretty clunky in the sense that it takes a very long time to use the controls and the tools given to you to make the botlab do what you want it to do. First of all, I think keyboard shortcuts would improve the building experience 1000%. Things like pressing x to focus the x coordinate, delete for deleting components, arrow keys/wasd + shift + space for moving things around/rotating, basically all the buttons and fields in the interface should have some keyboard mapping because clicking on everything takes forever. Remapping keys would also be great, i.e. i much prefer RMB to MMB for panning. As it is, it's very easy to make mistakes by putting the wrong numbers into the coordinates or into the wrong coordinates, and it's also way too easy to get yourself into a situation where you move something too far away and can only fix it through editing the bot file. An undue button would be a great help for this, and additionally some way to control the max distance from origin of all the components and toggle the room that you are in would all be huge helps. It's also really easy to get objects stuck inside of others, and there's currently a glitch where some small objects won't be able to be selected unless you exit and join the workshop. A lot of these issues could also be helped by having an expandable tree view of all the components like in the bot file and being able to select components like that. Being able to turn off blur from being too close would also be great. When using the moving sliders, they go in increments of .025, and if the component isn't currently at a multiple of .025 then it snaps to a multiple: there should be some way to turn the snapping to a multiple off, because a lot of the more complex builds will not use those multiples very often. This also applies to the rotation and size sliders. There should be a way to control what interval the moving axes move by, either through a field or through several hotkeys which are each set to common values, i.e. .01 and .005 with .025 as the default. It would be great if there was some way to change the directions of the coordinate system so that it doesn't have to be determined by what the object is sitting on, a lot of the times I just want the normal xyz directions. It would be fantastic if there was a way to copy the x, y, or z coordinate of one object and then set the coordinate to another in a streamlined fashion, e.g. hold x while clicking on another object. It would also be great if there was some way to clone mirrors of objects and flip each of the components. It would be nice if we could smooth components along a certain rotational axis. For the chassis and custom object builder it would be great if we could change the numerical values of the xy coordinates via text field of each of the vertices like we can for objects in the rest of the builder.
Personally, one of the more important things I would like to see added (besides pneumatics, custom decals, and destructible parts) is adjustable motor speeds. It would definitely help with making decent lifters among other things. I've been making a Complete Control style robot, and when it lifts, it'll just flip the opponent instead of picking it up. So far, I've been able to work around it a little bit, but it isn't as good as it could be.
Personally, one of the more important things I would like to see added (besides pneumatics, custom decals, and destructible parts) is adjustable motor speeds. It would definitely help with making decent lifters among other things. I've been making a Complete Control style robot, and when it lifts, it'll just flip the opponent instead of picking it up. So far, I've been able to work around it a little bit, but it isn't as good as it could be.Unless you have separate drive motors and weapon motors like in DSL, then I think this will also be needed once the motor buff comes into effect. You want your weapon motor to be going at (say) 3000 RPM, but if your drive motors are going that fast, your robot will be doing 60mph and be completely uncontrollable.
Personally, one of the more important things I would like to see added (besides pneumatics, custom decals, and destructible parts) is adjustable motor speeds. It would definitely help with making decent lifters among other things. I've been making a Complete Control style robot, and when it lifts, it'll just flip the opponent instead of picking it up. So far, I've been able to work around it a little bit, but it isn't as good as it could be.Unless you have separate drive motors and weapon motors like in DSL, then I think this will also be needed once the motor buff comes into effect. You want your weapon motor to be going at (say) 3000 RPM, but if your drive motors are going that fast, your robot will be doing 60mph and be completely uncontrollable.
It'd be handy (and realistic) if lowering the RPM also increased the torque. You could make shovebots that drive slowly but have a tonne of pushing power, or electric lifters/crushers with some serious force behind them. RA3 had something similar for spin motors, but you could increase speed and torque separately and there was no incentive to not just crank them both up to 100, so the sliders may as well have not been there at all.
-Smaler batts, maybe like Pulsar/Magnetar had?I would imagine that smaller batteries are planned, as the current ones are basically SLA car batteries, and modern combat robots all use LiPos.
-Smaler batts, maybe like Pulsar/Magnetar had?I would imagine that smaller batteries are planned, as the current ones are basically SLA car batteries, and modern combat robots all use LiPos.
Geared and non-geared seems like a sensible compromise regarding motor speeds.
One other thing I'd like to see added is custom wheels.
2 wheel drive bots just seem to straight up not work this update. The chassis seems to have a ton of friction with the floor which makes bots unable to turn, and motors seem to have less torque too which doubles this issue.
Will report further after I play the update more
This was on existing bots2 wheel drive bots just seem to straight up not work this update. The chassis seems to have a ton of friction with the floor which makes bots unable to turn, and motors seem to have less torque too which doubles this issue.
Will report further after I play the update more
For new robots, or existing ones? I set motors to their IRL torque-speed curves for this build. They should be a little different than before. Balance is really important in general. Does shifting the weight distribution help?
This was on existing bots2 wheel drive bots just seem to straight up not work this update. The chassis seems to have a ton of friction with the floor which makes bots unable to turn, and motors seem to have less torque too which doubles this issue.
Will report further after I play the update more
For new robots, or existing ones? I set motors to their IRL torque-speed curves for this build. They should be a little different than before. Balance is really important in general. Does shifting the weight distribution help?
Just to clarify, by existing bots, I mean bots that I built in a previous update, rather than the AI bots in gameThis was on existing bots2 wheel drive bots just seem to straight up not work this update. The chassis seems to have a ton of friction with the floor which makes bots unable to turn, and motors seem to have less torque too which doubles this issue.
Will report further after I play the update more
For new robots, or existing ones? I set motors to their IRL torque-speed curves for this build. They should be a little different than before. Balance is really important in general. Does shifting the weight distribution help?
Shoot. I will take a look at it next week to see what I can do.
Just to clarify, by existing bots, I mean bots that I built in a previous update, rather than the AI bots in game
Here is my feedback for the new update:
- I love how you can now make beetleweight robots. The main issue is that there is so much friction on the tires, and it won't let me turn. Also, when I was building one, it wouldn't let me re-select a motor.
- Parts actually fall off! Yay! The only issue is that small parts fall off way too easy. I would recommend having a set minimum for damage, and have it not be based completely off of weight.
- The AI builder is good to have, but it would be helpful to have it already working. I made a spinner, and the AI wouldn't do anything with the weapon for the entire match. It would also be nice to have a pre-made list for you to choose from, like one setup for spinners, flippers, and whatnot.
- The motors can't do sh**e! I made an attempt at a very light-weight hammer, and it couldn't even lift it. :vista:
Here is my feedback for the new update:
- I love how you can now make beetleweight robots. The main issue is that there is so much friction on the tires, and it won't let me turn. Also, when I was building one, it wouldn't let me re-select a motor.
- Parts actually fall off! Yay! The only issue is that small parts fall off way too easy. I would recommend having a set minimum for damage, and have it not be based completely off of weight.
- The AI builder is good to have, but it would be helpful to have it already working. I made a spinner, and the AI wouldn't do anything with the weapon for the entire match. It would also be nice to have a pre-made list for you to choose from, like one setup for spinners, flippers, and whatnot.
- The motors can't do sh**e! I made an attempt at a very light-weight hammer, and it couldn't even lift it. :vista:
Lots of fixes coming here shortly:
1. Parts don't come off until they receive about 20 times as much damage. Before they fall off, they propagate damage up to their parent component. This means that if you keep hitting the same spot you will eventually damage the chassis.
2. The AI builder should fire button 1 when close. There was apparently a bug which prevented anyone from pressing button 1, which has been fixed.
3. I just added a super low gear ratio 37 mm motor. It can flip beetleweights now. I feel like the existing gear motor should have been able to lift other robots, but for some reason 1 Newton-meter of torque didn't translate into 10 Newtons of force at 10 cm. The new motor has a LOT more torque, so it should do the trick.
4. I tweaked Manta, TR3, and Earthquake. They all flip in different ways.
5. You can now use a laptop trackpad in the botlab. Woohoo! Building robots on the work computer! :)
I still have more tweaking and balancing to do, but hopefully should be able to push something out in the next 24 hours...
Lots of fixes coming here shortly:Honestly, you couldve buffed up the hp multiplier for stuff by 400%
1. Parts don't come off until they receive about 20 times as much damage. Before they fall off, they propagate damage up to their parent component. This means that if you keep hitting the same spot you will eventually damage the chassis.
So up until now, material selection hasn’t affected damage resistance. I’m starting to address that in the next build. The 1 mm thick UHMW on Holy Wings flipper is not going to last long though. 😊Most of people use 1mm armour on flippers, niw that there is actual damage and durability mechanism, people will be smarter
Played it: here is the feedback
1. Flipper motors are still broken, they flip and break off
2. Music is added back, and i cant mute it
3. Worst one, you either get one hit KO'ed or do a one Hit KO
Okay so I just tried this out and just from the first few minutes I have this feedback:
- Manta's flipper is really havok-y. It manages one or two flips that yeet me right into the ceiling, and then it spends the rest of the fight propelling itself around the arena at warp-speed while its flipper panel glitches into another dimension. I've had the same issue with Goodbye Kiss's axe in the past, dunno if that helps at all. Earthquake's flipper doesn't close properly, preventing it from firing more than once or twice. TR3's flipper seems to work fine.
- None of my robots' weapons work anymore. I get that you can now choose which button fires them, but the dropdown just says "Button1", "Button2" etc, with no clue as to what those buttons actually are. Is it possible that you added controller compatibility for Bugglebots, but broke keyboard compatibility in the process?
- Bots still seem too fragile. I thought this might have been just Fait Accompli and its 3mm steel, which is the bare minimum for a real-life HW, but then I noticed that sometimes, I'll start taking massive damage while just driving normally, without my opponent anywhere near me. I can only imagine that my robot is somehow rubbing against the floor, and the game is interpreting that as damage. Ignoring the fact that a 6WD robot like Fait Accompli shouldn't be touching the floor with anything but its wheels in the first place, this should not be enough to kill you in two seconds.
1. Re: Manta - Oof. I struggled with Manta for about three hours on Tuesday night. In the game, pneumatics use a plunger system that pushes on the lifting arm to cause it to raise. In Manta's case, the plunger is really far back, which means that the physics engine can do wonky things as the plunger penetrates the flipper arm and the physics engine computes the impulse required to resolve the collision. I thought I had it working well, but you aren't the first one to report that it is broken.I think Manta's flipper has been broken for a while tbh, I managed to make it glitch out at least once in the previous build.
Back to the drawing (tweaking) board...
2. Re: Unworking weapons - There is still a bug that I haven't found that sometimes prevents button inputs from being read. This is an intermittent problem. My workaround has been to go back to the Robot Selection screen and start over. For me starting over fixes it about 70% of the time. I definitely need to track this down, but each time I think I have solved it, it pops up again.I'll try that. I assume Button1 is Space, then?
3. Re: Driving damage - You are absolutely right. Driving normally shouldn't damage a robot. Somehow or another something is registering a collision with a ton of impulse. Would you mind sending me Fait Accompli? I would like to do some testing. I have a few things I have in mind to improve driving dynamics that might solve this problem as well.Yep, I'll send it over right away.
1. and 3. - I've been testing with Holy Wings versus a horizontal spinner. I have found that if you leave everything on Holy Wings at 1 mm UHMW, the heavy spinning bar will indeed one-hit destroy any UHMW that it touches. This is fairly realistic. 1 mm UHMW is like protecting your robot with cardboard against a big spinner. If you armor everything with about 5 mm of steel, however, Holy Wings survives a lot longer.Problem is that the bots i was fighting had Steel armour. This OHKO also tends to happen to prebuilt bots
The biggest problem I am finding now is that the motors don't have enough torque to lift the flipper arms fast enough to work as flippers against another heavyweight. Now that all of the UHMW has been replaced by thicker steel armor,Make Servo motors that have high torque?
Holy Wings is just a wedge that can wave "hi!" with its flipper arms. I'm not sure how the bigger AmpFlow PMDC motors would work as flippers in real life either. To my knowledge people tend to use pneumatics for heavyweight flippers.Well tbh that is old wings, it does not use a hinged actuator for flipping
I think Manta's flipper has been broken for a while tbh, I managed to make it glitch out at least once in the previous build.
I'll try that. I assume Button1 is Space, then?
Yep, I'll send it over right away.
Problem is that the bots i was fighting had Steel armour. This OHKO also tends to happen to prebuilt bots
Make Servo motors that have high torque?
As for the flipper arms, i have been using Hinged actuators which are op
Well tbh that is old wings, it does not use a hinged actuator for flipping
Another oddity that i find is that when keys are binded, it keeps the control (lets say space), but if i rebind it again, the old imput key (space) will stay written while the new key will be functional
Also Metals have this odd Blue-ish tint where tint RGB is set on all to 1
AAAAAAlso like it how lightweight bots have great driving, but HW bots tend to bounce, 4wd ones atleast
Did my PM get through to you? The first time I tried, I got a "there's already a file with this name" error, and the second time I tried, I got a "you've already sent this PM" error. And GTM annoyingly doesn't save messages to your outbox by default, so I don't know whether either of them actually got sent.
Lighting probably? Either that or post-processing. They both could be contributing to an excess of blue. I'm pretty sure the texture is grayscale.Its throughout the whole game, so it might be post processing, UHMW is white tho
My current hypothesis on the whole Instant KO thing is that everything is treated like a part of the chassis. Most of the time when I lose a bot, it's because it got hit in the wheel or a thin weapon support.
I guess at the moment, everyone has RA2 logic in their head where if it isn't a part of the main chassis, it won't damage the bot when hit.
My current hypothesis on the whole Instant KO thing is that everything is treated like a part of the chassis. Most of the time when I lose a bot, it's because it got hit in the wheel or a thin weapon support.
I guess at the moment, everyone has RA2 logic in their head where if it isn't a part of the main chassis, it won't damage the bot when hit.
My assumption is that it being all chained to the chassis ripples in. Killing the chassis
Lighting probably? Either that or post-processing. They both could be contributing to an excess of blue. I'm pretty sure the texture is grayscale.Its throughout the whole game, so it might be post processing, UHMW is white tho
Also any chances to use an option to disable post processing? I have a feeling that that might be the culprit to the lag on lower end machines
As for driving, Just remove friction for now
Did my PM get through to you?
Oh, so the weapon actually did work, it was just too heavy for the motor? Well gee, now I feel stupid :facepalm: I did actually run another test with Defcon and its weapon worked just fine (it even gyros now!), so I guess that was all that was wrong. I'll try your suggested weights, and also see what happens if I put a counterweight on the other end.Did my PM get through to you?
I just tried out Fait Accompli and fixed the concussion damage issue when the robot is driving around. It turns out that I had set the minimum impulse limit ridiculously low such that pretty much every heavyweight would damage itself just by driving.
I also noticed that the axe didn't move when triggered. I tried dropping the thickness of the steel used. That did the trick. Here are my settings:
Axe head (pyramid) - 6 mm steel - 0.481 kg
Axe shaft (cube) - 3 mm steel - 0.637 kg
Now to see what it does to other robots...
I'll try your suggested weights, and also see what happens if I put a counterweight on the other end.
Glad you've got the driving issue sorted out, though!
I lowered the weight of the axe and it still didn't swing in the test area... then I switched the motor's activation button to Button 2 and then back to Button 1, and it worked perfectly. I think what might actually be happening is, where I've ported my bots over from the previous version, there's some sort of compatibility issue and it doesn't know what key should activate the robot's weapon until I go into the bot lab and tell it.I'll try your suggested weights, and also see what happens if I put a counterweight on the other end.
Glad you've got the driving issue sorted out, though!
Thanks!
I also have a sneaking suspicion that when I tell the physics system to give me a certain number of Newton-meters of torque, the system isn't giving me that much torque. I'll have to set up a test rig in Unity to see for sure. I feel like the motor you are using should be able to swing that axe head around in real life.
FWIW I have a 6" diameter motor in the works for weapons, similar to the old E-teks. I'm not sure how it would work for an axebot, but it should be killer for spinners.
Another fun discovery: attacking pieces that have fallen off a robot still deal damage.
Another fun discovery: attacking pieces that have fallen off a robot still deal damage.
To the robot the piece fell off from?! That is completely unintended and hilarious. :)
Another fun discovery: attacking pieces that have fallen off a robot still deal damage.
To the robot the piece fell off from?! That is completely unintended and hilarious. :)
Unless this is the next meta game :really_makes_you_think: heck
Is there anyone here who has judged a robot combat event? We just had our post-Bugglebots debrief and we were talking about how to do scoring in game.
Damage - Already done, we just need to display it
Aggression - Compute dot product of velocity vector and normalized displacement to other robot. The result should give the amount of time that a robot is driving toward its opponent.
Control - ???
How does one measure "control"? This one is super-duper subjective. Any thoughts?
@Hoppin, what exactly is giving you problems with scaling?
I can look into it if you can give me more details.
You are able to adjust the grid size on the left hand side.@Hoppin, what exactly is giving you problems with scaling?
I can look into it if you can give me more details.
Yea, absolutely.
Given how small the BWs tend to be to build. I've found the grid lacks the support for these small sizes. Often rounding up to the nearest number. It results in it being really difficult imo to make detailed and accurate bots. This, on top of the lack of wheel & battery support makes building at the weightclass really awkward and overall lacking
If you choose to judge controll by tge time wheels have touched the ground keep in mind that there are walkers also no wheels at all. Also bots like pussycat have wheels not touching the ground on purpose
Idk what to feel about the in built JD system in game tbh
I think I still prefer the one where people made it themself as on any other robot combat game before RR2. Also for aggression, is it basically tied with control, or will you take other factor into consideration, like the controlled bot trying to force itself against the opponent even if being controlled, or trying to use their weapon, like bringing down their saw into the opponent?
Judges decision
Should we have a BOTM for rr2?
I would 100% agree with you on that. It can make matches more competitive throughout, and if you don't agree with the decision that the Com made, you can always just ignore it.Judges decision
Ah! Thanks!
I think we need a scoring system for 2 primary reasons:
1. It is a way to build tension and excitement as you see one robot pulling ahead of another.
2. In single player or AI vs AI games, it is needed to determine the outcome of non-KO fights.
For me, the best part of the original Robot Rumble was watching the pips move as someone went on a particularly long scoring run, upsetting the leader.
Should we have a BOTM for rr2?The current botm has RR2 as part of the Custom category.
I think the one thing missing - and I keep forgetting to bring this up - is some sort of "green-screen" function, so we can take screenshots of our robots in front of a blank background, like we can do in RA2. Once we have that, we can start making proper splashes for our RR2 builds.Should we have a BOTM for rr2?
Up to you guys. Do you feel like the game is mature enough?
That should definitely be something to add in the next build. I could see some cool stuff coming from that.I think the one thing missing - and I keep forgetting to bring this up - is some sort of "green-screen" function, so we can take screenshots of our robots in front of a blank background, like we can do in RA2. Once we have that, we can start making proper splashes for our RR2 builds.Should we have a BOTM for rr2?
Up to you guys. Do you feel like the game is mature enough?
Doesn't have to be anything fancy, could be just a "Greenscreen" toggle in the Bot Lab that replaces the workshop background with a solid colour.
I think the one thing missing - and I keep forgetting to bring this up - is some sort of "green-screen" function, so we can take screenshots of our robots in front of a blank background, like we can do in RA2. Once we have that, we can start making proper splashes for our RR2 builds.That should definitely be something to add in the next build. I could see some cool stuff coming from that.
Doesn't have to be anything fancy, could be just a "Greenscreen" toggle in the Bot Lab that replaces the workshop background with a solid colour.
Neat. Will you be able to customize the lenght of the belt or is it preset like in DSL?
Nice! A new build incoming! That belt drive should make it a lot easier to build spinners than it currently is. Any other changes we can look forward to?
Not gonna lie, I was really hoping for some sort of belt drive and you guys have more than delivered once again! Cannot wait for the next build!
Out of curiosity - can the pulley system be 'doubled up' to potentially create two shafts powered by one motor? (For example, two wheels powered by the one motor)
Its a little impractical, but is something like this what you had in mind?
Its a little impractical, but is something like this what you had in mind?
Not quite... I was thinking more along the lines of how a lot of four wheel drive robots work, with two motors connected to two sets of belt systems, in turn powering four wheels in parallels of two. (I could draw up a quick diagram if that helps??)
I love seeing what you did there though! It's gonna be perfect for drum spinners and dual vertical spinners!
Would like something like this
(https://cdn.discordapp.com/attachments/486231999548358681/596833925804982295/unknown.png)
Illustration 100 fellas
Would like something like this
(https://cdn.discordapp.com/attachments/486231999548358681/596833925804982295/unknown.png)
Illustration 100 fellas
I’ll give it a shot tonight. :smile:
Would like something like this
(https://cdn.discordapp.com/attachments/486231999548358681/596833925804982295/unknown.png)
Illustration 100 fellas
I’ll give it a shot tonight. :smile:
I just thought about it a little more, and it looks like you are looking for a crown gear or bevel gear. No way to do that, and we hadn’t really planned on it...
yeah, as current motors are not Hori spinner friendlyWould like something like this
(https://cdn.discordapp.com/attachments/486231999548358681/596833925804982295/unknown.png)
Illustration 100 fellas
I’ll give it a shot tonight. :smile:
I just thought about it a little more, and it looks like you are looking for a crown gear or bevel gear. No way to do that, and we hadn’t really planned on it...
You might be able to accomplish the same space-saving effect with a pancake motor though. We can pretty easily put a flatter motor in the game.
yeah, as current motors are not Hori spinner friendlyWould like something like this
(https://cdn.discordapp.com/attachments/486231999548358681/596833925804982295/unknown.png)
Illustration 100 fellas
I’ll give it a shot tonight. :smile:
I just thought about it a little more, and it looks like you are looking for a crown gear or bevel gear. No way to do that, and we hadn’t really planned on it...
You might be able to accomplish the same space-saving effect with a pancake motor though. We can pretty easily put a flatter motor in the game.
Anyone have any preference for weapon motors? I am looking at something Etek-compatible currently. At a minimum I should be able to come up with a mock-up of the right dimensions, weight, and motor characteristics.Just a nice variety of shapes, sizes, and power levels, rather than the two (plus BW motor) that we have currently. Etek and pancake motors would be nice, maybe also an R-shaped one like the TWM3R in DSL. NPCs, too, maybe?
Arent LEM motors thin and wide? Idk if they are drive motors thoIIRC, they're about the same diameter as an Etek, but slightly thinner. Storm 2 used LEMs as drive motors at one point, but they're heavy enough that you'd need WhammetNuht's system of "one motor powering two/three wheels" for them to be practical in an RR2 rammer.
Just looked up lems. I thought they were actually huge, but i see they have variety. NiceArent LEM motors thin and wide? Idk if they are drive motors thoIIRC, they're about the same diameter as an Etek, but slightly thinner. Storm 2 used LEMs as drive motors at one point, but they're heavy enough that you'd need WhammetNuht's system of "one motor powering two/three wheels" for them to be practical in an RR2 rammer.
Just a nice variety of shapes, sizes, and power levels, rather than the two (plus BW motor) that we have currently. Etek and pancake motors would be nice, maybe also an R-shaped one like the TWM3R in DSL. NPCs, too, maybe?
Also, just a small thing, but would it be possible to put the motors' performance stats (like horsepower and torque) in their descriptions? Or are you going to wait until their stats have been finalised before doing something like that?
Oooh, that'd be handy. We'd potentially then be able to set tip speed limits for tournaments, like Extreme Robots and (IIRC) Battlebots have. Might help balance out the meta a bit. How would you differentiate between weapon motors and drive motors for those meters, though?
Just a nice variety of shapes, sizes, and power levels, rather than the two (plus BW motor) that we have currently. Etek and pancake motors would be nice, maybe also an R-shaped one like the TWM3R in DSL. NPCs, too, maybe?
Also, just a small thing, but would it be possible to put the motors' performance stats (like horsepower and torque) in their descriptions? Or are you going to wait until their stats have been finalised before doing something like that?
Will do.
You are correct about the reason for not putting specs in the description. Up until now I have been fudging numbers all over the place to get everything to work. Now that the spinner blur is functional, it is possible to simulate real-life speeds. A motor spins a bar at 3000 RPM? No problem. The question now becomes which specs to include. Do we got full on simulation, with Kv values, or do we just do something simple like power at rated voltage? What about torque? Weapon tip speed at full spin-up? Kinetic energy?
Maybe there is a kinetic energy, RPM, and tip speed meter in the test cage that allows you to see the numbers as you spin up, just like you would have when bench-testing a real robot?
Maybe there is a kinetic energy, RPM, and tip speed meter in the test cage that allows you to see the numbers as you spin up, just like you would have when bench-testing a real robot?Oooh, that'd be handy. We'd potentially then be able to set tip speed limits for tournaments, like Extreme Robots and (IIRC) Battlebots have. Might help balance out the meta a bit. How would you differentiate between weapon motors and drive motors for those meters, though?
Maybe there is a kinetic energy, RPM, and tip speed meter in the test cage that allows you to see the numbers as you spin up, just like you would have when bench-testing a real robot?Oooh, that'd be handy. We'd potentially then be able to set tip speed limits for tournaments, like Extreme Robots and (IIRC) Battlebots have. Might help balance out the meta a bit. How would you differentiate between weapon motors and drive motors for those meters, though?
That’s on my list for Monday. I was thinking of adding a “wheel” tag to wheels so that it knows to not consider a wheel a weapon if the wheel is properly attached to the motor or pulley.
Hey guys. Another free public alpha is coming out by the beginning of next week. For this build:Hopefully the drive and damage isnt broken so i can continue with hosting stuff
1. Massive spinner update.
2. Pulleys.
3. Flippers.
We have reworked physics so that everything is energy-based. As shown in the GIF above, you can get a handy realtime readout of your spinner’s energy in the test cage. This should be handy if you are using the game to prototype designs for your real-life robots. My plan is to use energy for damage too, but I’m not sure if that will be ready for this build.
Not shown in the GIF: The theoretical maximum kinetic energy for a spinner will be displayed too, if you want to design a tournament with energy limits. It is also handy to see how much your design is losing to friction.
Hopefully the drive and damage isnt broken so i can continue with hosting stuff
Ok, I'm not very good at posting images
Well... now I know, what I will do the next few weeks :mrgreen:Hopefully the drive and damage isnt broken so i can continue with hosting stuff
I'll do my best.
Drive: Reworking spinners required reworking drive as well. Unity physics doesn't like it when you throw big heavy masses around at anything more than a few hundred RPM. Spinners can now go 8,000+ RPM, so I had to adjust the dynamics so that Unity stays happy. I didn't have to go completely back to the drawing board with drive, but drive required a TON of tweaks. Hopefully it is pretty close to where it needs to be.
Damage: I haven't addressed damage yet. I'm hoping to do that over the next few days. My goal this fall is to completely rethink how damage is done, moving away from hit points to a more realistic system of ripping, puncturing, and breaking. If you tap a motor with a high energy spinner, that motor should break. The idea is that you protect your motors with armor that someone needs to break off / puncture to get to the sensitive bits inside.
Update: I'm working on spinner "bite" right now. The idea is that if you make something that spins too fast and/or come at an opponent too slowly, the spinner won't get any bite, and it will just bounce of the opponent instead without releasing much kinetic energy.
This game is so cool! It is like RA3, but every mistake has been fixed. (those were a lot of mistakes)
It would be cool to have an option, where you can turn a spinner down. This will be very useful, if you want to build replicas.what do you mean by that
Spinner air drag is now a thing. Air drag is computed based on the speed and geometry of the spinner. It is really hard to make a big spinner go super fast now.Ah so deep six clones are gonna be a hassle to make
Spinner air drag is now a thing. Air drag is computed based on the speed and geometry of the spinner. It is really hard to make a big spinner go super fast now.Ah so deep six clones are gonna be a hassle to make
I noticed you’ve included flippers in the next build. Out of interest - is the same damage physics rules that’s been built for the spinners going to apply to flippers? (E.g, the kinetic force from both being launched and hitting the ground at greater speeds = more damage?). I feel like that’s something which RA2 was definitely missing, hence why the only real competitive ‘flippers’ where the pop-ups.
Cannot wait for the new build!!!
What I mean is, that it would be cool to say: This spinner is not allowed to spin faster than 2000 rpm. I just noticed, that this will be possible to do by changing the pulley gear ratio.It would be cool to have an option, where you can turn a spinner down. This will be very useful, if you want to build replicas.what do you mean by that
What I mean is, that it would be cool to say: This spinner is not allowed to spin faster than 2000 rpm. I just noticed, that this will be possible to do by changing the pulley gear ratio.It would be cool to have an option, where you can turn a spinner down. This will be very useful, if you want to build replicas.what do you mean by that
CALLING ALL ENGINEERS!Sorry, I have no Idea, but I thought, that you were doing some stuff with the TR2 team and team Shock. Maybe they can help.
I'm looking for data on the following:
1. Energy required to puncture different thicknesses of common armor materials: UHMW, Polycarbonate, 6061-T6 aluminum, mild steel, hardened steel, titanium. Am I missing any? We are looking to cover beetleweights, featherweights, lightweights, and heavyweights.
2. Rated speed (based on motor kV) vs measured speed of bar spinners, drum spinners.
If you have access to equipment to do some testing, or know of good resources for the above, please post them here!
PS - Do we have any Robot Wars/Robogames/Battlebots competitors in the crowd? It would be nice to get some real-world quantitative and qualitative data from the heavier weight classes.
Somebody (his gtm name) is the guy who made HUGE
2. Rated speed (based on motor kV) vs measured speed of bar spinners, drum spinners.
2. Rated speed (based on motor kV) vs measured speed of bar spinners, drum spinners.
not sure if this is what you're looking for but its got a lot of useful info on it and is really easy to use
[ This attachment cannot be displayed inline in 'Print Page' view ]
Great!!! :claping :claping :claping will it already be in the upcoming build?
Oh, cool! I guess just a flat cylinder would be ok, too. Will the new House robot, you showed off be in the game?Great!!! :claping :claping :claping will it already be in the upcoming build?
Hopefully. If not the actual 3D model, at least a cylinder of the appropriate dimensions that you can hook up and power stuff. We are working on the full 3D model now, but the full visual representation might need to wait until the next build.
Oh, cool! I guess just a flat cylinder would be ok, too. Will the new House robot, you showed off be in the game?Great!!! :claping :claping :claping will it already be in the upcoming build?
Hopefully. If not the actual 3D model, at least a cylinder of the appropriate dimensions that you can hook up and power stuff. We are working on the full 3D model now, but the full visual representation might need to wait until the next build.
[ This attachment cannot be displayed inline in 'Print Page' view ]That looks very detailed :mrgreen:
Hot off the griddle!
This one is going to have some serious power.
[ This attachment cannot be displayed inline in 'Print Page' view ]
Hot off the griddle!
This one is going to have some serious power.
Can wait for new update, so i can break it
400KJ ? Ray Billings would be proud lmao, i dread to imagine how horribly slow spinup must be
i'll try to make it not look too bad lol
i know Tombstone's theorical max is around 100KJ, so that's a base to have for what would be the reasonable max energy you can reach
Liking the new build. Flippers fall off still tho
Love the build! Bubblegum seems to spasm at the beginning of every match however. It spins whilst seemingly hitting the floor and then just explodes. Any ideas why?
[ This attachment cannot be displayed inline in 'Print Page' view ]
Just started and already like it. First issue though is for some reason the game likes to "censor" spinning weapons.
Second and unrelated issue. If nothing is mounted to a motor and you go to the test Lab, you get a couple dozen air miles.
Otherwise, I like what you're doing with the music and the botlab. Things are looking nice.
Great build :mrgreen: .I like, what you have done to the botlab! But I have some issues with the spinners. In the test area it always sais, that the mass of the weapon is 5 kg. I also wanted to hit the toggle DB and it brought me back to the menu.
The flippers work very well! I didn't have any issues so far.same i dont know why people are complaining
The flippers work very well! I didn't have any issues so far.same i dont know why people are complaining
(Insert Attachment 0)
My robot keeps dancing on it's back :laughing
The flippers work very well! I didn't have any issues so far.same i dont know why people are complaining
Maybe a problem just with older robots?
Nvidia GeForce GTX 1050 Ti[ This attachment cannot be displayed inline in 'Print Page' view ]
Just started and already like it. First issue though is for some reason the game likes to "censor" spinning weapons.
Uh oh. That looks like a problem with the shader that I'm not seeing on my end that might be hardware related. What graphics card are you using?
I'm currently on vacation, so I have to wait until next Friday. :rage Looks awesome tho! Two Quick questions; is there a torque motor? And when will there be a Bot exchange on GTM, like RA2 has?
haven't figured out yet how to make a hard hitting spinner yet lol, also flippers seem to clip into other robots on firing
Looking at Kix's vid, I love the new lighting effects in the arena, but are the turntables in the menu screens supposed to spin that fast? I'm sure they were a lot slower in the previous builds.
Also unlimited hinge hp when? Im not feeling safe to host it as flippers tend to fall off after 10 ish-hits
Cant mute audio too
I know that stuff needs to be balanced, but currently, hosting is a no-go for flippersAlso unlimited hinge hp when? Im not feeling safe to host it as flippers tend to fall off after 10 ish-hits
Cant mute audio too
I'll let Chris answer on the timeframe, but all parts need a lot of balancing and tweaking still.
What audio are you unable to mute?
I can’t promise anything extravagant at this point. What do you think about just disabling the ability of flippers to break off? They should still be able to propagate damage inward to the chassis.
I can’t promise anything extravagant at this point. What do you think about just disabling the ability of flippers to break off? They should still be able to propagate damage inward to the chassis.Tbh, as a temp solution it would be great
Okay, so apparently, UHMW and/or Poly stuff breaks graphics. Thats why gulden gets that effect (and other people incl arcane and me)
Also materials like steel and aluminium have a blue-ish tint
Okay, so apparently, UHMW and/or Poly stuff breaks graphics. Thats why gulden gets that effect (and other people incl arcane and me)I haven't once used those materials, though...
Okay, so apparently, UHMW and/or Poly stuff breaks graphics. Thats why gulden gets that effect (and other people incl arcane and me)BTW, for the poly glitch, since the devs are not in the OW server and Arcane posted the pic there only, here it is:
Also materials like steel and aluminium have a blue-ish tint
(Insert Attachment 0)I think I know, why this happens. Always when you attatch an axe or a lifter to a Motor with limited rotation, the game thinks it's spinning 360 degree and hits the ground
My robot keeps dancing on it's back :laughing
A servo motor for heavyweights. It would be really useful, to build lifters and clamps.
This as much as i knowA servo motor for heavyweights. It would be really useful, to build lifters and clamps.
It's worth pointing out that this does not exist in reality. Every robot you see is running large gearboxes, geartrains, or chain/belt drives to gear down continuous rotation motors enough to be effective drive, or effective at lifting an opponent.
It's worth pointing out that this does not exist in reality. Every robot you see is running large gearboxes, geartrains, or chain/belt drives to gear down continuous rotation motors enough to be effective drive, or effective at lifting an opponent.
Music audio. It can be muted, but after entering a fight/botlab, it turns on
Speaking of the arena though, I think what you've done with the lighting effects and introduction before fights is PERFECTION. I would have loved to have somehow incorporated elements like those into my RA2 arenas but the game was never advanced enough to do it properly so this aspect really excites me! (It's the little things lol)
I have a Question: Is the announcer in the Bugglebots arena actually Bob ?
Epic speeds here
(https://media.discordapp.net/attachments/441273974274392065/603262035211452416/unknown.png?width=401&height=232)
Also seems that if i spin the weapon downwards, it will act like its spinning upwards which is weird. Will post a vid when i have time
Epic speeds here
(https://media.discordapp.net/attachments/441273974274392065/603262035211452416/unknown.png?width=401&height=232)
Also seems that if i spin the weapon downwards, it will act like its spinning upwards which is weird. Will post a vid when i have time
Epic speeds here
(https://media.discordapp.net/attachments/441273974274392065/603262035211452416/unknown.png?width=401&height=232)
Also, does anyone have featherweight spinner data that I can use to calibrate the air drag model for featherweight spinners?
Same question for beetleweights. Does anyone have real life beetleweight spinner data?
I built a hammer - bot. In the test Arena it's fine, but in battle it's bouncing all over the place.
[ This attachment cannot be displayed inline in 'Print Page' view ]
Okay, so apparently, UHMW and/or Poly stuff breaks graphics. Thats why gulden gets that effect (and other people incl arcane and me)
Also materials like steel and aluminium have a blue-ish tint
Okay, so apparently, UHMW and/or Poly stuff breaks graphics. Thats why gulden gets that effect (and other people incl arcane and me)
Also materials like steel and aluminium have a blue-ish tint
I don't know why it took me this long to ask, but:
Is the problem with the weird white glow around UHMW and polycarbonate a new problem with the July 19th build, or has it existed all along?
In the July 19th build, I made very few changes that would have affected how materials are displayed. If it is new problem, that is great because I have a pretty good idea of where to look to fix the problem.
It's only a result of the new build
Hey Guldenflame, could you post a picture of your Complete Control rep?I scrapped it when I realized how the bounce glitch worked, so I quickly made a crappy recreate for ye.
Once again love the new build. It fixed the aforementioned glowing material glitch.
Anyway, I think I found the cause of the bouncing hammer bot glitch.
When a bot has a weapon is driven with an electric motor, the game spins the weapon, even when it's off. (invisibly or something). The weapon hits the ground, and causes the robot to bounce.
Sauce: I tried to make an electric Complete Control bot. The upper arm didn't cause the bounce, but the lower one did. Two test bots later and we reached the conclusion.
how do u pan the botlab camera
[ This attachment cannot be displayed inline in 'Print Page' view ]Once again love the new build. It fixed the aforementioned glowing material glitch.
Anyway, I think I found the cause of the bouncing hammer bot glitch.
When a bot has a weapon is driven with an electric motor, the game spins the weapon, even when it's off. (invisibly or something). The weapon hits the ground, and causes the robot to bounce.
Sauce: I tried to make an electric Complete Control bot. The upper arm didn't cause the bounce, but the lower one did. Two test bots later and we reached the conclusion.
Drat!!! I didn’t make any changes that would have affected the glowing material! I hate the way Unity batches materials together! So performant, yet so frustrating to get working...
You are spot on about the cause of the hammer bouncing. The blur/collision cylinder should not be added to hammers, but for some reason it is, and I can’t seem to replicate the problem when I build stuff in the botlab. Would you mind sending me a .RR2Bot file that has the problem?
Tried making something similar on an older update using the hinged actuators, but it kept flippin itself. Yours low key looks nicer tho. :beer:Hey Guldenflame, could you post a picture of your Complete Control rep?I scrapped it when I realized how the bounce glitch worked, so I quickly made a crappy recreate for ye.
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]Once again love the new build. It fixed the aforementioned glowing material glitch.
Anyway, I think I found the cause of the bouncing hammer bot glitch.
When a bot has a weapon is driven with an electric motor, the game spins the weapon, even when it's off. (invisibly or something). The weapon hits the ground, and causes the robot to bounce.
Sauce: I tried to make an electric Complete Control bot. The upper arm didn't cause the bounce, but the lower one did. Two test bots later and we reached the conclusion.
Drat!!! I didn’t make any changes that would have affected the glowing material! I hate the way Unity batches materials together! So performant, yet so frustrating to get working...
You are spot on about the cause of the hammer bouncing. The blur/collision cylinder should not be added to hammers, but for some reason it is, and I can’t seem to replicate the problem when I build stuff in the botlab. Would you mind sending me a .RR2Bot file that has the problem?
I am using a rack and pinion burst piston and it starts bouncing, before the fight even starts.I built a hammer - bot. In the test Arena it's fine, but in battle it's bouncing all over the place.
[ This attachment cannot be displayed inline in 'Print Page' view ]
Weird. It should behave the same. Does it start bouncing immediately, or after you fire the weapon? Also, what kind of motor are you using to drive the weapon?
Yeah we've pinpointed the cause of the bouncing motor bug just trying to get a fix on it now. Gamedev is basically just making cool new features that randomly break the other ones :beer:
Gamedev is basically just making cool new features that randomly break the other ones :beer:Hear hear! :beer:
great! :mrgreen:Yeah we've pinpointed the cause of the bouncing motor bug just trying to get a fix on it now. Gamedev is basically just making cool new features that randomly break the other ones :beer:
I found the root causes (2) this morning. The fix is fairly straightforward. The collision response should only occur when two conditions are met:
1. The spinner is rotating faster than a threshold RPM.
2. The spinner has rotated more than 2 revolutions.
Fix should come when I can get decent internet access.
Just now got to play the new update, and I honestly feel a little underwhelmed. Don't get me wrong, I think that you guys made some great improvements, but I feel like the weapons don't do anything now, especially the spinners. Personally, I want to see the spinners knocking it's opponent around, not glance off it or stop spinning after contact.
As for the flippers, they are perfect.
I don't want to sound like a dick, but it sounds like you guys would relly benefit from better/more testing before releasing a build. It seems like there's a lot of these bugs that are apparent within a few minutes of gameplay that could be caught before release.
Tbh its easier for us to figure and find out bugsAgreed.
I think so, too. Better release the build sooner and let us find the bugsTbh its easier for us to figure and find out bugsAgreed.
As a fellow game dev, I couldn't agree more. All four of my Ludum Dare entries have had game-breaking bugs that you would have expected me to notice, but I just didn't. Then I wake up the next morning and find five reviews all pointing out the same issue and have to scramble out a patch, just like cjbruce has been having to do.I think so, too. Better release the build sooner and let us find the bugsTbh its easier for us to figure and find out bugsAgreed.
danny2462 would be proudI don't want to sound like a dick, but it sounds like you guys would relly benefit from better/more testing before releasing a build. It seems like there's a lot of these bugs that are apparent within a few minutes of gameplay that could be caught before release.
Thank you for sticking with us as we continue to create new bugs... *ahem* features!
Thanks for all of the comments, guys!Will both get gamage, if a spinner hits a wedge?
No ability to upload yet, but here's what I've come up with in the last few days on vacation:
1. Spinner impulse is working correctly in a physically realistic way. Spinners now apply action impulse to other objects, launching them and getting kicked backward in the process.
2. I took a first cut at spinner damage based on kinetic energy. I haven't done any tuning yet. If you hit an enemy, they take the damage. If you hit a wall or the floor, your own spinner takes damage.
3. Spinner on spinner collisions are not handled yet. I need to think about this.
Anything else before I get back to civilization? :)
PS - This next build will also include our first cut at chassis armor plates. Visually, at least.
Will both get gamage, if a spinner hits a wedge?
Honestly id say, ditch the material tilt and keep it all the same. Maybe different material characteristics?
Like Poly having no sparks on impact, Titanium having more sparks than other materials, and steel being more shiny
Honestly id say, ditch the material tilt and keep it all the same. Maybe different material characteristics?
Like Poly having no sparks on impact, Titanium having more sparks than other materials, and steel being more shiny
What do you mean by the material tilt? Are you referring to ignoring the angle of impact? I would like to keep it in for now. I think it might add a certain level of strategy to try to catch the edges of your opponents.
We have not yet begun to sparks! :smile: Once we have a good damage system in place, we absolutely intend to add more sparks than would happen in real life. Sparks are awesome!
Plastic = no sparks
Aluminum = no sparks
Steel = yellow sparks
Titanium = white sparks
I'm looking Forward to it :clapingWill both get gamage, if a spinner hits a wedge?
That’s a great question. In general I try to start with a good physical model, then simplify the variables so it is easier for everyone to grok. Here are my thoughts on spinners vs wedges:
A. When a spinner hits a surface, its ability to “dig into” the surface for a “good hit”, causing damage and impulse, is based on the amount of bite x the “directness of the hit”. A wedge at a glancing angle will make it very difficult to get a good hit. The wedge will slow/stop the spinner which will then bounce upward.
B. When a spinner is hit with a component of the force parallel to its axis, it can put a really nasty torque on the bearings. In our school competition, I watched a big heavy steel hammer spinner break all of its own supports upon impact with a well-built wedge. Everything tilted off-axis upon impact.
The build I’m getting ready for release models A but not B. Is it enough that a wedge just stops a spinner from rotating? I dunno. Lets get the build out and try it. We can always add damage later.
Also, just to be clear: If the spinner catches the edge of the wedge, it will register as a good hit, sending the robots flying and doing damage.
Alrighty, back to civilization. Working on a build that is mostly bug fixes:
1. Blur cylinder collision response should now work correctly in all cases. When a spinner hits something at high speed, action/reaction impulse should be applied correctly to both the spinner and its target. Damage is just a placeholder, and will be replaced as we put the new damage system together.
2. I figured out and solved the problem with blur cylinder opacity. Spinners should look much more believable now.
3. kix and codesilver23, is there anything else that needs to be fixed in order for you guys to run tournaments?
I just put out a bug fix build called RR2-xxxx-01AUGUST2019–Alpha. I think it is pretty clean, but I was having physics crash problems with high speed spinners earlier today that I can’t seem to replicate in the editor or in the build. Would you guys mind taking a look before I send out the email announcement that it is up?I have a bot that can replicate crashes, so hey
I just put out a bug fix build called RR2-xxxx-01AUGUST2019–Alpha. I think it is pretty clean, but I was having physics crash problems with high speed spinners earlier today that I can’t seem to replicate in the editor or in the build. Would you guys mind taking a look before I send out the email announcement that it is up?I have a bot that can replicate crashes, so hey
I just put out a bug fix build called RR2-xxxx-01AUGUST2019–Alpha. I think it is pretty clean, but I was having physics crash problems with high speed spinners earlier today that I can’t seem to replicate in the editor or in the build. Would you guys mind taking a look before I send out the email announcement that it is up?I have a bot that can replicate crashes, so hey
Drat! I’ll take a look.
What Kix said. Also, because mine is an AI tournament, more in-depth AI would be helpful. I was thinking maybe instead of having the AI editor, there could be a list of options based on the different bot types.Alrighty, back to civilization. Working on a build that is mostly bug fixes:
1. Blur cylinder collision response should now work correctly in all cases. When a spinner hits something at high speed, action/reaction impulse should be applied correctly to both the spinner and its target. Damage is just a placeholder, and will be replaced as we put the new damage system together.
2. I figured out and solved the problem with blur cylinder opacity. Spinners should look much more believable now.
3. kix and codesilver23, is there anything else that needs to be fixed in order for you guys to run tournaments?
It all seems fine. Just transfer the material tints from UHMW to alu and steel, so we can have pure white steel parts, instead of grayish parts (till paint tool works)
I didn't get a crash in the few minutes I played, although I did have this happen:
https://www.youtube.com/watch?v=0DisCAOG_Kc
Bubblegum freaks out at the start of every match, loses all it's wheels and gets counted out. It instakills any bot that touches it.
My 2 wheel drive bots are still just straight up unable to turn. It's been like this since IIRC the bugglebots patch came out. I've tried replacing the drive motors and everything and nothing seems to work. It's as though the chassis has crazy high friction with the floor or something
well
For some reason, the game is very laggy in battle. I have a Windows 7 and I tried everything from low graphics and shrinking the screen. :vista:
All the versions I played were just as laggy. :(For some reason, the game is very laggy in battle. I have a Windows 7 and I tried everything from low graphics and shrinking the screen. :vista:
Have you tried any previous versions? If so, is there any difference?
All the versions I played were just as laggy. :(For some reason, the game is very laggy in battle. I have a Windows 7 and I tried everything from low graphics and shrinking the screen. :vista:
Have you tried any previous versions? If so, is there any difference?
The axle broke off.
The UHMW skid seemed to help in the test arena, but when I took it into an actual fight I still couldn't turn at all. It's really got me stumped as to what's causing thisMy 2 wheel drive bots are still just straight up unable to turn. It's been like this since IIRC the bugglebots patch came out. I've tried replacing the drive motors and everything and nothing seems to work. It's as though the chassis has crazy high friction with the floor or something
Maybe try some UHMW skids? I’ve been experimenting with small spheres...
The UHMW skid seemed to help in the test arena, but when I took it into an actual fight I still couldn't turn at all. It's really got me stumped as to what's causing thisMy 2 wheel drive bots are still just straight up unable to turn. It's been like this since IIRC the bugglebots patch came out. I've tried replacing the drive motors and everything and nothing seems to work. It's as though the chassis has crazy high friction with the floor or something
Maybe try some UHMW skids? I’ve been experimenting with small spheres...
i've noticed that direct driving wheels for drive really doesn't work that well anymore, if you still have direct drive wheels, try using chain/belt drive and gearing them down, helped for a tombclone i had which drove like ass
what computer do you haveAll the versions I played were just as laggy. :(For some reason, the game is very laggy in battle. I have a Windows 7 and I tried everything from low graphics and shrinking the screen. :vista:
Have you tried any previous versions? If so, is there any difference?
Maybe some drive motors in future?i've noticed that direct driving wheels for drive really doesn't work that well anymore, if you still have direct drive wheels, try using chain/belt drive and gearing them down, helped for a tombclone i had which drove like ass
Hmm. Thats a really good point. The Ampflow A28-150G motors we use for our 85 lb school robots are geared down with an 8.3:1 ratio. This gives a stall torque of 122 Newton-meters. I’m not sure what would happen if we tried running them ungeared.
For contrast, the ungeared A40-300 has a stall torque of 27 Newton-meters in the game. This is pushing a robot that is almost 3 times heavier.
Idk what pc does he have, but this update, stuff is slow to loadwhat computer do you haveAll the versions I played were just as laggy. :(For some reason, the game is very laggy in battle. I have a Windows 7 and I tried everything from low graphics and shrinking the screen. :vista:
Have you tried any previous versions? If so, is there any difference?
i noticed a bug, it seems the bot weight that's displayed in menus is incorrect compared to the weight displayed in the botlab
I've just checked this out and I must say I'm really liking it despite my laptop being trash. Do you any long term goals for this project?
For example would you make it mobile or console compatible?
Maybe some drive motors in future?i've noticed that direct driving wheels for drive really doesn't work that well anymore, if you still have direct drive wheels, try using chain/belt drive and gearing them down, helped for a tombclone i had which drove like ass
Hmm. Thats a really good point. The Ampflow A28-150G motors we use for our 85 lb school robots are geared down with an 8.3:1 ratio. This gives a stall torque of 122 Newton-meters. I’m not sure what would happen if we tried running them ungeared.
For contrast, the ungeared A40-300 has a stall torque of 27 Newton-meters in the game. This is pushing a robot that is almost 3 times heavier.what computer do you haveAll the versions I played were just as laggy. :(For some reason, the game is very laggy in battle. I have a Windows 7 and I tried everything from low graphics and shrinking the screen. :vista:
Have you tried any previous versions? If so, is there any difference?
Idk what pc does he have, but this update, stuff is slow to load
haha classic kix putting comments inside of quotes
A great build. It even fixed the blue tint issue on components with alu/steel
Some gripes however:
-Weapon blur should be removed in my opinion, and you should just keep the weapon model not going transparent
-Spinner weapons do lose colour
-Stuff seems to spin up slow, but that might be 30 kg disc doing its thing
-I can make wheels from cylinder parts. Maybe add a rubber material with more grip?
video of blur issue: https://youtu.be/0NBwIUV5WYk (https://youtu.be/0NBwIUV5WYk)
-Time to return to menu is slow. It takes around 30 secs - 5 minutes (i have a high end pc so this is not on my end) It seems that main menu is the problem as it occurs whenever i press exit to main menu
-Game looks blurry whenever i launch it, it also seems to default on 1280X768 res. On 1080p resolution i get black borders that you would get on 16:10 resolutions on side but on virtual 1440p res it looks fine. It reverts to 768p whenever i exit botlab or a match. This is my biggest gripe
-Ampflows are a bit bigger than usual, which results in 5 inch wheels having no ground reach if placed directly on a motor. It also means that we need to resize compactly built robots. Apparently, it resizes when entering test area
Overall great update, can host parsec/10
A great build. It even fixed the blue tint issue on components with alu/steel
Some gripes however:
-Weapon blur should be removed in my opinion, and you should just keep the weapon model not going transparent
-Spinner weapons do lose colour
-Stuff seems to spin up slow, but that might be 30 kg disc doing its thing
-I can make wheels from cylinder parts. Maybe add a rubber material with more grip?
video of blur issue: https://youtu.be/0NBwIUV5WYk (https://youtu.be/0NBwIUV5WYk)
-Time to return to menu is slow. It takes around 30 secs - 5 minutes (i have a high end pc so this is not on my end) It seems that main menu is the problem as it occurs whenever i press exit to main menu
-Game looks blurry whenever i launch it, it also seems to default on 1280X768 res. On 1080p resolution i get black borders that you would get on 16:10 resolutions on side but on virtual 1440p res it looks fine. It reverts to 768p whenever i exit botlab or a match. This is my biggest gripe
-Ampflows are a bit bigger than usual, which results in 5 inch wheels having no ground reach if placed directly on a motor. It also means that we need to resize compactly built robots. Apparently, it resizes when entering test area
Overall great update, can host parsec/10
1. I will work on weapon blur some more. I was happy to finally figure out the problem with it not being transparency, and I think the rest of the problems can be addressed by tweaking the amount of blur and the speed at which it is activated. I like the idea of keeping the blur on axes and flippers. Without blur, axes move so fast that they appear to teleport from one position to another.
2. When you say "spinner weapons lose color" are you referring to tinted components, or painted components? I might address this with #1 above.
3. I like the wheels ideas! I put "rubber material" on the Trello list.
4. I suspect that the slow loading times might be due to Debug.Log() statements that I need to strip out. Let me know if you need a clean build for the tournament.
5. I'm not sure what happened with the size of the AmpFlow motors. An A40-300 motor should be 4" in diameter. I put it on the Trello list as something to look into.
My 2 wheel drive bots are still just straight up unable to turn. It's been like this since IIRC the bugglebots patch came out. I've tried replacing the drive motors and everything and nothing seems to work. It's as though the chassis has crazy high friction with the floor or somethingCan they spin on the spot? Spitfire can't turn while driving forward/backward, but it can spin on the spot okay. Can't remember whether it was like that before the Bugglebots patch though.
Might work to put a tiny cone on the bottom to reduce the surface area that’s touching the ground.My 2 wheel drive bots are still just straight up unable to turn. It's been like this since IIRC the bugglebots patch came out. I've tried replacing the drive motors and everything and nothing seems to work. It's as though the chassis has crazy high friction with the floor or somethingCan they spin on the spot? Spitfire can't turn while driving forward/backward, but it can spin on the spot okay. Can't remember whether it was like that before the Bugglebots patch though.
I can't open the zip file of the new build. How do I install it?Forget about it. I restarted my computer and it works.
That looks really good. I missed the early August update until today and for some reason the new download while saying it's the August version still keeps reverting to the hulu 19 version any idea why?
My latest design has crashed the game back to main menu 3 times in a row against 3 different AI all on test arena
After some some tinkering and help from Gulden (cheers boss) I've been able to get my bots working in this update. Only real issue I've noticed is the ice skate-y physics for some bots when inverted, but if that's the price of having my bots work then I'm more than willing to pay it. Really enjoying the combat dynamics too. The spinner physics and the tradeoffs between raw KE vs bite depth are proving really interesting to me.Maybe add small rubber pads at top to add friction?
Cheers for keeping up the work and listening to all our issues guys, this game is really starting to feel like the future :thumbup
kix,Will have to check when im home
Does the 06August2019 build still have the problem with taking forever to get back to the main screen?
I wasn't seeing the delays in the 02August2019 build on my end, but I did a ton of cleanup of the Debug.Log() statements anyway. The 06August2019 build should generate less garbage than the 02August2019 build. This should reduce the time required to switch back to the main screen.
Really enjoying the combat dynamics too. The spinner physics and the tradeoffs between raw KE vs bite depth are proving really interesting to me.
I'd also love to see flatter motors for horizontals and shell spinners.
New issue: My 10 or so bots are gone, and there is one robot button that does nothing. Cant also make new bots
Doesnt work. Seems that adding, the armor plates stats break that, (copied/merged some .rr2bot lines)New issue: My 10 or so bots are gone, and there is one robot button that does nothing. Cant also make new bots
That happened to me too.
Check out the instructions from a few posts back...
Maybe adding P40 lines of ampflow motors? Also Ampflow geared motors sound well.
idk how hard would it be to get a license from Vex or Magmotor comp.
Doesnt work. Seems that adding, the armor plates stats break that, (copied/merged some .rr2bot lines)New issue: My 10 or so bots are gone, and there is one robot button that does nothing. Cant also make new bots
That happened to me too.
Check out the instructions from a few posts back...
Oh, i figured out what was breaking my bots.
in the "robot_construction": section, "comp_string_id": "customShape_0" had "brake": true, which broke the bot, setting that to false fixed it
I thought tombstone used the tmw3r? Also wyachi has some motors that would be cool to look into.
on the topic of corrupted bots, it seems only new bots that were made using the 02 august build are affected, builds from before this build that were edited with this build are fine
also Kix's fix didn't work for me
Let me know if there is something else you are looking for, and we can put it on the list of motors to model.
In other news, is there a way I can add a chain drive to a motor without having to delete everything attached to it and rebuild it? Because I was about to make Goodbye Kiss' hammer chain-driven, and then realised I'd have to delete the whole thing one piece at a time and rebuild it, and sod that tbqhCopy paste is probably your best bet
I totally forgot that that was a thing (and that it worked on whole component chains). Thanks for the tip!In other news, is there a way I can add a chain drive to a motor without having to delete everything attached to it and rebuild it? Because I was about to make Goodbye Kiss' hammer chain-driven, and then realised I'd have to delete the whole thing one piece at a time and rebuild it, and sod that tbqhCopy paste is probably your best bet
on the topic of corrupted bots, it seems only new bots that were made using the 02 august build are affected, builds from before this build that were edited with this build are fine
also Kix's fix didn't work for me
the whole delete the robots folder and put your bots in it again ? yes, did nothing either, the bots are still corrupted
lost 7 robots, here's one of them
lost 7 robots, here's one of them
The thing is. Deep Regret and some other bots didnt have this when being transferred to 06 build, and worked fine. Craplectric also didnt have this, but it only worked when i apllied what i did (what i thought was a fix)lost 7 robots, here's one of them
Figured it out! The 02August build has plates defined, but no plate materials, thickness, or tint. The 06August build requires all of these for plates.
Open up the .RR2Bot file in a text editor and search for the word "material". In order to get the plate materials, thickness, and tint into the bot, you must add them as follows in bold for each plate. I'm pretty sure plates only exist for chassis parts so far, so you should only have to do this for however many plates your chassis has. Since Slambus uses a box for the chassis, it only has 6 plates.
"material_id": 4,
"thickness": 0.004000000189989805,
"tint": {
"r": 1.0,
"g": 1.0,
"b": 0.0,
"a": 1.0
},
"material_id_plates": [
4,
4,
4,
4,
4,
4
],
"thickness_plates": [
0.008999999612569809,
0.008999999612569809,
0.008999999612569809,
0.008999999612569809,
0.008999999612569809,
0.008999999612569809
],
"tint_plates": [],
thanks, so the only thing i have to change for my other broken bots is to add more "rows" to the material and thickness plate arrays depending on the number of faces right ?
The thing is. Deep Regret and some other bots didnt have this when being transferred to 06 build, and worked fine. Craplectric also didnt have this, but it only worked when i apllied what i did (what i thought was a fix)
Also something else I found with that massive bar even when it was just resting against another bot it absolutely shreds the other bot despite having no ke
I meant damage the health bar just goes down smoothly and fairly quick.
What can I do, if the filefor the new build doesn't open?Did you extract the zip file?
It doesn't want to extract or open it. Maybe that's just my computer doing weird stuffWhat can I do, if the filefor the new build doesn't open?Did you extract the zip file?
It doesn't want to extract or open it. Maybe that's just my computer doing weird stuffWhat can I do, if the filefor the new build doesn't open?Did you extract the zip file?
Ok I don't know why, but my computer only downloaded about 50 megabytes. Anyways it's working now, as I downloaded it againIt doesn't want to extract or open it. Maybe that's just my computer doing weird stuffWhat can I do, if the filefor the new build doesn't open?Did you extract the zip file?
Windows or MacOS?
Maybe try the build I just uploaded?
When it just shows a "robot" button, that means that something went wrong while loading a robot and it stops spawning the others.How can I fix it?
When it just shows a "robot" button, that means that something went wrong while loading a robot and it stops spawning the others.How can I fix it?
When it just shows a "robot" button, that means that something went wrong while loading a robot and it stops spawning the others.How can I fix it?
Check back a few posts to Post #883 in this thread. You should find instructions on how to edit your affected .RR2Bot files.
You will need to find where the .RR2Bot files are stored on your computer (different for Windows vs Mac) and edit the file manually.
When it just shows a "robot" button, that means that something went wrong while loading a robot and it stops spawning the others.How can I fix it?
Just downloaded it. I noticed that it only saved my first 5 robots and scrapped the rest.The game doesn't remove bots automatically, you still have them in the folder, but the game has encountered a problem while loading a bot and stopped there.
Out of curiosity if I copied bot file and renamed it would i be able to essentially clone a bot so I could say make a modular bot in a sense?
Only problem that im seeing wity bleeding edge version is that one of my bots (only the eruption rep) has an issue where it barely steers left. Right steering is normal
tested on previous copy, does the same thingOnly problem that im seeing wity bleeding edge version is that one of my bots (only the eruption rep) has an issue where it barely steers left. Right steering is normal
Very weird for a flipper!
Do I have a copy of the .RR2Bot file already? Steering should only be different for spinners, not for flippers.
(https://cdn.discordapp.com/attachments/436299751395426315/609809996103942154/unknown.png)Oh, now that's interesting. Mount a spinner on that and see what happens. I'd be very interested to see if the rotation translates, because this could open a pathway to flatter horizontal spinners.
was messing around with the file
Mystic I definently agree my big spinners were crashing game before occasionally but they do do it a little more now
Yep, that's game development for ya. I've been watching the Automation devs do this for like four years, don't worry about it.Mystic I definently agree my big spinners were crashing game before occasionally but they do do it a little more now
It sounds like physics stability needs to be my next priority. Every time I push into a new direction and add a new feature, stability suffers. Grrr.
More motivation to get flatter motors. Eep!Another option might be to have some kind of dedicated component for translating rotation in that way. Hypno-Disc used a gear setup like that IIRC (though Hypno-Disc was not exactly a shining beacon of mechanical reliability).
-A bot is unable to steer left and right, again pit floor eliminates thatThis can be a combanation on issues on the robot, not the game.
vid:
Nah its on all bots. Bots steer better on the pit floor-A bot is unable to steer left and right, again pit floor eliminates thatThis can be a combanation on issues on the robot, not the game.
vid:
-Your wheelbase is too thin.
-Your wheels are too small (Go one size larger than what barely peeks out).
-Your motors are the Ampflow 30-400s. They are way too weak to be used on 2WD.
This is totally on my “Dang! I really want this!” list.
I would really really like to get visual coding working. I think it would be a literal game-changer, and open up a whole new group of people to robot combat. There are probably 100 times as many kids involved in things like FIRST robotics as there are kids doing robot combat. A slick AI coding system in the game could help bridge that gap and get more kids involved in combat robotics.
I was also thinking (but forgot to put in my last post) about whether it might be a good idea to include the AI code as part of the .rr2 file? At this point I've done some stuff with the AI on certain bots that needed it, but it soon gets erased and set back to default by the game? Plus it would aid tournament hosts in the future by just having it as a part of the package sent over by entrants.
Hoo boy, we wont be able to fuse stuff together, i like that. Need to test it
Hoo boy, we wont be able to fuse stuff together, i like that. Need to test it
Its pretty rudimentary at this point. I don't think there is any checking that happens if you edited your .RR2Bot file, for example.
I think I may have found a bug. The newest version worked fine the first time I opened it however on the second time I now can’t select any buttons from the main menu.
Played the new build, here are some of my thoughts:
-Intersection is as is. Dont have much opinions rn in condition as is
-I have noticed that you have added spinner sound (+other sounds) in test area, hopefully you add it in battles
-Bouncing is almost non-existant in battles. What did you do?
-Steering is still a bit eh for 2wd bots. Gonna try and change motors to see if that works
-Flippers still are too op, they tend to ohko bots with steel chassis
-Flippers also still lose hp when they flip opponents when they dont have full hp
-Build seems to be a lot more stable
-Motor axles are a bit too fragile
I think I may have found a bug. The newest version worked fine the first time I opened it however on the second time I now can’t select any buttons from the main menu.
Very weird. One of the bleeding edge builds?
I’m not sure which bouncing you are referring to. Spinners or non-spinning things?Driving bouncing, you know, the issue we had for few builds now
Poor steering still means friction is set too high. I can lower it a little.i dont know how will that affect the driving/sliding, maybe its only one bot's issue, i do have noticed that the pit floor has perfect friction/material thp
Flippers are about twice as powerful as in real life. I can definitely tone them down.Its not about the power. Its about the fact that they deal too much damage. As for the power, its not bad, i have noticed if your flipper is a bit heavier, it will have more force/energy behind the flip
Good to hear about stability! Thats the thing that worries me the most.Only had one crash, but it was in test area, and with DB2
We can definitely adjust the way axles take damage. I almost feel like we might be able to get rid of axle breakage, depending on how much we like being able to chip away at stuff with the new damage system. Of course, it doesn’t exist yet, so who knows until it is in place.maybe re-add it when damage starts to work?
Yeah the 20th August bleeding edge version. I have to delete the file and re-extract every time I use it otherwise the menu buttons get a case of stage fright. It doesn’t look like Kix is having this problem so at least it’s not a universal problem.
Spinner wind up sound is apparently in fights, its just that they might be too quiet
Yeah the 20th August bleeding edge version. I have to delete the file and re-extract every time I use it otherwise the menu buttons get a case of stage fright. It doesn’t look like Kix is having this problem so at least it’s not a universal problem.
What's your resolution out of interest? Far as I'm aware there wasn't any difference in the menu UI between these builds, did you have this issue on the Itch.io build also?
I’m not sure which bouncing you are referring to. Spinners or non-spinning things?Driving bouncing, you know, the issue we had for few builds now
Also one idea for the damage, maybe instead of the whole part falling off, sides (basically each side mesh of a cube, for an example) fall off?
Yeah the 20th August bleeding edge version. I have to delete the file and re-extract every time I use it otherwise the menu buttons get a case of stage fright. It doesn’t look like Kix is having this problem so at least it’s not a universal problem.
What's your resolution out of interest? Far as I'm aware there wasn't any difference in the menu UI between these builds, did you have this issue on the Itch.io build also?
Using full screen - 1680x1050 resolution. Never had the issue on any previous versions of the game. The buttons are visible but don’t do anything (I have to alt tab to close the game, can’t access settings, workshop or battle mode etc).
Another idea. For the Momentary Switch for the burst motors, maybe have a second or 2 of delay after you press the button and release it the moment after, because currently they retract too fast
Yeah the 20th August bleeding edge version. I have to delete the file and re-extract every time I use it otherwise the menu buttons get a case of stage fright. It doesn’t look like Kix is having this problem so at least it’s not a universal problem.
What's your resolution out of interest? Far as I'm aware there wasn't any difference in the menu UI between these builds, did you have this issue on the Itch.io build also?
Using full screen - 1680x1050 resolution. Never had the issue on any previous versions of the game. The buttons are visible but don’t do anything (I have to alt tab to close the game, can’t access settings, workshop or battle mode etc).
I think I may have found a bug. The newest version worked fine the first time I opened it however on the second time I now can’t select any buttons from the main menu.
I think I may have found a bug. The newest version worked fine the first time I opened it however on the second time I now can’t select any buttons from the main menu.
Just tried opening it a few times on my Windows laptop. Things seemed to work fine.
Maybe the next step is to put out a new build. It is possible that something might have been corrupted during the build process.
I'll try to get a new build out on Thursday.
Ngl, hinges are fine, havent tested the axle yet
Maybe add a rotation limit on the hinge?
NOTE: What i have noticed in the last few builds, my gpu is running constantly at 100% while playing this game
I also did experience minor infrequent stuttersNgl, hinges are fine, havent tested the axle yet
Maybe add a rotation limit on the hinge?
NOTE: What i have noticed in the last few builds, my gpu is running constantly at 100% while playing this game
Hmmm. We will need to figure this out. I noticed that my Windows laptop is getting random freezes, and was wondering if this was GPU related.
I tried to attach a spinner to a hinge and built something like Monsoon. The spinner doesn't really hit the opponent and is a bit Buggy. Just a small minor thing.
I also have noticed, that the background music is overlapping. When I go in the botlab, the title screen music and the botlab music play at the same time.
I tried to attach a spinner to a hinge and built something like Monsoon. The spinner doesn't really hit the opponent and is a bit Buggy. Just a small minor thing.
I also have noticed, that the background music is overlapping. When I go in the botlab, the title screen music and the botlab music play at the same time.
Great! I will be able to make Monsoon ripoffs!I tried to attach a spinner to a hinge and built something like Monsoon. The spinner doesn't really hit the opponent and is a bit Buggy. Just a small minor thing.
I also have noticed, that the background music is overlapping. When I go in the botlab, the title screen music and the botlab music play at the same time.
Thank you for noticing it. I haven’t done much testing with multiple chained hinge joints to see how it would affect a spinner collider. It needs to work well — I will try it this week.
Hey, ive tried a tantrum design and the spinner kinda like doesnt spin up. Also ive found out that my spinners stop easily on impact and i dont like that. Also i would love to see a motor with allot of torque so you can spin like massive deep six clones up to a good speed. And maybe a motor that does like 10000 rpm but has like not allot of power.
I would like the rack - and pinion Piston to be less powerful. I built an axe bot using this and it jumps up really high, when it fires the axe.
I would like the rack - and pinion Piston to be less powerful. I built an axe bot using this and it jumps up really high, when it fires the axe.
I think systems like those are still in development. The same pretty much happens with the hinged actuator.
Stuttering is gone, fps is as is, i limited it and it doesnt affect the physics
- Eliminated a source of garbage in the miniscript handler we built for the game (not in Miniscript itself!). This should reduce stuttering due to garbage collection for user-created robots. kix, I believe this is the source of the jankiness you were seeing for the past few builds. Let me know if it is still there!
- Removed the really annoying cyan-tinted albedo texture from steel and aluminum. This should make it easier to match colors.
- Reduced friction on all physics materials except for rubber. Hopefully this makes robots easier to drive and more realistic. Please let me know if things can slide easily enough. I can reduce friction a little more if it is necessary.
- Eliminated the ability to break off objects. This is in preparation for the new damage system which will break off armor plates instead.
I haven't played around with the new build too much yet but I have noticed a quality of life downgrade whereby if you resize a component that has other components attached/linked to it, then it moves all the attached components by a large amount and often in different directions as opposed to moving them a small fraction like it used it in previous builds.
Basically makes resizing components a re-positioning nightmare.
The gearboxes sounds brilliant though, as always with these updates I'm really excited to see where this game goes.
Hey, ive tried a tantrum design and the spinner kinda like doesnt spin up. Also ive found out that my spinners stop easily on impact and i dont like that. Also i would love to see a motor with allot of torque so you can spin like massive deep six clones up to a good speed. And maybe a motor that does like 10000 rpm but has like not allot of power.
Have you tried using a pulley? None of the larger motors have any gearing. It might take some tweaking, but you should be able to get a weapon that spins up.
Also, make sure your weapon doesn’t rest on the floor.
Lastly, no motors in existence could get a Deep Six sized weapon up to 10,000 RPM. At that RPM, the weapon would be supersonic. I have modeled this in game by increasing air drag exponentially as you approach Mach 1. Edit: We did put in an ME0708. It has about as much power as you are going to see in a heavyweight. You can gear it for high torque with pulleys or chains, but you will be trading off top speed when you do it.
I haven't played around with the new build too much yet but I have noticed a quality of life downgrade whereby if you resize a component that has other components attached/linked to it, then it moves all the attached components by a large amount and often in different directions as opposed to moving them a small fraction like it used it in previous builds.
Basically makes resizing components a re-positioning nightmare.
The gearboxes sounds brilliant though, as always with these updates I'm really excited to see where this game goes.
Oh darn, in what situation does the scaling problems occur? Could you send the bot as well? So I can see exactly what situation you are having problems with.
Might have messed that up when I reworked a part of the code to reduce redundancy.
I haven't played around with the new build too much yet but I have noticed a quality of life downgrade whereby if you resize a component that has other components attached/linked to it, then it moves all the attached components by a large amount and often in different directions as opposed to moving them a small fraction like it used it in previous builds.
Basically makes resizing components a re-positioning nightmare.
The gearboxes sounds brilliant though, as always with these updates I'm really excited to see where this game goes.
Oh darn, in what situation does the scaling problems occur? Could you send the bot as well? So I can see exactly what situation you are having problems with.
Might have messed that up when I reworked a part of the code to reduce redundancy.
[ This attachment cannot be displayed inline in 'Print Page' view ]
All the component were lined up in place on this Basilisk replica, I clicked on the one part of the flipper panel to make it 0.05 wider and any attached components (and even some non attached) repositioned themselves in a clump together. In the past it would only slightly move any attached component out of alignment by 0.1 whereas this build of the game is drastically moving pieces around.
It’s not limited to just one bot either as it’s been a repeatable issue on any bot I try to amend in this latest build.
I can send you over a bot file once I’m back home if it’s of any help.
Talking about the pit floor though - I have found that when AI bots drive over the closed pit, they then take to driving in endless circles like they've lost all other bots and dunno where to go? It's not until I push them away off of it that they go back to fighting normally.
This is actually an issue since 2.01 buildTalking about the pit floor though - I have found that when AI bots drive over the closed pit, they then take to driving in endless circles like they've lost all other bots and dunno where to go? It's not until I push them away off of it that they go back to fighting normally.
This sounds like an issue with hazard detection/avoidance. They might be treating the closed pit as a hazard area, and then panicking once they're on top of it, because they know to avoid hazard areas but don't know what to do when inside one...? Idk, just spitballing. Certainly needs to be looked into.
I played the new bleeding build and 2 WD robots are still a bit hard to drive. Can you reduce the friction more?Its really not friction as its the floor having terrible stats, try driving 2wd bots over the pit and you will see that they are driving good
A few ideas:Those are some great Ideas! I have another one: I would like to power a weapon with multiple motors like a lot of the builders at Battlebots do.
- tutorial. I’ve been planning on making one for yt but haven’t gotten around to it yet. Maybe have one built into the game when it gets released? From what I’ve seen, A Heap Of Games along with others have no clue how to build anything.
- Chassis list. Maybe have multiple pre-made options for chassis along with the build-your-own option could definitely make it more user-friendly.
-Flamethrowers. Because why not?
- Decals. Obviously, the painter will need to be useable first, but decals would definitely be a nice edition.
- visual damage. Robot Champions’ visual damage gives me wet dreams, and I feel others would say the same.
- timed matches. It’s annoying to see a five minute ai push battle. Obviously would need a judging system.
Just put the finishing touches on a few bug fixes. I should be able to push them to bleeding edge builds tomorrow once Cloud Build is done:
1. Fixed the floor surface friction coefficient for all arenas.
2. Fixed OOTA not being called by any robots.
3. Fixed the Bugglebots pit glitches.
4. Fixed the scaling problem that Arcane pointed out a few posts back.
Just put the finishing touches on a few bug fixes. I should be able to push them to bleeding edge builds tomorrow once Cloud Build is done:
1. Fixed the floor surface friction coefficient for all arenas.
2. Fixed OOTA not being called by any robots.
3. Fixed the Bugglebots pit glitches.
4. Fixed the scaling problem that Arcane pointed out a few posts back.
Axles are also fixed to be non breakable on belts?
Did you guys added component damage again?
The disc of a bot fell out and after i hit it, bot lost hp
EDIT: Tested it and after certain hits, HP of the component goes to 0 and hits after that damage the chassis
Let me know if you guys think driving feels good. If so, I'll start working on damage. If not, lets get driving to the point where it feels great first.The Driving is almost perfect. I am certainly sure that you need to add friction tho. A lot of it, currently everything is too slidey
I think the damage strategy is going to be as follows:1. Deffo make the chassis damagable. Maybe add an option where a component can be damagable or not for temporary time until you add proper damage?
1. Comment out all existing damage code. We should start with a blank slate, with all robots being completely invincible.
2. Add damage types back in one at a time.
3. Each time we add a new damage type we will put out a bleeding edge build for testing. If it feels good, we'll keep it. If it feels bad, we'll remove it. If it doesn't make any difference at all to game feel, then we'll remove it. Complicated = bad. Fewer damage types = good.
New Bleeding Edge Test Build is out!
http://www.robot-rumble.com/bleedingedgebuilds/ (http://www.robot-rumble.com/bleedingedgebuilds/)
The latest versions are the 14SEPTEMBER2019 builds.
Two things for this build:
1. [Bug Fix] Eliminated Depth of Field postprocessing effect. This was causing excessive blur in the robot workshop when working on beetleweight robots.
2. [Tweaked] Adjusted friction coefficients to the following:
Aluminum: 0.4
Polycarbonate: 0.2
Rubber: 0.9
Steel: 0.3
UHMW: 0.05
MDF: 0.3
With this fix, friction coefficients are pretty close to their real-life values. Robots should now skid much more believably.
Let me know if driving feels good with the 14SEPTEMBER build. If so, we can finally start working on damage. :gunz:
Only thing is- I built an itty bitty vs, and this weird “bubble” formed around the weapon, and caused the bot to flip around the arena. It didn’t do that with any pulleys attached to it, but when I directly added the spinner on to the motor shaft, uh oh.
This shouldn’t be too big of a fix... It’s just a minor that needs tweaking.
Thanks for all of your feedback! I think we will push this one out as an official stable release on itch.io, then start work on the new features. Any last requests before then?
Thanks for all of your feedback! I think we will push this one out as an official stable release on itch.io, then start work on the new features. Any last requests before then?
-A few more shapes for use in Extra's & Weapons - mainly a ring and Taurus (to create wheel tyres) and maybe some letters?
-A flatter spin motor
-Some smaller motors & burst for featherweights (and the burst to be useable as a lifting burst for the heavys)
But they might just be more work in progress aha ;P xD
Otherwise, my only other thing to mention would be that the pit in the Bugglebots arena doesn't descend. That would be it.
-A few more shapes for use in Extra's & Weapons - mainly a ring and Taurus (to create wheel tyres) and maybe some letters?Yes to the ring and torus, but a hard no on the letters. I've been playing Automation for a few years, and when you put make/model names on the back of your car, you have to manually position each letter and try and get the sizes and spacings exactly right, and it's a colossal pain in the ass. I'd much prefer the ability to position a text box on one of the robot's faces and then type in the text. Much easier.
option to make parts indestructible
Thanks for all of your feedback! I think we will push this one out as an official stable release on itch.io, then start work on the new features. Any last requests before then?My requests are: letters as shapes, being able to power a spinner with multiple motors and CAD support.
Defenitely some good ideas!Thanks for all of your feedback! I think we will push this one out as an official stable release on itch.io, then start work on the new features. Any last requests before then?
-A few more shapes for use in Extra's & Weapons - mainly a ring and Taurus (to create wheel tyres) and maybe some letters?
-A flatter spin motor
-Some smaller motors & burst for featherweights (and the burst to be useable as a lifting burst for the heavys)
But they might just be more work in progress aha ;P xD
Otherwise, my only other thing to mention would be that the pit in the Bugglebots arena doesn't descend. That would be it.
option to make parts indestructible
Oof. This one is hard. It will require working on the backend code as well as coming up with the UI on the front end. Then it will need testing.
Is it worth it if it takes a few more weeks/months? I don’t imagine that we would want this in the released game...
is it just my version that has bubblegum spazz around? And both Crab bots just sliding over the arenafloor? and Manta killing itself by exploding sometimes? There has happend too much in this thread to read it all and to be up to date with known bugs and glitches. As of now it feels like there are 4 heavys working as intended with Faust, Earthquake, TR3 and Royal Bobby
Idk if I patched the game correctly with the latest fix. I was using the August 29 version and just pasted all the stuff in the folder with the same name like you did with RA2 back in the day
New Bleeding Edge Test Build is out!
http://www.robot-rumble.com/bleedingedgebuilds/
The latest versions are the 17SEPTEMBER2019 builds.
[Added] Gearboxes! They take up a fair amount of space right now, but they should work.
This build is a stable build release candidate. If the gearboxes have issues, we will release the 14September builds as the newest stable builds. Our next step is reworking damage, which will involve breaking A LOT of things. This will be the last stable build before we start down this new path.
No flat motor yet?
Lmao. For a second I thought you meant that your modeler is an actual ATM. Anyways, hope all goes well with everything!No flat motor yet?
Not yet. Our modeler is super busy with their day job ATM.
At this point we are trying to focus on getting the codebase up to speed. Once all the code pieces are in place we should be able to shift over to creating content.
Question: I am currently half way through building a fairly part heavy design and I seem to have reached a point where I am unable to make anymore custom parts. Is this an intentional limit or is it a bug? if it is a bug has anyone found a way round it?
Question: I am currently half way through building a fairly part heavy design and I seem to have reached a point where I am unable to make anymore custom parts. Is this an intentional limit or is it a bug? if it is a bug has anyone found a way round it?
It's a bug, there isn't supposed to be a limit.
Can I have the robot file to find the cause of the problem?
Whats up with the resolution? If i play at 1080p it looks like its 720p and with lot of aliasing, and if i play on 4k it also looks like 720p, but now with black birs on side, like its on a non widescreen format
-Robots you put in this directory (C:\Users\User\AppData\LocalLow\Nerd Island Studios LLC\Robot Rumble 2.0\Robots) can be found but (maybe on purpose) you can't find built in robots anywhere (so it looks like there's a gas tank in Earthquakev1 but you cant edit a copy of the robot to use the tank...)I think that devs are actually more interesting in perfecting stuff for user built bots, than prebuilt ones
Just goona throw out three things I believe should be added/fixed within the next few updates:This glitch should be fixed. I want to build Clamping Blade.
- Flatmotors
- somewhat decent AI for flippers and hammers
- Fix the motor attached to a motor/piston/hinge glitch.
I FIGURED OUT HOW TO FIX THE GLITCH!!! If you have a motor on a motor, attach a wheel to the second motor. Then you attach your weapon to the wheel. then BOOM! Now you have a saw bot.I mean yeah, this is a nice fix, but its as nice as applying tape to the saw to hold it together
The wheel technique is good for actually making wheels that don't come up as spinners, but the thing about using wheels with weapons is that while the weapon is now indestructable, it no longer gets classed as a weapon and a wheel. I have tried this with a full body spinner, and it turned out when the shell was mounted to a wheel, if the bot hit anything the game thinks that it's wheels are taking damage and the robot will end up hurting itself in the process.Thats not the wheel issue, but its physics being janky af, if you make a flipper, and if it also reaches 0 hp, every flip after that will harm the bot itself
With the damage being stupid af, a good example of that would be Hell Spawn losing to Speed Demon. SD lost it’s weapon, but still won after HS gutted itself with its own weapon.The wheel technique is good for actually making wheels that don't come up as spinners, but the thing about using wheels with weapons is that while the weapon is now indestructable, it no longer gets classed as a weapon and a wheel. I have tried this with a full body spinner, and it turned out when the shell was mounted to a wheel, if the bot hit anything the game thinks that it's wheels are taking damage and the robot will end up hurting itself in the process.Thats not the wheel issue, but its physics being janky af, if you make a flipper, and if it also reaches 0 hp, every flip after that will harm the bot itself
EDIT: Might have not read that properly
Here's the Panic Attack I'm having problems with. (Mentioned on the game page.)
I've left the srimech on just one gearbox so you can see the difference between that and the totally limp forks.
Here's the Panic Attack I'm having problems with. (Mentioned on the game page.)
I've left the srimech on just one gearbox so you can see the difference between that and the totally limp forks.
Taking a look at Panic Attack now. I have set the gear ratios to be the same, and I see that the srimech rotates quickly, while the forks rotate more slowly.
Are you using the same motors for all of the actuators? The same motors with the same gearboxes experiencing the same load should rotate at the same speed. Any speed difference would be due to a difference in load.
EDIT: It just occurred to me, are you certain the two things moved at significantly different speeds when they were set to be equivalent? The forks have further to move.Depends on weight too i guess
Kix and CodeSilver23, thank you for your answers guys (Sorry mine is a lil bit late...)
But... you missed the main point that would block most of new testers...
When you unpack the september 17's build the "C:\Users\User\AppData\LocalLow\Nerd Island Studios LLC\Robot Rumble 2.0\Robots" folder doesn't exist AND while you don't create it by yourself you can't see the built-in bots and can't start any battle !
For example, try renaming your folder (as "...\Robots.bak" for example), run the game and you'll fast see what I mean. It looks like actually nothing in the game create the folder...
I'm (and you are certainly too) the kind of guys searching the Web and not giving up so fast when it comes to get something interesting working... But at first it's a bit disappointing and some people would have given up the testing of this game deleting the folder thinking it's really too early in the alpha...
Noticed that the robots when immobile and upside down seem to continuously slide aroundI can't remember if I mentioned this already but the same goes for things like horizontal discs, you break one off and it goes sliding across the arena like a slow-motion hockey puck. I'm certain that one time I attacked a broken-off disc and it dealt damage to my opponent, but I haven't been able to replicate it so maybe I was mistaken.
You can damage the opponent if you hit a part that's been broken offNoticed that the robots when immobile and upside down seem to continuously slide aroundI can't remember if I mentioned this already but the same goes for things like horizontal discs, you break one off and it goes sliding across the arena like a slow-motion hockey puck. I'm certain that one time I attacked a broken-off disc and it dealt damage to my opponent, but I haven't been able to replicate it so maybe I was mistaken.
I FIGURED OUT HOW TO FIX THE GLITCH!!! If you have a motor on a motor, attach a wheel to the second motor. Then you attach your weapon to the wheel. then BOOM! Now you have a saw bot.Sorry for the lat reply. How long did you try different things? Thank you for finding a fix. This will be very helpful, but how did you get the Idea of putting on a wheel?
honestly, i am not 100% sureI FIGURED OUT HOW TO FIX THE GLITCH!!! If you have a motor on a motor, attach a wheel to the second motor. Then you attach your weapon to the wheel. then BOOM! Now you have a saw bot.Sorry for the lat reply. How long did you try different things? Thank you for finding a fix. This will be very helpful, but how did you get the Idea of putting on a wheel?
Like that the blur will be gone, but I don't really mind ithonestly, i am not 100% sureI FIGURED OUT HOW TO FIX THE GLITCH!!! If you have a motor on a motor, attach a wheel to the second motor. Then you attach your weapon to the wheel. then BOOM! Now you have a saw bot.Sorry for the lat reply. How long did you try different things? Thank you for finding a fix. This will be very helpful, but how did you get the Idea of putting on a wheel?
Oh damn, looks like this has been worked on a bit since last time. Nice one.Enter my tournament instead ;)
I'll get into it a little bit and see if I can host a test tournament or something.
Oh damn, looks like this has been worked on a bit since last time. Nice one.Enter my tournament instead ;)
I'll get into it a little bit and see if I can host a test tournament or something.
Ok so here are some thoughts after a month of playing the October 10th build:Those are some good ideas. I'm already looking forward to what might come in the next build
The Positive:
- The damage has been improved by a good bit.
- There is no sudden limit on custom shapes that would occur so ayy thats great
- The Gearboxes are a godsend, you can really make more stuff more compact, and the bots can be a bit more slimmer
The Negative:
- As much as you have reduced the friction there is an issue where sliding exist, and its a bit too much
- The friction however didnt also fix the driving, even if we thought so. Main issue is that 2wd bots with wheels on the back will still bounce, the further behind the wheel is, the more bounce it has. It again seems that the pit lid that you can drive on untill it gets activated and descend has something to it that makes it perfect. The bots just dont bounce at all.
- If i play the game with 2 controllers, in settings there will be only one controller selected. You can change it so every person has its own controller controls, but after exiting the match, settings reset.
- Settings reset to stock. Music unmutes, unless you delete it in the game folder, The internal resolution reverts back to 1280X720 every time you enter or exit something.
- We need an option to both: Remove the dreadful texture on poly/UHMW/Alu material, and the option to make Alu/Steel parts be white. The only way atm is to set the RGB values from 1 to 2 in the rr2bot file.
With everything what i just said, i still play the game as its not as bad as it was 4 or 5 months ago, its actually pretty good. Its just that it needs improvements.
Been trying this out now and I'm wondering how to actually use the painter. Seen others with nicely colored bots, but no luck for me. Doesn't seem to paint much.The painter doesn't really work. People have been colouring their bots by using the "tint" function when selecting material type, and then adding details using paper thin custom components
Hey, you know the turntable in the Robot Workshop? I think this was mentioned before, but its rotation speed is tied to the frame rate, right? Could you change that and make the speed constant? It was nice and slow on my old laptop, and on my brand-new rig it's comically fast. I'll have to see if I can get a recording.ATM, the workaround is to limit the fps in rivatune but its a really "eh" workaround
1. @tashic has been working on the mirroring function in the botlab.This makes me (and likely others too) very happy.
Hey guys,Hopefully, all submissions for the SvL tournament will still be functional... If not, I'll allow all entrants to send in new bots/ fix issues and resend them. Glad to have you back, cjbruce.
Its finals week here at school, so I've "final"ly had a chance to sit down and take a crack at a few things:
1. @tashic has been working on the mirroring function in the botlab.
2. We have (finally) nailed down the structure of robots and how they are reconstructed from the BotLab -> .RR2Bot file -> combat. For this go-around the chain of component addition is preserved in combat. This means when you hit something hard enough to destroy it, it and everything attached to it will break off together. You can even proceed to bash composite robot assemblies apart into their individual components.
I've tested #1 and #2 above for heavyweights, and still need to make sure the above works with beetleweights. I should be able to put something up in the next day or two.
@kix, sorry about the friction/driving. I'm not sure if I have touched it in the last few months. The Mental Breakdown you sent me doesn't drive so great anymore. I think it also has weight issues too. i.e. its plates are made from a material that will bust apart with very little effort. i.e. I need to switch everything to 3 mm steel plate to see how that changes the driving.
Hey guys,Hopefully, all submissions for the SvL tournament will still be functional... If not, I'll allow all entrants to send in new bots/ fix issues and resend them. Glad to have you back, cjbruce.
Its finals week here at school, so I've "final"ly had a chance to sit down and take a crack at a few things:
1. @tashic has been working on the mirroring function in the botlab.
2. We have (finally) nailed down the structure of robots and how they are reconstructed from the BotLab -> .RR2Bot file -> combat. For this go-around the chain of component addition is preserved in combat. This means when you hit something hard enough to destroy it, it and everything attached to it will break off together. You can even proceed to bash composite robot assemblies apart into their individual components.
I've tested #1 and #2 above for heavyweights, and still need to make sure the above works with beetleweights. I should be able to put something up in the next day or two.
@kix, sorry about the friction/driving. I'm not sure if I have touched it in the last few months. The Mental Breakdown you sent me doesn't drive so great anymore. I think it also has weight issues too. i.e. its plates are made from a material that will bust apart with very little effort. i.e. I need to switch everything to 3 mm steel plate to see how that changes the driving.
I dont see holding off being an issue, its p easy for host to use an older version, of fix bots.Hey guys,Hopefully, all submissions for the SvL tournament will still be functional... If not, I'll allow all entrants to send in new bots/ fix issues and resend them. Glad to have you back, cjbruce.
Its finals week here at school, so I've "final"ly had a chance to sit down and take a crack at a few things:
1. @tashic has been working on the mirroring function in the botlab.
2. We have (finally) nailed down the structure of robots and how they are reconstructed from the BotLab -> .RR2Bot file -> combat. For this go-around the chain of component addition is preserved in combat. This means when you hit something hard enough to destroy it, it and everything attached to it will break off together. You can even proceed to bash composite robot assemblies apart into their individual components.
I've tested #1 and #2 above for heavyweights, and still need to make sure the above works with beetleweights. I should be able to put something up in the next day or two.
@kix, sorry about the friction/driving. I'm not sure if I have touched it in the last few months. The Mental Breakdown you sent me doesn't drive so great anymore. I think it also has weight issues too. i.e. its plates are made from a material that will bust apart with very little effort. i.e. I need to switch everything to 3 mm steel plate to see how that changes the driving.
Should I hold off until after the tournament?
Glad to see you are back bruce! The new damage handling is looking very nice, cannot wait to play around with it. Would it be possible to add a toggle in the settings to disable parts breaking off in future versions?
As Kix mentioned we have been poking around in the assembled code and I have made a modification to disable the parts falling off for the current version (as it is a bit dodgy as you know). I just wanted to ask what your opinion is on people potentially modifying the game?
this is a great idea but i have a feeling that this could be an issue:
Lets say you break#1, the whole thing falls off. Now in reality, the other wedge sides will be screwed on to the chassis so if #1 breaks and falls off, 2/3/4 would still stay.
Yea that seems possiblethis is a great idea but i have a feeling that this could be an issue:
Lets say you break#1, the whole thing falls off. Now in reality, the other wedge sides will be screwed on to the chassis so if #1 breaks and falls off, 2/3/4 would still stay.
This is absolutely on my brain right now. The breakage scripts are working for entire components, but not (yet) for chassis armor plates.
At one point I had a picture of one of our robots that took a hit in the competition. The Ampflow A28-150G gearbox was bolted to the inside of a polycarbonate chassis armor plate. A horizontal spinner hit busted the whole thing off: plate, gearbox, motor, and wheel. The motor was still connected via two wires to the ESC, so it still worked, even though it was trailing guts everywhere. It was awesome, and our kids went nuts when it happened in the competition.
That's what I really want to build. :)
There isn't a toggle switch in the settings right now. My thought is that the entire damage system will be based on parts falling off.Yeah, I was thinking as a sort of debug option while the damage system is being worked on, so we don't need to utilise things such as the "wheelfix" if things aren't working as planned.
That being said, I consider people modifying the game to be the greatest possible form of flattery. I just want to feel like people are getting their money's worth when it finally does go on sale.That's good to hear, I was a little worried about toeing the line when it came to making modifications. Glad to see a Dev that embraces the possibilities of mods!
PS - How are your Unity/art skills? :)Well I studied Digital Graphic/Motion Design along with Software Development in college and have used Unity a bit over the years for little hobby projects. So not a pro, but not a complete noob either really.
an issue:
(ok i cant insert attachments)
Ya ill send you the bot.an issue:
(ok i cant insert attachments)
It looks like the Weapon_Blur_Cylinder that is automatically generated rotates around an incorrect axis. Drat. I need to fix this. Would you mind sending me the .RR2Bot file?
Am I correct in assuming that there are supposed to be 6 horizontal spinners?
Ya ill send you the bot.an issue:
(ok i cant insert attachments)
It looks like the Weapon_Blur_Cylinder that is automatically generated rotates around an incorrect axis. Drat. I need to fix this. Would you mind sending me the .RR2Bot file?
Am I correct in assuming that there are supposed to be 6 horizontal spinners?
That is actually a rammer, no hori spinners at all
I've always dreamed of seeing the Battlebots reboot arena in this game.
Ya ill send you the bot.
That is actually a rammer, no hori spinners at all
I've always dreamed of seeing the Battlebots reboot arena in this game.
I've reached out to Battlebots but haven't heard anything back. It would be awesome, but we would need their permission to put it in the game.
I'm putting in a damage multiplier slider. We haven't done any damage tuning yet.Thats actually great
You should be able to slide it all the way to "0" in settings to disable damage entirely for tournaments.
I'm putting in a damage multiplier slider. We haven't done any damage tuning yet.Thats actually great
You should be able to slide it all the way to "0" in settings to disable damage entirely for tournaments.
Will that mean that the options will now save?
Oh, maybe the multiplier then should be set to a low value i suppose atleast till the settings can saveI'm putting in a damage multiplier slider. We haven't done any damage tuning yet.Thats actually great
You should be able to slide it all the way to "0" in settings to disable damage entirely for tournaments.
Will that mean that the options will now save?
Unfortunately no, not in this build.
Thats actually great
Will that mean that the options will now save?
Unfortunately no, not in this build.
What other saving isn't working?Audio settings, video settings
Still keeping an eye on how well this is going.One of those 2 do exist
If I had a better laptop, I would be playing this a lot more. And a building tutorial.
What other saving isn't working?As Kix mentioned the video settings seem to bounce back to default on every scene change so it seems the current resolution isn't being stored/read correctly.
For me the audio/video settings save if I change them during a fight, but they don't work in the main menu.
It's great to see that custom wheels should be working a lot better now, and that damage multiplier slider is going to come in incredibly handy!What other saving isn't working?As Kix mentioned the video settings seem to bounce back to default on every scene change so it seems the current resolution isn't being stored/read correctly.
At the moment, I'm using a hacky fix by injecting a script that sets the window size on awake() 😅
While we are on the subject of hacky fixes I'm working on; is there any plans for the ability to toggle the UI in a match? I, personally, would love to be able to disable it (especially the massive amount of screen space the free look camera panel takes up) for recording matches.
Still keeping an eye on how well this is going.
If I had a better laptop, I would be playing this a lot more. And a building tutorial.
For me the audio/video settings save if I change them during a fight, but they don't work in the main menu.
Gotcha! I will take a look either tonight or tomorrow. I was just setting them from within a fight and they were saving then. I haven’t checked when setting them from the main menu screen.
The new build is live! It is dated 12December2019, and includes the features and fixes in the preceding post. Yay alliteration!
3. for the damage. Maybe you could make an option to couple up few smaller parts to turn it into a bigger part. this way you could avoid losing a fair bit of parts because one small part that was holding the weapon together reached 0hp
oh yea, the update did something to self collision so this is fun i guess
Sending atmoh yea, the update did something to self collision so this is fun i guess
Darn it. I thought I fixed this.
I guess I need to look at it again. Would you mind sending the .RR2Bot file?
Ok so some feedback:
1. Flame pit instantly breaks off parts
2. Im not a fan of the damage. Even at 50% parts fall off too fast and it makes not difference than on 200%. You dont even need to hit a bot with the weapon to break his part off
3. for the damage. Maybe you could make an option to couple up few smaller parts to turn it into a bigger part. this way you could avoid losing a fair bit of parts because one small part that was holding the weapon together reached 0hp
Okay, after a bit of testing I can say the damage slider is working apart from the fire pit issue, however it seems that even on 200% that bot chassis are now immune to damage completely. House robots still take damage correctly but custom bots cannot be killed now, is this expected behaviour?I'm not too sure the damage slider is working when set to 0% as parts still seem to fall off but again that could be down to the flame pit mentioned earlier
Following that train of logic, what if component destructibility isn't possible at all. Is the game better if the entire robot is just one big bag of hit points? Everything works perfectly until the robot is dead?I think component destructibility is a major feature that needs to stay in the game, however the current handling could use tweaks. One thought I had is to have each tree of components form a bag of HP and once that is depleted then the entire tree falls off? Somewhat similar to the previous updates handling, but using the total tree health instead of just the weakest parts.
Would it always be optimal to just make the entire robot one group so that nothing ever falls off?Unfortunately there are always going to be people that optimise the fun out of any system, but I don't personally think that should be a reason not to do something.
Good to know. I might retune the slider to give a 25% option.The main thing is that you can hit an opponent with a wheel, and the part may fall off. Everything that is not a weapon prolly shouldnt deal damage.
It also fundamentally affects the design of the game. Would it always be optimal to just make the entire robot one group so that nothing ever falls off?Ok this one is kinda hard i guess, ofc i think with the way damage works people will need to relearn how to build. The problem is that the smaller the part is the less durable it is, which is okay, the issue however is that it seems like the scaling is off as small parts even on 50 thickness steel fall too off easily, Maybe make only weapons groupable?
Following that train of logic, what if component destructibility isn't possible at all. Is the game better if the entire robot is just one big bag of hit points? Everything works perfectly until the robot is dead?
The main thing is that you can hit an opponent with a wheel, and the part may fall off. Everything that is not a weapon prolly shouldnt deal damage.
[snip]
As for the damage multiplier, i think you should also add 5% and 10% because 25 might still be too high
Another issue is that the custom wheels fall off by themselves overtime. This is a shame really, as lot of my bots use custom made wheels
i think that the main culprit and issue is self damage, which breaks stuf. I was hitting an opponents chassis with my axe, and the axe fell off, he did not have a weapon at all
1. Objects should be damaged because they absorb kinetic energy (or impulse, or whatever). This could be from a spinner hit, but also from just naturally bumping into stuff. Case in point: a flipper launches a robot 2 meters in the air. The robot lands. It breaks into 2 pieces.The problem is, i was just driving the bot, i did not bounce into everything nor i was hit by a spinner/flipper/axe. Bot bouncing may have also been a culprit
2. The advantage of saying that "only weapons can cause damage" is that is a very clearly understood idea for players. The disadvantage is that it means that you can give literally anything you create a "weapon" tag, resulting in everything damaging everything. This puts us right back where we started.Maybe a weapon could only be parts that are not rubber and they are only on motors/pistons/servos.
1. Objects should be damaged because they absorb kinetic energy (or impulse, or whatever). This could be from a spinner hit, but also from just naturally bumping into stuff. Case in point: a flipper launches a robot 2 meters in the air. The robot lands. It breaks into 2 pieces.The problem is, i was just driving the bot, i did not bounce into everything nor i was hit by a spinner/flipper/axe. Bot bouncing may have also been a culprit2. The advantage of saying that "only weapons can cause damage" is that is a very clearly understood idea for players. The disadvantage is that it means that you can give literally anything you create a "weapon" tag, resulting in everything damaging everything. This puts us right back where we started.
Maybe a weapon could only be parts that are not rubber and they are only on motors/pistons/servos.
Maybe also a function where of you pressed f12, you could see what is a weapon (parts would be highlighted green), and what is not. This would be helpful for hosts i guess
1. Maybe the answer to this is that a minimum amount of kinetic energy needs to be dissipated in order for damage to occur. This should prevent random vibrations and bumping around from doing anything.I like the idea, this way, the vibrations/bouncing wont hurt thr bot. Also maybe at 0hp, you'd need to reach a certain force of KJ to rip the part out too!
2. Giving things a "weapon" tag would definitely help with player understanding. I like the idea of pressing the f12 key (or something similar on the mac keyboard) to highlight things. It doesn't address the damage caused by being launched into the air though. Should a big fall cause damage? What about getting launched sideways into the arena wall at 10 meters/second?Atm, Flipper damage should not be touched till the damage itself is sorted. As for the launching stuff, i guess internal damage would be the best, however if you would hit the side/floor at a high speed with a spinning weapon, then i guess external damage would work there
I've downloaded and started up the new version for a short bit. May be trying to build stuff with mirroring now in place.Alternatively, you can rotate the bot. Select the chassis and do a 180. Heading to 0 and voila!
What I did notice is an issue with the forward heading. Some of my bots (namely Stopping Power and Miasma) have it at 180 (or -180, doesn't matter), but every time the botlab is entered with one of them, the forward heading gets reset to 0.
also while i'm here, can i request the ability to run a weapon off of multiple motors? this would help tremendously with trying to make more compact robots.
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. [ This attachment cannot be displayed inline in 'Print Page' view ]
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 had to turn things way down because my laptop is chugging:You wanna know chugging? 4 highly detailed bots in one arena, lagging out a 6 core pc, although it was the gpu that was struggling
I had to turn things way down because my laptop is chugging:You wanna know chugging? 4 highly detailed bots in one arena, lagging out a 6 core pc, although it was the gpu that was struggling
I had to turn things way down because my laptop is chugging:You wanna know chugging? 4 highly detailed bots in one arena, lagging out a 6 core pc, although it was the gpu that was struggling
I'm noticing that too. All of the robots I build are really simple. No decoration, just basic blocky parts to see if the basic ideas are working correctly. When I pulled up the second version of Panic Attack my memory usage went through the roof and the game slowed to a crawl.
I have a few ideas that might help:
1. Put each robot on its own collision layer during combat and disable all self-collisions within that layer. I have a hunch that this should fix Crabsolutely Clawfull, Beetle Crab, Son of Ziggy, and any other robots whose motor armatures have things attached with overlapping colliders. (EASY FIX - can be done today)
2. Get the painter working. Having an entire separate component dedicated to every piece of paint on the robot is just crazy: awesome looking, but computationally expensive. (HARD FIX - will take weeks/months of building out the painting system)
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.Genius.
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 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.
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. [ This attachment cannot be displayed inline in 'Print Page' view ]
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 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.
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
Yeah 0.5 secs will be good.
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
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 easilyYeah 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”.
Thats grat, damage multiplier untouched i guess
Ok my life is complete, i also guess forward heading might be borkedThats grat, damage multiplier untouched i guess
Fixed! It is now a continuous slider.
What about gyro?What about gyro?
Works fine for meWhat about gyro?What about gyro?
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.
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.
I've just tested with a giant box scaled down, and that definitely is the problem. If you resize the chassis using the standard scaling tool, the inside layer of the armour doesn't change.
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.
that's what i meant and that's what i figured. unfortunate, but if you ever get the chance to try something like that i'd really be grateful.also while i'm here, can i request the ability to run a weapon off of multiple motors? this would help tremendously with trying to make more compact robots.
Were you thinking two motors, both turning the same belt? You can request it, but it really complicates the component assembly tree. I.e. it isn't really a tree structure any more. The .RR2bot file and component assembly is currently built around a tree structure. Each component has exactly one parent component. With the possibility of two parents, things become much more complicated.
Regarding robot damage, I'd love for something like this to be possible:
https://youtu.be/RkvHRf6T8L4?t=74
I have no idea how hard that would be to model, but I'd love to be able to disintegrate other robots :dance:
That is indeed a way, but the forward heading should still be fixed regardless. Otherwise it's a bit useless.I've downloaded and started up the new version for a short bit. May be trying to build stuff with mirroring now in place.Alternatively, you can rotate the bot. Select the chassis and do a 180. Heading to 0 and voila!
What I did notice is an issue with the forward heading. Some of my bots (namely Stopping Power and Miasma) have it at 180 (or -180, doesn't matter), but every time the botlab is entered with one of them, the forward heading gets reset to 0.
New build: Damaged components do something very comical in that they float in place once they've been broken off... Kinda like it becomes a fighter bonus reward or something. The same also seems to happen with robots with a flipper piston system. They just kinda float around.
I also managed to try out the mirroring properly. AMAZING!! Exactly what I would have hoped for! Even with the wiring!! Bravo!
Would it be possible maybe to incorporate a similar system in the plot gird for custom components & the chassis? Maybe set up a rule with it that all start and end points need to be on their corresponding mirror axis/plane (so if you wanted to mirror on the X, the first and last points must be on the middle line on the X axis, if that makes sense?)
Regarding robot damage, I'd love for something like this to be possible:
https://youtu.be/RkvHRf6T8L4?t=74
I have no idea how hard that would be to model, but I'd love to be able to disintegrate other robots :dance:
Loved that fight video! :claping
If you built reps of the two robots in the workshop, I'm pretty sure you could recreate exactly that level of robot disintegration with the current (20December2019) build.
Regarding robot damage, I'd love for something like this to be possible:
https://youtu.be/RkvHRf6T8L4?t=74
I have no idea how hard that would be to model, but I'd love to be able to disintegrate other robots :dance:
Loved that fight video! :claping
If you built reps of the two robots in the workshop, I'm pretty sure you could recreate exactly that level of robot disintegration with the current (20December2019) build.
What happened? It's blocked over here.
New build: Damaged components do something very comical in that they float in place once they've been broken off... Kinda like it becomes a fighter bonus reward or something. The same also seems to happen with robots with a flipper piston system. They just kinda float around.
Hmmm. Weird. I thought I had fixed the instances of this. Can you send me a .RR2Bot file to play with?
Yeah, the floating parts happen a lot for me. It looks like an item drop tbh.
Note: The parts that are broken off still feel like they have moon gravity, and they still are immovable
This:
(https://i.makeagif.com/media/6-22-2015/odOeWB.gif)
There was not a whole lot left afterwards.
Over the past week or so I've been working on integrating an open source mod api in to Robot Rumble that allows non-destructive mod injection using the Harmony Library. I just have a couple of technical questions to help with mod development in the future. I'll start for now with this one:
Do you know if there is a method that is called on each scene load outside of the default sceneLoaded event? I'm working on a roundabout fix for the resolution issue and it seems that a method that triggers (potentially on Awake()) on scene load is causing the resolution to be set incorrectly but I haven't been successful in finding it. Also its just occurred to me as I'm writing that such a global hook would be very useful for modding if it did exist.
Also, on the topic of modding:Im pretty sure you might be able to inject arenas into the game via mod. Or alternatively, an arena builder just like how bot builder works
2. We also could really use an open source arena builder tool.
Also, on the topic of modding:Im pretty sure you might be able to inject arenas into the game via mod. Or alternatively, an arena builder just like how bot builder works
2. We also could really use an open source arena builder tool.
I could make a mock up
Also, on the topic of modding:Im pretty sure you might be able to inject arenas into the game via mod. Or alternatively, an arena builder just like how bot builder works
2. We also could really use an open source arena builder tool.
I could make a mock up
I was thinking something more official. Like using Unity to create arena AssetBundles that you can load from a directory.
Also, on the topic of modding:Im pretty sure you might be able to inject arenas into the game via mod. Or alternatively, an arena builder just like how bot builder works
2. We also could really use an open source arena builder tool.
I could make a mock up
I was thinking something more official. Like using Unity to create arena AssetBundles that you can load from a directory.
Idk how friendly would that be to inexperienced people.
Also, on the topic of modding:Im pretty sure you might be able to inject arenas into the game via mod. Or alternatively, an arena builder just like how bot builder works
2. We also could really use an open source arena builder tool.
I could make a mock up
I was thinking something more official. Like using Unity to create arena AssetBundles that you can load from a directory.
Idk how friendly would that be to inexperienced people.
But it would give unlimited creative freedom. You could make literally anything that you could make in Unity.
Building a bespoke arena builder would be quite a bit more work. We played around with the idea a bit initially, but didn’t have enough developer time to do it. It really needs a dedicated person working on it.I wonder if it would be easy to just copy everything from bot builder, just as a test
I wonder if there is a runtime scene builder on the Unity asset store that we could use...Let me see what i can find
The botlab stuff is pretty robot-specific. We would have to add quite a bit to make it useful as an arena tool.EDIT: Maybe it should just be like early bot builder. It works, but its not functional as it doesnt save
What version of Unity is being used to build the game? (If at all relevant).
I might have a go at seeing how easy it would be for a beginner to create something for the game potentially.
Also, on the topic of modding:
1.We still have the RR2 Component Modding Tool project on the back burner. The idea is to make all of the in-game components using the tool.
2. We also could really use an open source arena builder tool.
Both of these have languished in the vaporware stage because we are down just @tashic and me for development. Would you be interested in picking up one (or both) of these projects? I would like to put them up on github when they are ready.
I kinda want to ask for that to see if i can do some stuff, but i dont think i wantAlso, on the topic of modding:
1.We still have the RR2 Component Modding Tool project on the back burner. The idea is to make all of the in-game components using the tool.
2. We also could really use an open source arena builder tool.
Both of these have languished in the vaporware stage because we are down just @tashic and me for development. Would you be interested in picking up one (or both) of these projects? I would like to put them up on github when they are ready.
I mean if you have the start of the projects and can put up with me asking technical questions/asking for access to parts of the source of RR2 I'd be more than happy to take on these in my spare time.
Funnily enough my next question was going to be about implementing arenas as dynamically loaded AssetBundles so this is exactly what I had in mind for the future.
Some more thoughts regarding damage, chassis hitpoints, and breaking apart components with reference to my previous post about disintegrating robots:
-Currently, the game mechanics are similar to Robot Arena 2, where players design a chassis that is most like a solid body onto which components are attached.
-In real life combat robot design, the chassis is not a solid block, but panels and components attached to a frame or unibody construction of some sort, covering other panels, components, and mounts for those components. During combat, these panels and components are deformed and/or forcibly removed from the frame (also known as damage to the robot).
-The creative freedom currently allowed in Robot Rumble 2 allows for robots to be built out of custom parts much like they are in real life. The only weird part about this is the base "chassis", which seems to have the robot's hit points for judging a KO.
As an experiment, I created a sort of egg beater-style vertical spinner robot that actually has a base chassis that makes up for a small part of the center of the robot. The rest of the robot is composed of re-scaled shapes that are formed into body panels that cover the front, sides, and rear. These are attached to base body panels which are themselves attached to the small chassis piece.
While this method of construction is time-consuming and pretty KO-proof compared to what we're used to experiencing in RA2, I find the combat this creates a lot more satisfying. For an example, I pitted my Tombstonesque horizontal bar-spinning robot against my beater-spinning robot created in this way and the destruction is just awesome! I easily pick apart the wheels, the frame surrounding the spinner, then whoops the spinner breaks off! Then repeated hits to the top and rear body panels just send them flying away, exposing the poor robots guts!
Am I the only one who's going to be building robots in this way from now on? Because it's just fun being able to tear these things apart piece by piece!
One thing I don't quite understand is how the damage is working. How does the material thickness slider affect the damage a panel or weapon takes? What about the physical size of the panel or weapon, or its material? I know the system is totally a WIP, though.
They are fully redoing the damage, and in future, you might be able to slit open a chassis, for now it is as it is. Now the method of construction you are using, is very popular in ra2 and it is known as extednderbot building.
The damage, is a mixed bag, slider is self explanitory, i guess the hp is calculated by this formula: material thickmess*material itslef*component cubed size=HP. Idk if this is true, but im speculating that it is built like that
Can components mounted directly to the chassis be broken off, or are they invincible like in RA2?They can be broken off, unless they are motors for some reason
The problems in my existing bots are only getting more numerous as I keep testing. :baffled:
It's impossible to make Panic Attack capable of steering fast enough to rotate 360 degrees inside 10 seconds, S3 is under reversed gravity on one side so it balances on the weapon and the other wheel at all times, and my shell-drum bot is incapable of rotating horizontally at all once it starts its weapon, and the weapon can never be stopped - even once it gets broken off completely the effect remains.
I haven't worked on any other broken bot besides Panic Attack yet, because it ideally needs to be present to defend the Parsec Rumble title, but this particular issue with Panic itself just isn't effected by anything.
I've tried different gearing, lifting the forks and skirts off the floor, replacing the back wheels with low friction alternatives, removing the back wheels entirely, removing the entire paint job to simplify the physics. No effect from any of those.
The problems in my existing bots are only getting more numerous as I keep testing. :baffled:
It's impossible to make Panic Attack capable of steering fast enough to rotate 360 degrees inside 10 seconds, S3 is under reversed gravity on one side so it balances on the weapon and the other wheel at all times, and my shell-drum bot is incapable of rotating horizontally at all once it starts its weapon, and the weapon can never be stopped - even once it gets broken off completely the effect remains.
I haven't worked on any other broken bot besides Panic Attack yet, because it ideally needs to be present to defend the Parsec Rumble title, but this particular issue with Panic itself just isn't effected by anything.
I've tried different gearing, lifting the forks and skirts off the floor, replacing the back wheels with low friction alternatives, removing the back wheels entirely, removing the entire paint job to simplify the physics. No effect from any of those.
By any chance do you still have the old version of Panic Attack to compare? I am curious to see how much things slow compared to the newer, decorated version. I suspect that all of the bits and pieces are adding up to significant CPU load.
I have a very rough idea on how to go about “flattening” the decorations at runtime. I’m not sure if it will work, but it might help...
Oh yeah one thing that i figured out but forgot to tell.
When a wheel/weapon falls off spinning motor screws up the physics
AFAIK - When a part completely falls off, the motor will spin completely and gyro like hell.
What's just occurred to me is that the issue might relate to both weapons technically being spinners as far as the game's concerned. It might struggle to deal with them being moved not on their axis of rotation.
EDIT: Okay... Now I'm confused. This old version works fine, but the modern version with all the decals removed doesn't.
The only practical differences between this and the unpainted modern version is that this version had motor-driven skirts because I didn't know sprung hinges were a thing, and everything is still wheel-fixed on this one.
But the modern one still had this issue when it was wheel-fixed.
So... could it be the sprung hinges?
EDIT 2: I just made a copy of one of the broken Panic Attacks, and swapped the hinged skirts for motor driven. That had no effect. So that isn't the difference. I guess... Maybe re-wheel-fix the weapons, see if that works?
EDIT 3: It was the absence of the wheel-fix. So it hasn't been rendered obsolete just yet, the current physics model is so unforgiving to low-geared spinners that motor-driven lifters still need the wheel-fix to avoid having their ability to steer nearly removed.
What's just occurred to me is that the issue might relate to both weapons technically being spinners as far as the game's concerned. It might struggle to deal with them being moved not on their axis of rotation.
EDIT: Okay... Now I'm confused. This old version works fine, but the modern version with all the decals removed doesn't.
The only practical differences between this and the unpainted modern version is that this version had motor-driven skirts because I didn't know sprung hinges were a thing, and everything is still wheel-fixed on this one.
But the modern one still had this issue when it was wheel-fixed.
So... could it be the sprung hinges?
EDIT 2: I just made a copy of one of the broken Panic Attacks, and swapped the hinged skirts for motor driven. That had no effect. So that isn't the difference. I guess... Maybe re-wheel-fix the weapons, see if that works?
EDIT 3: It was the absence of the wheel-fix. So it hasn't been rendered obsolete just yet, the current physics model is so unforgiving to low-geared spinners that motor-driven lifters still need the wheel-fix to avoid having their ability to steer nearly removed.
FOUND IT!
The Weapon_Blur_Cylinder was still being added to the srimech on the newer version of Panic Attack.
This shouldn't be happening, but it was.
It turns out that I was making the check to see if the motor had angle limits (instead of spinning all the way around) too early in the robot reconstruction process.
In the end I created a workaround that checks to see if the motor EVER has angular limits on its hinge joint. If so, then it will destroy the blur cylinder.
Thank you so much for sending both robots. It was key to figuring out what was happening. You are amazing!
The game is building now. I will try to get an update out amidst the holiday festivities...
PS - Hopefully this build means no more wheel fixes! :)
[Bug Fix] Broken off objects no longer spin when you press a control button.
New build is building right now. While we wait:
[Changed] When a motor breaks off, the whole assembly comes as a single rigid object. This eliminates some weird behavior where the motor is inside the chassis connected via a hinge joint to everything else outside the chassis. The whole mess would just bounce around bizarrely.
[Changed] When a component is broken off, it is given a random velocity. This should help eliminate the weird floating that is occurring for broken components.
[Bug Fix] Broken off objects no longer spin when you press a control button.
[Bug Fix] Eliminated the second copy of the chassis armor plates that weren't being scaled correctly when chassis was scaled.
[Bug Fix] Fixed problem with the heading slider always snapping back to zero when you came back to the Robot Workshop.
[Bug Fix] Added Steel physics material to flywheel to prevent it from sliding all over the place when it breaks off.
[Bug Fix] If a motor has limits, the blur cylinder is no longer added.
NOTE - The above is making physics run faster for lots of robots.
The 24December build is up!
Look back a few posts for the bug fixes.
https://robot-rumble.itch.io/builds (https://robot-rumble.itch.io/builds)
A thing we have been talking about on discord. There should be a function to fuse all the smaller part as a one part. Atleast on weapons only. The issue is that some amazing looking bots are made out of a lot of smaller pieces, including the weapon. Now evrn on 20%damage, they all fall off too easily because they mostly have less than steel 5 on them, and that can be a problemooh, yes please! Maybe add holes too?
Ah... Turns out the need for the wheel-fix isn't quite gone for good.
I'm testing the Panic Attacks now. The ones without the fix perform just as well as the fixed ones in the test area, but in the actual battle arenas they still steer like motion sick cows. :(
A thing we have been talking about on discord. There should be a function to fuse all the smaller part as a one part. Atleast on weapons only. The issue is that some amazing looking bots are made out of a lot of smaller pieces, including the weapon. Now evrn on 20%damage, they all fall off too easily because they mostly have less than steel 5 on them, and that can be a problem
A thing we have been talking about on discord. There should be a function to fuse all the smaller part as a one part. Atleast on weapons only. The issue is that some amazing looking bots are made out of a lot of smaller pieces, including the weapon. Now evrn on 20%damage, they all fall off too easily because they mostly have less than steel 5 on them, and that can be a problemooh, yes please! Maybe add holes too?
A thing we have been talking about on discord. There should be a function to fuse all the smaller part as a one part. Atleast on weapons only. The issue is that some amazing looking bots are made out of a lot of smaller pieces, including the weapon. Now evrn on 20%damage, they all fall off too easily because they mostly have less than steel 5 on them, and that can be a problemooh, yes please! Maybe add holes too?
Holes. I would love holes. *he says wistfully*
Just thinking about thinking about how to do mesh boolean subtraction makes my head hurt. Maybe @tashic has some ideas on this. He's smarter than I am.
Im sceptical about this. You see if a spinner is made out of small parts, that means that the spinner may not have collision where its needed, which will be a big problem. I recommended having an option to group parts together to have combined hp so that way atleast the whole weapon will fall offA thing we have been talking about on discord. There should be a function to fuse all the smaller part as a one part. Atleast on weapons only. The issue is that some amazing looking bots are made out of a lot of smaller pieces, including the weapon. Now evrn on 20%damage, they all fall off too easily because they mostly have less than steel 5 on them, and that can be a problemIf the hit points are super small, just disable their collider.
Im sceptical about this. You see if a spinner is made out of small parts, that means that the spinner may not have collision where its needed, which will be a big problem. I recommended having an option to group parts together to have combined hp so that way atleast the whole weapon will fall offA thing we have been talking about on discord. There should be a function to fuse all the smaller part as a one part. Atleast on weapons only. The issue is that some amazing looking bots are made out of a lot of smaller pieces, including the weapon. Now evrn on 20%damage, they all fall off too easily because they mostly have less than steel 5 on them, and that can be a problemIf the hit points are super small, just disable their collider.
When will we get brushless motors? They would be more compact then brushed. However they would overheat. Now because overheating not a thing. Maybe atm, they would weigh more
Someone had to write it :VWhen will we get brushless motors? They would be more compact then brushed. However they would overheat. Now because overheating not a thing. Maybe atm, they would weigh more
You actually took my idea. Cuck
What exactly is community manager?
Ah... Turns out the need for the wheel-fix isn't quite gone for good.
I'm testing the Panic Attacks now. The ones without the fix perform just as well as the fixed ones in the test area, but in the actual battle arenas they still steer like motion sick cows. :(
Aauuugh!
I'm so sorry for that! I will take a look when I have some time. Do you notice that the wheel fixed versions of Panic Attack drive normally?
PS - These are the versions of Panic Attack that I am testing with. They perform pretty similarly, except for the extra CPU/GPU load of the v2 version:
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
Tbh i want to help, but im fine giving you feedback like we all are doing on gtm.
Now how about we talk about Chassis damage, part grouping, tube components and brushless motors?
I'm hoping to ramp up development in 2020 and bring on a few more people to the official dev team. It would be great to get things into a beta state by the end of 2020.
Community Manager
Component Modding Tool Developer
Is anyone interested in the above? Any other ways that you have been dying to contribute?
Please send me a PM if you are interested!
I'm hoping to ramp up development in 2020 and bring on a few more people to the official dev team. It would be great to get things into a beta state by the end of 2020.
Community Manager
Component Modding Tool Developer
Is anyone interested in the above? Any other ways that you have been dying to contribute?
Please send me a PM if you are interested!
Would it be possible for us to contribute by, for example, submitting ideas or designs for house robots? Idk how many pre-built robots you want to have in the finished game, but more is always better, and across a wide range of weapon types and weight classes.
Mind you, maybe it's too early to be thinking about stuff like that, considering the number of breaking changes that keep getting introduced...
Yeah, the wheelfixed versions have normal handling everywhere.
These are the two versions of the current tournament model, wheel-fixed and not. I was gonna remove the paintwork from them for the sake of your CPU load, but this time - which surprised me given it never worked for the previous versions of the problem - removing the decals did actually fix the in-battle handling problem. So this time the decals do undoubtedly relate to the issue.
[ This attachment cannot be displayed inline in 'Print Page' view ] [ This attachment cannot be displayed inline in 'Print Page' view ]
At this point, I've been wondering if the problem might relate to the super-low gearing too.
So at this point, I imagine the issue would probably be mostly if not entirely fixed by the whole part grouping thing.
Ah... Y'know I said less detailed Panic Attacks didn't need the wheelfix?
Only sometimes. It seems like the problem is still with either the double-gearbox or the total ratio of 125:1, because all it takes is a moderately complex opponent to push it over the edge back into passive ultra-gyro.
Maybe we can do another slider to control the number of hit points before a component becomes breakable in settings?Maybe an option like in gmod? This would be similar where You select all small parts, press group button and then select main part and press group to button, and then it would group stuff together. The collision would be there, unless you maybe check disable collision. I could draw up a mockup. It would be simpler then that slider i guess.
The driving issues are just as bad as before, if not worse. D:
The skirts now come off way too easily too, just a couple of low speed collisions of the kind they're designed for can snap off the whole thing. And the part that actually runs on the floor doesn't have collisions, so makes the whole skirt pointless.
Ok so the new update is bad. It breaks robots with thin and small parts, it seems like you tried to do something with group coupling and it didnt really worked that well.
Can i recommend this? Its a longer thing so it is in spoiler below:
Tbh im not really a fan of this, lets say theoretically that you need a small part to be functional , but the game wont allow that because its too small. Atm the tip of the wedges for cyar's panic attack are not working as they dont have collision. Thats why i recommended that, and people over at RA2 central discord liked the idea. (we usually talk about rr2 improvements there)Ok so the new update is bad. It breaks robots with thin and small parts, it seems like you tried to do something with group coupling and it didnt really worked that well.I think I would like a hybrid approach where you set a threshold and it shows you which parts are too small to add colliders. With this approach you can always bump up the thickness or switch materials for a particular part to ensure its collider stays enabled.
Can i recommend this? Its a longer thing so it is in spoiler below:
What if we added a workshop for components? What is made in that workshop could have combined hp, and you could also apply that part to multiple bots without having to do it all again. You could then share stuff like letters and logos with the community.Oh so like you can build a bar in there made out of multiple shapes then save it as a one shape?
Exactly.What if we added a workshop for components? What is made in that workshop could have combined hp, and you could also apply that part to multiple bots without having to do it all again. You could then share stuff like letters and logos with the community.Oh so like you can build a bar in there made out of multiple shapes then save it as a one shape?
What if we added a workshop for components? What is made in that workshop could have combined hp, and you could also apply that part to multiple bots without having to do it all again. You could then share stuff like letters and logos with the community.
Worst case scenario: Make a material called decorative, it would have a 0kg multiplier and it would remove collision, also it wouid be good because then it would fall off when the part that its connected to would fall off.
Im still liking my idea more, as then we could fix the issue where spinners with a lot of small parts would be fragile
I just think its a good idea to focus on producing the Component Modding Tool. It seems to produce a long term fix rather than a short that is gonna be changed laterYeah i guess that should be a big focus rn
What if we added a workshop for components? What is made in that workshop could have combined hp, and you could also apply that part to multiple bots without having to do it all again. You could then share stuff like letters and logos with the community.I don’t know how well this would work, but with my current knowledge, couldn’t you create .partfiles kinda like what you do with the robots? Then you can share your designs that way. Also, all components you make or import could show up under custom weapons and custom extras. This is what I mainly had in mind.
What if we added a workshop for components? What is made in that workshop could have combined hp, and you could also apply that part to multiple bots without having to do it all again. You could then share stuff like letters and logos with the community.I don’t know how well this would work, but with my current knowledge, couldn’t you create .partfiles kinda like what you do with the robots? Then you can share your designs that way. Also, all components you make or import could show up under custom weapons and custom extras. This is what I mainly had in mind.
Osh** we gonna make stuff in blender? Thats epic actually, i can make some good sh**What if we added a workshop for components? What is made in that workshop could have combined hp, and you could also apply that part to multiple bots without having to do it all again. You could then share stuff like letters and logos with the community.I don’t know how well this would work, but with my current knowledge, couldn’t you create .partfiles kinda like what you do with the robots? Then you can share your designs that way. Also, all components you make or import could show up under custom weapons and custom extras. This is what I mainly had in mind.
That’s the basic idea behind the RR2 Component Modding Tool. We are starting work on it and the Arena Builder at the same time.
The intent for the tools is for them to be separate Unity projects that you can use to create pretty much anything you want, export it as a unity assetbundle, then import it into the game. The big advantages with this approach is that you will be able to create literally anything you want, limited only by your 3D modeling skills.
Also, you should be able to use the new tools to create parts that are optimized for the game. If you were to use our existing in-game tool to create an intricate compound assembly it is going to be extremely inefficient and run very slowly. I am already having lots of problems trying to run Panic Attack on my laptop. This isn’t the fault of the robot. It is an amazing robot. It is a problem with the tool which can’t handle making really complicated things that run efficiently.
I recommend using Blender to create things. It’s free and has a massive open source development effort. It already does everything people have asked for, and is the tool we have been using to create robot parts for the game,
You say that people are gonna be limited by their skills only. Well if thats the case, i might be able to make vrushless motors then!
the one thing that may be a tad concering, is that if there's no limits to the stats and stuff those components can have, what's preventing someone from having an invincible tinyaf brushless motor with more power than an E-Tek, or having some kind of giant SMEEEEEEE wedge with 3 trillions of HP, you may want some kind of limiters so that some people don't start making an arms race of making the dumbest, most overpowered sh**
oh and other thing, is there any way to fix the bug where the AI just goes in circles like an idiot when it drives over the closed pit ?
The 28December build is up!
https://robot-rumble.itch.io/builds (https://robot-rumble.itch.io/builds)
This one should allow you to apply decorations without physics colliders.
Next up is getting chassis armor plates to break off.
Enjoy! :smile:
The decoration material is a brilliant idea!! My only suggestion would maybe be an additional Decorative_Steel (and maybe Polycarb) for small yet shiny/transparents decorations such as Rivets and Warning Lights :)I havent tested it yet but pls tell me that decorative material doesn't have that dreadful bumpmapping on itself like alu/uhmw/and poly
The decoration material is a brilliant idea!! My only suggestion would maybe be an additional Decorative_Steel (and maybe Polycarb) for small yet shiny/transparents decorations such as Rivets and Warning Lights :)I havent tested it yet but pls tell me that decorative material doesn't have that dreadful bumpmapping on itself like alu/uhmw/and poly
Yeah so ever since the 24th build when the weapon falls off, the blur is still there. Even worse, the blur does damage... at this point, I gotta decide between moon gravity and ghost spinners for SvL. I mean... I could always use October 10, but people probably won’t like that. I’m at a dilemma at this point.
Moon gravity is nothing much really, its just an thing when you attach a wheel then the weapon on itYeah so ever since the 24th build when the weapon falls off, the blur is still there. Even worse, the blur does damage... at this point, I gotta decide between moon gravity and ghost spinners for SvL. I mean... I could always use October 10, but people probably won’t like that. I’m at a dilemma at this point.
Shoot! Let me look into this. I definitely want to keep the spinners. I just need to iron out the bugs like ghost spinners. It shouldn’t be too hard. I just need to find and fix all the wired edge cases.
What is the moon gravity issue? Can you send me an .RR2Bot file to play with?
Moon gravity is nothing much really, its just an thing when you attach a wheel then the weapon on itYeah so ever since the 24th build when the weapon falls off, the blur is still there. Even worse, the blur does damage... at this point, I gotta decide between moon gravity and ghost spinners for SvL. I mean... I could always use October 10, but people probably won’t like that. I’m at a dilemma at this point.
Shoot! Let me look into this. I definitely want to keep the spinners. I just need to iron out the bugs like ghost spinners. It shouldn’t be too hard. I just need to find and fix all the wired edge cases.
What is the moon gravity issue? Can you send me an .RR2Bot file to play with?
Im pretty sure that he means that the gyro is increasedMoon gravity is nothing much really, its just an thing when you attach a wheel then the weapon on itYeah so ever since the 24th build when the weapon falls off, the blur is still there. Even worse, the blur does damage... at this point, I gotta decide between moon gravity and ghost spinners for SvL. I mean... I could always use October 10, but people probably won’t like that. I’m at a dilemma at this point.
Shoot! Let me look into this. I definitely want to keep the spinners. I just need to iron out the bugs like ghost spinners. It shouldn’t be too hard. I just need to find and fix all the wired edge cases.
What is the moon gravity issue? Can you send me an .RR2Bot file to play with?
I’m not sure I understand. If you attach a wheel, there shouldn’t be a blur cylinder or any of the associated physics. Does something weird happen when an object breaks off?
Im pretty sure that he means that the gyro is increased
I just tried out Panic Attack with the new decorative material. While it doesn't break its own physics anymore, and does have functional skirts, if it fights a complex opponent the problem returns. :(
So... Better, but still issues.
Yeah so ever since the 24th build when the weapon falls off, the blur is still there. Even worse, the blur does damage... at this point, I gotta decide between moon gravity and ghost spinners for SvL. I mean... I could always use October 10, but people probably won’t like that. I’m at a dilemma at this point.
I just tried out Panic Attack with the new decorative material. While it doesn't break its own physics anymore, and does have functional skirts, if it fights a complex opponent the problem returns. :(
So... Better, but still issues.
Phew! The rest is just a matter of tweaking numbers until it feels right. My thought for the first draft of this is to compute object hit points based on the energy absorption capabilities of the part. Something like 1 HP = 1 Joule
Huh niceI just tried out Panic Attack with the new decorative material. While it doesn't break its own physics anymore, and does have functional skirts, if it fights a complex opponent the problem returns. :(
So... Better, but still issues.
Phew! The rest is just a matter of tweaking numbers until it feels right. My thought for the first draft of this is to compute object hit points based on the energy absorption capabilities of the part. Something like 1 HP = 1 Joule
Thinking more about how the skirt should break:
The skirt should be extremely resistant to damage from spinners because of its shape. It should deflect blows upward instead of absorbing energy. It should be extremely fragile if hit from underneath by a vertical spinner.
I think I can accomplish this generically by computing the incidence angle of any spinner hits. Glancing blows should bounce off.
That would honestly be pretty cool. Reading this, I take it that currently the shape of, lets say the front armor, doesn't matter too much?I just tried out Panic Attack with the new decorative material. While it doesn't break its own physics anymore, and does have functional skirts, if it fights a complex opponent the problem returns. :(
So... Better, but still issues.
Phew! The rest is just a matter of tweaking numbers until it feels right. My thought for the first draft of this is to compute object hit points based on the energy absorption capabilities of the part. Something like 1 HP = 1 Joule
Thinking more about how the skirt should break:
The skirt should be extremely resistant to damage from spinners because of its shape. It should deflect blows upward instead of absorbing energy. It should be extremely fragile if hit from underneath by a vertical spinner.
I think I can accomplish this generically by computing the incidence angle of any spinner hits. Glancing blows should bounce off.
That would honestly be pretty cool. Reading this, I take it that currently the shape of, lets say the front armor, doesn't matter too much?I just tried out Panic Attack with the new decorative material. While it doesn't break its own physics anymore, and does have functional skirts, if it fights a complex opponent the problem returns. :(
So... Better, but still issues.
Phew! The rest is just a matter of tweaking numbers until it feels right. My thought for the first draft of this is to compute object hit points based on the energy absorption capabilities of the part. Something like 1 HP = 1 Joule
Thinking more about how the skirt should break:
The skirt should be extremely resistant to damage from spinners because of its shape. It should deflect blows upward instead of absorbing energy. It should be extremely fragile if hit from underneath by a vertical spinner.
I think I can accomplish this generically by computing the incidence angle of any spinner hits. Glancing blows should bounce off.
Another thing I would personally like to note, unrelated to the damage stuff, is in the workshop. Sometimes I want to do or edit something on the underside of the bot. The table there then kinda gets in the way. Would have to zoom in a lot on the bot to actually see it then.
While one could technically rotate the entire robot for a bit to work on the underside, just moving the camera there is just easier. Could it be done to see through the table if the camera is under it? Make it transparent or fade out of sight perhaps.
That would honestly be pretty cool. Reading this, I take it that currently the shape of, lets say the front armor, doesn't matter too much?
Thinking more about how the skirt should break:
The skirt should be extremely resistant to damage from spinners because of its shape. It should deflect blows upward instead of absorbing energy. It should be extremely fragile if hit from underneath by a vertical spinner.
I think I can accomplish this generically by computing the incidence angle of any spinner hits. Glancing blows should bounce off.
Another thing I would personally like to note, unrelated to the damage stuff, is in the workshop. Sometimes I want to do or edit something on the underside of the bot. The table there then kinda gets in the way. Would have to zoom in a lot on the bot to actually see it then.
While one could technically rotate the entire robot for a bit to work on the underside, just moving the camera there is just easier. Could it be done to see through the table if the camera is under it? Make it transparent or fade out of sight perhaps.
The 29December build is up!Tbh i dont think that the damage should be calculated by blur cylinder. I think KJ should cause damage, that way rammers might also do damage
No Blur Cylinders in this build! This also means (almost) no damage, since most of the damage is calculated from blur cylinders.
https://robot-rumble.itch.io/builds (https://robot-rumble.itch.io/builds)
The 29December build is up!Tbh i dont think that the damage should be calculated by blur cylinder. I think KJ should cause damage, that way rammers might also do damage
No Blur Cylinders in this build! This also means (almost) no damage, since most of the damage is calculated from blur cylinders.
https://robot-rumble.itch.io/builds (https://robot-rumble.itch.io/builds)
Tested the build and i gotta say that the damage is pretty great, i can actually feel comfortable enough to do 50-100% multiplier, whereas with the blur i used only 20%
The blur cylinder does four things, but maybe we can take a look at what we like and don't like:1# From what ive heard, noone likes the blur at all
1. Visual blur - a visual representation of the cylinder created by rotating an object around an axis.
2. Cylinder collider - a trigger collider that registers when something overlaps the space of the revolved object.
3. Pushout - applying impulse to the robot and whatever it hits.
4. Bite - Determining the exact amount of "bite" when the spinner hits another object.
1# From what ive heard, noone likes the blur at all1) the blur could do with being a bit toned down imo, but I personally like it
2# I need more explanations as atm i dont see it too useful
3# Is impulse really necessary
4# Im sure you could do it easily, what counts as bite?
3) impulse is what makes the bots fly apart on hit, essentially the simulation of force/physicsWell i got that wron XD
Maybe we can use an invisible blur
Or perhaps (later) make an option where it can be turned on and off, or via a slider to determine how visible it is.Maybe we can use an invisible blur
I think you might be right. I personally need to see the blur cylinder so that I can tell if the shape is correct. Once I know that it is generating correctly (it isn’t right now), then I can disable the mesh renderer.
That would honestly be pretty cool. Reading this, I take it that currently the shape of, lets say the front armor, doesn't matter too much?I just tried out Panic Attack with the new decorative material. While it doesn't break its own physics anymore, and does have functional skirts, if it fights a complex opponent the problem returns. :(
So... Better, but still issues.
Phew! The rest is just a matter of tweaking numbers until it feels right. My thought for the first draft of this is to compute object hit points based on the energy absorption capabilities of the part. Something like 1 HP = 1 Joule
Thinking more about how the skirt should break:
The skirt should be extremely resistant to damage from spinners because of its shape. It should deflect blows upward instead of absorbing energy. It should be extremely fragile if hit from underneath by a vertical spinner.
I think I can accomplish this generically by computing the incidence angle of any spinner hits. Glancing blows should bounce off.
Another thing I would personally like to note, unrelated to the damage stuff, is in the workshop. Sometimes I want to do or edit something on the underside of the bot. The table there then kinda gets in the way. Would have to zoom in a lot on the bot to actually see it then.
While one could technically rotate the entire robot for a bit to work on the underside, just moving the camera there is just easier. Could it be done to see through the table if the camera is under it? Make it transparent or fade out of sight perhaps.
[Changed] When the first part on a rigidbody goes to <0 HP, the previous component is broken off. Everything now breaks off together.Does that mean that the part with the lowest hp, lets say on a spinner will cause the whole thing to fall off? If so, yikes
[Changed] When the first part on a rigidbody goes to <0 HP, the previous component is broken off. Everything now breaks off together.Does that mean that the part with the lowest hp, lets say on a spinner will cause the whole thing to fall off? If so, yikes
Oh i just figured out what it means. Yeah it works.[Changed] When the first part on a rigidbody goes to <0 HP, the previous component is broken off. Everything now breaks off together.Does that mean that the part with the lowest hp, lets say on a spinner will cause the whole thing to fall off? If so, yikes
Not necessarily, though that could be the case. It means that when you build a spinner you need to make sure the base part is relatively large and can take a hit.
Otherwise, just like in real life, if you build something tiny and attach a bunch of stuff to the tiny part it will snap the whole thing off.
Edit: You have to actually hit the tiny part to damage it. If you have a bunch of other things farther out then they are likely to be hit first.
Ooo. Interesting. I have a center of mass script I could use for that. I like it!Ya also, is it possible to make an option where the cylinder blur is invisible in the settigns? or atleast opacity settings, because Cylinder Blur can work even with 100%Transparency
Thanks for testing the shell spinner! Would you mind sending me the .RR2Bot file? I need to work on spinner bite.[ This attachment cannot be displayed inline in 'Print Page' view ]
Right now I have oversimplified things and assume that spinners will always come to a complete stop, dumping all of their kinetic energy on a single hit. For a spinner with lots of angular momentum like a shell spinner this is a bad model of reality. I need some heavy spinners like your to test with when I make changes to this.
I've had an issue for a little while now with one of my bots. There are two parts of its front wedge that I could only practically build by using giant wedge sides that are mostly inside the bot's chassis.
Issue being that when those wedge sides get broken off separately to the main wedge part, they often end up rattling around inside the robot, which results in it having mobility issues even worse than some of my Panic Attack variants due to the way broken parts move.
Thanks for testing the shell spinner! Would you mind sending me the .RR2Bot file? I need to work on spinner bite.[ This attachment cannot be displayed inline in 'Print Page' view ]
Right now I have oversimplified things and assume that spinners will always come to a complete stop, dumping all of their kinetic energy on a single hit. For a spinner with lots of angular momentum like a shell spinner this is a bad model of reality. I need some heavy spinners like your to test with when I make changes to this.
Ooo. Interesting. I have a center of mass script I could use for that. I like it!Ya also, is it possible to make an option where the cylinder blur is invisible in the settigns? or atleast opacity settings, because Cylinder Blur can work even with 100%Transparency
I've had an issue for a little while now with one of my bots. There are two parts of its front wedge that I could only practically build by using giant wedge sides that are mostly inside the bot's chassis.
Issue being that when those wedge sides get broken off separately to the main wedge part, they often end up rattling around inside the robot, which results in it having mobility issues even worse than some of my Panic Attack variants due to the way broken parts move.
Is there a way to re-engineer the robot so that the problem goes away? Alternatively, is this something that could be solved with special components using the RR2 Component Modding Tool?
I'm hesitant to try to implement a fix when one might consider broken parts interfering with mobility part of the challenge of the game.
I've found that with the blur, when a bot slowly approaches my shell spinner, the shell always suddenly stops spinning and gets ripped up. But the problem didn't appear in the 29th build
And sometimes the weapons still get stuck together then the weapon parts would be torn apart.
The 03January build is up!Do that man, atm im testing this build but it seems to be great, link tho?
I'm going to have to slow down after this one. School starts on Monday!
I noticed this glitch in the 03January build:
EDIT: The robot that is gyrodancing has no spinning weapons.
I’m pulling out the center of mass calculations that I did this afternoon. I will have a clean version up tomorrow morning.Will that fix clipping thru issues and random teleportation?
Chassis damage will need to wait a bit.
I’m pulling out the center of mass calculations that I did this afternoon. I will have a clean version up tomorrow morning.Will that fix clipping thru issues and random teleportation?
Chassis damage will need to wait a bit.
I noticed this glitch in the 03January build:
[ This attachment cannot be displayed inline in 'Print Page' view ]
EDIT: The robot that is gyrodancing has no spinning weapons.
I noticed this glitch in the 03January build:
[ This attachment cannot be displayed inline in 'Print Page' view ]
EDIT: The robot that is gyrodancing has no spinning weapons.
I've had that problem on S3 ever since the first build with part damage. Except on S3, it's the bot's default state of being. Regardless of damage, drive controls, and whether the weapon is running.
I noticed this glitch in the 03January build:
[ This attachment cannot be displayed inline in 'Print Page' view ]
EDIT: The robot that is gyrodancing has no spinning weapons.
I've had that problem on S3 ever since the first build with part damage. Except on S3, it's the bot's default state of being. Regardless of damage, drive controls, and whether the weapon is running.
Would you mind sending me S3? I would like to get the spinning-related quirks nailed out.
At some point I’m going to have to deal with the fact that hammers are going to have less than 1% of the kinetic energy of a spinner. Damage will need to work differently. I suppose that is a problem for the future though.If materials had puncture strength and tear strength, then hammers could do puncture damage and spinners could do tear damage.
Would you mind sending me S3? I would like to get the spinning-related quirks nailed out.
Sure. [ This attachment cannot be displayed inline in 'Print Page' view ]
Just put up a new 06January2020 Bleeding Edge Build:
http://www.robot-rumble.com/bleedingedgebuilds/ (http://www.robot-rumble.com/bleedingedgebuilds/)
The purpose of this build is to test driving with your big spinners. I reduced the mass of all big spinners by about 90% from where they were this should significantly improve the stability of the simulation for big heavy spinners.
In particular, if you have a shell spinner let me know how it drives with this build!
Just put up a new 06January2020 Bleeding Edge Build:
http://www.robot-rumble.com/bleedingedgebuilds/ (http://www.robot-rumble.com/bleedingedgebuilds/)
The purpose of this build is to test driving with your big spinners. I reduced the mass of all big spinners by about 90% from where they were this should significantly improve the stability of the simulation for big heavy spinners.
In particular, if you have a shell spinner let me know how it drives with this build!
Okay. So... First off, I imagine you already know this, but this test does make spinners nearly incapable of scoring effective hits.
My verts handle so well they're actually harder to aim because of the oversteer. Circumvolution in particular is pretty ridiculous, it almost feels like it steers faster than without the weapon, though that's probably just a psychological thing from me over-correcting.
My more standard horizontals basically feel like they don't have a weapon at all, in all aspects of handling, despite one of them having a "32 kg" flywheel with the torque to spin up in under 3 seconds.
My shell and my ring both have basically the same problem; they feel like they've already lost their weapons, and their opponents don't notice their hits at all.
While I'm here, I might as well also mention: This test does actually fix the suicidal torque when I use the srimech on non-wheelfixed versions of Panic Attack. Unfortunately it also makes it too flimsy.
The issue still remains though with it being effectively unable to steer when I gear the weapons low without the wheelfix.
The problem there being that with the wheelfix, they go completely limp when put under any minor shock from moving parts of opponents. With both gearboxes on each weapon set to 10/1 - meaning a total ratio of 100/1, the effective limit of a single gearbox - they move fast enough that it isn't an issue in battle.
But the wheelfix makes them unuseable at the more authentic speed given by setting each gearbox at 10/0.4 - a speed at which the torque would have little enough of an effect that I'd be able to use the srimech effectively.
So right now the choice with the bot is between being nearly incapable of steering, and being nearly incapable of self-righting. :dead:
While I'm here, I might as well also mention: This test does actually fix the suicidal torque when I use the srimech on non-wheelfixed versions of Panic Attack. Unfortunately it also makes it too flimsy.
The issue still remains though with it being effectively unable to steer when I gear the weapons low without the wheelfix.
The problem there being that with the wheelfix, they go completely limp when put under any minor shock from moving parts of opponents. With both gearboxes on each weapon set to 10/1 - meaning a total ratio of 100/1, the effective limit of a single gearbox - they move fast enough that it isn't an issue in battle.
But the wheelfix makes them unuseable at the more authentic speed given by setting each gearbox at 10/0.4 - a speed at which the torque would have little enough of an effect that I'd be able to use the srimech effectively.
So right now the choice with the bot is between being nearly incapable of steering, and being nearly incapable of self-righting. :dead:
Do you have limits set on the srimech motor? The wheelfix shouldn't actually do anything if that is the case. If the code sees that limits are set, it should treat it exactly the same as if a wheel is attached. I just checked both versions of Panic Attack you sent, and neither of them have a Spinner Mass Reducer -- both have limits set on the motor. Both versions should behave exactly the same.
Yup. Limits are set. Both do the exact same 90 degree arc, but the non-wheelfixed one runs better, while being kinda flimsy.
Make sure all four weapon gearboxes on the non-wheelfixed one are set to 10/1, to match the wheelfixed one, then put each of them in the test area and give the srimech a waggle.
If your simulation is running roughly the same as mine, then on the jan 6 build you should see the non-wheelfixed version twitch faintly (reasonably good), while the wheelfixed one pivots clear into the air (practically kills the robot in battle.)
Ok so tested the new build.
The good:
-Sparks actually are great.
The bad:
-Gyro is non existant
-Driving seems to be lower and more sluggish than the previous builds
-The hits seem to be mixed bag. My hits seem to be okay, i can hit the bot and the weapon will not slow down immensly. Some bots fail to do that
-When a disc/bar spinner hits the ground it loses all the torque and the bot doesnt even react properly, its like the bar weighs 0 kilos. Craplectric ant self right like that anymore, it just tumbles until it self rights, even tho the spinner is running at 150+ mph when it hits the ground.
So basically all of my bots have lost their gyro with this new build, even the ones with huge spinners. And it was working fine in the Jan 01 build
Honestly the hits is kinda feeble to me.
And the sparks look nice but a bit weird
Ok so tested the new build.
The good:
-Sparks actually are great.
I'm glad you like them! They need some tweaking, but I thought they weren't bad for a first attempt.
The bad:
-Gyro is non existant
The slider should help with that. I'm thinking that we put in a slider that goes from 0% - 50%. In the 01January2020 build, I had minimum spinner masses of around 30%, depending on RPM. In the current build my minimum spinner masses are around 1%.
-Driving seems to be lower and more sluggish than the previous builds
Now that the overall robot mass is kept constant, all robots should maintain their inertia. We got use to the inertia dropping once the spinner got up to speed. Maybe this explains the sluggishness?
-The hits seem to be mixed bag. My hits seem to be okay, i can hit the bot and the weapon will not slow down immensly. Some bots fail to do that
The hit response depends on bite. If bite is small, then a glancing blow occurs and there isn't much kick. If bite is big, then a "good hit" occurs and the spinner will stop instantly and create a large amount of kick (impulse).
I hope it does-When a disc/bar spinner hits the ground it loses all the torque and the bot doesnt even react properly, its like the bar weighs 0 kilos. Craplectric ant self right like that anymore, it just tumbles until it self rights, even tho the spinner is running at 150+ mph when it hits the ground.
I'm planning to increase the kick on glancing blows. This should help with the self-righting.
-Driving seems to be lower and more sluggish than the previous builds
Now that the overall robot mass is kept constant, all robots should maintain their inertia. We got use to the inertia dropping once the spinner got up to speed. Maybe this explains the sluggishness?
it kinda does, but if i gear up the motor (or down), in theory, the bot should drive faster, but in game the bot bounces
[Changed] Sparks are only emitted on glancing blows.Idea: More sparks = Bigger blows, like small hits would emit a tiny ammount of sparks and really big ones would emit lot of sparks. Will we also get sparks on alu material?
[Changed] Sparks are only emitted on glancing blows.Idea: More sparks = Bigger blows, like small hits would emit a tiny ammount of sparks and really big ones would emit lot of sparks. Will we also get sparks on alu material?
Huh alu might not actually spark yeah. Now i kinda wish we had titanium material in this game XD[Changed] Sparks are only emitted on glancing blows.Idea: More sparks = Bigger blows, like small hits would emit a tiny ammount of sparks and really big ones would emit lot of sparks. Will we also get sparks on alu material?
I agree, but don't worry about it for a couple of builds tbh. Just focus on getting this physics stuff sorted :)
And I wouldn't say so as aluminium doesn't spark in the same way steel would (in fact I don't think it sparks at all). I would maybe say when it gets to that point for materials like aluminium, plastic, ect. maybe just having chips/small debris instead of sparks.
Huh alu might not actually spark yeah. Now i kinda wish we had titanium material in this game XD
I don’t think that’s the way to go. I’d prolly go with glancing blow= straight line of sparks, and big blow=more spread out sparks.[Changed] Sparks are only emitted on glancing blows.Idea: More sparks = Bigger blows
I can't seem to select bots to play at all. Here's a screen recording of the issue below:Aw **** i remember one if my friends having this issue. Idk how did we fix it. I think we wiped appdata game stuff, or he made a bot. As for the music, you can remove it by deleting musicstreams(or whatever is the 10mb one) file in the streaming folder in data folder.
https://www.youtube.com/watch?v=bd3E-t8EGvg
I'm not sure when this started happening, as I haven't given RR2 a go in a good while and there's been a lot of software and hardware updates since the last time I got it to work. I'm currently on Windows 10 with an AMD RX 5700XT GPU with the latest video drivers. I'm on a dual monitor setup (one 1080p and one 4k), and the issue is the same no matter which monitor I have the game on, in fullscreen or in windowed, even if I disable one of the monitors.
Also, and more importantly, the music slider doesn't save it's setting between restarts which is REALLY annoying.
ok driving is still an issue:
This is what we refer to when the bots bounce. Way early builds didnt have the issue at all.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.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.
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.
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.
Then of course there's Roller, which along with un-wheelfixed Panic Attack still has crippling problems even when idle.
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.
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.
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?
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.
I noticed this glitch in the 03January build:
EDIT: The robot that is gyrodancing has no spinning weapons.
My brain is melting.
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.
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?
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.
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.
kix,Tbh im not too fussed about the increased cpu usage as my pc is pretty good, but as long as bots stop doing the bounce thing ill be more than happy
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.
Speaking about hammers, I tried to make a sawbot and this happened:Saws dont work. Idk when will the official fix happen, but atm a "fix" would be to attach the saw on a wheel
[ This attachment cannot be displayed inline in 'Print Page' view ]
Could you please fix it?
Speaking about hammers, I tried to make a sawbot and this happened:Saws dont work. Idk when will the official fix happen, but atm a "fix" would be to attach the saw on a wheel
[ This attachment cannot be displayed inline in 'Print Page' view ]
Could you please fix it?
kix,Well i do see some minor improvements, but noting really that stopped jittering completely
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/ (http://www.robot-rumble.com/bleedingedgebuilds/)
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
As long as it stops the jittering, im more than happy. There are fair amount of people wit bots that jitter.worst case scenario, set the floor material to steel.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...
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.
Try driving on the pit floor, it might work thereI'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.
This is what Roller and Panic Attack look like on my end.
Smooth simulation quality, but both bots are far more broken than you've described on your end.
But, one thing to note is that the test area doesn't break Panic Attack. Only actually going into battle does.
https://youtu.be/S2gJpr8WiM4
I noticed with the new steel floor there is this weird clanking that seems to be coming from that rolling pin. Here's a video, play it with sound:I second this
[ This attachment cannot be displayed inline in 'Print Page' view ]
I noticed with the new steel floor there is this weird clanking that seems to be coming from that rolling pin. Here's a video, play it with sound:
New bleeding edge build is coming out tomorrow. I have added sliders to adjust the following:Thats weird. The fix might not be that? What if the wheels have too much grip or something which cause it to jump?
Physics Tick Rate (100 - 500 ticks per second)
Physics Default Solver Velocity Iterations
Physics Default Iterations
I might try adding a few more sliders to see if we can figure out a fix to the jittering problem. I have noticed that if I increase the physics tick rate to 300 I the jittering in Beta seems to become a smooth oscillation back and forth. It just about doubles the time spent in physics per frame though. My baby laptop CPU is getting HOT.
Yup. You guys are right. There was a bug in the breakage code.Nice, how about the 500 tick lagging like crazy on certailn bots, even tho the cpu usage was not full?
When all of the parts connected to a spinner (a.k.a. a single wheel) are broken off, it was supposed to set the remaining mass (a.k.a. just the axle) to have a mass of something just higher than zero. Instead it was setting the remaining mass to be equal to the original mass. This meant that the robot would shake and wobble like crazy when everything was broken off other than the axle itself.
New build coming soon...
I watched the video, and it looks like it was only when you were in the fire pit.Yup. You guys are right. There was a bug in the breakage code.Nice, how about the 500 tick lagging like crazy on certailn bots, even tho the cpu usage was not full?
When all of the parts connected to a spinner (a.k.a. a single wheel) are broken off, it was supposed to set the remaining mass (a.k.a. just the axle) to have a mass of something just higher than zero. Instead it was setting the remaining mass to be equal to the original mass. This meant that the robot would shake and wobble like crazy when everything was broken off other than the axle itself.
New build coming soon...
It aint the flame pit. Its the bot im certainI watched the video, and it looks like it was only when you were in the fire pit.Yup. You guys are right. There was a bug in the breakage code.Nice, how about the 500 tick lagging like crazy on certain bots, even tho the cpu usage was not full?
When all of the parts connected to a spinner (a.k.a. a single wheel) are broken off, it was supposed to set the remaining mass (a.k.a. just the axle) to have a mass of something just higher than zero. Instead it was setting the remaining mass to be equal to the original mass. This meant that the robot would shake and wobble like crazy when everything was broken off other than the axle itself.
New build coming soon...
When I ripped a wheel off in the 11January build, the bot still gyrodances around.
EDIT: The rolling pin doesn't even rotate with my settings, so that fixes the annoying clanking.
EDIT 2: Can you send me Rainbow Circus? I have a VERY powerful laptop I would like to try it on.
Maybe also add a group function for currently built bots that use ingame components, because cmt is gonna mean that bots should be rebuiltCMT????? What is that?
Lightning, I will trade you Rainbow Circus for the robot with the gyro dancing! :smile:If you look at my showcase, Takedown does the weird gyro thing. I include a download link on my showcase for the bots I post.
EDIT: What do the other 2 sliders do on the right?
PS. The smooth oscillation is actually just beta having lwered wheels for previous builds
I did a little performance testing for 3 robots using the Unity profiler. The times shown here are only significant insofar as they are relative to each other.
The complexity of the robot is almost directly proportional to the time spent in physics processing.
Rainbow Circus 2 is a shell spinner with 125 components. It is pretty much unplayable on my laptop. kix saw significant slowdowns on this robot on his computer, particularly as it passed through the flame pit and all of the colliders triggered collisions with the flame trigger volume.
Mental Breakdown is a simple vertical spinner with 32 components. It runs well on my laptop at 100 ticks/second. It slows down, but is still playable at 300 ticks/second.
HUGE Spinny is a "Tombclone" with 18 components. It also runs well on my laptop, slightly better than Mental Breakdown.
Rainbow Circus 2 has about 7x the part count, and spends about 10x the amount of time spent in the CPU compared to HUGE Spinny.
In order to make cool-looking robots we need to figure out a more efficient way to create visual complexity than simply adding components. The simplest way to do this is to get the RR2 Component Modding Tool (CMT???) up and running. This will allow you to create something really cool-looking in Blender, then pull it into Unity and have Unity create a single mesh collider for it. With such a tool in place we could reduce the number of colliders in Rainbow Circus 2's shell from 109 down to 1. I expect that this would reduce physics frame time by 90%.
(http://www.robot-rumble.com/gifs/3robotrelativeperformance.png)
Problem with the tool is that personally i wouldn't allow custom components for my tournament. Unless there is a way to block it. Someone could enter a bit with low weight and extremely high hp count
I'll want to add that while the tool is not a bad idea, I'm not much of a fan of having to use that and Blender or whatever if I want cool looks and have a still durable component. I'm more for just doing everything in game and see where it ends.
With that I am more fond of the idea of grouping bits together in game where it'll look good and still be durable enough.
Maybe also add a group function for currently built bots that use ingame components, because cmt is gonna mean that bots should be rebuiltCMT????? What is that?
Lightning, I will trade you Rainbow Circus for the robot with the gyro dancing! :smile:If you look at my showcase, Takedown does the weird gyro thing. I include a download link on my showcase for the bots I post.
I'll want to add that while the tool is not a bad idea, I'm not much of a fan of having to use that and Blender or whatever if I want cool looks and have a still durable component. I'm more for just doing everything in game and see where it ends.
With that I am more fond of the idea of grouping bits together in game where it'll look good and still be durable enough.
Idk, setting a material not ingame is kinda eh. There can always be a chance that the modded part is better than the ingame part. Again, this modding tool is great for motors and parts like that
Problem with the tool is that personally i wouldn't allow custom components for my tournament. Unless there is a way to block it. Someone could enter a bit with low weight and extremely high hp count
I was thinking that you would set a material and the tool would automatically compute the weight and hp upon creation.
Eventually there will be more than enough people that would rather not go through multiple programs in order to finish up a bot that looks nice, I'd think.I'll want to add that while the tool is not a bad idea, I'm not much of a fan of having to use that and Blender or whatever if I want cool looks and have a still durable component. I'm more for just doing everything in game and see where it ends.
With that I am more fond of the idea of grouping bits together in game where it'll look good and still be durable enough.
I agree that Blender is intimidating. I would love to eventually get a lot of the tool features built into the main game, but this should be a good start.
Grouping is a pretty big undertaking. @tashic, any thoughts on getting something like this working? Maybe we could reuse the chassis compound collider code?
I have some ideas on how to do in-game grouping, but it is going to take a lot of work and troubleshooting to get things like collisionshapes, component breakage, hit points, center of mass, etc working correctly.Honestly:
Download Red Ring of Death from my showcase, fight it versus Takedown AI, and tear a wheel off of Takedown. I am using the 11January build. My physics slider settings are 500 ticks a second, and 100 on the other two. The thing is you have to wait a little bit for it to start glitching. I built these bots in an earlier build so maybe that’s why they’re glitching.I'll want to add that while the tool is not a bad idea, I'm not much of a fan of having to use that and Blender or whatever if I want cool looks and have a still durable component. I'm more for just doing everything in game and see where it ends.
With that I am more fond of the idea of grouping bits together in game where it'll look good and still be durable enough.Maybe also add a group function for currently built bots that use ingame components, because cmt is gonna mean that bots should be rebuiltCMT????? What is that?
"Component Modding Tool"?Lightning, I will trade you Rainbow Circus for the robot with the gyro dancing! :smile:If you look at my showcase, Takedown does the weird gyro thing. I include a download link on my showcase for the bots I post.
I just loaded up Takedown and didn't see the gyro dancing in the latest build. Are you using the 11January bleeding edge build?
Here's Rainbow Circus 2. Cyar, this is one of your creations, correct?No it was made by Minthemad
[ This attachment cannot be displayed inline in 'Print Page' view ]
I've downloaded that circus to have a look, set tick to 500. Saw no dropping in performance at all on my PC.
Sure thing.I've downloaded that circus to have a look, set tick to 500. Saw no dropping in performance at all on my PC.
That's a good data point. Would you mind sharing your PC specs?
4 x Rainbow Circus, all CPU controlled is my worst-case scenario for testing. AI Miniscript currently takes up about 8 ms per robot for me, so 4 robots automatically drops my frame rate below 30 fps no matter what my physics settings are.
After we get physics and damage sorted out, reworking the AI system is next on my list. My first priority is to rewrite everything so it doesn't take up so darn much CPU time.
New build coming today. I finally isolated and fixed the source of the problem with the gyro dancing and unrealistic behaviors when everything is broken off an axle.Ayy the issue that has been haunting us for months has finally been resolved
TL:DR - The mass of the remaining axle will be set to 0.00001 kg in the simulation. This should prevent weirdness.
The full story:
[Bug Fix] Fixed a bug where the remaining mass of the axle alone was set to several kilograms when the last part attached to the axle is broken off. This was causing robots to gyrodance and jitter unrealistically. I also identified the source of the extra mass -- see "POTENTIAL BUG SOURCE" below.
POTENTIAL BUG SOURCE - I just noticed that the "Axle" subassemblies on motors and actuators comes with its own rigidbody. For the Ampflow A40-300 motors, this "Axle" rigidbody has a mass of 4 kg. I tried reducing the axle mass to something more realistic, like 1 kg. This was a TERRIBLE change. It made robots drive poorly, with the wheels bouncing and not gripping. Apparently we had set this default axle mass value years ago in the very early stages of the game and completely forgotten about it.
From now on, every time we create a motor with an axle, we need to make sure that the axle has sufficient mass, maybe 4 kg for a 110 kg robot? When everything breaks off except for the axle the mass of the axle will be set to 0.00001 kg.
I have some ideas on how to do in-game grouping, but it is going to take a lot of work and troubleshooting to get things like collisionshapes, component breakage, hit points, center of mass, etc working correctly.Honestly:
collision shapes - Atm maybe not really necessary untill much later builds
omponent breakage - If you would group parts, i guess you would have combined HP and once it reaches 0, the whole struture falls off
hit points - Huh, thats the one thing that my knowledge is non existant.
center of mass - i guess if you did that before grouping, that wouldnt be an issue
Ayy the issue that has been haunting us for months has finally been resolved
The problem with the gyrodancing didn't go away. I'm thinking that if the motors stopped after a wheel is torn off, then the glitch will be fixed.
EDIT: The problem is fixed, apparently I mistook the gyro created by the wheels for the glitch.
I do notice my fans are spinning up a lot and then keeping that constant. Even in workshop or something.Well from my experience, the fps is uncapped, and at uncapped fps, gpu runs at 100%
I tried the circus bot again, but this time multiple in the arena at once.
So, 4 was the engine wanting to commit suicide. 3 went well until collision; then the frames drop. 2 was fine. Frame drops only happens when components went clipping into each other.
This is run on the bleeding edge released today.
Unrelated but something that has also been a thing. AI on own robots being reset to the default of the game after installing a new version of the game (drag & drop over the previous version). This is a bit annoying since some of my bots just no long use their hammer or flipper until I give them their AI again.
How about if a motor has nothing on it, it auto turns off,The problem with the gyrodancing didn't go away. I'm thinking that if the motors stopped after a wheel is torn off, then the glitch will be fixed.
EDIT: The problem is fixed, apparently I mistook the gyro created by the wheels for the glitch.
Awesome! There is still pretty significant gyro caused by the remaining wheel due to the extra 4 kg mass added by the remaining wheel's axle.
I'm thinking maybe we need another slider to play around with the ratio of wheel mass / chassis mass. Currently, with the extra 4 kg added to the axle, wheel mass is between 4-5% of chassis mass.
My hypothesis is that as you raise the percentage of wheel mass to chassis mass:
Pros: Joint stiffness would increase, reducing the annoying bounciness of wheels.
Cons: Wheel gyroscopic effects would also increase, throwing the robot out of balance and potentially causing it to gyro dance on its side once the wheel gets going fast enough.
Only one way to find out. Its slider time!!! :)
How about if a motor has nothing on it, it auto turns off,I've been trying to say this for weeks!
But then you don’t get the cool spinning axle with nothing on it! :smile:Tbh i dont think that people will notice cool spinning axle in a match
You might be right. Lets see how this feels. If we don’t like it we can always change it.
I think the cool spinning axle is causing the glitching.
EDIT: Can we get an sparks slider? Atm I kinda miss the sparks on low impact.
Yay! My sawbot doesn’t spark like it should, so I am all for SPARK SLIDER!!!!!!!!EDIT: Can we get an sparks slider? Atm I kinda miss the sparks on low impact.
Yeah baby! :)
Sparks are so satisfying! I know they aren't always realistic, but stupid and over the top are what we live for in robot combat!
The spark slider didn't make it into today's Alpha build (coming soon!), but please remind me when I get back from my game dev hiatus next week!Dang it... I really wanted to make an arc welder XD.
And about breakable armor plates, can’t you just treat the plates as components?
>Looks at top secret.Just a quick update from me on the first pass of the new Arena handling system.
The very basic framework for all the systems are in place now so soon enough you should
be seeing all new arenas using the new system!
As I said before I am expecting the first internal release to be ready for February and have
started on the documentation to help even Unity Novices get the most out of the tool, so
hopefully the first public release won't be too far away (no promises though).
Alongside all this I've updated the UI for the arena selection in order to add in the ability to
scroll through the list in preparation for the no doubt countless stages you guys will come up with!
(https://i.imgur.com/lpk5YLm.png)
With Kupa's addition of the extended Arena Selector screen, there may be some new Arena's popping up soon....Trust me, you guys are in for a treat! As a little extra to this: Custom Arenas now support preview images so now they can stand out with even more customisation!
Watch this space ;)
Where can I download the arena builder and CMT?The CMT is going to be tackled after the ArenaModTool. Neither are available yet, but once the documentation is in a place where it is user friendly, and the framework for the AMT is done I think the plan is to create a GitHub project for it as that will allow for easy maintenance and updating as well as allowing you guys to potentially collaborate with the creation of new features and such.
Bass intensifies as Ali-A intro rolls. heck>Looks at top secret.Just a quick update from me on the first pass of the new Arena handling system.
The very basic framework for all the systems are in place now so soon enough you should
be seeing all new arenas using the new system!
As I said before I am expecting the first internal release to be ready for February and have
started on the documentation to help even Unity Novices get the most out of the tool, so
hopefully the first public release won't be too far away (no promises though).
Alongside all this I've updated the UI for the arena selection in order to add in the ability to
scroll through the list in preparation for the no doubt countless stages you guys will come up with!
(https://i.imgur.com/lpk5YLm.png)
>Laughs in non-malicious intention
Ok so we stumbled upon this. Something is wrong with collisions, also the fact that physics is unoptimised, casuing the whole match to run at low fps at 500tick (my cpu usage was at maybe 30%)
https://youtu.be/VGp2I0YeSaw
I've just done some testing with a crusher, and I can confirm that gearing anything down further than a total of about 100/1 results in the entire robot being incapable of rotating faster in battle (not in the test area) than the speed of the geared object itself.
Ok so we stumbled upon this. Something is wrong with collisions, also the fact that physics is unoptimised, casuing the whole match to run at low fps at 500tick (my cpu usage was at maybe 30%)
I've just done some testing with a crusher, and I can confirm that gearing anything down further than a total of about 100/1 results in the entire robot being incapable of rotating faster in battle (not in the test area) than the speed of the geared object itself.
Would you mind sending an .RR2Bot file, or is it possible to replicate this with Panic Attack?
Edit: Panic Attack is really difficult to edit because the robot is so dense. Could you send an .RR2Bot file that shows the problem?
Ok so we stumbled upon this. Something is wrong with collisions, also the fact that physics is unoptimised, casuing the whole match to run at low fps at 500tick (my cpu usage was at maybe 30%)
I love it! This is so great!
I'm probably suffering from "Developer Eyes Syndrome" and can't see everything that you guys see, but I see 2 things here that need fixing:
1. The spinners should have come to a stop. Either or that or they should have broken off. For whatever reason that didn't happen and the now-invisible blur cylinders were still spinning and working their magic.
2. The lag is due to the fact that there is a literal pile of colliders on top of each other, all interacting. The only way to minimize this is to reduce the number of interacting colliders.
Have you guys found a reliable way to reproduce #1? It looks like P2 and P3's spinners didn't come to a stop, even though they were out of the arena. Is this correct? Were the weapons still turned on for P2 and P3?
Ok so we stumbled upon this. Something is wrong with collisions, also the fact that physics is unoptimised, casuing the whole match to run at low fps at 500tick (my cpu usage was at maybe 30%)
I love it! This is so great!
I'm probably suffering from "Developer Eyes Syndrome" and can't see everything that you guys see, but I see 2 things here that need fixing:
1. The spinners should have come to a stop. Either or that or they should have broken off. For whatever reason that didn't happen and the now-invisible blur cylinders were still spinning and working their magic.
2. The lag is due to the fact that there is a literal pile of colliders on top of each other, all interacting. The only way to minimize this is to reduce the number of interacting colliders.
Have you guys found a reliable way to reproduce #1? It looks like P2 and P3's spinners didn't come to a stop, even though they were out of the arena. Is this correct? Were the weapons still turned on for P2 and P3?
I think I have found and fixed the "Pit Blender" problem. It turns out that when a robot is disabled, it would lose player input and maintain the existing state of the control signals. Super scary when this happens in a real-life competition -- you have to wait until the batteries die on the robot.
In any case, this will be fixed in the next release.
The buggy spinners started midway through the fight, when nobody was even in the pit. I could still drive the robot fine. We got this to happen a second time, but nothing after that. We don’t have a consistent method of triggering the glitch. P2 was the main source of the problem. At some point the bar started teleporting off of the axle and was able to clip through the floor and other robots. The same thing happened to P1 later, but not quite to the same extent.
The buggy spinners started midway through the fight, when nobody was even in the pit. I could still drive the robot fine. We got this to happen a second time, but nothing after that. We don’t have a consistent method of triggering the glitch. P2 was the main source of the problem. At some point the bar started teleporting off of the axle and was able to clip through the floor and other robots. The same thing happened to P1 later, but not quite to the same extent.
Would you mind sending the .RR2Bot files for P2 and P3? I want to see if there is something weird going on...
The buggy spinners started midway through the fight, when nobody was even in the pit. I could still drive the robot fine. We got this to happen a second time, but nothing after that. We don’t have a consistent method of triggering the glitch. P2 was the main source of the problem. At some point the bar started teleporting off of the axle and was able to clip through the floor and other robots. The same thing happened to P1 later, but not quite to the same extent.
Would you mind sending the .RR2Bot files for P2 and P3? I want to see if there is something weird going on...
The buggy spinners started midway through the fight, when nobody was even in the pit. I could still drive the robot fine. We got this to happen a second time, but nothing after that. We don’t have a consistent method of triggering the glitch. P2 was the main source of the problem. At some point the bar started teleporting off of the axle and was able to clip through the floor and other robots. The same thing happened to P1 later, but not quite to the same extent.
Here's the bot file for Infrared. I'm not sure what physics stats we were using though, as this was on Kix's computer.
This is where grouping would work
The buggy spinners started midway through the fight, when nobody was even in the pit. I could still drive the robot fine. We got this to happen a second time, but nothing after that. We don’t have a consistent method of triggering the glitch. P2 was the main source of the problem. At some point the bar started teleporting off of the axle and was able to clip through the floor and other robots. The same thing happened to P1 later, but not quite to the same extent.
Here's the bot file for Infrared. I'm not sure what physics stats we were using though, as this was on Kix's computer.
I think I got it! When the last component is broken off an axle, the mass of the remaining axle is set to 0.000001 kg. I incorrectly determined what the "last component" meant. When the colored bars were broken off of Infrared, the game thought that they were the last component, and had set the mass remaining to 0.000001 kg. What you see in the video is the underlying steel bar that is teleporting all over the place because it has almost no inertia (mass). I fixed it in the system, and should have a new build up today.
For Infrared, I also noticed that the colored bars are attached directly to the axle and not to the underlying steel bar. This means that the colored bars will break off as a separate piece, kind of like a thin strip of plastic. The manual fix is to attach the colored pieces to the underlying steel bar and mark them as "decoration" material. I'm not sure if there is a way to automatically attach the entire strip to the underlying bar and mark them as "decoration".
Can you fix the telemetry?
I haven't looked at this in a long time but something that allows for very precise movement with wasdqz or wasd-shift-space in amounts of ~0.01 a la movepixel was one of the things I remember wanting.You can edit the coordinates of components to like 3 decimal places
I mean the glitch where the telemetry screen doesn't turn off when the telemetry button is pressed.Can you fix the telemetry?
I can try! Can you point me to a few .RR2Bot files with the symptoms? The more, the better!
And while I'm at it, here's the version of it where I was testing a crusher. You'll need to set a second one of the gearboxes to 10/0.1 to get the result where it barely steers in battle. Just like with Panic Attack, the issue doesn't effect it at all in the workshop test area.
[ This attachment cannot be displayed inline in 'Print Page' view ]
I'm well aware of this, it's just that in very precise builds like my Nightmare build it's too difficult to math out where everything should be, and the build time would go down rapidly if there were movepixel-esque controls rather than having to edit the coordinate, see if its close enough, edit it again, etc.I haven't looked at this in a long time but something that allows for very precise movement with wasdqz or wasd-shift-space in amounts of ~0.01 a la movepixel was one of the things I remember wanting.You can edit the coordinates of components to like 3 decimal places
Is there anyway I can see what features are planned for future versions? Anyway, I have some suggestions after building in the botlab for some time. A lot of suggestions and a lot of them are complex, so I don't expect you to agree with all of them or try to implement much of what's here in the near future, I know you guys are busy.
I know you guys are not nearly done with the botlab and that given time you guys will make it great, but talking about the botlab right now as it is, it's still pretty clunky in the sense that it takes a very long time to use the controls and the tools given to you to make the botlab do what you want it to do. First of all, I think keyboard shortcuts would improve the building experience 1000%. Things like pressing x to focus the x coordinate, delete for deleting components, arrow keys/wasd + shift + space for moving things around/rotating, basically all the buttons and fields in the interface should have some keyboard mapping because clicking on everything takes forever. Remapping keys would also be great, i.e. i much prefer RMB to MMB for panning. As it is, it's very easy to make mistakes by putting the wrong numbers into the coordinates or into the wrong coordinates, and it's also way too easy to get yourself into a situation where you move something too far away and can only fix it through editing the bot file. An undue button would be a great help for this, and additionally some way to control the max distance from origin of all the components and toggle the room that you are in would all be huge helps. It's also really easy to get objects stuck inside of others, and there's currently a glitch where some small objects won't be able to be selected unless you exit and join the workshop. A lot of these issues could also be helped by having an expandable tree view of all the components like in the bot file and being able to select components like that. Being able to turn off blur from being too close would also be great. When using the moving sliders, they go in increments of .025, and if the component isn't currently at a multiple of .025 then it snaps to a multiple: there should be some way to turn the snapping to a multiple off, because a lot of the more complex builds will not use those multiples very often. This also applies to the rotation and size sliders. There should be a way to control what interval the moving axes move by, either through a field or through several hotkeys which are each set to common values, i.e. .01 and .005 with .025 as the default. It would be great if there was some way to change the directions of the coordinate system so that it doesn't have to be determined by what the object is sitting on, a lot of the times I just want the normal xyz directions. It would be fantastic if there was a way to copy the x, y, or z coordinate of one object and then set the coordinate to another in a streamlined fashion, e.g. hold x while clicking on another object. It would also be great if there was some way to clone mirrors of objects and flip each of the components. It would be nice if we could smooth components along a certain rotational axis. For the chassis and custom object builder it would be great if we could change the numerical values of the xy coordinates via text field of each of the vertices like we can for objects in the rest of the builder.
And while I'm at it, here's the version of it where I was testing a crusher. You'll need to set a second one of the gearboxes to 10/0.1 to get the result where it barely steers in battle. Just like with Panic Attack, the issue doesn't effect it at all in the workshop test area.
[ This attachment cannot be displayed inline in 'Print Page' view ]
I have been messing around with Circumvolution C, and I can't seem to get it to exhibit the behavior you were referring to. With the gearbox set to 10:0.1, I see the same steering performance as with the gearbox set to 1:1. Would you mind sending a copy of the robot where you see the effect?
One thing to note is that, in general, CPU usage is 4x higher in combat than it is in the test arena. In the test arena, the computer only has to run a single robot's worth of physics. In combat, the CPU has to run 2 x physics + 2 x AI code. Not only that, but there are WAY more potential colliding colliders in combat. Maybe this is the slowdown you are seeing? Do you see a driving performance improvement if you set the physics tick rate to 100 ticks/second?
I have been messing around with Circumvolution C, and I can't seem to get it to exhibit the behavior you were referring to. With the gearbox set to 10:0.1, I see the same steering performance as with the gearbox set to 1:1. Would you mind sending a copy of the robot where you see the effect?
One thing to note is that, in general, CPU usage is 4x higher in combat than it is in the test arena. In the test arena, the computer only has to run a single robot's worth of physics. In combat, the CPU has to run 2 x physics + 2 x AI code. Not only that, but there are WAY more potential colliding colliders in combat. Maybe this is the slowdown you are seeing? Do you see a driving performance improvement if you set the physics tick rate to 100 ticks/second?
You need more than one of the gearboxes geared down, producing a total gear-down greater than 100/1. Try setting all three gearboxes at 10:1. So it should be 1000:1 total.
Also, while I'm here, I've still never seen the game stop considering something a spinner because it has rubber on it, but I feel like that's supposed to be a thing now.
Something bad happened.
When I was building something for about 2 hours, I accidentally clicked the Option 1(convex) collision generation when editing the chassis.
Is there any way to bring it back to life?
Shoot. That means I need to figure out where the rest of the gearboxes are. :)
EDIT: Here's what I am seeing with the first gearbox at 10:1 and the second at 10:0.1
Uh oh. I hadn't considered that people would use rubber to circumvent weapon spinners entirely. This is bad because it completely sidesteps the weapon damage system. By placing rubber on a spinner, you are telling the game that this isn't a spinner -- it is a wheel. Wheels don't get the (now invisible) Weapon_Blur_Cylinder, and so therefore can't damage anything.
I have an idea for a no-user-input-required fix that just finds the outermost component. If the outermost component is rubber, it treats it as a wheel. If not, then it treats it as a weapon. This can be recomputed every time you knock off a piece, so that a spinning object can first be a wheel, then when its rubber gets ripped off it becomes a weapon.
Something bad happened.
When I was building something for about 2 hours, I accidentally clicked the Option 1(convex) collision generation when editing the chassis.
Is there any way to bring it back to life?
Oh no! Looking into it!
Something bad happened.
When I was building something for about 2 hours, I accidentally clicked the Option 1(convex) collision generation when editing the chassis.
Is there any way to bring it back to life?
Oh no! Looking into it!
Just uploaded the fix!
I was able to replicate the Beetle Crab glitch with a beetleweight robot I made.I actually got the same issue as well, but only when the weapon or wheel comes off. It's easiest to replicate with a bot I'm attaching to this as it's weapon falls off fairly easily in fights. Please find a fix to this!
Question: Is there a way to make it so two motors spin one weapon? For an example, I have a design that has two motors driving the same bar spinner, each with a separate belt drive going from the motor to the spinner.Not a doable thing at all.
I was able to replicate the Beetle Crab glitch with a beetleweight robot I made.I actually got the same issue as well, but only when the weapon or wheel comes off. It's easiest to replicate with a bot I'm attaching to this as it's weapon falls off fairly easily in fights. Please find a fix to this!
I am running the latest version, and the glitch I am referencing is the glitch where Beetle Crab is sluggish and hovers.I was able to replicate the Beetle Crab glitch with a beetleweight robot I made.I actually got the same issue as well, but only when the weapon or wheel comes off. It's easiest to replicate with a bot I'm attaching to this as it's weapon falls off fairly easily in fights. Please find a fix to this!
1. Which glitch are you referring to? Beetle Crab has almost nothing in common construction-wise with botlab robots, so it is unlikely to be a related issue.
2. Are you running the latest version?
I was able to replicate the Beetle Crab glitch with a beetleweight robot I made.I actually got the same issue as well, but only when the weapon or wheel comes off. It's easiest to replicate with a bot I'm attaching to this as it's weapon falls off fairly easily in fights. Please find a fix to this!
Question: Is there a way to make it so two motors spin one weapon? For an example, I have a design that has two motors driving the same bar spinner, each with a separate belt drive going from the motor to the spinner.Not a doable thing at all.
Couldn't you put a button in the workshop that allows you to connect one part to another?Question: Is there a way to make it so two motors spin one weapon? For an example, I have a design that has two motors driving the same bar spinner, each with a separate belt drive going from the motor to the spinner.Not a doable thing at all.
We can keep it on the list of requests, but it would require getting rid of the current tree structure for robot construction. The tree structure is a core feature of the game.
Couldn't you put a button in the workshop that allows you to connect one part to another?Question: Is there a way to make it so two motors spin one weapon? For an example, I have a design that has two motors driving the same bar spinner, each with a separate belt drive going from the motor to the spinner.Not a doable thing at all.
We can keep it on the list of requests, but it would require getting rid of the current tree structure for robot construction. The tree structure is a core feature of the game.
I was able to replicate the Beetle Crab glitch with a beetleweight robot I made.
What if the button didn’t actually assign a part more than one parent component, but instead linked two parts together? Would that work?Couldn't you put a button in the workshop that allows you to connect one part to another?Question: Is there a way to make it so two motors spin one weapon? For an example, I have a design that has two motors driving the same bar spinner, each with a separate belt drive going from the motor to the spinner.Not a doable thing at all.
We can keep it on the list of requests, but it would require getting rid of the current tree structure for robot construction. The tree structure is a core feature of the game.
Yes, we could add a button, but there is a lot more work to be done than that.
When the robot is reconstructed from the .RR2Bot file, all of the scripts assume that the robot is built with a tree structure. In a logical tree, branches split and never come back together. Everything that we have coded, reconstruction, component links, component breakage, and the damage system, all assume that each component has only one parent. If we were to change this underlying assumption it would break pretty much everything in the game. It isn't an impossible task to change this assumption, but it would take a significant chunk of time to fix and troubleshoot all of the bugs.
Bottom line: It is a significant (months? a year?) amount of work just to allow a spinner to be powered by two motors. We have other things that are higher on the priority list.
Here is the botfile for the glitchy beetleweight:I was able to replicate the Beetle Crab glitch with a beetleweight robot I made.
Can you send me the robot with the glitch? I have a potential fix for the robot that CodeSilver sent, but I want to make sure it works with yours as well.
I also need to check a few more robots to make sure the fix doesn't create some undesirable consequences.
What if the button didn’t actually assign a part more than one parent component, but instead linked two parts together? Would that work?
Question: Is there a way to make it so two motors spin one weapon? For an example, I have a design that has two motors driving the same bar spinner, each with a separate belt drive going from the motor to the spinner.
Now that hotkeys are a thing, how about giving me ideas on what features you want to have available on keyboard and with what key to activate it.Hotkeys that i really want that would help with building:
They can be stuff that already has a button assigned to it but would benefit from a keyboard shortcut for experienced players, but also stuff that is only usable through keyboard as they would be impractical in the UI or needs to work together with the mouse.
The hotkeys for functions that are on different sections of the botlab can have the same key, for example snap to grid in the shape creator can have the same key as the snap function when adding components to the robot.Question: Is there a way to make it so two motors spin one weapon? For an example, I have a design that has two motors driving the same bar spinner, each with a separate belt drive going from the motor to the spinner.
As cjbruce said, the robot is saved as a tree structure and that makes this specific feature pretty tricky to implement as I have to rework quite a bit the system to allow for this.
I have had this feature in mind however, and I would be interested in implementing this, but I still haven't found a satisfactory way of doing that.
Now that hotkeys are a thing, how about giving me ideas on what features you want to have available on keyboard and with what key to activate it.
They can be stuff that already has a button assigned to it but would benefit from a keyboard shortcut for experienced players, but also stuff that is only usable through keyboard as they would be impractical in the UI or needs to work together with the mouse.
The hotkeys for functions that are on different sections of the botlab can have the same key, for example snap to grid in the shape creator can have the same key as the snap function when adding components to the robot.Question: Is there a way to make it so two motors spin one weapon? For an example, I have a design that has two motors driving the same bar spinner, each with a separate belt drive going from the motor to the spinner.
As cjbruce said, the robot is saved as a tree structure and that makes this specific feature pretty tricky to implement as I have to rework quite a bit the system to allow for this.
I have had this feature in mind however, and I would be interested in implementing this, but I still haven't found a satisfactory way of doing that.
Also, Chris, did you see the video I posted a bit back of what the Panic Attack steering issue looks like?
I have a possible idea for how to do multiple motors running a weapon.
What if there were a way of making the *weapon* the start of the branch, maybe with a special axle or something, and having it be spun by two motors that extend from that branch?
If it worked, it might also be a solution to making hubmotors actually work as they should.
The only way I can see it work is if it's 1 motor that looks like 2? Idk, maybe click one motor, then click an option, then click the other motor, and tadaa! now it looks like 2 motors powering 1 thing, but the game sees it a 1 motor.I have a possible idea for how to do multiple motors running a weapon.
What if there were a way of making the *weapon* the start of the branch, maybe with a special axle or something, and having it be spun by two motors that extend from that branch?
If it worked, it might also be a solution to making hubmotors actually work as they should.
But what happens when one motor breaks? Is each motor powered separately? Does the spinner keep spinning? Lots of stuff would need to be figured out. It would be its own special system with special rules. Kind of like pneumatics. The motors would need to be aligned. Weird to think about how it would work...
I feel like the simplest solution would just be to make a "dual" variant of each motor, like the 2-mag, 4-mag etc. from DSL. That way, it's still technically one motor, so it doesn't require any changes to the existing game mechanics, but it has the same stats as two motors joined together.
The spark slider didn't make it into today's Alpha build (coming soon!), but please remind me when I get back from my game dev hiatus next week!Reminder: CREATE SPARK SLIDER
I noticed something (or lack thereof) where I had a bot that lost half of its weapon. It didn't spaz around like it should have. Here's a video:
[ This attachment cannot be displayed inline in 'Print Page' view ]
Also, Chris, did you see the video I posted a bit back of what the Panic Attack steering issue looks like?
I didn’t see it. Would you mind resending the link?
Also, Chris, did you see the video I posted a bit back of what the Panic Attack steering issue looks like?
The eggbeater (player 1) lost half of its weapon but didn’t spaz around like it should have. Condo the fact that half of the eggbeater weighs 11 kg, it should have jumped around like crazy.I noticed something (or lack thereof) where I had a bot that lost half of its weapon. It didn't spaz around like it should have. Here's a video:
[ This attachment cannot be displayed inline in 'Print Page' view ]
Which one lost half of its weapon?
I took out the center of mass recalculation code because I’m still working on spinner and wheel physics and I need to eliminate some variables.
My big issue right now is that we are doing a hack to improve drivability. The hack is not scaling to smaller robots. This manifests as the problem you see in Beetle Crab where the robot will spontaneously float up on its side. Beetleweights are in a bad place right now if they have an active weapon. I need to nail this down to make driving consistent across weight classes.
Did you not read this line?The eggbeater (player 1) lost half of its weapon but didn’t spaz around like it should have. Condo the fact that half of the eggbeater weighs 11 kg, it should have jumped around like crazy.I noticed something (or lack thereof) where I had a bot that lost half of its weapon. It didn't spaz around like it should have. Here's a video:
[ This attachment cannot be displayed inline in 'Print Page' view ]
Which one lost half of its weapon?
I took out the center of mass recalculation code because I’m still working on spinner and wheel physics and I need to eliminate some variables.
My big issue right now is that we are doing a hack to improve drivability. The hack is not scaling to smaller robots. This manifests as the problem you see in Beetle Crab where the robot will spontaneously float up on its side. Beetleweights are in a bad place right now if they have an active weapon. I need to nail this down to make driving consistent across weight classes.
Also, Chris, did you see the video I posted a bit back of what the Panic Attack steering issue looks like?
It looks like you are using the 08January build for this video. Do you still have the problem in the 12January builds and later? For the 12January build I changed the arena floor from "Metal" to "Steel" so that it matches the Robot Workshop floor. With this change I was able to make Panic Attack and Roller drive the same on both surfaces.
CyarSkirata, can you confirm this on your end?
It might be because Panic Attack is so long, and that the wheel friction is too much for it to be able to turn. Maybe you can add wheels to the game that have less friction?
Why is it geared up so much? Does it not function properly at a lower gearing?CyarSkirata, can you confirm this on your end?
I'll check it in the morning.It might be because Panic Attack is so long, and that the wheel friction is too much for it to be able to turn. Maybe you can add wheels to the game that have less friction?
The wheel-base isn't actually all that far off square, and the handling problems are directly related to the srimech. They only happen in general use if I have the srimech geared down by a total of *more than* 100/1, and under those conditions the effect is reduced by having the srimech sticking up vertically, rather than pointing horizontally forwards.
Why is it geared up so much? Does it not function properly at a lower gearing?
I'm getting into the nitty gritty of physics now. I'm looking at wheel mass, axle mass, and center of mass locations.
So far I have found that Panic Attack's driving is dependent on the value of the "Wheel Mass Ratio" slider. At 1%, Panic Attack drives great, but other robots' wheels wig out. At 10% Panic Attack drives poorly, but other robots drive well. At 50% Panic Attack is completely immobile.
CyarSkirata, can you confirm this on your end?
I found a problem with the location of the center of mass of wheels. For some reason wheels have center of masses that are off-center. This is causing all sorts of wobble once the wheel rotates, and is even causing some robots to spontaneously flip over on their sides or back.Could this fix the jittering on low tick and oscillation on high tick?
Robots that use the largest wheels are the least affected. Beetleweights are completely unplayable.
We are working on a fix now.
I believe so. We won’t know until we have a fix in place.How long until this fix is released? I can't wait to see if this fixes the gyrodancing glitch.
Working on it. I’m trying a million little things to solve the problem at its source without luck.How do I edit the file in Unity? Can I just import the .exe or do you have to send me the project file?
In the end I might have to go back and manually fix the center of mass of wheels after the entire assembly is created. I know this will work for wheels but would not fix any similar problems that might arise for weapons.
You pretty much need to have the project, and then compile it to a working gameWorking on it. I’m trying a million little things to solve the problem at its source without luck.How do I edit the file in Unity? Can I just import the .exe or do you have to send me the project file?
In the end I might have to go back and manually fix the center of mass of wheels after the entire assembly is created. I know this will work for wheels but would not fix any similar problems that might arise for weapons.
The new 28January2020 Bleeding Edge Test Build is out:
http://www.robot-rumble.com/bleedingedgebuilds/ (http://www.robot-rumble.com/bleedingedgebuilds/)
This build is designed to help solve the problems we are having with driving and other physics weirdness like robots spontaneously deciding to lean over on their side for no apparent reason. The root cause has been an improperly computed location of the center of mass, particularly for wheels that are attached directly to motors. This problem has made beetleweights completely impossible. Beetleweights appear to be driving correctly now.
For this bleeding edge build I have included COMTrackers that visualize the location of the center of mass of each rigidbody. Any time you add a motor and attach something to it, you are adding an additional rigidbody.
Please give it a try and let me know if you are still seeing issues.
[Added] Added COMTracker.cs to track the location of all the centers of mass of every rigidbody on a robot.
[Added] Added COM_Controller.cs. This script should correctly compute the COM of a rigidbody based on the center of mass of each of its Component_Info components. This can be done repeatedly at runtime. I still need to do extensive testing to make sure the script works in all cases. If it does, then it should be possible to apply the script to things that have lost parts due to damage, as well as broken pieces lying around the arena.
[Added] Added COM_Controller to rigidbodies spawns when a component breaks off.
[Added] COM_Controller.recomputeCOM() is now called on the original rigidbody when a component breaks off.
[Added] Added more hotkeys (now hotkeys can be shift/ctrl + key): -close pause menu, hotkey screen and help screen with the same keys for opening those screens. -Toggle workbench with B key. -Toggle music with N key. -Cycle through music tracks with ctrl + N. -Confirm on popups is enter, cancel in popups is backspace or escape. -You can move through the botlab sections using the right and left Arrow.
[Removed] Removed the makeup mass code from SpinnerMassReducer. By using the COMTracker spheres, I noticed that the center of mass was not in the right location, and could completely throw off the balance of a robot.
[Changed] Set the axle mass of various motors to 0.000001 kg: AmpFlow A40-300 37 mm Geared 37 mm Ungeared 22 mm Geared
Ok so a quick test, and i can tell that driving didnt really improve. 420-500 tick is still way to go without jitter
One thing i did notice is that there is no more weird oscillation where the bot feels like its too light and has next to no gravity, which is a good thing
Imma just post these pics here as I saw this on Twitter:
Okay, so my bot RIPtear mk2 looked like this:
Is this good or bad?
EDIT: The image attachment system broke for me :( .
Here ya go:Okay, so my bot RIPtear mk2 looked like this:
Is this good or bad?
EDIT: The image attachment system broke for me :( .
It looks like there is a COM sphere that is slightly to the right of a bar. That's weird. It looks like you have a COM that might be outside of the bounds of the robot.
Can you send me the .RR2Bot file?
A request from cjbruce, this arena is a replica of the real life arena his students fight their robots in! Perfect for the lighter weights.
Ok so this sawbot crashes the game when it hits something at high speed and force.
How soon?Ok so this sawbot crashes the game when it hits something at high speed and force.
Crash fix coming soon. It was a stupid mistake that was easy to spot and fix.
Idk if the fix will fix this, but small parts tend to clip into opponent. Lets say a small spinner tooth hits an opponents, the tooth will most likely get stuck and it will be that way until it breaks off
Well spinners pretty much cause the issuesIdk if the fix will fix this, but small parts tend to clip into opponent. Lets say a small spinner tooth hits an opponents, the tooth will most likely get stuck and it will be that way until it breaks off
Nope. That is something that happens with compound colliders and discrete physics like we are using. I tried switching to continuous physics a few times, but it made wheels bounce all over the place so I switched back.
The blur cylinder completely eliminates the problem if we set it to turn on at a low enough speed. Maybe I can play with this a bit. It will only work for spinner weapons though.
I haven't said anything about it until now since it slipped my mind, but I've been having an interesting situation with Panic Attack these last few builds.
...every version still has that issue from jan 17 of having too much traction to steer properly.
Also: Is it possible to turn off the pink COM spears of doom on detached parts?
It also adds a 12V AmpFlow A28-150 motor. This is a less-powerful lower voltage motor we use for our lightweight class robots.Ok but when are we getting brushless motors?
We’ve got one in the art pipeline. I haven’t decided how to handle the performance characteristics. Maybe it is only usable with a belt drive? Maybe it has very little low speed torque? Has anyone built a real robot with brushless motors? A heavyweight?There are many HW bots with Brushless motors, Pulsar/Magnetar is one (iirc it used brushless motors for drive). Atm the issue is that many compact bots have to rely on weaker motors for their spinners, where bigger bots just can use the montenegry(etek) motors.
For overheating, couldn't you add a variable that is incremented whenever the motor is on but not spinning?We’ve got one in the art pipeline. I haven’t decided how to handle the performance characteristics. Maybe it is only usable with a belt drive? Maybe it has very little low speed torque? Has anyone built a real robot with brushless motors? A heavyweight?There are many HW bots with Brushless motors, Pulsar/Magnetar is one (iirc it used brushless motors for drive). Atm the issue is that many compact bots have to rely on weaker motors for their spinners, where bigger bots just can use the montenegry(etek) motors.
For the compensation for the motor itself to not be overused. Well IRL as you possibly know, Brushless motors are more fragile and are tend to overheat easily. Because the game atm has no overheating. Maybe compensate with the motor being heavy (unlike irl where its lighter than brushed), till we get overheating stuff.
I believe that the solution for Panic Attack is to shorten and widen the wheelbase as much as possible, though I haven't tried.
The issue I have with that is twofold. Partly that there isn't really room to do that without clipping until multiple wheels can be belted to one motor, partly that the real thing - albeit with six wheels - had a wheelbase just as long as this one and handled fine.
I think, I found an issue with the new build. Some asymmetrical spinners, that were balanced before are now unbalanced
I believe that the solution for Panic Attack is to shorten and widen the wheelbase as much as possible, though I haven't tried.
The issue I have with that is twofold. Partly that there isn't really room to do that without clipping until multiple wheels can be belted to one motor, partly that the real thing - albeit with six wheels - had a wheelbase just as long as this one and handled fine.
I believe that the solution for Panic Attack is to shorten and widen the wheelbase as much as possible, though I haven't tried.
The issue I have with that is twofold. Partly that there isn't really room to do that without clipping until multiple wheels can be belted to one motor, partly that the real thing - albeit with six wheels - had a wheelbase just as long as this one and handled fine.
Maybe we can play around with friction coefficient to see if we can better match reality?
I sense another slider in our future! :)
Likewise, does anyone have any real-life experience with 4-wheeled robots? It would be nice to get some turning and driving feel feedback.
All of our robots use 2 wheel drive.
Panic Attack turns fairly quickly with the keyboard if you don't try to drive forward or backward at the same time as you turn.
The issue I have with that is twofold. Partly that there isn't really room to do that without clipping until multiple wheels can be belted to one motor, partly that the real thing - albeit with six wheels - had a wheelbase just as long as this one and handled fine.
Have you tried building the robot with 6 wheels? Having two wheels in the middle of the robot will most likely give Panic Attack more control when turning as it has more of a 'pivot point'.
If you're concerned about weight, you could always have the front pair of wheels motor'ed and the back ones mounted to a free axle?
Also: Is it possible to turn off the pink COM spears of doom on detached parts?
Done! Check out the Alpha build I just posted.
Panic Attack turns fairly quickly with the keyboard if you don't try to drive forward or backward at the same time as you turn.
Okay... Now I'm confused.
I have the exact opposite problem. I can only get it to turn at a decent rate by getting up some speed and drifting it.
Panic Attack turns fairly quickly with the keyboard if you don't try to drive forward or backward at the same time as you turn.
Okay... Now I'm confused.
I have the exact opposite problem. I can only get it to turn at a decent rate by getting up some speed and drifting it.
What is your setting for Wheel Mass Ratio? I've been using 10%.
Panic Attack turns fairly quickly with the keyboard if you don't try to drive forward or backward at the same time as you turn.
Okay... Now I'm confused.
I have the exact opposite problem. I can only get it to turn at a decent rate by getting up some speed and drifting it.
What is your setting for Wheel Mass Ratio? I've been using 10%.
Mine's at 10 too
COMING SOON TO THE GAME:I love you man
Updated model for AmpFlow A28-150 + individual gearbox
[ This attachment cannot be displayed inline in 'Print Page' view ]
AND - I have managed to bag the game permission to use NPC. For the time being they have let us use the T-64 motor.
[ This attachment cannot be displayed inline in 'Print Page' view ]
I love you man
Oh yessssI love you man
You'll love me even more when you know I've got a brushless motor in the works lol
Is the robot taking significantly longer than this to complete a turn for you?
COMING SOON TO THE GAME:
Updated model for AmpFlow A28-150 + individual gearbox
AND - I have managed to bag the game permission to use NPC. For the time being they have let us use the T-64 motor.
Yeah, my thwackbot couldnt do that since jan 9 update. It seems like its slow motion. The arm swings so slowlyIs the robot taking significantly longer than this to complete a turn for you?
Yup, longer than that.
In other news, I just built a thwackbot that works perfectly in the test area, but I can't make it thwack in the arena. :(
I have managed to bag the game permission to use NPC. For the time being they have let us use the T-64 motor.
I have managed to bag the game permission to use NPC. For the time being they have let us use the T-64 motor.
But can you accurately simulate the annoyance of the holes not being mirrored on either side :mrgreen:
No, no, no, pls noI have managed to bag the game permission to use NPC. For the time being they have let us use the T-64 motor.
But can you accurately simulate the annoyance of the holes not being mirrored on either side :mrgreen:
Ooo! What a fun challenge!
@tashic? :)
COMING SOON TO THE GAME:I'm really looking forward to those!
Updated model for AmpFlow A28-150 + individual gearbox
[ This attachment cannot be displayed inline in 'Print Page' view ]
AND - I have managed to bag the game permission to use NPC. For the time being they have let us use the T-64 motor.
[ This attachment cannot be displayed inline in 'Print Page' view ]
Is there a place folks are uploading their RR2 creations for others to download?
Is there a place folks are uploading their RR2 creations for others to download?I upload my bots in my showcase.
Thank you for sharing! I was disappointed to see that GTM doesn't have a repository for any RR2 bots.You’re welcome. If you want to, you can modify them and post them on my showcase so I can get ideas.
All thwackbots will need to be rebalanced after the build that I’m working on now.When is this build coming out?
I finally got the the center of mass calculation working correctly based on components. This means it should be really easy to adjust a thwackbot by putting a shape out near the edge and adjusting its thickness or material.
Soon! I was hoping to put the new arenas in the build, but they aren’t quite ready.YES, PLEASE!!!!!!!!!!
I can do a build with just the physics if you would like.
I mean the glitch where the telemetry screen doesn't turn off when the telemetry button is pressed.Can you fix the telemetry?I can try! Can you point me to a few .RR2Bot files with the symptoms? The more, the better!
Just fixed the telemetry button in the robot workshop. It now toggles correctly.Thank you!
I should have a new Alpha build up within the next few hours.
The 03February2020 Build is up!The build is amazing. I have nothing much negative to say about it.
https://robot-rumble.itch.io/builds (https://robot-rumble.itch.io/builds)
[Updates in the February 3rd Build]
[Bug Fix] Fixed manual Center of Mass (COM) calculation bug. COM is now computed correctly based on the location and mass of components, rather than the location of colliders. If COM was important to a robot (i.e. an overhead thwackbot), the robot will need to be rebalanced. This can be done by changing shape materials, changing thickness of the shape, shifting the location of components, or by adding or removing components.
[Added] New shape prefabs. The new geo cylinders and hollow cylinders make for some beautiful discs! The hollow box is great for chassis components.
[Added] New Aluminium Treadplate amour
[Added] More hotkeys added on these parts of the botlab:
-Intro screen (enter to start);
-chassis screen;
-shape creator;
-overview screen.
[Changed] Refined the list of the hotkey screen:
-Made the window bigger to fit more hotkeys when necessary;
-Merge certain combination of keys (when an action has both left and right shift buttons, it just shows "shift", same thing done for ctrl and notmal/keypad digits);
-Depending on the section of the botlab the player is in, it shows the appropriate hotkeys;
[Changed] Now the hotkeys can trigger the popups that appeared when a non interactable element was clicked.
[Removed] Removed sliders for Wheel Mass Ratio, Spinner Mass Ratio, Spinner Impulse, and Spinner Pushout. User feedback has converged on values for these variables, and the sliders appear to no longer be necessary. The gamewide values for these are now hard coded as follows: Wheel Mass Ratio = 0.1 Minimum Spinner Mass Ratio = 0.1 Spinner Impulse = 1.0 Spinner Pushout = 1.0
[Changed] Changed materials of the motors.
[Bug Fix] Fixed Telemetry Toggle button in Robot Workshop test cage. It now toggles the telemetry display on and off.
I haven't downloaded this build yet but I just wanna ask, is there a way to create true spherical armor in this game? I've always didnt like how RA2's chassis creation had no way to handle actual spheres (or pure triangles)chassis creation is like ra3 (so just like RA2, but with more than 2 layers)
I haven't downloaded this build yet but I just wanna ask, is there a way to create true spherical armor in this game? I've always didnt like how RA2's chassis creation had no way to handle actual spheres (or pure triangles)
So the gyrodancing glitch is back :/. Yay.
Oh and i used to use arrow keys to move tabs is a bad thing, especially for people who use arrows to change the part location numbers
The glitch I’m talking about is the one where you tear off someone’s wheel and they gyro around like they have a drum spinner even if they are weapon less.So the gyrodancing glitch is back :/. Yay.
What do you mean when you use the words “gyro dancing glitch”?
To me gyro dancing is the result of applying a steering input to a rapidly spinning vertical spinner. This is not a glitch. It is something that i happens in real life.
Is it possible to post a video that clearly shows the behavior you are concerned about? If it is truly gyro dancing, then it doesn’t need to be fixed because it is the correct behavior. If it is something other than gyro dancing, let’s come up with a better name for the concerning effect.
I noticed this glitch in the 03January build: EDIT: The robot that is gyrodancing has no spinning weapons.
The glitch I’m talking about is the one where you tear off someone’s wheel and they gyro around like they have a drum spinner even if they are weapon less.So the gyrodancing glitch is back :/. Yay.
What do you mean when you use the words “gyro dancing glitch”?
To me gyro dancing is the result of applying a steering input to a rapidly spinning vertical spinner. This is not a glitch. It is something that i happens in real life.
Is it possible to post a video that clearly shows the behavior you are concerned about? If it is truly gyro dancing, then it doesn’t need to be fixed because it is the correct behavior. If it is something other than gyro dancing, let’s come up with a better name for the concerning effect.I noticed this glitch in the 03January build: EDIT: The robot that is gyrodancing has no spinning weapons.
I’ll call it the spazzing glitch.The glitch I’m talking about is the one where you tear off someone’s wheel and they gyro around like they have a drum spinner even if they are weapon less.So the gyrodancing glitch is back :/. Yay.
What do you mean when you use the words “gyro dancing glitch”?
To me gyro dancing is the result of applying a steering input to a rapidly spinning vertical spinner. This is not a glitch. It is something that i happens in real life.
Is it possible to post a video that clearly shows the behavior you are concerned about? If it is truly gyro dancing, then it doesn’t need to be fixed because it is the correct behavior. If it is something other than gyro dancing, let’s come up with a better name for the concerning effect.I noticed this glitch in the 03January build: EDIT: The robot that is gyrodancing has no spinning weapons.
Ah. Gotcha. Maybe we can call it the “tilting glitch”? I’ll look at it as soon as I can. I’m pretty sure I know where the mistake is...
Rubber wheels seem to be registered as spinners again.I noticed that too.
Rubber wheels seem to be registered as spinners again.
I’ll call it the spazzing glitch.
Rubber wheels seem to be registered as spinners again.
What are the symptoms you are seeing?
Only issue is that i find NPC to be a bit too weak of a drive motor. Seems like torque might need to go up a bitOk so the NPC motor isnt slow as i thought, the rubber material seems to not have any grip at all
Circumvolution has had an occasional problem for awhile where when a part of the flywheel breaks off, child components of that part will stay attached, hovering and still a capable part of the weapon.
Sometimes, the central axle will come off from the impacts of the teeth on an opponent (already concerning), and only take one of the flywheel sections with it.
Well, any rubber wheels will show up in the telemetry as spinners, which didn't happen in previous builds.
[ This attachment cannot be displayed inline in 'Print Page' view ]
Circumvolution has had an occasional problem for awhile where when a part of the flywheel breaks off, child components of that part will stay attached, hovering and still a capable part of the weapon.
Sometimes, the central axle will come off from the impacts of the teeth on an opponent (already concerning), and only take one of the flywheel sections with it.
This is a result of how the components are attached to each other in the tree structure.
Each component has a parent. If a parent breaks off, all of the children also break off. If a component's parent has not broken off, the component and all of its children remain.
In Circumvolution's case, this means that there are many many bits and pieces attached to other bits and pieces. It is easy to lose track of which piece is parented to which when building.
I am looking to do some automatic collider reduction. This should help reduce the problem, but won't eliminate it entirely. Fewer colliders = things break off in larger chunks. It would still be possible for something to break off in an unrealistic way if components were attached to components in a weird way.
...the rubber material seems to not have any grip at all
I didn't lose track of it though. :/
When I reworked it to add the beefed up axle, I even re-attached *everything* to the axle.
Also, on that note, it's impossible to break off the decorative parts of Panic Attack's srimech.
As in: when the main plate of the srimech breaks off, everything decorative stays attached.
Ive done a multi piece wheel, placed a rim, then a hollow part that is rubber
...the rubber material seems to not have any grip at all
...more evidence to my hunch. I assume you are creating custom wheels...
By any chance did you send a copy of the .RR2Bot file for the affected robot(s)?
Wheels should not get Blur Cylinders or Spinner Mass Reducers. If a wheel has them, the spinning wheel's behavior (driving a robot) will be replaced by spinning weapon behavior (launching things around on impact).
The game's current definition of when to add the spinner mass reducer and blur cylinder is pretty convoluted. A "Blur Cylinder" (a cylindrical weapon collider) and a "Spinner Mass Reducer" (a bit of logic that reduces the mass of a spinner so it doesn't go nuts at high RPM) are added to anything attached to a motor, unless any of the following are true.
- if (comps.Length > 0 && comps[0].comp_type == CompType.Wheel) addWeaponBlurCylinderAndSpinnerMassReducer = false; // Do not add to wheels.
- //if (comps.Length > 0 && comps[0].armorMaterial.name == "Rubber") addWeaponBlurCylinderAndSpinnerMassReducer = false; // Do not add to rubber things.
- if (hinge.useLimits == true) addWeaponBlurCylinderAndSpinnerMassReducer = false; // Do not add to hinges with limits.
- if (hinge.useSpring == true) addWeaponBlurCylinderAndSpinnerMassReducer = false; // Do not add to hinges with limits.
- if ((int)hinge.limits.min != 0) addWeaponBlurCylinderAndSpinnerMassReducer = false; // Do not add to hinges with limits.
- if ((int)hinge.limits.max != 0) addWeaponBlurCylinderAndSpinnerMassReducer = false; // Do not add to hinges with limits.
I think I need to redefine "wheel" as anything that is attached to a motor assigned to "Left Drive" or "Right Drive". I think this will be much more clear than the system I am using above.
Ive done a multi piece wheel, placed a rim, then a hollow part that is rubber
...the rubber material seems to not have any grip at all
...more evidence to my hunch. I assume you are creating custom wheels...
By any chance did you send a copy of the .RR2Bot file for the affected robot(s)?
Wheels should not get Blur Cylinders or Spinner Mass Reducers. If a wheel has them, the spinning wheel's behavior (driving a robot) will be replaced by spinning weapon behavior (launching things around on impact).
I think I need to redefine "wheel" as anything that is attached to a motor assigned to "Left Drive" or "Right Drive". I think this will be much more clear than the system I am using above.
Now I need to take a crack at the issue CyarSkirata brought up: When you attach decorative materials directly to an axle, the materials don't have a collider and therefore can't be broken off. Maybe if you attach decorative materials directly to an axle, they break off immediately as soon as you spawn the robot? Would that be weird?I think that the component tree is not good. IIRC a main part of the wedge on my bot has fallen off, however smaller parts that were attached to it stay on. The materials weren't decorative on then
I didn't lose track of it though. :/
When I reworked it to add the beefed up axle, I even re-attached *everything* to the axle.
Also, on that note, it's impossible to break off the decorative parts of Panic Attack's srimech.
As in: when the main plate of the srimech breaks off, everything decorative stays attached.
Gotcha. The problem is that an axle is not currently defined as its own component. It doesn’t have health, at least not by itself. It can’t be hit or take damage. Rather, it is part of a motor. In order to break things off of the axle, they must have their own collider. Since the collider is removed from anything marked as decorative, the decorative pieces attached directly to the axle won’t come off until the motor itself is destroyed.
Need to think about this...
Any robots in my showcase will work. The only requirement is they have to be direct drive with prebuilt wheels.
I’ll call it the spazzing glitch.
Can you send me an .RR2Bot file? COMs are showing up in the correct spot when I pop a wheel off my robots.
Also I noticed that music for the main menu is COMPLETELY NONEXISTENT!!!! :vista:
Any robots in my showcase will work. The only requirement is they have to be direct drive with prebuilt wheels.
I’ll call it the spazzing glitch.
Can you send me an .RR2Bot file? COMs are showing up in the correct spot when I pop a wheel off my robots.
Its basically the thing when the wheel falls off and the motor spins at full power and it causes the bot to lift on that sideAny robots in my showcase will work. The only requirement is they have to be direct drive with prebuilt wheels.
I’ll call it the spazzing glitch.
Can you send me an .RR2Bot file? COMs are showing up in the correct spot when I pop a wheel off my robots.
Could you point me to one in particular that is frustrating? The faster I can pinpoint the problem, the faster I can get the build out.
Also I noticed that music for the main menu is COMPLETELY NONEXISTENT!!!! :vista:
Its basically the thing when the wheel falls off and the motor spins at full power and it causes the bot to lift on that sideAny robots in my showcase will work. The only requirement is they have to be direct drive with prebuilt wheels.
I’ll call it the spazzing glitch.
Can you send me an .RR2Bot file? COMs are showing up in the correct spot when I pop a wheel off my robots.
Could you point me to one in particular that is frustrating? The faster I can pinpoint the problem, the faster I can get the build out.
I noticed the same happens. When I was testing out some new Bug weight components it was even more noticeable once the wheels came off.A fix would be to turn off the motor once the wheel is off, aka there is nothing on the motor
Oh. When I said axle, that's not what I meant. I meant that I added a beefed up steel cylinder to the spinner, and made every other section of the weapon be child parts to that.
It's entirely possible for that cylinder - the parent part to the entire weapon - to come off from the teeth hitting opponents. On top of that, when that parent part does come off, it very rarely takes its child parts with it.
As for Panic Attack:
The srimech has three aluminium components attached to the main slab. Each of those parts has decorative parts attached to it.
When those break off, the decorative parts attached to them go with them. When the main slab breaks off, the decorative parts attached to it don't go with it. They remain attached to the gearbox.
The skirts also take their decorative parts with them when they break off.
Having talked about the issues with the two bots together, I do now have a theory. Perhaps the fault lies specifically in the components that are attached directly to the axle? Since that's the case both for the main plate of Panic Attack's srimech, and the cylinder in Circumvolution's weapon.
That’s pretty much what I was thinking it was. I recall recommending a fix for this glitch, but I need to find it.Its basically the thing when the wheel falls off and the motor spins at full power and it causes the bot to lift on that sideAny robots in my showcase will work. The only requirement is they have to be direct drive with prebuilt wheels.
I’ll call it the spazzing glitch.
Can you send me an .RR2Bot file? COMs are showing up in the correct spot when I pop a wheel off my robots.
Could you point me to one in particular that is frustrating? The faster I can pinpoint the problem, the faster I can get the build out.
That’s pretty much what I was thinking it was. I recall recommending a fix for this glitch, but I need to find it.Its basically the thing when the wheel falls off and the motor spins at full power and it causes the bot to lift on that sideAny robots in my showcase will work. The only requirement is they have to be direct drive with prebuilt wheels.
I’ll call it the spazzing glitch.
Can you send me an .RR2Bot file? COMs are showing up in the correct spot when I pop a wheel off my robots.
Could you point me to one in particular that is frustrating? The faster I can pinpoint the problem, the faster I can get the build out.
EDIT: kix’s fix was the one I was thinking about.
Does this game's damage system support crushers? My friend who's a big fan of Razer really wants to play a game where crushers are viable
Does this game's damage system support crushers? My friend who's a big fan of Razer really wants to play a game where crushers are viableNah this game uses the rigidbody system like ra2 has. However if a bot has a hole somwhere, there is a chance that you could grab it
Does this game's damage system support crushers? My friend who's a big fan of Razer really wants to play a game where crushers are viableNah this game uses the rigidbody system like ra2 has. However if a bot has a hole somwhere, there is a chance that you could grab it
I have a possible solution but however its more complicated to explain
What did you have in mind? I wasn't thinking along the lines of ripping off small parts, but I think I like where you are going with the idea. It might be computationally expensive though.For the hole i meant, if there was a hole in the design, like something that was built, there is a chance that a crusher could grab that.
That’s pretty much what I was thinking it was. I recall recommending a fix for this glitch, but I need to find it.Its basically the thing when the wheel falls off and the motor spins at full power and it causes the bot to lift on that sideAny robots in my showcase will work. The only requirement is they have to be direct drive with prebuilt wheels.
I’ll call it the spazzing glitch.
Can you send me an .RR2Bot file? COMs are showing up in the correct spot when I pop a wheel off my robots.
Could you point me to one in particular that is frustrating? The faster I can pinpoint the problem, the faster I can get the build out.
EDIT: kix’s fix was the one I was thinking about.
Gotcha! I thought I disabled the motor anytime everything was broken off in a previous build. I'll take a look at it again today.
So weird...
I've been having another go at getting my thwackbot to work, and I feel like part of the problem is a lack of traction with the arena floor.
It uses the stock 12.5 inch wheels, and in the workshop test area it thwacks so hard it bounces the wheels up off the ground, but out in the arena it needs a several metre run-up to turn over at all, and when it does do so it's too sluggish to have any real impact even if it did hit.
kix, does Mental Breakdown show the bug?I dont have mental breakdown, but removing a wheel shows that it doesnt do it in the test cage. Craplectric Jr. did do that but iirc it was on an older build
In which arena are you guys seeing the problem? Does it occur in the Robot Workshop test cage?
Oh, I forgot to mention that the robot has to be driving when the wheel is taken off.
Oh, I forgot to mention that the robot has to be driving when the wheel is taken off.Gotcha. I think I might have a robot with the problem. I tried setting the chassis mass to almost nothing and put a really powerful motor on.I drove forward. The robot went nuts.Do you have another robot I could try with just to make sure?
Would someone mind posting their absolutely worst case robot showing the following problem:
1. A wheel breaks off.
2. The robot tilts unnaturally.
None of the robots I have built seem to have the problem. I have tried to replicate the issue without success, but have a few changes I would like to try.
Just wanna say I really like the most recent version with the hollow shapes.
I figured I could finally make a ring spinner now, so instead I had the brilliant idea of putting the E-Tek big motor inside a drum as hub motor, creating this gyro-mad monster called Chaos Assembly 0.3
I've even attached the botfile for those who wanna try control this thing.
pls tell me that that brushless is made for hw
awww, well its still a thing. Guess ill have to waitpls tell me that that brushless is made for hw
Currently for bug weights. lighter and heavier weight brushless motors to come :)
How do the rims and tires work?
BRUSHLESS BABY
Fact: Magnetar from RW used brushless motors for drive and weaponBRUSHLESS BABY
Still need to figure out the game mechanics for brushless motors!
I’m thinking:
1. They need more gear reduction.
2. They have very poor starting torque. I just got some numbers on this versus AmpFlow, so we should be set on this.
3. They tend to break more easily (lower health).
Fact: Magnetar from RW used brushless motors for drive and weaponBRUSHLESS BABY
Still need to figure out the game mechanics for brushless motors!
I’m thinking:
1. They need more gear reduction.
2. They have very poor starting torque. I just got some numbers on this versus AmpFlow, so we should be set on this.
3. They tend to break more easily (lower health).
Im here fighting for the brushless **** offFact: Magnetar from RW used brushless motors for drive and weaponBRUSHLESS BABY
Still need to figure out the game mechanics for brushless motors!
I’m thinking:
1. They need more gear reduction.
2. They have very poor starting torque. I just got some numbers on this versus AmpFlow, so we should be set on this.
3. They tend to break more easily (lower health).
**** off Kix
Would someone mind posting their absolutely worst case robot showing the following problem:
1. A wheel breaks off.
2. The robot tilts unnaturally.
None of the robots I have built seem to have the problem. I have tried to replicate the issue without success, but have a few changes I would like to try.
Having said all that, I don’t have any personal experience with brushless motors in robot combat. I’m just guessing, and am really hoping to get a data dump from someone who has actually tried them in the larger weight classes.
I'm just wondering about why brushless motors would be deemed to break more easily.
And if they didn't, why would you ever use the other motors the game has to offer. Brushless motors are smaller, lighter, more convenient, and pretty much as powerful as you'll ever need. Without some balancing factor there you might as well remove the other motors from the game because they'll never get used if brushlesses don't have a drawbackI'm just wondering about why brushless motors would be deemed to break more easily.
Because they do... at least, currently. As kix said, Pulsar/Magnetar exclusively used brushless components, and it was one of the most unreliable combat robots I've ever seen. It was an incredible piece of engineering, and very powerful when it worked, but being cutting-edge has its drawbacks.
Would someone mind posting their absolutely worst case robot showing the following problem:
1. A wheel breaks off.
2. The robot tilts unnaturally.
None of the robots I have built seem to have the problem. I have tried to replicate the issue without success, but have a few changes I would like to try.
My clusterbot has developed this bug sometime since the last time I tested it.
The wheels are pretty exposed, so I suggest putting one of them in the arena under AI control and using Circumvolution (reach, side-wedges and good bite for getting at the sides) to pull the wheels off while it tries to fight back, to test the bug under combat conditions, where the target bot is moving pretty much all the time.
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
Fun to drive he says. Lol! Glad to see it being enjoyed.Just wanna say I really like the most recent version with the hollow shapes.
I figured I could finally make a ring spinner now, so instead I had the brilliant idea of putting the E-Tek big motor inside a drum as hub motor, creating this gyro-mad monster called Chaos Assembly 0.3
I've even attached the botfile for those who wanna try control this thing.
Ooo! Fun to drive!
Nicely done!
I'm not seeing anything too weird here. The COMs are in the correct location when the wheels break off and the rigidbody masses are set to 0.00001 kg like they are supposed to be. Is it possible that the behavior that you are seeing is actually the correct result of the angular momentum of the big, fast vertical spinner?
Yeah this issue has been happening for quite a while now. This video might be able to show you more:I'm not seeing anything too weird here. The COMs are in the correct location when the wheels break off and the rigidbody masses are set to 0.00001 kg like they are supposed to be. Is it possible that the behavior that you are seeing is actually the correct result of the angular momentum of the big, fast vertical spinner?
The issue isn't with getting gyro. It's with getting something that resembles gyro, but the robot will - for example - end up with one side completely hovering while it drives back and forth in a straight line, or take a vert hit and be sent spinning through the air but only be capable of spinning on the axis of the axle that's lost its wheel.
I think I learned a little something about brushless motors. I didn't realize that they weighed less compared to brushed motors.
This looks like a center of mass issue. I need to track this down.I’m 100% sure there isn’t anything stuck inside. The so called “gyro” only happens when one of the wheels come off of a drive motor. The bot I used in the video only gyros a little bit when both wheels are intact. This “invisible gyro” issue happens with every single bot I have, both my own and all tournament entries. Maybe if a motor is controlled with the drive function, you could set it up to not include gyro in its physics?
Is it possible that there is a part that is broken off and stuck inside the robot?
How do the rims and tires work?
They're something new I'm working on. So for now just please watch this space :)
I think a fix would be to have motors without anything attached to them immediately stop spinning.
Is it just me, or are the video settings in the 05 February build totally broken? The game defaults to 1024x800 with medium graphics, and reverts back to that no matter what you set it to. It also opens in fullscreen even when fullscreen isn't ticked.
Typical, I can finally play the game in decent quality and it's forcing me to play in potato quality again 😂
Nope that doenst work, i use the kupatec modtool and 1080p fixIs it just me, or are the video settings in the 05 February build totally broken? The game defaults to 1024x800 with medium graphics, and reverts back to that no matter what you set it to. It also opens in fullscreen even when fullscreen isn't ticked.
Typical, I can finally play the game in decent quality and it's forcing me to play in potato quality again 😂
Try setting them in the combat arena. I believe that is the only place where settings will stick.
With this fix the motors slow down gradually, but the robots still havok around for 3-4 seconds.I think a fix would be to have motors without anything attached to them immediately stop spinning.
I agree. This should already be true as of the 05February bulls:
[Bug Fix] Set mass of remaining axles to 0.00001f if all attachments break off a motor.
[Bug Fix] Set Motor_Script.maxrpm to zero if all attachments break off. Previously this was only true for spinners, but now it is true for wheels as well.
With this fix the motors slow down gradually, but the robots still havok around for 3-4 seconds.I think a fix would be to have motors without anything attached to them immediately stop spinning.
I agree. This should already be true as of the 05February bulls:
[Bug Fix] Set mass of remaining axles to 0.00001f if all attachments break off a motor.
[Bug Fix] Set Motor_Script.maxrpm to zero if all attachments break off. Previously this was only true for spinners, but now it is true for wheels as well.
Could you send me the project file as a .rar?With this fix the motors slow down gradually, but the robots still havok around for 3-4 seconds.I think a fix would be to have motors without anything attached to them immediately stop spinning.
I agree. This should already be true as of the 05February bulls:
[Bug Fix] Set mass of remaining axles to 0.00001f if all attachments break off a motor.
[Bug Fix] Set Motor_Script.maxrpm to zero if all attachments break off. Previously this was only true for spinners, but now it is true for wheels as well.
Roger. Power is off, but more needs to be done to get the speed down.
Could you send me the project file as a .rar?With this fix the motors slow down gradually, but the robots still havok around for 3-4 seconds.I think a fix would be to have motors without anything attached to them immediately stop spinning.
I agree. This should already be true as of the 05February bulls:
[Bug Fix] Set mass of remaining axles to 0.00001f if all attachments break off a motor.
[Bug Fix] Set Motor_Script.maxrpm to zero if all attachments break off. Previously this was only true for spinners, but now it is true for wheels as well.
Roger. Power is off, but more needs to be done to get the speed down.
EDIT: I want to look at the code for motors so I can see if there's a value that can be changed to make the motors stop immediately.
How do the rims and tires work?
They're something new I'm working on. So for now just please watch this space :)
Introducing:
[ This attachment cannot be displayed inline in 'Print Page' view ]
THE WHEEL BUILDER
Comprised of 10 hubs and 15 tires, the wheel builder allows you to make any sort of wheel you may want for your robot!
-All rims can have a material and tint set to them.
-All tires are recolourable. Whether you want Sewer Snake's reds or Carbide's yellows - now you can have whatever you want!
-All parts are fully scaleable, with the attachment points balanced to ensure pure '0' every time.
-Once myself or the team have gotten round to stat balancing, every combination of hub and tire will bring it's own pros and cons to allow for true competitive gameplay.
Release of the Wheel Builder is subject to establishing of stats, but they are at least in development! :)
uh...
there seems to be a glitch with the A28-150 gearbox
Quick question: will we be getting more shapes like quarter cylinders/spheres, letters, and square side wedges in the near future?
uh...
there seems to be a glitch with the A28-150 gearbox
Wow. Nice catch! I'm taking a look at it now.
Ok so i did some testing around with the bots that have 600+ colliders, thanks rep makers, appreciate that.How's your CPU/GPU utilisation while playing? No change in FPS from 768p to 4k is a good pointer to it being a huge CPU bottleneck, possibly due to your CPU not being able to keep up with the physics engine? Try lowering the physics engine tickrate, if that's an option in the game. If neither your GPU or CPU are pinned at 100% utilisation, I'd take a wild uneducated guess at there being a weird bottleneck somewhere in the rending pipeline.
One thing im having a feeling about is that the game may be only limiting itself to max 4 cores/ 4 threads. Im not sure on this one, maybe thats why my cpu usage cant reach 100% (6c/12t), again, im not exactly sure on this one.
And uh ok so resolution settings do nothing, nothing at all, no fps gain/decrease.
https://youtu.be/5w_bHSP4LqQ (https://youtu.be/5w_bHSP4LqQ)
Even did windowed mode of the game and scaled down the window down to this
(https://cdn.discordapp.com/attachments/675006573772537874/677179764519206935/unknown.png)
even changed the res to 4k as in the yt vid
Then i tried gfx quality settings.
Mid/ High are the same, low however
https://youtu.be/T2eusgmW968 (https://youtu.be/T2eusgmW968)
It might be shadows or post processing that is making stuff lag.
Also what ive noticed, when the bots are upside down, and if you drive the motors at full speed, on 100 tick, the premade wheels wheels spaz out.
EDIT: Premade wheels do that too:
[ This attachment cannot be displayed inline in 'Print Page' view ]
How's your CPU/GPU utilisation while playing? No change in FPS from 768p to 4k is a good pointer to it being a huge CPU bottleneck, possibly due to your CPU not being able to keep up with the physics engine? Try lowering the physics engine tickrate, if that's an option in the game. If neither your GPU or CPU are pinned at 100% utilisation, I'd take a wild uneducated guess at there being a weird bottleneck somewhere in the rending pipeline.The game has tickreate
kix, by any chance are you using KupaTech’s screen resolution hack? The way I understand it, the hack sets the resolution of the screen one frame after the screen loads. This means you will never see any resolution other than the one hard-coded by the hack.Uh i do, however you can turn it off which is convenient. I turned it off when i did the testing
Sorry for being incommunicado. I’ve been out with the flu for the past few days.Can you post the code for this hack?
CodeSilver, thank you for the video. It is super clear and easy to reproduce. When I get my strength back I will have a look.
kix, by any chance are you using KupaTech’s screen resolution hack? The way I understand it, the hack sets the resolution of the screen one frame after the screen loads. This means you will never see any resolution other than the one hard-coded by the hack.
Also, for those who don't know what I'm talking about, here is a basic visual:
https://youtu.be/DzgswRreqHQ (https://youtu.be/DzgswRreqHQ)
My idea didn't work, so cjbruce please fix this.
Also, for those who don't know what I'm talking about, here is a basic visual:
https://youtu.be/DzgswRreqHQ (https://youtu.be/DzgswRreqHQ)
My idea didn't work, so cjbruce please fix this.
CodeSilver23, you are a genius. With the help of the video I was able to find an eliminate the problem. The errant gyroscopic effect that you have shown should be gone in the next build.
For the physics geeks out there:
Unity has really lousy physics documentation. I had assumed that when you change the mass of an attached rigidbody, the moments of inertia would be recomputed as well. In our case, I was setting the mass of the rigidbody to a very small number (0.000001 kg) when all of the components break off an axle. I had assumed (incorrectly) that this would cause the moments of inertia (which directly affect angular momentum and gyroscopic effects) to be nearly zero as well.
I was wrong. CodeSilver23 was spot on in his video. What he was seeing could only be gyroscopic effects. I turned on a display of moment of inertia and sure enough, the MOI was set to 1 kg * m^2 in all dimensions. This is an insanely huge moment of inertia for a wheel. Apparently, Unity decided that since it could no longer compute an MOI because there was nothing attached, instead of setting the MOI to 0 it set MOI to 1. This is crazy. It also explains the ridiculousness that happens when you break everything off.
In any case, it should be fixed now. I tried to go back and find and fix all of the weird quirks that I introduced when I didn't know the root cause of the problem. Hopefully I got everything, but please let me know if you find more stuff cropping up in the next build.
Ok so i did some testing around with the bots that have 600+ colliders, thanks rep makers, appreciate that.
One thing im having a feeling about is that the game may be only limiting itself to max 4 cores/ 4 threads. Im not sure on this one, maybe thats why my cpu usage cant reach 100% (6c/12t), again, im not exactly sure on this one.
And uh ok so resolution settings do nothing, nothing at all, no fps gain/decrease.
Even did windowed mode of the game and scaled down the window down to this
even changed the res to 4k as in the yt vid
Then i tried gfx quality settings.
Mid/ High are the same, low however
https://youtu.be/T2eusgmW968 (https://youtu.be/T2eusgmW968)
It might be shadows or post processing that is making stuff lag.
Also what ive noticed, when the bots are upside down, and if you drive the motors at full speed, on 100 tick, the premade wheels wheels spaz out.
EDIT: Premade wheels do that too:
Also, for those who don't know what I'm talking about, here is a basic visual:
https://youtu.be/DzgswRreqHQ (https://youtu.be/DzgswRreqHQ)
My idea didn't work, so cjbruce please fix this.
CodeSilver23, you are a genius. With the help of the video I was able to find an eliminate the problem. The errant gyroscopic effect that you have shown should be gone in the next build.
For the physics geeks out there:
Unity has really lousy physics documentation. I had assumed that when you change the mass of an attached rigidbody, the moments of inertia would be recomputed as well. In our case, I was setting the mass of the rigidbody to a very small number (0.000001 kg) when all of the components break off an axle. I had assumed (incorrectly) that this would cause the moments of inertia (which directly affect angular momentum and gyroscopic effects) to be nearly zero as well.
I was wrong. CodeSilver23 was spot on in his video. What he was seeing could only be gyroscopic effects. I turned on a display of moment of inertia and sure enough, the MOI was set to 1 kg * m^2 in all dimensions. This is an insanely huge moment of inertia for a wheel. Apparently, Unity decided that since it could no longer compute an MOI because there was nothing attached, instead of setting the MOI to 0 it set MOI to 1. This is crazy. It also explains the ridiculousness that happens when you break everything off.
In any case, it should be fixed now. I tried to go back and find and fix all of the weird quirks that I introduced when I didn't know the root cause of the problem. Hopefully I got everything, but please let me know if you find more stuff cropping up in the next build.
I'm going to try to get out a build while I have a clear head. This one has several things that change the game in major ways:When's this build coming out?
1. The chassis plates can now be broken off. This means that every component that you add to the robot can become exposed. This means that "Robot Health" effectively becomes a meaningless idea. You can continue bashing pieces off a robot until there is nothing left to bash. I'm strongly leaning toward eliminating the health bars at the top of the screen, as they don't have any meaning anymore.
The "Robot" itself is effectively the bottom plate of the chassis. It can't be broken off from itself. The camera tracks it. The "P1" icon hovers above it. All other pieces are attached to it via a tree structure. One question is lingering in my mind: should the bottom chassis plate be invulnerable? If not, what should the consequences be for hitting it? On a good hit should we roll a die and randomly destroy something attached to it?
2. The first of the new arenas built with KupaTec's new "Arena Modding Tool" (AMT) is going to be included in this build. It is a shameless duplicate of the school arena that my students will be competing at on February 28-29. It is a smaller box, suitable for lightweights. It has polycarbonate walls, 8" steel angle iron guard rails, and an arena spinner hazard.
The Arena Modding Tool makes it possible for you guys to create and share your own arenas. KupaTec and WhamettNuht are the geniuses behind the tool and the new arenas. Expect more arenas soon!
3. We are in the process of removing old arenas, robots, menu systems, UI, and other stuff that has developed and mutated over the years. Over the next few months, expect to see a lot of stuff disappear and be replaced by newer, shinier versions. And you know what that means? New bugs!!!
All kidding aside, we are consolidating things down so that there is only one menu system (instead of one for every screen), one set of rules for robot behavior (instead of one for each robot), one set of rules for arena construction (instead of one for each arena), etc. It should significantly reduce the amount of bugs that need to be squashed.
With this build you are seeing the start of the transition of the game from its current Alpha state into a future Beta state.
The thing is if you are going to fix it, i do not want to resize stuff then
The thing is if you are going to fix it, i do not want to resize stuff then
What sort of things are getting messed up? Can you see a pattern to it?
The thing is if you are going to fix it, i do not want to resize stuff then
What sort of things are getting messed up? Can you see a pattern to it?
One nitpick is that the new motors dont have the proper attachment points. Now all of them are attachable on the axle which is weird by itself, but new modes of the same motors have their axle points on the side. Ill prolly provide a videoI’ve had the same problem. All of my bots are broken. :/
I can confirm that. The scaling for the hex, tri, and Octo cylinders were along the lines of 11.5, 5, 11.5 in the previous build.The thing is if you are going to fix it, i do not want to resize stuff then
What sort of things are getting messed up? Can you see a pattern to it?
Someone correct me if I’m wrong. It seems to be the 3 non-hollow components added in the previous update; Hexagon/Triangle/The Other One. They all had bizarre base sizes (around 11.0 X/Y/Z) if these have been reset to the same as the rest (1.0) then that would explain why it’s stretched the components out.
Guys - I’m not being funny but please don’t forget this is a work in progress game.
Everything and anything within it is subject to change.
I did mention that the changing of motor directions, ect would most likely cause some frustration among the current community but ultimately it’s something we wanted fixed for all upcoming builds.
At this point the best bit of advise I can give you all is just don’t get too attached to anything in the game as it could all change very easily! But ultimately we hope that such sacrifices will be for the better good in the long run :)
Guys - I’m not being funny but please don’t forget this is a work in progress game.
Everything and anything within it is subject to change.
I did mention that the changing of motor directions, ect would most likely cause some frustration among the current community but ultimately it’s something we wanted fixed for all upcoming builds.
At this point the best bit of advise I can give you all is just don’t get too attached to anything in the game as it could all change very easily! But ultimately we hope that such sacrifices will be for the better good in the long run :)
I'm just reflecting on the update. I currently don't have any working bots, so I can't test it. Also, don't call me Lightning, cause there's another guy who's username is Lightning S.Guys - I’m not being funny but please don’t forget this is a work in progress game.
Everything and anything within it is subject to change.
I did mention that the changing of motor directions, ect would most likely cause some frustration among the current community but ultimately it’s something we wanted fixed for all upcoming builds.
At this point the best bit of advise I can give you all is just don’t get too attached to anything in the game as it could all change very easily! But ultimately we hope that such sacrifices will be for the better good in the long run :)
Wham with all due respect, we are not sh**ting on this game, we are just pointing out what is broken so yall dont miss a thing. Lightning is on his own tho
I just shared something that I'm fairly certain is a bug. Further, I just go with the changes as they come.
Yeah, but you can do fun stuff with it!I just shared something that I'm fairly certain is a bug. Further, I just go with the changes as they come.
Agreed! There are a lot of motor changes in this build. We were buns to screw something up.
The motor sitting at a right angle is definitely not right.
Guys - I’m not being funny but please don’t forget this is a work in progress game.
Everything and anything within it is subject to change.
I did mention that the changing of motor directions, ect would most likely cause some frustration among the current community but ultimately it’s something we wanted fixed for all upcoming builds.
At this point the best bit of advise I can give you all is just don’t get too attached to anything in the game as it could all change very easily! But ultimately we hope that such sacrifices will be for the better good in the long run :)
From my perspective, and maybe I’m speaking out of place here, however I was unsure if the changes I’d seen in the update (stretched components) we’re intentional or not. If it’s intentional then I know to adjust my builds accordingly, if it’s not and it’s an error then there’s no point making any changes in case the error gets fixed.
Hopefully all SvL entrants are safe...
FWIW,Its all gud and all, we will adapt, but the thing is that most of us got used to the old mounting system. Its not only this game only. Ive been playing RA2 for around 5 years, and the way you attach the motors is to attach them directly onto the bottom of the chassis. Thats why i got sourfaced
Here's an image of an AmpFlow A40-300. It clearly shows the 4 mounting bolt holes. It has been mounting on the wrong side of the motor in the game since the beginning. With WhamettNuht on board to rework all of the models it was time to fix the bug.
Maybe you could create a build with the bugfixes and everything but with the old meshesHopefully all SvL entrants are safe...
Oh man! I'm so sorry! Eep!
:embarr
Maybe you could create a build with the bugfixes and everything but with the old meshesHopefully all SvL entrants are safe...
Oh man! I'm so sorry! Eep!
:embarr
I mean, if someone wants to make that happen, I’m all for it. I’d probably need to talk to Kupa first though.Maybe you could create a build with the bugfixes and everything but with the old meshesHopefully all SvL entrants are safe...
Oh man! I'm so sorry! Eep!
:embarr
Not doing it that way was my call. WhammetNuht originally created an “old” and “new” version of the motors. I made the decision to simplify things for newer players who would inevitably wonder why there were two versions with similar names, pick the wrong version, then be absolutely furious when their robots wouldn’t load because we deleted the “old” motors in some future build. It would be better to rip off the bandaid now than to cause more problems later.Maybe just hide them now? Like they can still be ingame but they cant be selected at all
From what I'm seeing, The Ampflow 30-400's are severely broken, the 40-300's are fine, and the Motoenergy spins the other way now, which is fine, but it's WAY too heavy now. Thankfully all SvL have the same issue, which is the 30-400's, so fixing that should fix all of them.No kidding about the Etek-R.
Ugh. It kills me to say this, but there is a way to reset the motors back to a similar configuration we had before, hiding them in the process. It won’t be perfect though. Alignment will be off. Attachment points won’t be in the exact same spots.Could you change the old motor meshes back too?
But there is a way to make it happen. I just hate it because it will become a legacy problem that will never go away.
Is it worth doing if the motors don’t go exactly back to the way they were before?
Ugh. It kills me to say this, but there is a way to reset the motors back to a similar configuration we had before, hiding them in the process. It won’t be perfect though. Alignment will be off. Attachment points won’t be in the exact same spots.
But there is a way to make it happen. I just hate it because it will become a legacy problem that will never go away.
Is it worth doing if the motors don’t go exactly back to the way they were before?
Ugh. It kills me to say this, but there is a way to reset the motors back to a similar configuration we had before, hiding them in the process. It won’t be perfect though. Alignment will be off. Attachment points won’t be in the exact same spots.Could you change the old motor meshes back too?
But there is a way to make it happen. I just hate it because it will become a legacy problem that will never go away.
Is it worth doing if the motors don’t go exactly back to the way they were before?
Ugh. It kills me to say this, but there is a way to reset the motors back to a similar configuration we had before, hiding them in the process. It won’t be perfect though. Alignment will be off. Attachment points won’t be in the exact same spots.
But there is a way to make it happen. I just hate it because it will become a legacy problem that will never go away.
Is it worth doing if the motors don’t go exactly back to the way they were before?
Ugh. It kills me to say this, but there is a way to reset the motors back to a similar configuration we had before, hiding them in the process. It won’t be perfect though. Alignment will be off. Attachment points won’t be in the exact same spots.It’s better than our current predicament. I’d feel much better doing minor adjustments on 100 bots than doing major adjustments on 100 bots.
But there is a way to make it happen. I just hate it because it will become a legacy problem that will never go away.
Is it worth doing if the motors don’t go exactly back to the way they were before?
Would it be possible to release the Feb 5 build again but with the Motor gyro fix as the only change?
Aight. How long would it take to fix the 30-400’s for the new build? Contemplating whether i should fix all the entries or just wait it out.Would it be possible to release the Feb 5 build again but with the Motor gyro fix as the only change?
Not really. This build has a ton of commits and affected hundreds of lines of code and many hours worth of assets. The new build would be done specifically to address legacy compatibility. It might take a few days.
Future compatibility really shouldn't be something we worry about. We should expect robots from previous patches to lose viability every now and then.
I'm honestly surprised this is the first time anyone's complained about this.
Future compatibility really shouldn't be something we worry about. We should expect robots from previous patches to lose viability every now and then.
I'm honestly surprised this is the first time anyone's complained about this.
For you its not a problem, but for me with again, over 80 robots, i feel like i dont wanna refix them all because its too much work and hassle
I was already in hell when i had to redo most of my bots once when they wouldnt show up
I'm really enjoying this new build! I made a couple test robots and noticed the following:
-Mobility kills are definitely a real deal now with the wheel building tools. It doesn't take too much effort to use my bar spinner to remove tires from my 4-wheeled drum spinner to immobilize it, just like in real robot combat.
-I love that chassis panels can now break off. I think it's safe to say that the health bar can go away as KOs are effected by smashing the other robot to pieces in some manner IRL.
-It seems that material resilience is still pretty high compared to what I see on TV. Shouldn't a bar spinner with 100 kJ of energy absolutely destroy polycarbonate almost regardless of realistic thickness?
-I think the bottom of the chassis should be destroyable. Any components mounted to the destroyed bottom of the chassis go with it. So if the bot controller is mounted to the bottom of the chassis and that panel goes away, so does the controller and the bot is KO.
--Building on that thought, perhaps the tree structure of building bots is too limiting in the way these things can actually be destroyed? IRL bots keep going until they can't, either though mobility issues or complete dismemberment. I remember seeing a battle between Warhawk and Hydra where Hydra literally dismembered Warhawk, but Warhawk's individual components kept moving based on operator inputs. The bot got counted out because it was immobilized. Another example was a fight between Tombstone and some kind of pushbot. But Tombstone's bar spinner nailed a corner of the push bot and broke the bot in half diagonally. Yeah, that bot was down for the count.
With that being said, if the way the game works could be converted from the tree structure to some kind of universal interconnectivity, the ways stuff could be destroyed would be less limiting.
-How fine can destruction be made? Is it reasonable to believe that computers can simulate panels shredding or shattering to some degree based on the materials and type if impact involved? Realistically, panels may do more than just break off - they may be ripped in half or shattered to pieces too. Then the bot can puke out batteries, motors, etc.
EDIT: Totally destroyed this robot, but even with the side panels gone, it took awhile for the bar spinner to eviscerate it of its motors and batteries. The damage slider is turned all the way up to 200%, so perhaps it needs to be 400%?
[ This attachment cannot be displayed inline in 'Print Page' view ]
Yay so my etek thwack will survive AND be in the correct weight class!
My apologies to anyone caught in the middle. This coming build will break anything you have created using the A40-300 or F30-400 with the 15February2020 build.
PS - I fixed the mass on the ME0708. I have no idea what happened, but it suddenly became a 35 kg motor. :)
Where is the arena modding tool?
EDIT: the new arena building capability sounds awesome, so I would like to try it out.
Ok. Could you put out a preview version on /bleedingedgebuilds?Where is the arena modding tool?
EDIT: the new arena building capability sounds awesome, so I would like to try it out.
KupaTec has it at the moment, with WhammetNuht working on the new arenas with it. There are still quite a few features they are looking to put in before we release it to the public.
Ok. Could you put out a preview version on /bleedingedgebuilds?Where is the arena modding tool?
EDIT: the new arena building capability sounds awesome, so I would like to try it out.
KupaTec has it at the moment, with WhammetNuht working on the new arenas with it. There are still quite a few features they are looking to put in before we release it to the public.
The 16February2020 builds are up:Yay! Thanks!
https://robot-rumble.itch.io/builds (https://robot-rumble.itch.io/builds)
[Updates in the February 16th Build]
[Bug Fix] Fixed the lighting/shaders/color in the School Tournament Arena for Windows machines.
[Bug Fix] Restored the ME0708 motor mass to the correct mass of 12.7 kg. For some reason it got set to 35 kg in the 15FEBRUARY builds.
[Reversion] MOTORS REVERTED TO THE 05FEBRUARY2020 VERSIONS - Due to the fact that the February 15th build reduced the attachment points and flipped the orientation of the motors by 180 degrees for the A40-300 and F30-400 motors, causing pretty much every robot players had previously built to suddenly become wonky, we have restored the settings of the motors for pre-existing robots.
This means you shouldn't have to go back and change your .RR2Bot files.
The old versions of the motors are still in the game, but no longer listed as an option to be selected.
IMPORTANT - Please note that this should restore any robots made with these motors in the 05FEBRUARY or earlier builds. This also means that any robots made with the 15FEBRUARY build using the A40-300 or F30-400 will have incorrect motor positioning. Robots made with the 16FEBRUARY build will work as normal.
They released the game and it isn't complete.Ok. Could you put out a preview version on /bleedingedgebuilds?Where is the arena modding tool?
EDIT: the new arena building capability sounds awesome, so I would like to try it out.
KupaTec has it at the moment, with WhammetNuht working on the new arenas with it. There are still quite a few features they are looking to put in before we release it to the public.
Why the **** are you so annoying with these requests? If its not finished, they wont release it, you know it, we know it, everyone knows it.
Ayy new build. Okay so if i used the (New motors i should be fine i guess)
They released the game and it isn't complete.
The zip isn't affected. Just unzip it again because the arenas are in the default windows 64 data folder.They released the game and it isn't complete.
Game and a mod tool arent the same thing lol. They cant release a thing that can potentially break the game
They released the game and it isn't complete.If Kupa and Wham aren't in a position where they're comfortable enough to release the AMT, then it clearly isn't in a functional enough state to make high quality arenas in. It's completely reasonable to want the tool, but it's going to be released no matter what and I'm sure you can muster the patience to wait. If you want to make arenas so badly, just use blender for now, as anything you make in there can easily be imported into the AMT later on. Pestering Kupa to release the tool is not going to make it come any faster, and there is no point in releasing it when it isn't done. Just be patient.
Yeah. IK ive gotta be patient.They released the game and it isn't complete.If Kupa and Wham aren't in a position where they're comfortable enough to release the AMT, then it clearly isn't in a functional enough state to make high quality arenas in. It's completely reasonable to want the tool, but it's going to be released no matter what and I'm sure you can muster the patience to wait. If you want to make arenas so badly, just use blender for now, as anything you make in there can easily be imported into the AMT later on. Pestering Kupa to release the tool is not going to make it come any faster, and there is no point in releasing it when it isn't done. Just be patient.
Oh yeah btw, the old motors are not hidden in the motors section
Oh yeah btw, the old motors are not hidden in the motors section
Darn it! Time for another build!
Stupid flu makes brain fuzzy hard to think.
Oh yeah btw, the old motors are not hidden in the motors section
Darn it! Time for another build!
Stupid flu makes brain fuzzy hard to think.
Also, the new A40-300 have broken axle points. Instead of spinning in z direction its spinning in x direction
The school arena still looks like this for me:
[ This attachment cannot be displayed inline in 'Print Page' view ]
EDIT: The chassis damage is so realistic! Thank you RR2 devs!
EDIT 2: After looking at the file in notepad, maybe the reason its broken is its encoded in carriage return, not carriage return and line feed.
Maybe. In a traditional game a professional artist manually goes in and creates two versions of every part, an intact one and a broken one (or multiple broken ones depending on time and budget). In our game it is a MUCH harder challenge. YOU are the artist who made the part in the first place. We can't put it on the players to make a bunch of broken version of parts, and developing the tool set to do this is extremely involved. The price tag of our game will pale in comparison to the $1500/year that Adobe charges for 3ds Max. They can hire A LOT more programmers than we can to make the tool set good, and they have been iterating since the 1990s.
I think the closest thing to this I can think of is whatever makes destructible terrain work in some combat games, or soft-body physics simulators like Rigs of Rods, the latter of which can be pretty CPU-intensive. I'm just a dreamer, not a programmer :dumb)
Also, the new A40-300 have broken axle points. Instead of spinning in z direction its spinning in x direction
Also, the new A40-300 have broken axle points. Instead of spinning in z direction its spinning in x direction
Could you send me some screenshots of what you're currently seeing? I'll take a look at this tonight.
And regarding anything wheel builder - please note I am currently balancing a lot of values, ect. I have a feeling a lot of bouncing, driving, ect. issues might be down to incorrect weights. I'm currently trying to find a low-level and high-level stat range I am happy with then I'll apply these across all parts as balanced values.
On a AAA game team sizes are typically around 1000 people, with several hundred artists working full time to produce broken terrain pieces.
Because our meshes are user-generated, we would have to create our own breakage algorithm.
Alternatively, we currently have an asset that will do real-time mesh deformation, but it is low-poly and looks terrible.
We are still in the trying things out stage. We have a long way to go still.
There's some issue with the new custom wheels. When I replace my old custom rubber wheels or premade wheels with the new ones, some of my bots which used to drive well starts drifting, oversteering and bouncing.
For another, when my 4WD or 8WD bots only have 2 or 4 of the motors running while the other motors shut down, if they are attaching to the old custom rubber wheels or premade wheels, they work fine. But if attaching to new custom wheels, the bot will fly to the air when driving.
Here is one of the examples.
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
Also, the new A40-300 have broken axle points. Instead of spinning in z direction its spinning in x direction
Could you send me some screenshots of what you're currently seeing? I'll take a look at this tonight.
And regarding anything wheel builder - please note I am currently balancing a lot of values, ect. I have a feeling a lot of bouncing, driving, ect. issues might be down to incorrect weights. I'm currently trying to find a low-level and high-level stat range I am happy with then I'll apply these across all parts as balanced values.
Heres one better:
https://youtu.be/-vvx_gar8XQ (https://youtu.be/-vvx_gar8XQ)
Could you post the windows school arena file?The school arena still looks like this for me:
EDIT: The chassis damage is so realistic! Thank you RR2 devs!
EDIT 2: After looking at the file in notepad, maybe the reason its broken is its encoded in carriage return, not carriage return and line feed.
I somehow managed to upload the MacOS version of the arena for the Windows build. One of the quirks of the arena builder is that it has to create a version for each platform. Windows uses DirectX, while MacOS uses OpenGL or Metal. We’re currently trying to streamline the process. I tried to add the correct version to the build by manually, but made a mistake in the process.
I’m glad you like the chassis damage. On the surface it’sa little thing, but from a game design perspective I think it potentially changes the way the game is played.
Ok a follow up:Yeah I have shown it before where I found it during the reworking of Miasma. Had a gearbox mounted on the side of the new 40-300.
https://youtu.be/-8FUTqk11Ac (https://youtu.be/-8FUTqk11Ac)
I think powerrave noticed this before
Ok a thing i would also wish is that the disc wouldnt fall off because of the self damage, basically, if there was a system where you could assign 2 parts to hold the disc together, or the game could assign the closest ones from the centre of the disc/drum , and if one breaks off, the disc would fall off then
Yeah I have shown it before where I found it during the reworking of Miasma. Had a gearbox mounted on the side of the new 40-300.Yeah k im actually turning into a boomer
Still some fine-tuning issues for the coding guys to sort out but the A40-300 motor should be back to working as intended for the next build.Will the brushless motor be fixed for the next build?
Still some fine-tuning issues for the coding guys to sort out but the A40-300 motor should be back to working as intended for the next build.Will the brushless motor be fixed for the next build?
Still some fine-tuning issues for the coding guys to sort out but the A40-300 motor should be back to working as intended for the next build.Will the brushless motor be fixed for the next build?
What's wrong with it?
Okay, so... I've just tried the feb16 build, and Circumvolution's gotten catastrophically worse for reasons I can't figure out. The entire robot disintegrates at the slightest provocation, and the weapon is simply incapable of damaging anything more than exposed wheels during its brief existence. If anything, the shrapnel is probably more dangerous than the robot itself.
I even built a completely new robot to the same concept with fewer parts (such as using a hollow cylinder for the flywheel) and that one's even worse. I've seen its wheels break seemingly just from the weight of the robot pressing down on them, and the flywheel consistently just comes clean off after it scores one or occasionally two of its pathetic hits.
:vista:
I even built a completely new robot to the same concept with fewer parts (such as using a hollow cylinder for the flywheel) and that one's even worse. I've seen its wheels break seemingly just from the weight of the robot pressing down on them, and the flywheel consistently just comes clean off after it scores one or occasionally two of its pathetic hits.
:vista:
The only damage that should exist in the game right now is due to spinner hits. A robot pressing down on its wheels shouldn't do any damage. Do you think its weapon is damaging its own wheels?
Also, just curious, but what damage slider setting are you using?
I just thought of a theory regarding one of the issues I've been seeing with flywheels.
Perhaps damage is now being calculated based on the size or weight of the individual part that scores the hit? That would explain why I see bars doing just fine but all the flywheels I have do basically nothing, since said flywheels all have their teeth attached as separate components rather than included as part of the main body of the weapon.
The puncture damage system needs to be updated. It should be a relatively easy fix.
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? ;)
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.
hey i wanna ask, how do ya acces the arena builder or is it still locked away?Atm it is currently unavailable.
Atm it is currently unavailable.
OK so...
Using a 3 inch brushless
https://youtu.be/PkHPVDf2zP8
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?
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.
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.
Wait so discs will now get unbalanced when they lose parts?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.
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
eyOk 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.
eyOk 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.
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
eyOk 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.
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.
ya but can you sload in this game
ya but can you sload in this game
Pardon my ignorance, but what does it mean to “sload”?
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?
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);
An option to turn the multi part spinner into a single part spinner? Keep the collision. Also circumvolution is only a 16kg spinner, and at that size its... Not really supposed to be durableParts 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...
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 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.
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
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.
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.
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.
Agreed! Love this idea!
Also circumvolution is only a 16kg spinner, and at that size its... Not really supposed to be durable
Circumvolution isn’t a replica, it’s an RR2 bot made by Cyar Skirata.Also circumvolution is only a 16kg spinner, and at that size its... Not really supposed to be durable
I don't know anything about Circumvolution (tried Googling it and nothing came up), but one of Tombstone's blades weighs around 30 kg alone, so I think it would make sense for a 16 kg bot to be OHKO'd by that weapon.
If a robot simulator is desired, I definitely think that OHKOs should be a thing, but I understand if certain bot building limitations make it hard to design a bot to prevent that from happening. I imagine one would have to design a frame, the way the frame is bolted or welded together, how the body plates attach to the frame, etc.
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.
but what if i have to use it on a hw?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.
You should be able to make something very similar (or even better and smaller!) with the Wheel Builder components. Granted they're not perfect currently and probably as weak as the current 3 inch wheel, but that is what they are there for :)Yeah I think the issue with the health of the new wheels (not the 3 inch foam one) is that the weight of a 3x3x3 scaled rim is not even .1 kg, but the tires at that scale are like 16 kg.
Therefore I set the rims as decorations.;)You should be able to make something very similar (or even better and smaller!) with the Wheel Builder components. Granted they're not perfect currently and probably as weak as the current 3 inch wheel, but that is what they are there for :)Yeah I think the issue with the health of the new wheels (not the 3 inch foam one) is that the weight of a 3x3x3 scaled rim is not even .1 kg, but the tires at that scale are like 16 kg.
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
Not false tho, is it?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
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
Correct me if I’m wrong, but isn’t sloading (snapper loading?) a way to get components in weird places in ra2?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.
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.
I'm just fine with playing with the build that came before this one. I don't make it a habit of downloading and working with the latest one each time in case something breaks. After all, the lead dev seems to have school to focus on.Well, If you want to join in the community, make better bots and enter tournaments then you have to catch up with the latest build. And if bots should be broken, that would be just inevitable, else you can still get back to use the early version.
Sorry for the delay! I’m trying to get one out today.Yay! Bugfixes! (No I’m not being sarcastic)
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.
Sorry for the delay! I%u2019m trying to get one out today.Yay! Bugfixes! (No I%u2019m not being sarcastic)
I%u2019m 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.
About the AMT, any updates?
Ah, crap. I have no unity knowledge. :/ Ah, well ¯\_(ツ)_/¯Sorry for the delay! I%u2019m trying to get one out today.Yay! Bugfixes! (No I%u2019m not being sarcastic)
I%u2019m 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.
About the AMT, any updates?
Lets say that yall need to prepare your unity knowledge
As for the wobble, maybe the axle is the reason of teleportation?
Neither have i ;)Ah, crap. I have no unity knowledge. :/ Ah, well ¯\_(ツ)_/¯Sorry for the delay! I%u2019m trying to get one out today.Yay! Bugfixes! (No I%u2019m not being sarcastic)
I%u2019m 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.
About the AMT, any updates?
Lets say that yall need to prepare your unity knowledge
As for the wobble, maybe the axle is the reason of teleportation?
I can’t wait!!!!!!Neither have i ;)Ah, crap. I have no unity knowledge. :/ Ah, well ¯\_(ツ)_/¯Sorry for the delay! I%u2019m trying to get one out today.Yay! Bugfixes! (No I%u2019m not being sarcastic)
I%u2019m 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.
About the AMT, any updates?
Lets say that yall need to prepare your unity knowledge
As for the wobble, maybe the axle is the reason of teleportation?
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.
Good idea. Or you could leave it as it is and Have a setting that highlights intersections
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. No “sloading” is specific to RA2, but 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?
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
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
The AMT won%u2019t 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%u2019t tried it myself.
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.
How fast can you dish out a fix?
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?
Another thing to consider is that in RA2, we actually allow weapons to cut through armor as long as the plate / chassis is not completely bisected by the path, because theoretically you could cut holes in the parts. I'm thinking this is less of an issue in RR2 though, because we have enough control to mold things to whatever shape we want (e.g. its realistic now).
kix,
I’m at our real-life robotics competition today and tomorrow, so I won’t be able to do much fixing. I can re-enable an older build on itch.io though. Is there a particular build that I should enable for your tournament?
The new arenas are awesome! Also the sliders inside the workshop makes it much more convenient to build high-customed-part-bots, really appreciate this one. And there're some issues imo of this new build.
The bots are not back to original size, but slightly smaller than those in previous builds. Maybe it's for other purpose but Idk.
Those new weapons look nice, but the weight might not be that suitable. 10kg for a flywheel, 0.5kg for an axe is a bit too fragile and lacking of energy. Resizing is still not enough. If we could tweak the material thickness of them that would be better.
The damage is unrealistically high in the new build, bots seems to be fragile as plastic, which makes me have to tweak the damage slider to 5%, but even so the small weapon parts like spinner teeth still easily fall off.
Also the bouncing problem of new custom wheels is getting more severe. And bots keep give out noises while driving.
I noticed with the latest build that the blade-to-gear axle connection on my custom bar spinner is very weak. Then again, it is also capable of spinning up to 200 kJ in less than 20 seconds. Is there something I'm missing durability-wise? It's actually a 67 kg bar :confused:
Actually in general, I noticed that all components seem much weaker, even the internal ones like the motors and batteries. They seem like they break off a lot more easily, which is awesome! But I'd think the weapons would be a little more robust.
There are some issues with the new custom wheels. When I replace my old custom rubber wheels or premade wheels with the new ones, some of my bots which used to drive well starts drifting, oversteering and bouncing.I've talked about this issue at P93 before, and ya, it still exists. And here's a more obvious example.
For another, when my 4WD or 8WD bots only have 2 or 4 of the motors running while the other motors shut down, if they are attaching to the old custom rubber wheels or premade wheels, they work fine. But if attaching to new custom wheels, the bot will fly to the air when driving.
Here is one of the examples.
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
There are some issues with the new custom wheels. When I replace my old custom rubber wheels or premade wheels with the new ones, some of my bots which used to drive well starts drifting, oversteering and bouncing.I've talked about this issue at P93 before, and ya, it still exists. And here's a more obvious example.
For another, when my 4WD or 8WD bots only have 2 or 4 of the motors running while the other motors shut down, if they are attaching to the old custom rubber wheels or premade wheels, they work fine. But if attaching to new custom wheels, the bot will fly to the air when driving.
Here is one of the examples.
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
Btw, we kinda have demands of the size scaling factor cuz we've made numbers of bots that are normal-sized in previous builds but now they are slightly a bot small. Also some replicas has many tiny detailings that we cannot make the bot small. It might take us a long as time to rescale them, but with the scale factor we can save a great amount of time rescaling them. It's like, it can rescale all the components that are able to resize(like chassis and all customed stuff) together with other components like motors, batteries and default wheels etc stay unchanged. Would it be something that can be realized?
Hmmm. That would be kind of weird to implement. Some things can be scaled while others can’t. Things would definitely come out looking strange. Here’s an example:
1. I create a robot that has batteries arranged in a brick. Each battery is immediately adjacent to the next battery.
2. I scale the robot down. Batteries can’t scale down. Now the batteries are overlapping each other.
Or another case:
1. I make a drivetrain with motors, wheels, and gearboxes.
2. I scale the robot up.
3. Now the wheels don’t reach the ground, and they are completely inside the chassis.
There is all sorts of weirdness that would occur with a scale slider because some components are not scalable.
A scale factor of 1.5 (typical for many of the robots in the 110 kg range) would make the robots mass increase by a factor of 1.5^3 = 3.375X. This would put the robots at 371 kg.Again, we are aware of that
A scale factor of 1.5 (typical for many of the robots in the 110 kg range) would make the robots mass increase by a factor of 1.5^3 = 3.375X. This would put the robots at 371 kg.That still only takes like 5 minutes to fix. Rescaling each individual part takes 10x longer.
I guess I still don’t understand what you are trying to accomplish. What exactly is the problem you are trying to solve? Things are now scaled correctly. Whatever looks right in the workshop now matches what you see in the arena.I dont need to accomplish anything. But it would be a good addition as you can always mess up the scaling while building
Maybe a picture would help?No that’s not what we mean. We’re just saying that in general it would be a nice addition to the game.
Why do you want to change the scale of the parts? Aren’t they scaled correctly now?
Maybe a picture would help?
Why do you want to change the scale of the parts? Aren%u2019t they scaled correctly now?
Gotcha! Sorry. I’m a little dense. We can put it on the list.
So you were thinking of building a really big robot in its entirety, then scaling the whole robot down to make weight?
And I'm sure this is obvious now but I'd say it only applies to parts which are 'Is Scaleable = True'. I have to be honest and admit this would be helpful.... When I was building reps finding out you hadn't scaled a robot correctly was incredibly frustrating. And even now as I'm rebuilding the stock robots I could do with scaling some up/down (the new Royal Robby - as an example, could do with being scaled up from how I built it).Oh yeah about reps, do you want to join the rep building team over on discord, Wham?
And I'm sure this is obvious now but I'd say it only applies to parts which are 'Is Scaleable = True'. I have to be honest and admit this would be helpful.... When I was building reps finding out you hadn't scaled a robot correctly was incredibly frustrating. And even now as I'm rebuilding the stock robots I could do with scaling some up/down (the new Royal Robby - as an example, could do with being scaled up from how I built it).Oh yeah about reps, do you want to join the rep building team over on discord, Wham?
I genuinley dont even know why did he askBecause you were too much of a beta male to ask him yourself. heck
I genuinley dont even know why did he askBecause you were too much of a beta male to ask him yourself. heck
Lmao I know that I’m just screwing with youI genuinley dont even know why did he askBecause you were too much of a beta male to ask him yourself. heck
I ****ing did you blind cuck
While romping around with my bar spinner I straight-up destroyed the opposing robot's Motenergy motor (seen at the bottom of the screen shot). That's quite the detail with that motor's 3D model!
[ This attachment cannot be displayed inline in 'Print Page' view ]
The rotor was actually wobbling as it spun down! Haha I bent that thing up good heck
While romping around with my bar spinner I straight-up destroyed the opposing robot's Motenergy motor (seen at the bottom of the screen shot). That's quite the detail with that motor's 3D model!
[ This attachment cannot be displayed inline in 'Print Page' view ]
The rotor was actually wobbling as it spun down! Haha I bent that thing up good heck
I am SOOOO glad someone noticed I put in that detail!!
If you look closely at the motor as it’s spinning you should see the inner coil spinning aswell :)
Spinners in Feb28 have something weird going on with their mass or something. My verts start to wheely when their weapons are spinning.My Monsoon has the same issue which makes me have to gear it really slow to avoid it.
It's by far at its most noticeable with S3. Drive forward with the weapon off, it's fine. Drive forward with the weapon on, and it's more overhead thwackbot than vert.
[ This attachment cannot be displayed inline in 'Print Page' view ]
Spinners in Feb28 have something weird going on with their mass or something. My verts start to wheely when their weapons are spinning.
It's by far at its most noticeable with S3. Drive forward with the weapon off, it's fine. Drive forward with the weapon on, and it's more overhead thwackbot than vert.
[ This attachment cannot be displayed inline in 'Print Page' view ]
Spinners in Feb28 have something weird going on with their mass or something. My verts start to wheely when their weapons are spinning.
It's by far at its most noticeable with S3. Drive forward with the weapon off, it's fine. Drive forward with the weapon on, and it's more overhead thwackbot than vert.
[ This attachment cannot be displayed inline in 'Print Page' view ]
Is it the reaction torque that occurs when the weapon starts up?
Circumvolution is hard to drive too. It tends to flip on its back a lot.
It seems like there's definitely something up with my vertical dual-bar spinner. A combined 400 kJ of energy doesn't seem to do any damage to the opposing bot, yet any collisions made against the opposing bot cause my robot to flip over. It's almost like no energy is being transferred to the target with the vertical spinners.
It makes me wonder now what would happen if I made it a diagonal spinner...
What changes were made to physics? And what was the reason behind it? Feb 16 had it pretty spot on, so I guess I'm just confused as to why that needed adjustments...
Reason I'm asking is because SvL's arena free-cam might not be compatible with the most stable version of the game, Feb 16. Still crossing my fingers on it, but if not, I'm a little worried about how all the entries will react to the removal of the MassScaleFactor. Hopefully, this all works out in the end and I can get started on filming.What changes were made to physics? And what was the reason behind it? Feb 16 had it pretty spot on, so I guess I'm just confused as to why that needed adjustments...
Prior to the most 28 February build, there were two scaling factors in robot reconstruction:
1. massScaleFactor - Introduced in the very beginnings of the robot workshop. This was originally set to 0.1. We had some difficulties very early on trying to get driving to feel good for heavyweights, so this scale factor was introduced to bring the mass of the chassis down to approximately 10 kg. This just happened to work well with wheel masses of 1 kg.
2. sizeScaleFactor - Introduced about a year ago when we started focusing on beetleweight driving for Bugglebots. At the time, I couldn't understand why heavyweights drove fine, but beetleweights would randomly float and flip on their sides with no user input. The only thing I could do that seemed to have any effect was to increase the scale (but not the mass) of the beetleweights so that they were similar in size to heavyweights. This created all sorts of problems, so I settled on a scale factor that depended on the weight of the robot, but made typical beetleweights be approximately 1.5 times their original size.
In the 29 February build, I set both mass and size scale factors to 1. We had found and eliminated the root cause of the problems that the scale factors were designed to address.
The massScaleFactor created a part management problem where we had to manually adjust component torque and force values. This was prone to error, and causing all sorts of random problems and inconsistencies now that Wham is creating a bunch of components.
The sizeScaleFactor created a problem where what you saw in the robot workshop didn't match what you saw in the arena. In general, robots were way too big for the arena. Moreover, scaling was inconsistent between robots. One robot's A40-300 motor would be a different size than another robot's A40-300 motor. This made it very difficult to create arenas at the correct scale when every single robot was scaled differently.
I am confident that eliminating the sizeScaleFactor was the right thing to do. I am less confident that eliminating the massScaleFactor was the right thing to do, as it has exposed a few more things that I didn't anticipate. One of them is an interaction with another bit of code that causes vertical spinners to more easily flip backward (Circumvolution and S3). One of them is the fact that the increased weight is pushing down harder on the wheel joints, causing robots with low clearance to scrape against the floor (Nuclear Crisis). I think these things are fixable, but it is a work in progress.
I think that your number 1 priority would be to fix the A40 motor, it has been an issue for a couple of builds now
The one where the axle goes to 0/0/0 location when in test area and the battlesI think that your number 1 priority would be to fix the A40 motor, it has been an issue for a couple of builds now
Could you send a screenshot? I'm not seeing the issue in the inspector.
I haven’t seen it. Is it for the old motor or the (new) one?New one, try attaching a wheel to the motor that isnt in 0/0/0 position and then go to the test bot section
I haven’t seen it. Is it for the old motor or the (new) one?New one, try attaching a wheel to the motor that isnt in 0/0/0 position and then go to the test bot section
I haven’t seen it. Is it for the old motor or the (new) one?New one, try attaching a wheel to the motor that isnt in 0/0/0 position and then go to the test bot section
I see it now. I have no idea what is causing it. Definitely will look into it!
For this next build I have combined spinners into a single damageable object. This means that the whole spinner will break off together.
My Tombclone will break off Circumvolution's spinner in a single hit every single time. It makes for really short fights.
For this next build I have combined spinners into a single damageable object. This means that the whole spinner will break off together.
My Tombclone will break off Circumvolution's spinner in a single hit every single time. It makes for really short fights.
Ah i really love this thing you said, maybe you should enable an option to disable breaking stuff off if on an axle
Just out of curiosity. Does the multi part spinner get combined HP as a single component, or does it have the HP of the base part?
For this next build I have combined spinners into a single damageable object. This means that the whole spinner will break off together.
My Tombclone will break off Circumvolution's spinner in a single hit every single time. It makes for really short fights.
Ah i really love this thing you said, maybe you should enable an option to disable breaking stuff off if on an axle
Just out of curiosity. Does the multi part spinner get combined HP as a single component, or does it have the HP of the base part?
It adds up the total health of the spinner components and consolidates them into a single number. Right now health = mass * (health per mass of the material). More mass = more health.
Circumvolution Spinner = 250 health
Tombclone Spinner = 500 health
Tombclone can do thousands of Joules of damage on a single hit, so Circumvolution's spinner is destroyed every single time.
Else lower the damage slider to let the fight last longerFor this next build I have combined spinners into a single damageable object. This means that the whole spinner will break off together.
My Tombclone will break off Circumvolution's spinner in a single hit every single time. It makes for really short fights.
Ah i really love this thing you said, maybe you should enable an option to disable breaking stuff off if on an axle
Just out of curiosity. Does the multi part spinner get combined HP as a single component, or does it have the HP of the base part?
It adds up the total health of the spinner components and consolidates them into a single number. Right now health = mass * (health per mass of the material). More mass = more health.
Circumvolution Spinner = 250 health
Tombclone Spinner = 500 health
Tombclone can do thousands of Joules of damage on a single hit, so Circumvolution's spinner is destroyed every single time.
Tbh irl Hori would beat a vert easily. If you are uncomfortable with it you can always add a small HP multiplier
Else lower the damage slider to let the fight last longerFor this next build I have combined spinners into a single damageable object. This means that the whole spinner will break off together.
My Tombclone will break off Circumvolution's spinner in a single hit every single time. It makes for really short fights.
Ah i really love this thing you said, maybe you should enable an option to disable breaking stuff off if on an axle
Just out of curiosity. Does the multi part spinner get combined HP as a single component, or does it have the HP of the base part?
It adds up the total health of the spinner components and consolidates them into a single number. Right now health = mass * (health per mass of the material). More mass = more health.
Circumvolution Spinner = 250 health
Tombclone Spinner = 500 health
Tombclone can do thousands of Joules of damage on a single hit, so Circumvolution's spinner is destroyed every single time.
Tbh irl Hori would beat a vert easily. If you are uncomfortable with it you can always add a small HP multiplier
I'm experiencing a lot of trouble working around rims. For an example, I'm working on a bot inspired by HUGE and am trying to attach a rod to each rim to prevent immobilization by tipping the whole bot onto its side. However, I accidentally attached a cylinder shape to the center of the rim, and cannot remove said cylinder shape. Every time I try to select the cylinder, the workshop selects the rim instead and tells me that I can't delete the rim with components attached to it. It seems like an issue with bounding boxes and it doesn't matter how big the rim is (I have this issue mounting tires to the rim too).resize the tire on one side or shift+right arrow
I'm experiencing a lot of trouble working around rims. For an example, I'm working on a bot inspired by HUGE and am trying to attach a rod to each rim to prevent immobilization by tipping the whole bot onto its side. However, I accidentally attached a cylinder shape to the center of the rim, and cannot remove said cylinder shape. Every time I try to select the cylinder, the workshop selects the rim instead and tells me that I can't delete the rim with components attached to it. It seems like an issue with bounding boxes and it doesn't matter how big the rim is (I have this issue mounting tires to the rim too).
I'm experiencing a lot of trouble working around rims. For an example, I'm working on a bot inspired by HUGE and am trying to attach a rod to each rim to prevent immobilization by tipping the whole bot onto its side. However, I accidentally attached a cylinder shape to the center of the rim, and cannot remove said cylinder shape. Every time I try to select the cylinder, the workshop selects the rim instead and tells me that I can't delete the rim with components attached to it. It seems like an issue with bounding boxes and it doesn't matter how big the rim is (I have this issue mounting tires to the rim too).
Unfortunately it is a collision aspect which means all the rims are essentially one solid cylinder. Unity doesn't allow for things such as hollow collisions unless you incorporate a lot of individual collision meshes into one, which cjbruce wants to avoid as it would push the number of active collisions up too high. The best way to do it is to scale parts that get in the way, or if you zoom in close enough to a part you can bypass it's collision and select parts that are inside. Unfortunately this is the only way the game can handle these parts.
This past weekend I had the opportunity to watch about 30 different spinners fight each other, then walk through the pits to see what damage had occurred. The spinner robots were all around 85 pounds, and they mostly had small-ish vertical spinners. They were only a handful of horizontal spinners in the mix. A few observations:
1. Most of the horizontal spinners broke. The broken ones I looked at tended to have weapon axles that were more than 8 inches apart.
2. When a spinner broke it was because the entire axle came out. This occurred due to a combination of axle bending (long, thin axle = bad) and frame bending (warped frame = axle pops out). A 1500 Joule spinner with an 8" long x 3/4" diameter steel axle bent and popped out every time it hit anything solid. They lost two consecutive axles that way.
3. The spinners were driven mostly by Ampflow A28-150s or A28-400s at 24 volts.
4. Most of the horizontal spinners were larger than 12" in diameter.
5. None of the vertical spinners broke.
6. Most of the vertical spinners were less than 12" in diamater.
Some inferences:
1. Larger diameter spinners break more often.
2. Spinners with bearings farther apart break more easily.
I'm thinking of maybe trying to incorporate the "larger spinner = more dangerous to itself" idea into the game. My Tombclone has a long bar. Maybe it is more prone to self damage by accidentally hitting the wall or the floor? It also tends to send itself flying.
Totally agree.Current form of self damage is the weapon falling off which happens unrealistically often and its very sensitive, id recommend more of an internal shock
The game makes a distinction between hitting an opponent and hitting an immovable object. It would be straightforward to increase self damage for large diameter spinners.
Current form of self damage is the weapon falling off which happens unrealistically often and its very sensitive, id recommend more of an internal shock
Current form of self damage is the weapon falling off which happens unrealistically often and its very sensitive, id recommend more of an internal shock
Which again - goes back to my thing about the damage system being moved to the health of internal components including impact damage ;)
Current form of self damage is the weapon falling off which happens unrealistically often and its very sensitive, id recommend more of an internal shock
Which again - goes back to my thing about the damage system being moved to the health of internal components including impact damage ;)
But how do we communicate to players that damage is accumulating? The nice thing about something falling off is that it is very visual.
90% of the robot KOs this weekend were because the little wires that go to the receiver popped out after a hit. It is an incredibly unsatisfying way to lose. There is no warning, and it sucks when it happens. Your robot stops working.
Even though losing like this is completely realistic, I don't want RR2 players to feel like every time they lost it was because of an unlucky hit.
Would it be possible to have parts warp visually based off of damage received? And maybe more total damage taken = slower spin up time and maybe motors shutting off entirely?Visual warp is gonna be kinda awful to make with rigidbodies, ra2 is having one for chassis and you can see how well that works. I could see a uhh component deteriation system with scratches, dents (with bumpmapping) and uhh fractures, I like the slower spin up. Now for the wires breaking off, maybe if you could have a visible wire once the advanced wiring system exists, we could cut the wires off with the weapon in a battle? This way you wont lose to wire falling off, you would lose to wire getting cut instead
Visual deformation looks terrible right now. It would take a lot of work to make it subtle and probably only mediocre looking. Not worth the time, IMO.
An LED system could work. Maybe that is enough? I%u2019m not so keen on a %u201Cself healing%u201D mechanic. It just seems like this is so gamey and not at all representative of the real world. I think I would be a lot more okay with hits putting a robot off balance though.
Visual deformation looks terrible right now. It would take a lot of work to make it subtle and probably only mediocre looking. Not worth the time, IMO.
An LED system could work. Maybe that is enough? I’m not so keen on a “self healing” mechanic. It just seems like this is so gamey and not at all representative of the real world. I think I would be a lot more okay with hits putting a robot off balance though.
Honestly for an axe, the stronget the armour the longer the bot lasts. I think a perfect example where a bot was axed to death was between THZ and Spawn Again where the bot just slowly died.
how does the visual deformation look like rn btw?
Honestly for an axe, the stronget the armour the longer the bot lasts. I think a perfect example where a bot was axed to death was between THZ and Spawn Again where the bot just slowly died.
how does the visual deformation look like rn btw?
Wouldn't this be from that Mesh Deform script we currently have in the back log of the game?? Albeit I haven't played around with this feature yet for new arena props but I'm still sceptical on how they would work for them hahaha
Visual deformation looks terrible right now. It would take a lot of work to make it subtle and probably only mediocre looking. Not worth the time, IMO.
An LED system could work. Maybe that is enough? I’m not so keen on a “self healing” mechanic. It just seems like this is so gamey and not at all representative of the real world. I think I would be a lot more okay with hits putting a robot off balance though.
After all - Power LEDs are required in real life robots, so might as well use this to our advantage.
And if not self restoring I like the idea of slowing down an opponent. That could also play into our previously mentioned idea about instead of just eliminating a robot on instant knockout, doing a 10 second count down. In real life competitions once a robot has been immobilised they still count it down rather than just going 'Oh your bot aint moving it's out'. Then players can dance around the arena for a bit, ect. lol. Maybe with this in mind we could make robot's less responsive as well as gradually slowing down? Twitching motors, one drive motor slower than the others, ect. ect.
Visual deformation looks terrible right now. It would take a lot of work to make it subtle and probably only mediocre looking. Not worth the time, IMO.
An LED system could work. Maybe that is enough? I’m not so keen on a “self healing” mechanic. It just seems like this is so gamey and not at all representative of the real world. I think I would be a lot more okay with hits putting a robot off balance though.
After all - Power LEDs are required in real life robots, so might as well use this to our advantage.
And if not self restoring I like the idea of slowing down an opponent. That could also play into our previously mentioned idea about instead of just eliminating a robot on instant knockout, doing a 10 second count down. In real life competitions once a robot has been immobilised they still count it down rather than just going 'Oh your bot aint moving it's out'. Then players can dance around the arena for a bit, ect. lol. Maybe with this in mind we could make robot's less responsive as well as gradually slowing down? Twitching motors, one drive motor slower than the others, ect. ect.
There is some precendent for slowing down an opponent. Wheel guards are notorious for this when they get bashed in. Wheels get stuck or they move really slowly.
I like it.
Thanks, haha. I would also say about some sort of particle effect coming from damaged motors but in reality I'm fairly sure they don't do this - all the smoke, ect, that comes from damaged components comes from things like the batteries. Another thing to consider?
Ooo... How about spinners get wobbly once they lose half their health? It would throw off the driving of the robot, and it might be worth it to just spin up if you really needed to.
Thanks, haha. I would also say about some sort of particle effect coming from damaged motors but in reality I'm fairly sure they don't do this - all the smoke, ect, that comes from damaged components comes from things like the batteries. Another thing to consider?
Yes to particle effects!!!
I don't care if it isn't strictly realistic. More player feedback = better.
I assume like in ra2 when a bot loses its toothOoo... How about spinners get wobbly once they lose half their health? It would throw off the driving of the robot, and it might be worth it to just spin up if you really needed to.
How do you mean? Like they vibrate on the axle rather than detach??
I assume like in ra2 when a bot loses its toothOoo... How about spinners get wobbly once they lose half their health? It would throw off the driving of the robot, and it might be worth it to just spin up if you really needed to.
How do you mean? Like they vibrate on the axle rather than detach??
Ooo... How about spinners get wobbly once they lose half their health? It would throw off the driving of the robot, and it might be worth it to just spin up if you really needed to.
How do you mean? Like they vibrate on the axle rather than detach??
Ooo... How about spinners get wobbly once they lose half their health? It would throw off the driving of the robot, and it might be worth it to just spin up if you really needed to.
How do you mean? Like they vibrate on the axle rather than detach??
Rotate all of the components 5 degrees off axis, and shift the COM by 1 centimeter for a heavyweight (less for beetleweights). This should give a really annoying wobble.
Ooo... How about spinners get wobbly once they lose half their health? It would throw off the driving of the robot, and it might be worth it to just spin up if you really needed to.
How do you mean? Like they vibrate on the axle rather than detach??
Rotate all of the components 5 degrees off axis, and shift the COM by 1 centimeter for a heavyweight (less for beetleweights). This should give a really annoying wobble.
Oh!!! So not enough to throw the robot around but just enough to vibrate it? Throw the driving off, ect.? I like it.
Whether the script can calculate the amount of throw-off by the size of the bounding box of the spinner?
Ok off this topic: I have a possible idea:
Burst pistons that you have could be resizable. Smaller the piston is, less co2/hydraulics/nitrogen can enter the piston, thus less pressure and less powerful flippers. Maybe split between vertical scaling and horizontal scaling? So we can make short but wide bursts, or tall and slim ones
Spinner wobble is working now. As the spinner gets more and more damaged, it wobbles more and more. This makes driving more difficult.
Also, @tashic found and fixed the bug with the A40-300 (New) motor. Go tashic!
New build coming soon...
Spinner wobble is working now. As the spinner gets more and more damaged, it wobbles more and more. This makes driving more difficult.
Also, @tashic found and fixed the bug with the A40-300 (New) motor. Go tashic!
New build coming soon...
Love to hear that, might use this latest version for robogames if the damage isnt busted :)
A question for future release? Are we gonna get more compact batteries? Atm most batts are oversized
I reduced damage by quite a bit. Spinners take a lot longer to come off, and they start working annoyingly before they do. I still want to do another round of testing before I put the build out though.Need a tester? ;)
I reduced damage by quite a bit. Spinners take a lot longer to come off, and they start working annoyingly before they do. I still want to do another round of testing before I put the build out though.Need a tester? ;)
I can test tooI reduced damage by quite a bit. Spinners take a lot longer to come off, and they start working annoyingly before they do. I still want to do another round of testing before I put the build out though.Need a tester? ;)
Well I’m free at 8 so I can give you a quick response.I reduced damage by quite a bit. Spinners take a lot longer to come off, and they start working annoyingly before they do. I still want to do another round of testing before I put the build out though.Need a tester? ;)
Bleeding Edge Build?
Adding on to what Min and Code were saying, most spinners have drastically increased in power.I mean, you are using a HW brushless motor on a lw
[ This attachment cannot be displayed inline in 'Print Page' view ]
My lightweight breaks the scales with how much energy it holds
[ This attachment cannot be displayed inline in 'Print Page' view ]
That’s true, but it was working at realistic speeds and energy in the February 16th build.Adding on to what Min and Code were saying, most spinners have drastically increased in power.I mean, you are using a HW brushless motor on a lw
[ This attachment cannot be displayed inline in 'Print Page' view ]
My lightweight breaks the scales with how much energy it holds
[ This attachment cannot be displayed inline in 'Print Page' view ]
Will give the new build a go now that im awake
Lots of great feedback here. You guys found bugs WAY faster than I would have. Thank you!Ya it can be fixed by moving them to right position.
For this build I disabled collisions with the all of the colliders that made up the part and am relying entirely on the (now invisible, but still there) blur cylinder and my custom-written collision handler. This is the cause of spinners being inside of other things weirdly. I had hoped I had solved all of the edge cases to this, but apparently I haven't. Thank you for finding them! :)
Aluminum density = 2760 kg / m^3
Steel density = 7861 kg / m^3
Steel is about 3 x the weight for the same thickness. I'm pretty sure Wham intends to go back and tweak things.
In previous builds, the F30-400's origin was set on the side of the motor. This needed to be reset to the center of the motor. This does shift the motor down.
min440303, please let me know if this isn't fixable by shifting the motor back up and the wheels back down.
I will take a look at energies again. I did a LOT of fiddling with physics in the past few days. Eventually I reset the massScaleFactor back to 0.1, but this involved adjusting a lot of other things as well that were dependent upon it. Also, the brushless motor spinner model doesn't exist yet, and I haven't checked the torque and speed numbers for the 3" brushless motor to verify that they are realistic.
Hobo Droo, I'm having trouble with the video. Would you mind sending the .RR2Bot file with the million Joule spinner?
CodeSilver, would you mind sending me the lightweight that launches the box through the ceiling and phases itself into the floor?
3" brushless is good, with LW, HW and HW are all being extremely more powerful, and at least in Feb 16 brushless is doing well in all weight class. So it should have nothing to do with the brushless motor.
Actually almost all spinners have a chance to phase themselves into the floor, maybe it's just because the spinner is too powerful and push itself into the floor by the reacting force while hitting the crate.
[ This attachment cannot be displayed inline in 'Print Page' view ]
In order to solve the phasing problem I'm pretty sure I'm going to have to reenable collisions on the spinner part colliders. One day I hope to make a proper single compound collider out of all of them. The tradeoff is that it will increase the physics load having all of those spinning colliders.We never had any issues with old colliders
I have a little request, could we bring back the ready button for the test arena? Cuz I ehhhh, used to take pics for bots using free cam at the freezing time before starting the battle.I second this.
Here's the file of the million joule lightweight:
[ This attachment cannot be displayed inline in 'Print Page' view ]
mmm but the real Poison Arrow just uses brushless for its drum and spins up to 9000rpm within 10 seconds. Isn't having more small but powerful spinner bots the initial purpose of creating brushless? Its stats in Feb 16th are to the right point. It's better than ampflows, and weaker than eteks.Here's the file of the million joule lightweight:
[ This attachment cannot be displayed inline in 'Print Page' view ]
Thanks for this!
With the proper numbers for the 3" brushless motor the robot becomes a lot less usable. 2/3 of its weight is in the weapon, and the weapon spins up really slowly, taking about 10 seconds to get to 3000 RPM. It maxes out at 300,000 Joules, but in combat it is typically hitting with about 100,000 Joules because of the long spin-up time.
I need to do some hand-calculations to estimate the moment of inertia, but I suspect it is a little off.
EDIT - I did the calculations. The MOI is off by a factor of 10x or so. Spinup time is much too short in the game. Correcting the MOI will drop the energy way down. This 0.5 meter diameter x 13 mm thick steel spinner should have an MOI of approximately 0.7 kg * m^2 and a peak KE of approximately 60,000 Joules. It should only be at a few hundred joules and a few hundred RPM after 3 seconds, taking about 150 seconds to get to top speed. It should be completely useless as a weapon in robot combat.
Yay! More realistic! I can’t wait to build something with a brushless!Here's the file of the million joule lightweight:
Thanks for this!
With the proper numbers for the 3" brushless motor the robot becomes a lot less usable. 2/3 of its weight is in the weapon, and the weapon spins up really slowly, taking about 10 seconds to get to 3000 RPM. It maxes out at 300,000 Joules, but in combat it is typically hitting with about 100,000 Joules because of the long spin-up time.
I need to do some hand-calculations to estimate the moment of inertia, but I suspect it is a little off.
EDIT - I did the calculations. The MOI is off by a factor of 10x or so. Spinup time is much too short in the game. Correcting the MOI will drop the energy way down. This 0.5 meter diameter x 13 mm thick steel spinner should have an MOI of approximately 0.7 kg * m^2 and a peak KE of approximately 60,000 Joules. It should only be at a few hundred joules and a few hundred RPM after 3 seconds, taking about 150 seconds to get to top speed. It should be completely useless as a weapon in robot combat.
You'll build nothing with this brushless.Yay! More realistic! I can’t wait to build something with a brushless!Here's the file of the million joule lightweight:
Thanks for this!
With the proper numbers for the 3" brushless motor the robot becomes a lot less usable. 2/3 of its weight is in the weapon, and the weapon spins up really slowly, taking about 10 seconds to get to 3000 RPM. It maxes out at 300,000 Joules, but in combat it is typically hitting with about 100,000 Joules because of the long spin-up time.
I need to do some hand-calculations to estimate the moment of inertia, but I suspect it is a little off.
EDIT - I did the calculations. The MOI is off by a factor of 10x or so. Spinup time is much too short in the game. Correcting the MOI will drop the energy way down. This 0.5 meter diameter x 13 mm thick steel spinner should have an MOI of approximately 0.7 kg * m^2 and a peak KE of approximately 60,000 Joules. It should only be at a few hundred joules and a few hundred RPM after 3 seconds, taking about 150 seconds to get to top speed. It should be completely useless as a weapon in robot combat.
I’ll see...You'll build nothing with this brushless.Yay! More realistic! I can’t wait to build something with a brushless!Here's the file of the million joule lightweight:
Thanks for this!
With the proper numbers for the 3" brushless motor the robot becomes a lot less usable. 2/3 of its weight is in the weapon, and the weapon spins up really slowly, taking about 10 seconds to get to 3000 RPM. It maxes out at 300,000 Joules, but in combat it is typically hitting with about 100,000 Joules because of the long spin-up time.
I need to do some hand-calculations to estimate the moment of inertia, but I suspect it is a little off.
EDIT - I did the calculations. The MOI is off by a factor of 10x or so. Spinup time is much too short in the game. Correcting the MOI will drop the energy way down. This 0.5 meter diameter x 13 mm thick steel spinner should have an MOI of approximately 0.7 kg * m^2 and a peak KE of approximately 60,000 Joules. It should only be at a few hundred joules and a few hundred RPM after 3 seconds, taking about 150 seconds to get to top speed. It should be completely useless as a weapon in robot combat.
You did not read did you, those brushless will be 10 times weaker than they were in feb 16 version.I’ll see...You'll build nothing with this brushless.Yay! More realistic! I can’t wait to build something with a brushless!Here's the file of the million joule lightweight:
Thanks for this!
With the proper numbers for the 3" brushless motor the robot becomes a lot less usable. 2/3 of its weight is in the weapon, and the weapon spins up really slowly, taking about 10 seconds to get to 3000 RPM. It maxes out at 300,000 Joules, but in combat it is typically hitting with about 100,000 Joules because of the long spin-up time.
I need to do some hand-calculations to estimate the moment of inertia, but I suspect it is a little off.
EDIT - I did the calculations. The MOI is off by a factor of 10x or so. Spinup time is much too short in the game. Correcting the MOI will drop the energy way down. This 0.5 meter diameter x 13 mm thick steel spinner should have an MOI of approximately 0.7 kg * m^2 and a peak KE of approximately 60,000 Joules. It should only be at a few hundred joules and a few hundred RPM after 3 seconds, taking about 150 seconds to get to top speed. It should be completely useless as a weapon in robot combat.
I haven’t used them yet.You did not read did you, those brushless will be 10 times weaker than they were in feb 16 version.I’ll see...You'll build nothing with this brushless.Yay! More realistic! I can’t wait to build something with a brushless!Here's the file of the million joule lightweight:
Thanks for this!
With the proper numbers for the 3" brushless motor the robot becomes a lot less usable. 2/3 of its weight is in the weapon, and the weapon spins up really slowly, taking about 10 seconds to get to 3000 RPM. It maxes out at 300,000 Joules, but in combat it is typically hitting with about 100,000 Joules because of the long spin-up time.
I need to do some hand-calculations to estimate the moment of inertia, but I suspect it is a little off.
EDIT - I did the calculations. The MOI is off by a factor of 10x or so. Spinup time is much too short in the game. Correcting the MOI will drop the energy way down. This 0.5 meter diameter x 13 mm thick steel spinner should have an MOI of approximately 0.7 kg * m^2 and a peak KE of approximately 60,000 Joules. It should only be at a few hundred joules and a few hundred RPM after 3 seconds, taking about 150 seconds to get to top speed. It should be completely useless as a weapon in robot combat.
I haven’t used them yet.A quick sum up:
Ahh... I see. Brushless motors will be crappy.I haven’t used them yet.A quick sum up:
Feb 16, we got brushless, they were great, however the torque could be lowered
Feb 28th brushless got a weird buff that made them more than op
Next update would nerf the brushless to the ground to the point where normal brushed motors would work better as a motor for spinning weapons
The 3” brushless will be in the same ballpark as an AmpFlow A28-150. Not useless by any stretch, and completely appropriate for drive once they are geared down. It would be an absolutely killer motor for a featherweight. It has the highest power to weight ratio of any motor in the game.We need a six inch brushless.
The 3” brushless will be in the same ballpark as an AmpFlow A28-150. Not useless by any stretch, and completely appropriate for drive once they are geared down. It would be an absolutely killer motor for a featherweight. It has the highest power to weight ratio of any motor in the game.However it will be total trash for HW bots which is not really great as most people make HW bots
The 3” brushless will be in the same ballpark as an AmpFlow A28-150. Not useless by any stretch, and completely appropriate for drive once they are geared down. It would be an absolutely killer motor for a featherweight. It has the highest power to weight ratio of any motor in the game.We need a six inch brushless.
And there goes the compactness of a brushlessThe 3” brushless will be in the same ballpark as an AmpFlow A28-150. Not useless by any stretch, and completely appropriate for drive once they are geared down. It would be an absolutely killer motor for a featherweight. It has the highest power to weight ratio of any motor in the game.We need a six inch brushless.
I agree that we need some bigger brushless motors for heavyweight weapons. Let me talk to Wham to see what we can come up with.
And there goes the compactness of a brushlessThe 3” brushless will be in the same ballpark as an AmpFlow A28-150. Not useless by any stretch, and completely appropriate for drive once they are geared down. It would be an absolutely killer motor for a featherweight. It has the highest power to weight ratio of any motor in the game.We need a six inch brushless.
I agree that we need some bigger brushless motors for heavyweight weapons. Let me talk to Wham to see what we can come up with.
Would there be an AI pack released for these Battlebots (in RR2)?
Tbh id first fix the fundimental issues that we are having rn before you add more stuff into the game, id say as of now, keep the feb 16 brushless, and fix the weapon phasing issue, and we would have a solid build that would be great base for tournaments and other stuff
Tbh id first fix the fundimental issues that we are having rn before you add more stuff into the game, id say as of now, keep the feb 16 brushless, and fix the weapon phasing issue, and we would have a solid build that would be great base for tournaments and other stuffI gotta agree with this. At least for now. I’m just wanting to get started on filming for SvL, and I’m not sure if I can get the free cam for the arena to be compatible with Feb 16.
The goal of all of this is that you guys won't have to do a motor swap from your February 16th build, but the motor itself will be larger.This can be a solution. Btw when will the bot scaling tool be out? Cuz we may need to upscale our bots to fit the bigger mesh of brushless.
But, does that mean that all these bots from 'Battlebots' I can find and if so, what codes do they need?Would there be an AI pack released for these Battlebots (in RR2)?
My intent is to have AI programming be part of the in-game experience. You can go with the default AI, or modify the code using the in-game editor.
Please note that once we get the physics, damage, and weapon systems worked out over the next few months, I intend to go back and rewrite AI with all of the new inputs.
I expect that lots of people will be posting AI code here on GTM that people will be able to copy-paste into the game for their robots.
But, does that mean that all these bots from 'Battlebots' I can find and if so, what codes do they need?Would there be an AI pack released for these Battlebots (in RR2)?
My intent is to have AI programming be part of the in-game experience. You can go with the default AI, or modify the code using the in-game editor.
Please note that once we get the physics, damage, and weapon systems worked out over the next few months, I intend to go back and rewrite AI with all of the new inputs.
I expect that lots of people will be posting AI code here on GTM that people will be able to copy-paste into the game for their robots.
The goal of all of this is that you guys won't have to do a motor swap from your February 16th build, but the motor itself will be larger.This can be a solution. Btw when will the bot scaling tool be out? Cuz we may need to upscale our bots to fit the bigger mesh of brushless.
Ok that seems like a good thing, it is a nice middleground between a brushed A40 and an ETEK. I just hope it doesnt have a negative impactThe goal of all of this is that you guys won't have to do a motor swap from your February 16th build, but the motor itself will be larger.This can be a solution. Btw when will the bot scaling tool be out? Cuz we may need to upscale our bots to fit the bigger mesh of brushless.
min440303,
I'm going to use Lotus's spinner in conjunction with a TP Power TP100 brushless motor (the same motors used in a lot of heavyweights) to calibrate the new MOI and KE computations.
There is a great online calculator that shows the basic computation at http://runamok.tech/RunAmok/spincalc.html (http://runamok.tech/RunAmok/spincalc.html). Here's what I'm shooting for:
[ This attachment cannot be displayed inline in 'Print Page' view ]
We are replacing the 3" Brushless Motor with the TP100. The TP100 is about 4" diameter x 4" length.Okay that's cool enough.
Once it is geared down it should have higher top-end power than an AmpFlow A40-300 or an NPC T64, in about half the size and weight. It won't be usable for drive unless you gear it down first.
But, does that mean that all these bots from 'Battlebots' I can find and if so, what codes do they need?Would there be an AI pack released for these Battlebots (in RR2)?
My intent is to have AI programming be part of the in-game experience. You can go with the default AI, or modify the code using the in-game editor.
Please note that once we get the physics, damage, and weapon systems worked out over the next few months, I intend to go back and rewrite AI with all of the new inputs.
I expect that lots of people will be posting AI code here on GTM that people will be able to copy-paste into the game for their robots.
Apart from those issues above, I'll talk about something that I think is really important and some own issues.
All motors spins up really slow, especially at the beginning, both brushed and brushless act like that, examples like Rainbow Circus with etek, or Aftershock with brushless I've posted before, the energy stacks in 10 joules from start, we can even see how slow a spinner is rotating.
And as a result, spinners barely have pushing power(except the crate in test cage) and all the vertical spinners lose their ability to self-right automatically, for motors having far less torque.
Here's a strange personal issue. My flipper Equator uses F30 for drive, but it has become extremely slow in this build. Other bots with A40 or F30 drive well as before(the position of old F30 still not right tho), only this one is having some problem.
Mar 04
https://youtu.be/gvSQTDfeLrg
Mar 09
https://youtu.be/_Z1hNQgxBj4
Circus
https://youtu.be/XBVwjVIDWoI
Aftershock
https://youtu.be/52aqk-Krfrw
[ This attachment cannot be displayed inline in 'Print Page' view ] [ This attachment cannot be displayed inline in 'Print Page' view ]
I feel like you have not listened to me at all and instead of fixing the current issues, you have just added stuff to game.
Ive tested the game pre work (and im typing this on a bus actually)
I feel like you have not listened to me at all and instead of fixing the current issues, you have just added stuff to game.
Follow up of some sorts, to say what is good and what is bad.
Well the spinup time is slower which is technically more realistic on small diameter spinners, but the larger it is, the slower it gets, or in hobo's case that is just the motor.
The brushless has no torque whatsoever on 10:0.1 gearing and opposite, its not usable for drive at all.
Flippers dont flip, it seems like the axle doesnt move at all.
When a vertical spinner hits the floor it loses all of its torque, thus making it impossible to selfright
I’d recommend changing 1 thing at a time. If you don’t like the physics, only work on that for the next build. If you want new parts, work on those in a different build. When you put a sh** ton of stuff into one build, the game becomes pretty much unplayable, or at least has some frustrating glitches. I understand that you want to develop the game as much as possible, but at least make sure that you’re posting stable builds on itch.io. Anything untested should be bleeding edge.
Roger.Pretty much
Either physics changes or content changes, but not both.
The problem is that sometimes new content brings new physics. This is the case with brushless motors. It will also be the case with batteries, pneumatics, etc.
The best solution is going to probably involve lots of very small bleeding edge builds.
Would it be possible to go back to the Feb 16 build and then work from that? It might be easier, considering the current build has so many issues. Also, if you’re planning on doing super small bleeding edge builds, maybe take Kix’s idea and get a small team of private testers to help.
Honestly there arent many issues to be fixed at all, its just that the few issues are pretty large ones and will need some rework.Would it be possible to go back to the Feb 16 build and then work from that? It might be easier, considering the current build has so many issues. Also, if you’re planning on doing super small bleeding edge builds, maybe take Kix’s idea and get a small team of private testers to help.
Scrapping the thousands of small changes we have made since February 16th isn't something I'm comfortable with.
I think the better course of action is to very clearly define what we don't like about the current state. I suspect that there are probably less than 10 things that need to be addressed. Fix them. Move on.
I put in a "flip robot" button for the Robot Workshop test cage. It should help when we want to test self-righting systems.Aftershock is not capable of self righting from a cold start. However once it hits the floor it fully stops. Its like the disc has no mass
In particular, I have been testing it out with min's Aftershock rep with the TP100 motor. I have found that Aftershock is not capable of self-righting unless the weapon is already spinning when it flips over.
Does anyone know if this is accurate to the real robot? Can Aftershock self-right from a cold start?
I put in a "flip robot" button for the Robot Workshop test cage. It should help when we want to test self-righting systems.Aftershock is not capable of self righting from a cold start. However once it hits the floor it fully stops. Its like the disc has no mass
In particular, I have been testing it out with min's Aftershock rep with the TP100 motor. I have found that Aftershock is not capable of self-righting unless the weapon is already spinning when it flips over.
Does anyone know if this is accurate to the real robot? Can Aftershock self-right from a cold start?
Seeing that vid, i think that there is prolly 250-500rpm loss.I put in a "flip robot" button for the Robot Workshop test cage. It should help when we want to test self-righting systems.Aftershock is not capable of self righting from a cold start. However once it hits the floor it fully stops. Its like the disc has no mass
In particular, I have been testing it out with min's Aftershock rep with the TP100 motor. I have found that Aftershock is not capable of self-righting unless the weapon is already spinning when it flips over.
Does anyone know if this is accurate to the real robot? Can Aftershock self-right from a cold start?
My hand calculations indicate that Aftershock's motor should need about 10x more torque than the TP100 is capable of producing to self-right from a cold start. This matches what I see in the game.
My hand calculations also indicate that if Aftershock has enough angular momentum (about 200 kg * m^2 / s^2) it should be able to bounce once to a height of 15 cm, then bounce again and flip itself over. In the fight between Aftershock and Eruption, Aftershock used tiny little hits to get itself back upright again:
https://www.youtube.com/watch?v=EqEqp6czDAk (https://www.youtube.com/watch?v=EqEqp6czDAk)
The fight starts around 28:00.
I think kix is correct. It isn't a matter of increasing the motor torque. Rather, the correct approach looks to be not completely killing the rotation on each hit, even on the so-called "good hits". There is too much blur in the video to measure precisely how much speed is lost, but I might be able to figure it out based on how high Aftershock hops when its spinner hits the ground at 28:05.
Building with a few changes now. I'm going to try to get a bleeding edge build out tonight with the following changes:
[Changed] Increased default torque and RPM numbers for the A28-150 to match the values for 24 volts. They were previously set for 12 volts.
[Changed] Reduced spinner wobble by setting the max COM offset to 10% of radius. Previously it was set to 20% of radius.
[Changed] Less spinner speed is lost on impact. Instead of a "good hit" causing all KE to be lost, only a fraction of it is lost. This fraction depends on how far the spinner overlaps the floor or other robot. If it overlaps by half of the spinner's radius, then all energy is lost. Otherwise, only some speed is lost.
[Added] Added a "Flip Robot" button in the Robot Workshop Test Cage. This helps to simulate being launched by a flipper and for testing self-righting mechanisms.
Not yet. It’s on the list though. Maybe tomorrow if you like what you see in this one?Hmmm interesting
We cannot unzip the file
The scaling stuff is awesome! It will save tons of efforts to do some resizing stuff. Really appreciate it! Also, some issues that still might need to be done:
-Flippers don't work
-Old F30s' moving downward
-Looks like spinner wobbling makes the bot drive much slower, when Aftershock's spinner took certain damage, the bot just couldn't move even when the weapon motor was off.
-Motor's starting torque are still really bad, thus lifters, crushers, saws and hammers are useless. And spinners spins up extremely slow at the start no matter how it's geared.
-Spinners easily lose all its speed before delivering a hit.
-Equator's driving issue with F30s
You mean LEM170 is the same size as Pancake Etek? That means my Aftershock rep is incredibly small to fit this motor...
PS - I'm still working out the numbers on some of the newer motors. In real life, Aftershock uses an LEM170. It is a 7" diameter motor slightly smaller than an Etek, but quite a bit larger than the 4" brushless in the Aftershock rep. For now, the "Pancake Etek" is the closest thing in game to an LEM170.
You mean LEM170 is the same size as Pancake Etek? That means my Aftershock rep is incredibly small to fit this motor...
PS - I'm still working out the numbers on some of the newer motors. In real life, Aftershock uses an LEM170. It is a 7" diameter motor slightly smaller than an Etek, but quite a bit larger than the 4" brushless in the Aftershock rep. For now, the "Pancake Etek" is the closest thing in game to an LEM170.
I have extrapolated the torque-speed curves out at 48 volts. It looks like we are going to run into a few interesting effects/issues:Whats an IRL example of 8.5 Nm?
1. The AmpFlow A40-300 is only rated to 24 volts. Unless we can figure out how to do separate batteries for drive (24 volts) and weapons (48 volts), the A40-300 won't be an option for robots wanting a higher voltage for their weapons. We don't have any brushed drive motors in the game that can operate at 48 volts. I believe a lot of the heavyweight robot builders are running into this problem as well.
2. The ME0708 (or any of the really big motors) will exceed the current capacity of the available ESCs at 48 volts. This means we will need to put on-off solenoids into the game for the really big motors. They will only be controllable by an on-off toggle switch at 48 volts, and won't be reversible.
3. At 48 volts, the brushless motor is current-limited for most of its operating range. This means it will provide the same 8.5 Nm of torque all the way up to 20,000 RPM. A solenoid-operated ME0708 will provide 70 Nm of torque at the start, but will really rapidly drop off.
[ This attachment cannot be displayed inline in 'Print Page' view ]
I have extrapolated the torque-speed curves out at 48 volts. It looks like we are going to run into a few interesting effects/issues:Whats an IRL example of 8.5 Nm?
3. At 48 volts, the brushless motor is current-limited for most of its operating range. This means it will provide the same 8.5 Nm of torque all the way up to 20,000 RPM. A solenoid-operated ME0708 will provide 70 Nm of torque at the start, but will really rapidly drop off.
Maybe for the crude voltage system? Where you can just set the voltage in electronics section. Or differently, atm receivers have set voltage to them? Atm its not realistic at all, but again, until the real system is out it could work temporarilyWhat you could do is add a tab for voltage. In the tab, you would select the battery, set its voltage, and then select the motors it powers.
I have other game related ideas for you that is game related
Robogames and BattleBots both have a 48 volt limit. Robot Wars has a 75 volt limit. I'm not sure what our limit is going to be.
Ok so wheelfix kind of has a purpose again, as It is able to nerf a lot of the damage.
Ok so wheelfix kind of has a purpose again, as It is able to nerf a lot of the damage.Or... you could change the damage multiplier
Please don’t “fix” this just yet. At least not until the damage is fixed.Ok so wheelfix kind of has a purpose again, as It is able to nerf a lot of the damage.
Hmmm... Wheelfixing shouldn't be a thing anymore. How does it work?
Need to fix this...
Ok so the weapon wobble works... Not too great. I feel like wobble shoudnt appear if youre bot is the one that is dealing the damage to the opponent. It should only appear if you are hitting the floor at high speed or if your spinner is receiving high ammount of damage on the disc itself. Also This bot tends to lose the weapon while hitting the floor at high speed.
Please don’t “fix” this just yet. At least not until the damage is fixed.Ok so wheelfix kind of has a purpose again, as It is able to nerf a lot of the damage.
Hmmm... Wheelfixing shouldn't be a thing anymore. How does it work?
Need to fix this...
Ok so the weapon wobble works... Not too great. I feel like wobble shoudnt appear if youre bot is the one that is dealing the damage to the opponent. It should only appear if you are hitting the floor at high speed or if your spinner is receiving high ammount of damage on the disc itself. Also This bot tends to lose the weapon while hitting the floor at high speed.
I think you might be right. If a spinner hits an opponent, it has presumably been engineered to take the shock load. I will try reducing/eliminating the damage that occurs to self.
I have to use both the wheelfix AND 50% damage for matches to be at least somewhat good.Ok so wheelfix kind of has a purpose again, as It is able to nerf a lot of the damage.Or... you could change the damage multiplier
How low are you guys setting the damage slider? CodeSilver says 50%.
That will give me a number to work from.
How low are you guys setting the damage slider? CodeSilver says 50%.
That will give me a number to work from.
Hey guys,
We got hit with coronavirus here. I will still be checking in periodically but development might be slow for a bit.
Hey guys,Stay safe. Hope you guys get through this tough time.
We got hit with coronavirus here. I will still be checking in periodically but development might be slow for a bit.
Hey guys,Best to take it easy man. Health is more important.
We got hit with coronavirus here. I will still be checking in periodically but development might be slow for a bit.
I'm using 75% in Feb 16th, but have no idea how low in recent builds cuz the damage is kinda weird.
Also for the new bleeding edge, the motors don't work right.
ME0708 is like this
[ This attachment cannot be displayed inline in 'Print Page' view ]
And pancake-etek spins up even much slower than TP100 brushless (spinner 1 is brushless, and spinner 2 is PE)
[ This attachment cannot be displayed inline in 'Print Page' view ]
huh seems like changing gear ratio doesnt change the torque of anything. Atm TerrorHurtz on the latest version cant swing its axe. Its gear ratio is 10:1 and the axe hits 2 rpm, and doesnt lift at all. This took me awhile to figure out
No, no im actually using a A40 motor for the axe, i limited it to have only 400rpm. In Feb 16 build it works just fine, in current one the torque is non existanthuh seems like changing gear ratio doesnt change the torque of anything. Atm TerrorHurtz on the latest version cant swing its axe. Its gear ratio is 10:1 and the axe hits 2 rpm, and doesnt lift at all. This took me awhile to figure out
What does it list as the max RPM? I accidentally typed in 18 RPM instead of 1800 for the pancake Etek.
No, no im actually using a A40 motor for the axe, i limited it to have only 400rpm. In Feb 16 build it works just fine, in current one the torque is non existanthuh seems like changing gear ratio doesnt change the torque of anything. Atm TerrorHurtz on the latest version cant swing its axe. Its gear ratio is 10:1 and the axe hits 2 rpm, and doesnt lift at all. This took me awhile to figure out
What does it list as the max RPM? I accidentally typed in 18 RPM instead of 1800 for the pancake Etek.
On a 10:1 ratio it cant even swing. Maybe a dedicated axe motor that has high torque like beta used? (well beta used an etek that was geared), the burst motors launch bots up in the airNo, no im actually using a A40 motor for the axe, i limited it to have only 400rpm. In Feb 16 build it works just fine, in current one the torque is non existanthuh seems like changing gear ratio doesnt change the torque of anything. Atm TerrorHurtz on the latest version cant swing its axe. Its gear ratio is 10:1 and the axe hits 2 rpm, and doesnt lift at all. This took me awhile to figure out
What does it list as the max RPM? I accidentally typed in 18 RPM instead of 1800 for the pancake Etek.
I’m not sure an A40-300 has the torque to do an axe at its limit of 24 Volts unless the axe is really light. I would need to do some calculations. It maxes out at 27 Newton-meters. At a 10:1 gear ratio that is 270 Newtons at one meter. For a 1kg axe, that gives a max acceleration of 27 g’s, but only briefly. Its top speed would be around 21 meters per second. It should take about 1/10th of a second to swing down. For a 10 kg axe, it would take much longer to swing. Maybe more than half a second?
Much slower than this and something is wrong...
On a 10:1 ratio it cant even swing. Maybe a dedicated axe motor that has high torque like beta used? (well beta used an etek that was geared), the burst motors launch bots up in the airNo, no im actually using a A40 motor for the axe, i limited it to have only 400rpm. In Feb 16 build it works just fine, in current one the torque is non existanthuh seems like changing gear ratio doesnt change the torque of anything. Atm TerrorHurtz on the latest version cant swing its axe. Its gear ratio is 10:1 and the axe hits 2 rpm, and doesnt lift at all. This took me awhile to figure out
What does it list as the max RPM? I accidentally typed in 18 RPM instead of 1800 for the pancake Etek.
I’m not sure an A40-300 has the torque to do an axe at its limit of 24 Volts unless the axe is really light. I would need to do some calculations. It maxes out at 27 Newton-meters. At a 10:1 gear ratio that is 270 Newtons at one meter. For a 1kg axe, that gives a max acceleration of 27 g’s, but only briefly. Its top speed would be around 21 meters per second. It should take about 1/10th of a second to swing down. For a 10 kg axe, it would take much longer to swing. Maybe more than half a second?
Much slower than this and something is wrong...
Oh! I forgot to ask: what is the mass of the axe?Mass of the axe is 6 kilos, Pancake etek is too big to fit it in. Im pretty sure something is off with the gearing torque tho
Even tho i am not an electrician, this seems pretty straightforward so im keeping forward to it!
To the developer: I've got a quick question. Is it possible to import 3D models into Robot Rumble 2.0?
Thanks for letting me know! Cheers cjbruce :)
you guys kick ass. if the pneumatics revamp is anything like this i'm sure you'll knock it out of the park. keep up the good work!
also mark joerger won robotica with a stripped out lawnmower and then proceeded to suck sh** at robot wars with said lawnmower. he also spends his free time complaining about modern combat robotics on facebook. not saying his info isn't valid, just that there's likely better sources than him for modern robot info
22-May is missing for windows btw.
EDIT: it is mislabeled as 02-May
ALL MOTORS MUST BE GEARED DOWN.
period. full stop. This is true for building in real-life too.
ALL MOTORS MUST BE GEARED DOWN.
period. full stop. This is true for building in real-life too.
a certain gareth barnaby would argue otherwise
yeah i know i'm just messing around with you. all his beetles/feathers including our new joint feather are all direct drive brushless, but for game purposes i think this is the right way to go about things :)
yeah i know i'm just messing around with you. all his beetles/feathers including our new joint feather are all direct drive brushless, but for game purposes i think this is the right way to go about things :)
Another issue is, 2WD vertical spinners could barely turn, it's like something's stuck with the floor and make it hard to drive.
[ This attachment cannot be displayed inline in 'Print Page' view ]
bots here.
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
Edit: Like what kix said, the spinner bite is supposed to be an issue. Especially disc spinners act like there was no teeth on it.
The new build is really great and the electronic system is awesome, the hits inside the fights are back to the right position as well. But there're some issues for driving in this build.
For 4WD vertical spinners, when the weapon motor is off, the bot works fine and turns fine, but when the weapom motor's on, the bot could only run in circles instead of turning.
[ This attachment cannot be displayed inline in 'Print Page' view ]
And for 4WD horizontal spinners, it goes to the opposite, run in circles when the weapon motor's off, and turns fine when the weapon motor's on.
Here are the bots.
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
After a few tests, I suspect Aftershock's turning issue was not cause by gyroing. I've test some more vertical spinners inside the test cage, and found issues like:
Aftershock's turning issue happened not only when the weapon was on, but also when it was off.
Magnetar's was quite fast at first, but you could actually see it moving more and more slowly.
When Poison Arrow was going to turn, something in the air blocked it from turning.
(All issues above happened when weapon motor's off)
And as you said: There's much more gyro in this build, but I think it's a bit too significant. you can see it on Poison Arrow. It just start gyroing madly even when the drum is 1000rpm, which is definitely unreal.
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
Tried the build and, its great.
Its a shame that the flippers are gone, but its not an issue
Overheating is great, but imo they overheat too much
A40 motors are overheating when idle if: it is set as servo, and has limited angles
If a battery is not wired to the esc, and if you go to test area, the bot explodes, and when i go back to the lab, parts fall off
The fighting is top notch, the hits are well done, and bots dont self destruct
One thing that is broken is the selfrighting. It is kinda non functional as seen in this vid below:
https://cdn.discordapp.com/attachments/622944371494486016/713436897200046140/2020.05.22-19.02_03.mp4
Also custom arenas are gone, all the AMT made and the game made (Test arena is still selectable)
Fun story about the ampflows. When running-in our A28 motors, brand new, just running for 10 minutes on the bench with no load, they ended up hot enough to burn me.
Hey guys,
With schools shut down due to COVID here in the US, we were just asked if the game could be used in "virtual summer camps" to teach about robotics and to hold virtual robot combat tournaments. How do you guys feel about using the game with a bunch of kids and hosting a tournament via Parsec? I know that we do it here with a bunch of die-hard folks, but is it ready for a bunch of students?
Not sure. It might be for an engineering camp this summer.
Not sure. It might be for an engineering camp this summer.
Oh, i thought it would be sooner, but gladly its not as im busy, and will be for a couple of weeks.
Hosting a tournamet via parsec may or may not be a problem, depending on the ping/input delay, as if i were to host, i would be hosting from EU. I had success hosting to US people so im not that worried.
Might want to use Discord or something alongside Parsec to better communicate with those attending. It also might help to plan everything out like build rules. Make sure bots sent in are actually functional.Not sure. It might be for an engineering camp this summer.
Oh, i thought it would be sooner, but gladly its not as im busy, and will be for a couple of weeks.
Hosting a tournamet via parsec may or may not be a problem, depending on the ping/input delay, as if i were to host, i would be hosting from EU. I had success hosting to US people so im not that worried.
The plan is to run the host on the computer at the college. They have a VR gaming PC and a high-bandwidth connection. Everyone, including the host, would be within the same city. I just wanted to know what sort of issues we are going to have if we start advertising this as a thing that people can do with the game. I would love to open it up to students, but I'm a little scared of the logistics -- parents would be paying money for the experience, and it needs to go well.
Not sure. It might be for an engineering camp this summer.
Oh, i thought it would be sooner, but gladly its not as im busy, and will be for a couple of weeks.
Hosting a tournamet via parsec may or may not be a problem, depending on the ping/input delay, as if i were to host, i would be hosting from EU. I had success hosting to US people so im not that worried.
The plan is to run the host on the computer at the college. They have a VR gaming PC and a high-bandwidth connection. Everyone, including the host, would be within the same city. I just wanted to know what sort of issues we are going to have if we start advertising this as a thing that people can do with the game. I would love to open it up to students, but I'm a little scared of the logistics -- parents would be paying money for the experience, and it needs to go well.
Fun story about the ampflows. When running-in our A28 motors, brand new, just running for 10 minutes on the bench with no load, they ended up hot enough to burn me.
Oof! Are you still using them?
We haven't had any problems, but we are only running the A28-150Gs at 24 volts to push a 60 pound robot.
BTW - The girls team's version of "HUGE" (they called it "Colossus") worked really really well! They did a thwackbot with a crowbar on the end and 22" diameter UHMW wheels. Thank you for your help!
One thing you could think about adding to the game is being able to place one wheel in both ends of a belt or chain system. If I have a motor in the back of the robot for an example, and I'm trying to make a 4 WD, I can't place a wheel in the back because the game won't let me. And another thing, is is possible to use only one battery for all motors in a bot? IRL most robots from lower weight classes are powered by only one battery.
yeah i know i'm just messing around with you. all his beetles/feathers including our new joint feather are all direct drive brushless, but for game purposes i think this is the right way to go about things :)
Speaking of real life, do you have any idea what is happening with Bugglebots this year?
That's awesome! And I think the A28-150G's should work perfect in that size. A few heavyweights even boldly use them. Valkyrie has always just been 2 A28-150 motors, although it's never been tasked with pushing much. Since we used the A28-400G's, we were using the same gearboxes as well, which held up fine for 6 fights at BattleBots and 3 at Robot Ruckus (in thwackbot mode). We won't be using them for 2020 (or 2021... or 2022.......), as we designed in Maytech 8085 Brushless motors. We were swapping the weapon to those motors and decided to change the drive over as well, so that all of the spares can be double-useful.
Min,If I set drive motors to 8 or 12 volts, its turning speed reduced as well as its linear speed, so...actually I didn't feel much difference, just like the entire bot was slower. As the turning speed reduced, surely the gyro was more controllable, but meanwhile it would be much harder to turn, so yeah.
I just had a thought about gyro. If you were driving the real-life Minotaur you wouldn't push the stick all the way left or right if you felt the robot lifting due to gyro. You would back off the stick slightly to try to keep the robot flat. Likewise, you would be continuously adjusting the motor speed so you weren't going full speed all of the time.
If you don't have a game controller with an analog stick at home, you can simulate this input by hooking up the drive motors to 8 or 12 volts.
If you were to try a reduced drive voltage, how does it feel when you are turning with a reduced input signal? Is gyro controllable?
Drums gyro way too much in this game, imo. If you have a standard vert with the same weight (or even more) in its weapon, it doesn't gyro as ludicrous as a drum would. I feel like there's something up with a formula you're using that is causing this.Min,If I set drive motors to 8 or 12 volts, its turning speed reduced as well as its linear speed, so...actually I didn't feel it much different, just like the entire bot was slower. As the turning speed reduced, surely the gyro was more controllable, but meanwhile it would be much harder to turn, so yeah.
I just had a thought about gyro. If you were driving the real-life Minotaur you wouldn't push the stick all the way left or right if you felt the robot lifting due to gyro. You would back off the stick slightly to try to keep the robot flat. Likewise, you would be continuously adjusting the motor speed so you weren't going full speed all of the time.
If you don't have a game controller with an analog stick at home, you can simulate this input by hooking up the drive motors to 8 or 12 volts.
If you were to try a reduced drive voltage, how does it feel when you are turning with a reduced input signal? Is gyro controllable?
I don't know much about physics, but as I saw in real battles, when drums like minotaur started gyroing, they just turn in place for self-righting.
In my cognition, gyro should be like (Feb 16th)
https://youtu.be/OS-U0xKTxTo
not like(May 26th)
https://youtu.be/8qkEl-gE3yM
That's awesome! And I think the A28-150G's should work perfect in that size. A few heavyweights even boldly use them. Valkyrie has always just been 2 A28-150 motors, although it's never been tasked with pushing much. Since we used the A28-400G's, we were using the same gearboxes as well, which held up fine for 6 fights at BattleBots and 3 at Robot Ruckus (in thwackbot mode). We won't be using them for 2020 (or 2021... or 2022.......), as we designed in Maytech 8085 Brushless motors. We were swapping the weapon to those motors and decided to change the drive over as well, so that all of the spares can be double-useful.
Nice! I%u2019m excited to see how you feel about the brushless motors vs the AmpFlows. I felt like I was designing the brushless motor simulation in a vacuum. We don%u2019t use them in real life, and manufactures data is nonexistent. In the end I assumed that torque is limited by current over most of the RPM range. It makes the brushless motors in the game behave like constant torque devices.
1. We are putting the A28-400s in the game for the next build. Would you be willing to build a mock-up of a certain robot in the game to see how it drives? We have Colossus, but I was hoping to build simulations at several different weight classes to see how close we can match the real life robots.
2. Would you mind sharing the ESCs you are using in your brushless setup? Are there any other components we are missing?
re: turning a bot with massive gyro, i rewatched this yesterday and sam really demonstrates how tricky turning something with a massive disc can be, literally just tapping the turn button is about as realistic as it getsVertical disc spinners did have kinda realistic gyro in the new build, but drums didn't. The width of the spinner would massively increase the gyroing of a bot in this game which was unrealistic. You can see in my vids above, Poison Arrow was already gyroing insanely when the drum was only 1000~2000 rpm.
https://www.youtube.com/watch?v=5_FsG9oETiI
Yea it is a thing. When I made E-max (the 4WD drum bot) into a 4WD disc spinner without changing the weapon weight, the turning issue caused by gyro just disappeared.
But I think 2WD verts still have some unsolved problems. Just look at my post above.
Finally gave the build a proper go, and not a fast check.
So about the bite. I feel like there is a delay between a spinner's tooth collides with the opponent, and when the opponent is sent flying
Gyro is ok, not the best, but im sure that it works like that in irl
Ive seen that titanium is added ingame, its all there for placeholder or? Atm It has no sparks unlike real titanium which sparks like crazy (its all about them spark effects that are melting the cpu)
I cant seem to break parts off, i assume damage is off because of the experiments with the spinner bite and gyro
Hmm. I hadn’t thought to put a controllable current limiter into the game. That would probably be helpful. We don’t do it with our own ESCs, and I didn’t realize it was a thing that people do for brushed ESCs.
Right now brushed ESCs are completely unlimited. I ended up artificially reducing the torque for drive motors to dull the initial current (and torque) spike. Drive motors were so torquey initially that the simulation couldn’t keep up and it was causing the lighter robots to jump unrealistically around the arena.
It wouldn’t be difficult to add a current limiter to ESCs. 60-100 amps is low! I haven’t built a drive system with the A28-400s yet, but I suspect most robots will exceed that unless they are geared down a lot.
It sounds like the brushless motor model might be reasonably close to real life. I limited current to some suitably small value. I can’t remember the exact number, but it is something like 25% of what the stall torque would be for a brushed motor. You might try the brushless motors in game. They have an insane top speed but their current limiting means they have to be geared way down. If we can find the numbers for the motors you are using I would be happy to put them in the game for testing purposes.
Was still playing May 26th and found something interesting.
[ This attachment cannot be displayed inline in 'Print Page' view ]
The hits are kinda still underwhelming and i still feel like the hits are delayed/not happening,The hits were great in the last two builds I think. They are just massively weakened in this new one.
Crashes? Uhoh! Where are crashes occurring? Can you replicate them reliably?Crashes occur mid match. How to replicate? Hit a bot. Idk if its the Robogames arena or the game, use the 2 bots i sent. If you want the arena, i can PM you the arena, as its not really planned to be released as of now so i wont post it here
[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.I did notice a difference when a bot used UHMW to protect its front compared to Steel, so it works
[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.It is noticeable, the motors can be geared a bit higher now, which is good
[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.Again, fairly noticeable as vertical spinners are now able to self Right
[Bug Fix] Resolution being downscaled on scene transitionThis is still not working sadly, only place it works is in the multiplayer battle bot selection scene.
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.How much did you gear it to?
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.
Somewhere in the range of 8:1 to 12:1.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.
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.
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 should try using a controller for the bots tbh, i could give you feedback i suppose
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.
Somewhere in the range of 8:1 to 12:1.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.
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.
Somewhere in the range of 8:1 to 12:1.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.
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.
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...
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.I feel like good hits happen most often when one bot gets a “running start” when going to hit its opponent.
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.
[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.Wouldnt it be the opposite? I have a feeling that if RotatoR’s wedge was plastic, it would’ve died pretty quickly against Tombstone.
kix,I dont think i really have that issue, i will have to check it again, could be a build problem possibly?
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.
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!
Eureka! The instability occurred because Physics Tick Rate was set at 100 ticks/second.Tbh, its 2020, and from what i have heared, either people can run it at 400+tick no problem, or they cant run it at all.
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.
There's a thing I've noticed is the fight is even easier to get crashed.
ehhh I don't know how to describe, it just happens randomly. I'll try to record some examplesThere's a thing I've noticed is the fight is even easier to get crashed.Drat. Can you show me how to replicate it?
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?Ill see what i can do
After this build we are going back into development and adding new features and breaking things. :)
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.It would be nice. You guys have discord? We prefer to host it there as voice chat is a godsend
We do. We just started using Discord last week and it has been great so far.Nice, so how would we go arrangement wise? Im free this week
My laptop gets a bit laggy when doing full-screen recording but it's ok, so yea here's the video.
https://youtu.be/fHv6jzq6Slk
And if you want bots shown in the vid
We do. We just started using Discord last week and it has been great so far.Nice, so how would we go arrangement wise? Im free this week
I might be available in 2 weeks. Yall have a server ill be able to join for the tournament?We do. We just started using Discord last week and it has been great so far.Nice, so how would we go arrangement wise? Im free this week
This week we are finding and fixing bugs. Next week I'm building real-life robots. What about two weeks from now? That will give me time to figure out child care too.
We do!Yeah 8 robots is pretty great. If youre thinking of it as a proper tournament. I remember doing 32 bot tournament in few hours, single bracket wise so 16 shouldnt be a gamble, 2 bots per person. Due to timezone differences, i most likely wouldnt be able to do more than 3 hours so thats a thing. You say that youll be ready in two weeks. Any possible date? Tbh date isnt really a problem, im really more interested in time
How many people do you think might be interested? Due to family constraints I can only commit to three hours. Maybe 8 robots total? That would give us time to talk about stuff as we are going.
Uh oh. That looks like a highlighter selection bug. I'm assuming you are clicking on the turquoise cylinder, but a scale has been applied to it and the highlighter is not scaling correctly.Oh it was my comprehension problem. There actually is a smaller cylinder with remove plate placing through the huge cyinder.
Removable plate material should work like this:
1. Click on a mesh and select the "Remove Plate" material instead of "Steel".
2. In the botlab the mesh should become invisible.
3. When you go to the test cage, the mesh is invisible and its collider is removed.
Unfortunately, no.
Boolean subtraction is crazy hard to do for arbitrary shapes. It would be awesome to have it though! :)
Unfortunately, no.
Boolean subtraction is crazy hard to do for arbitrary shapes. It would be awesome to have it though! :)
What about making the part invisible to look like it's removed? I think it might be the same way as how hollow cylinders are made?
Unfortunately, no.
Boolean subtraction is crazy hard to do for arbitrary shapes. It would be awesome to have it though! :)
What about making the part invisible to look like it's removed? I think it might be the same way as how hollow cylinders are made?
The problem with boolean subtraction is that at some point you need to make a new mesh composed of many more triangles than the number of triangles in the original meshes.
The photo below shows an extremely simple example. The 6-sided cube starts with 12 triangles. When you slice it with a plane, the resulting 7-sided shape now has 23 triangles. This gets MUCH worse for more complex shapes like cylinders:
(https://doc.cgal.org/latest/Polygon_mesh_processing/clip_open_close.png)
Now i wonder if we could keep the collision but just make the parts have a hole. Ik roblox has that feature iirc
kix, I forgot to ask, but does the new botlab shader keep your GPU cooler? The new shader should be slightly more efficient.Tbh, kupa limited the game to 60fps, so my gpu already got cooler back 2 builds ago
We just heard back from the community college. They won’t be ready for in person tournaments until October. That means we have some time. We will put out this as a stable release tomorrow morning, then take our time getting damage, pneumatics, and crushers working properly.That gives you more time to prepare as people say.
Something I'm curious about: As we already have overheating for bots to disable their own motors, would self-damage be as high as before or maybe just get removed and replaced by overheating?
1. Overheating is completely avoidable if you are willing to play it safe with battery voltage. The AmpFlows can run all day at the 24 volts for which they are rated. Maybe we need to include rated voltage in the motor description so people have an idea of what a "safe" voltage is?
2. Over the next few weeks I am going to take what we have learned about damage in previous builds and rewriting damage from scratch. Is your fear that self damage has been too much of a factor in previous builds?
I thought that eteks were prone to overheating too easy. But then i was running them at 48v (although iirc they can easily take 48v)But shouldn't your headbanging verts survive less time?
I am using brushless motors for verts, and unlike brushed they can take higher voltages easily afaikI thought that eteks were prone to overheating too easy. But then i was running them at 48v (although iirc they can easily take 48v)But shouldn't your headbanging verts survive less time?
I am using brushless motors for verts, and unlike brushed they can take higher voltages easily afaikI thought that eteks were prone to overheating too easy. But then i was running them at 48v (although iirc they can easily take 48v)But shouldn't your headbanging verts survive less time?
Ngl gearings don't affect spinup time that much on brushless. On the contrary I think brushless should be geared up to have more tip speed due to its insane cooling ability yet eteks should be geared down to keep away from overheating.I am using brushless motors for verts, and unlike brushed they can take higher voltages easily afaikI thought that eteks were prone to overheating too easy. But then i was running them at 48v (although iirc they can easily take 48v)But shouldn't your headbanging verts survive less time?
The brushless motors have current limits. This keeps them a lot cooler, but you have to gear them down to keep spinup time short.
Kix, what voltage/gear ratio are you using for brushless?
It's amazing how far this has come. My guess is that it's still to hard for me to build anything in this but it looks great. Keep up the good work guys!
Developer’s comment:
Overvolting a motor rated for 24 volts all the way to 96 volts is extremely dangerous and not recommended! Even though it might be okay in the game (for now), please try to keep the AmpFlows to 48 volts or below. A lot of competitors have learned the hard way that AmpFlows can fry themselves when run this high.
Developer’s comment:
Overvolting a motor rated for 24 volts all the way to 96 volts is extremely dangerous and not recommended! Even though it might be okay in the game (for now), please try to keep the AmpFlows to 48 volts or below. A lot of competitors have learned the hard way that AmpFlows can fry themselves when run this high.
That is true indeed. I was just showing what can be done
Tbh, i would keep it as is, as atm, they are kinda saving the flippers. More voltage/more torque for the motor. Atleast keep it till the pneumatics get addedDeveloper’s comment:
Overvolting a motor rated for 24 volts all the way to 96 volts is extremely dangerous and not recommended! Even though it might be okay in the game (for now), please try to keep the AmpFlows to 48 volts or below. A lot of competitors have learned the hard way that AmpFlows can fry themselves when run this high.
That is true indeed. I was just showing what can be done
I’m going to limit this when I get a chance. We don’t have a system in place for that yet though. Maybe if you go above 48 volts the motor melts immediately...
True. I think if you could go to 96 volts on a motor this size you might see a lot fewer pneumatic systems IRL. Motors are just easier.They truly are. We just need to figure out the jankines when on gearing higher than 10:0.1
since kix doesnt know how to image tagsNah, i know, i just get the broken pic icon
(https://i.imgur.com/8TZpYCx.gif)
No updates since a year ago? LameNo mr. Sage man, you see we dont post on gtm anymore, we have transferred to discord as it is waaay better.
[Update] We updated to Unity 2020.3.21! This should come with better performance and might fix our mac struggles! It might also introduce some new bugs...
[Bugfix] Changed collision detection on wheels to prevent snipes through the armor
[Bugfix] Fixed a bunch of weight scaling issues (sounds, pneumas etc.)
[Bugfix] Fixed a major part of Groaties/floaties. Stuff that gets broken off can still clip but should be much less dramatic
[Bugfix] Fixed AI, it now runs at half CPU but actually works this time
[Change] New take at spinner physics, involved an epic amount of changes
[Change] Changed mass scaling to be 1:1 (aka 10 times heavier then before). This makes spinners behave better and gives bot a much heavier feel.
Known issues:
- Highlighting in botlab is borked
- Hinged bits/rotating body groups are mostly invincible, welding doesnt work correctly on them yet
I still have to check out the recent updates. Haven't played this for at least 2 years
New Bleeding Edge build: JAN13
This build fixes some issues with welding around hinged groups (everything that spins/rotates)
An important thing to know is that the first placed object on a hinge/chain/belt/etc will be the root component of said group,
this root component part is invincible for now.
Parts that dont have a physical connection to the root component or hinge/chain/belt/etc will fall off on spawn, just like unwelded parts on the chassis.
This can be tricky to fix, because the highlighting of unwelded components it currently not working for hinged groups. This will be fixed later.
The fixed welding causes EVERYTHING apart from root components to be capable of getting damaged, including spinners.
The strenght of a part is mostly determained by the material and the material thickness, set by the slider in the materials tab.
You should always try to get this thickness slider as high as possible on weapons and armor, since this will greatly improve the strength.
You should imagine parts you place as being hollow and that the slider determains the thickness of the walls of the hollow part.
So to get the physical thickness of your part, you should multiply the slider number by two, it will then also be correct with the scaling value.
(A 0.1 scale box will be 10mm thick, the slider will go to a max of 5mm and and the part will then be solid and maximum strength)
There will likely be bots that need fixing, but most weld issues can be fixed by putting an axle through the hinge/chain/belt and the root component.
Just make sure everything is touching physically; parts cant float in midair in the real world either (unless some substances are used. Probably.)
Please report any issues with getting things to weld in #rr2-support and things that seem to actually be bugged in #Bugreports and #Bugchatter
Have fun playing, idlove to hear what you thing of this new build!
Changelog:
[Bugfix] Added massScaleFactor to the strength of sprung hinges (no more weak)
[Change] Upped all spring strengths to be 1:1 with before I broke them
[Bugfix] Added missing sounds to some pneumatics
[Bugfix] Fixed a bug in Weld Manager to have it calculate welds on hinged groups
[Change] Damage is now applied to all individual components and their welds
[Change] Belts etc should no longer dissapear at random
New bleeding edge: JAN19!
Today we bring ARM DAMAGE and ENERGY DISSIPATION!
Arm damage: how does it work?
Anything that is not classed as a wheel or spinner and that has a tip speed of more than 0,6 m/s will become an arm capable of doing damage.
The arm does damage based on the kinetic energy it stores at the moment of impact. Kinetic energy is generated by the moment of inertia and speed of the arm.
The damage done is altered by how direct the hit is, how much the material being hit flexes and by what part is doing the impact: Maximum damage will be delivered at the outer tip of the arm and only half damage will be done if you are hitting with a point half way the arm!
Hold up, does that mean my flipper can do damage as well?
Yes, although a flipper generally starts its stroke in contact with the opponent and thus has a very slow- or even no impact, so they wont do much damage.
(Unless there is a mile of acceleration distance and the flipper hits the opponent at massive speed... but then it is basically a hammer...)
Energy Dissipation: how does it work?
So, without getting into really heavy physics: think of hitting a really thick piece of hard steel with a hammer: you will never be able to damage it and it just kinda "gongs" your energy away.
This is now simulated in the game! Every weld/component of a certain material can take a certain amount of abuse without breaking and deforming, in physics we call the point the Yield Strength. (point where something breaks off is the Ultimate Tensile Strength)
You need to beat the Yield Strength with your damage in order to do permanent, lasting damage. Materials like AR-Steel and Titanium have a high yield strength but can still take allot of abuse after they have been permanently deformed and thus are very tough.
Materials like rubber are very elastic but instantly break once you cross this elastic point and a material like Carbon fiber has a very high strength and is a bit flexible, but it will instantly crack once you go above the yield strength!
Okay cool physics and all... but how exactly does the game do this?
Every weld has a maximum amount of hit points (~= ultimate tensile strength * overlap * length * thickness^2).
And every weld has a yield threshold (~= yield strength * overlap * length * thickness^2).
The damage needs to be more than the yield threshold, if it is not enough then the weld will dissipate the damage away and no damage is done.
If the damage IS more than the yield treshold, then all the damage that goes over the yield will take hit points away!
Repeat until broken!
NOTE: Notice how the hit point equation has thickness^2, if you make something twice as thick, it will be FOUR times as strong!
Changes:
[Added] Allot more material variables to help aid in simulation of flex etc.
[Added] Hammer damage! or as I call it "arm damage", swing something at your opponent and it will now do damage! atm it doesnt really care about the hammer head shape (pointy, blunt etc.), but that will come! IMO they are still a bit too clippy, i have some ideas reduce this.
[Added] Energy dissipation! You need to beat a certain energy threshold before you can damage a component/weld. This fixes wheels being broken very easily by spinners AND in the test box AND it much improves the strength of the Tires and Rims, and makes spinners (or in general very thick materials) stronger.
[Change] Switched collision detection of arms to a different option to hopefully reduce clipping and jitter
[Change] Upped the Default Contact Offset from 0.0001 to 0.001, this greatly reduces clipping but might result in slightly different collision interactions (a spinner suddenly slightly hitting the ground)
[Change] Switched collision detection of spinners to a different option to reduce sniping
[Change] CDC can no longer be enabled on chassis components (this caused groaties)
[Change] Enabled the rotation part of Arena damage again.
[Bugfix] Test area props now have correct masses
[Bugfix] Below 100a, the ESC amp limit will round to 1 instead of 10, to make the small ESC,s usable again!
[Bugfix] Fixed all calculations around hinged groups (it was bad...)
Enjoy and let me know what you think!
New Bleeding Edge: JAN30!
Changes:
[Added] 2 additional LEM sizes: 170, 200! The 170 likes about 60v and 250/300a, the 200 likes up to 84v and 300/350a, both will do just above 400a for short time
[Change] Changed spinner bite, below a certain bite treshhold spinners are much more likely to grind
[Change] Changed physics stuff around spinners to make them less spastic and hit a little less hard
[Change] Disabled a part of velocityLimiter to not set CCD when something is moving fast. This caused more clipping then it solved
[Change] Stopped velocitylimiter from setting a collisionmode every frame (...?)
[Change] Ever so slightly increased the size of the high speed spinner collider to improve grinding
[Added] Added a slight drag so that spinners spin down (yes this will slightly reduce the maximum spinner speed, deal with it, effect is much worse irl)
[Bugfix] Spawnable crate and additionals are actually 100kg now, also doesnt defy gravity anymore...
[change] Increased the amount of available cameras to 6 (Thank Kris for this)
[Change] Changed a ton of particlesystems to collider with the correct layers, particle FX now look much better
[Change] Improved the look and flow of flamethrowers
[Change] Enabled Speculative collision detection on arm damagers, seems to much reduce clipping, even on pointy tips (only works now because i fixed the velocity limiter thing)
[Bugfix] Fixed a few weird settings on some motors particlesystems
[Bugfix] Fixed a small issue with the collisionmatrix
[Bugfix] LEM's are not scalable...
Enjoy, report bugs and let me know what you think!
New bleeding edge: FEB24
Important!
Hinged groups (arms, spinners, hammers, flippers) can now be broken off with weld damage.
When there is only one part attached to these hinged groups (= invincible root component) they will be broken off!
Belts and chains now respond to the weld system, when they fall off, add a static axle through the pullies!
We noticed gearboxes often dont show up unwelded and dont fall off, while their wheels/spinners randomly fall off: the gearbox is unwelded and needs to be attached to static frame!
There were A TON of bugs fixed creating this, there might be some more left, yet to be discovered...
Procedurally generated spinner hums are still very WIP, especially at higher frequencies they need some work, let us know what you think and how they could be improved!
The weld highlighting system is still not working correctly, sorry for the inconvenience!
We also went through a big project migration, there might be some unforeseen problems, but as far as we know it all works!
Changelog:
[Added] Tetrahedron, half cylinder, sixth cylinder. Attaching the parts is kinda broken atm, USE THESE AT OWN RISK they are WIP
[Added] Superheavyweight weight class
[Added] Spinner hums! still pretty WIP but getting interesting
[Added] Hardox textured variant, rn its paintable where it shouldnt be
[Added] The mighty TriCAT, as inspired by Pardon My French and Madcatter
[Added] Dual TP100 (Say goodbye to those filthy brushes)
[Added] Added motors locking when the maximum rpm/voltage is exceeded for more than 10 seconds: the motor will start to spark, then lock up and short, generally overheating the motor in the process! VOLTAGE LIMITS MATTER NOW!!!
[Added] Belts and chain collisions! (they now need to be "welded" with a static axle through them) (there might be visual bugs around this still)
[Added] Added logic to welding to break off hinged groups in a correct, weld based manner
[Change] Changed FX in botlab (Hello proper green screen...)
[Change] Changed Motor_Script to destroy a motor once Rotor_Max_Rpm is passed for 10 seconds (limits voltage)
[Change] Slightly upped drive motor torque limiter to let robots push better
[Change] Changed wheelmassratiocontroller to subtract the mass it adds, all robots are now physically the same weight, no matter the amount of wheels
[Change] Changed some texture normalmaps (better looking hardox)
[Change] Changed the bot selection menu to three rows
[Change] Set the electronic disable limit to a more realistic 10 joules (50cm drop). 2j was too little.
[Change] Made the armdamager speed threshold higher (10m/s tip) this might give problems for smaller weight classes but we will see about that
[Change] Made spinner hums a little louder
[Change] Updated all motor stats to have correct max_rotor_rpm and voltage values
[Change] Upped the "Flip robot upside down" strength
[Change] If the root component is the only component left in a group, it will break off (otherwise its invincible)
[Change] Some improvements to SpinnerHum sound (no longer plays on pause)
[Change] Tweaked wheel rpms to make them more stable
[Change] Cleaned up spinnerCollisionHandler, it does not aim for (unused) combined damageable objects anymore
[Bugfix] Fixed some collider errors on several motors
[Bugfix] solenoid is now single direction and ON/OFF again
[Bugfix] Both the TP100 and CAT are now inrunner motors as their IRL counterparts(the outside does not spin)
[Bugfix] Arena selection menu is now scrollable
[Bugfix] Fixed wrong tipforce calculation, the other calculations are also likely off
[Bugfix] Reduced sniping of Arm damagers
[Bugfix] Fixed motors being powered while the motor is clearly broken off
[Bugfix] Added logic to not break the game when a hinged group is broken off
[Bugfix] Reordered some damage code so that electronic parts are disabled when they are hit instead of breaking their welds before breaking themselves
[Bugfix] Wheels no longer take damage from the Arena (that took a while...)
[Bugfix] Added AIstate variable back, you guys are going to have to tell me if it works properly...
New Bleeding edge: MAR5
(Pretty much a FEB24 hotfix)
Changelog:
[Change] modified higher rpm spinner hums, as well as some updated sounds (to make them less annoying)
[Bugfix] Fixed a bug where the chassis would be set to 0kg when a wheel is taken off (chassis spazzing outa here)
[Bugfix] Fixed broken off parts getting flipped in the botlab instead of the bot itself
Known issues:
Highlighting of weld is still not working correctly
Chassis parts stay transparant (this is a bug because of Cloud build being broken, the issue occurs because of me doing a local build)
New bleeding edge: APRIL 13Windows
Allot of performance upgrades in this, let me know what improvements you see, enjoy!
Potential issues:
Spinners very "snipey"? doing damage to things they dont really hit?
Changelog:
[Bugfix] Motors will now not randomly spark when not overvolted
[Bugfix] Spinners are now allot less spastic
[Bugfix] Fixed motor "phantom noise" that continued playing after a match was restarted
[Change] Changed spinner damage output: spinners will now do "less" damage to "allot more" things, this likely has some funny effects but we will see (bewerkt)
[Change] Optimised Immobile script for better performance
[Change] Optimised Temperature script for (significantly) better performance
[Change] Optimised Editor COM marker script for better performance
[Change] Disabled component data stream to AIController for a SIGNIFICANT performance increase of all AI scripts
[Change] Added logic to remove all "reverse" meshes and renderers when not in the botlab for a SIGNIFICANT performance increase, especially on high part count robots during fights
[Change] Enabled spinners damaging themselves on static objects
[Change] Rebalanced gyro, drums should now gyro less bad
[Change] Buffed Rubber strength (doesnt really work)
[Change] Upped PSI limit to 2000
New bleeding edge: APRIL 14
Mostly a hotfix for April 13
Changelog:
[Revert] Re-enabled the spinner collision stop timer (so only one component takes damage on a spinner hit)
[Bugfix] Fixed a bug where unwired motors create lag
New bleeding edge: APRIL 21
Fixed some ennoying issues in regards to ghost collisions and sniping. And some additional ease of life changes!
Enjoy and let me know what you think and report bugs!
Added logging:
I am not completely sure how this works yet, but the game should now generate a log file with all console entries!
This will be very nice for debugging stuff, especially on Mac!
For bug reports ill now often ask for this file!
The logfiles should be created in the following locations:
(idk why the name is different, I can maybe fix that later)
Windows:
%USERPROFILE%\AppData\LocalLow\Nerd Island Studios LLC\Robot Rumble 2.0\Player.log
Mac:
~/Library/Logs/Nerd Island Studios LLC/Robot Rumble 2.0/Player.log
Changelog:
[Added] Added code to spinner collision scripts to much better filter "fake" collisions, this massivly improves sniping and ghost collisions!
[Added] Added code to hammer/arm collision scripts to much better filter "fake" collisions, this massivly improves sniping and ghost collisions!
[Change] Disabled "shock damage" since it didnt really make sense and was more ennoying then it was interesting
[Change] Enabled "sweeping" spinners again, spinners will now damage more then one component per collision
[Change] Tweaked spinner damage output to a more reasonable damage output
[Change] Modified some logic to somewhat improve bite on wedgeless verts
[Change] Reworked weld to break the root component off by its health when all welds to it are broken, now you dont need at least two components to prevent things from falling off! (was honestly super ennoying and dumb)
[Change] Enabled player logs (still testing how this works)
[Change] Upped "non weld" connection strength x3 (atm it doesnt make any sense but at least it will make wheels a little less garbage)
[Bugfix] Fixed an error when Combine meshes only had a single mesh to combine
[Bugfix] Fixed a bug that caused hammers/arms to almost never do damage
[Bugfix] Fixed a bug where chains/belts would collide with the simplified group meshes
[Bugfix] Fixed a broken camera reference in bot selection
[BugFix] Fixed and issue where IMPORANT physics numbers would be changed at random, causing differences between botlab and arena fights
[revert] rubber is now correct strength again
1. Open terminal
2. Run each of these commands in order
3. Tell terminal to go to your downloads folder where you downloaded the game to cd Downloads
4. Make the game executable chmod +x "RR2_APR14_2022_BLEEDING_EDGE_MAC.app/Contents/MacOS/Robot Rumble 2.0"
5. Remove the quarantine flag that stops the game from running xattr -r -d com.apple.quarantine RR2_APR14_2022_BLEEDING_EDGE_MAC.app/
6. Close terminal and launch the game! :D
New bleeding edge: MAY16
Changelog:
[Added] Models of camera
[Added] Added "Test" matchtype that enables telemetry mid fight note: this only works if you change the camera for some reason
[Added] Option for an "infinite time" match, the timer will count up instead of down
[Added] Dark chain!
[Change] Slightly rebalanced spinner damage output
[Change] Added a thing to improve reach verts
[Bugfix] Fixed a bug that caused single part hinged groups to not collide with the floor
[Bugfix] Fixed US style pneumatic system
[Bugfix] Fixed ESC current limit being WACK in 20 different ways
[Bugfix] Quad A28-400 is now centered.
[Bugfix] Arena hazard impulse script now fires more then once
[Bugfix] Fixed heating on LEM 170 and LEM200
[Bugfix] Fixed an issue where electrical components could not be directly disabled by spinners
[Additional] Game has a logfile system, when the game has a bug or something like that it records it in the log file. Please send that when telling about bugs
New bleeding edge: MAY21
Changelog:
[Added] Power output of a motor in telemetry
[Added] Added a static collider on spinners to reduce the distance that they can clip, substantially reducing clipping of spinners
[Added] Added some peculiar logic to Pause Function...
[Added] Robot unsticker! Hit "home" during a fight to reposition all bots back to their spawn location
[Added] Enabled rigidbody interpolation for slightly better motion blur (and something else)
[Added] Added the Slam Cam! a small camera that you can put on your robot, find it under "extra misc"
[Added] Added "totalStrucTuralIntegrity" to display the total weld integrity of a part in the editor
[Change] Tweaked some things in spinner collisions
[Change] Retuned damage output again. The "Anti clip" spinner collider seemed to limit damage output a fair bit
[Change] Added some logic to slightly reduce spinner spasticness
[Change] Changed 0.8,0.8,0.8 grey (slot 2) to 0.7,0.7,0.7 grey which matches many ingame parts
[Change] Made some "things" available (From what it looks like, some sponsorship stickers and the ability to press F1 and F2 to enable slow-mo)
[Bugfix] Fixed some small issues in motorscript
[Bugfix] Fixed some small issues with telemetry
[Bugfix] Speeds no longer get messed up when one of the motors of a multimotor break
[Bugfix] Fixed some issues with the robot unsticker not working in a compiled build
[Bugfix] Fixed test mode not working
[Bugfix] Fixed Impulse Hazard being super weak
[Bugfix] Made Slam Cam not "Dev-only"
[Bugfix] Fixed a bug where the mesh combiner would fail and create massive lag
[Removed] CDC option, it caused more problems then it fixed
How 2 use the Slam Cam
Put it on a bot
Enter an arena fight
The Slam Cam will be activated by any of the unused arena cam slots (so if you have an arena with 6 cams, you CANNOT activate the Cam)
New bleeding edge: SEPTEMBER15Link to the builds:
IMPORTANT: Linux builds are now available! It is very WIP and may not work!
Changelog:
[Added] Added native Linux support (still needs some more testing)
[Added] Arm damager slider! disables or multiplies the damage done by hammers/flippers/arms
[Added] Trampa VESC 100/250
[Added] CAT X3330
[Added] CAT X1020
[Added] Trampa 60/120 (by Liam)
[Added] CAT 30100 (by Liam)
[Added] VEX BB (by Liam)
[Added] Green Brocc 200a (by Liam)
[Change] Adjusted friction values on many materials to be more realistic
[Bugfix] Fixed telemetry applying gear ratio twice to the torque value
[Bugfix] Fixed telemetry displaying half the actual bite depth
[Bugfix] Disabled CCD on some stock shapes
[Removed] Deleted some old damage code causing groups/wheels to break off at random
[Disabled] Disabled the wheel torque limiter since it is causing some issues and inconsistancies and is not really needed anymore (might cause some robots to bounce/float again maybe?)
Our revitalized dev team's first game update! It's been great working with the rest of the team, and I think Doyle is happy that he isn't carrying on is own anymore.
Changelog:
[Added] A Workshop button that opens the UserRobots folder in a native file explorer.
[Added] There is now a button next to the Components Attached counter that explains the basics of weld.
[Added] Added a toggle option in Display settings to hide the weld help button.
[Removed] Test Arena from Arena Select menu
[Added] Wreckbots Arena as built-in arena
[Change] The Championship button on the main menu has been changed to an Open Game Folder button that opens the appdata/ApplicationSupport folder in the user's file explorer.
[Added] Main Menu buttons now have small icons (made by @MellowedRose☕)
[Added] Arena Select now has a guide that explains how to add arenas in addition to linking the Discord server, AMT download, AMT tutorial, and the arenas folder
[Change] New spinner mechanics! More precise impacts and more realistic!
This includes:
New static and dynamic high speed colliders that detect collisions much more precise
New damage and impact calculations
New impact spinner speed reduction
New Impact filters (No sniping possible in combination with the new HS colliders!)
New grind mechanic
New absolute bite calculations that takes in account the speed and direction of the opponent as well
A basic implementation of ablative and springy bite/impulse reduction
Improved spark emission
Improved performance by deleting old, unused calculations
[Change] Motors now actually reach their break even continuous work point
[Change] Motors now heat up and cool down more realistic (slower then earlier)
[Change] All motors now have correct stats (Moto, Ampflow and TP100 are less powerfull, LEM's, NPC's are more powerfull)
[Change] Increased gyro for wide and big diameter spinners
[Change] Different material components now use adapted welding that simulates a bolted connection
[Bugfix] Hinged groups break off correctly without bugs now
[Bugfix] Fixed a bug where spinners could not damage some components including other spinners
[Bugfix] Pause now stops all sounds
[Bugfix] Motors now display their continuous current
[Bugfix] Gas splitter now has as many inputs as it visually has (4x input)
[Added] More TP power motors! The TP2030, TP2930, TP3650, TP5680. From BW to HW!
[Added] CAT TrackTail motors! 1:10th and 1:8th scale RC motors for BW and FW!
[Added] PrimalPower X23850! A GIANT flat outrunner that can deliver a whopping amount of power!
[Added] The Green BroccSC VeggieMaster 800A ESC! A ridiculous ESC for the most stupid Brushless setups you can imagine (Temporary model)
[Added] Lynch LEM 200x2. This is litterely two LEM 200's slapped together...
[Added] A range of small brushless outrunners!
[Added] A fixed version of the 3 inch brushless! (the old one is hidden, since completely unrealistic but it wont break old bots now)
[Added] Screws! Bolts! Hex heads! Flat heads! Philips heads! All to make things pretty with.
[Removed] Removed more old damage code that fused broken parts together mid air
[Bugfix] Fixed weight of connected flipper systems
[Bugfix] Debug spinner options are no longer visible in settings mid-fight
Links:
Windows: https://drive.google.com/file/d/14_73BEdE3asXFZ-K1bKK6da3jxfIxAFA/view?usp=sharing
Mac: https://drive.google.com/file/d/1F92lxqzSXVsljVMYn-bJ1LZw-hKwhWm1/view?usp=sharing
Linux: Can be built upon request
Changelog
[Bugfix] The controls button in the settings menu now brings up the controls settings during a battle.
[Bugfix] TP5680, CAT TrackTail 1/8, and CAT TrackTail 1/10 should no longer burn at their max voltage
[Bugfix] Lowered PrimalPower X23850 max RPM to proper stats
[Bugfix] PrimalPower X23850 now weighs its proper weight
[Bugfix] Updated comp_info of PrimalPower motor
[Bugfix] VeggieMaster 800A is no longer scalable
[Bugfix] Weld Help Button should now show up by default for new users
[Bugfix] Fixed ESC current limits resetting at random
[Bugfix] Fixed spinners on arms generating way too big HS collider
[Change] Slight update to LEM texture (LEM2x200 showing mesh centre instead of what looked like 3 motors stacked)
[Change] Updated Visual of Broccsc 200a
[Added] Broccsc 100a, 70a, 40a and 30a ESC's!
[Added] The godly TP100XL
[Change] went over all motors to fix all specs and limits
[Bugfix] Fixed spinner edge detector being way too big on spinners on arms or hinged groups
[Remove] Removed combined_damage_object since it was obsolute and broke spinners off in the test area
[Removed] removed several unused script
[Bugfix] BW with spinners will no longer gyro when their spinners are not spinning
[Bugfix] Fixed a bug where the edge detector would not work and spinners would grind excessively
[Added] Goose! a small brushless motor for beetleweight drive!
[Added] A fitting small gearbox for the 18xx brushless motors
[Change] Minor updates to some motors
[Bugfix] Fixed Goose motor
[Bugfix] Fixed beetle gearbox size
[Changed] Arena add help button is now a question mark instead of a plus sign
[Added] New official RR2 default arena by @LiamHaddev! (edited)
[Bugfix] Game Folder and Open Robot Folder buttons should now work on Mac
[Added] Arena damage! All arenas now apply damage when you ram/fall/slam into them
[Added] Arena Damage is now added to AMT arenas upon instantiation
[Added] Arena Damage Slider
[Bugfix] Damage values can now be adjusted mid-fight
[Change] Fixed values from GOOSE motor
[Bugfix] Fixed some components not having damage applied to their welds
[Remove] Some old scripts that still ran but didnt do anything useful
[Changed] The botlab camera can now be zoomed in more
Hotfix:
[Bugfix] Arena damage slider no longer affects arm damage
[Changed] Set default arena damage to 25%
Changelog
[Removed] Wreckbots arena due to it being built in an outdated version of AMT
[Changed] The default arenas are now copied to the Arenas folder instead of being loaded from StreamingAssets. ⚠️ If you use the October Builds after this update, you will need to remove the arenas folder from the October build StreamingAssets ⚠️
[Added] UserRobots is now created when the game first launches. You no longer need to export a robot to have it created.
[Changed] Stock Robots are now copied to the UserRobots folder instead of being loaded for battling.
[Added] Damage and tickrate sliders now have textboxes that let you change the value without having to use the slider
[Bugfix] Damage and tickrate can now be changed mid-fight (for real this time)
[Updated] Concave Collider generator has been updated to version 1.30
[Updated] Rewired has been updated to the latest version
[Change] Rebalanced spinner bite
[Change] Improved edge detection of spinners
[Removed] Some laggy debug statements
[Bugfix] Fixed N20 rpm/volt limit
[Bugfix] 1.8A ESC colliders now matches the model
[Added] New botlab icons by @Mellowed Rose☕
[Updated] Credits now include all developers as well as outside contributors
[Added] The RR2 UK default arena designed by @LiamHaddev!
[Bugfix] Credits scrollview now shows the entire credits
[Bugix] Clicking in the Credits window no longer hides it
[Change] Changed the material slider to properly round and accept decimals more easily
[Bugfix] The New Shape button is no longer off-center
[Changed] RR2 Arena is now 0.5x larger
[Changed] The cameras in the RR2 arena have been adjusted to better positions
[Added] Dual CAT 30100 motor due to popular demand (not added by Doyle ;p)
[Bugfix] Transparent Shape and Chassis now works on Hardox and other textured materials.
[Added] Goose Mini battery splitter
[Added] Fillet shape (might need a positioning fix)
[Added] Perf Round quarter hollow cylinder (might need a positioning fix)
[Added] Countout timers can now be hidden with Video Settings
[Added] Epilepsy warning in opening splashes
[Added] Octo A28-150 motor
[Added] Goose S2838 motor
[Added] Goose HK3536 outrunner motor, 3000watt cont and good looking...
[Added] Goose HK7050 outrunner motor: Minotaur runs two of these for the drum, make of that what you will...
[Added] A ball bearing! make things spin!
[Added] Goose 4S 14.8v 850mAh battery (NOT PLACABLE YET)
[Added] Many new basic shapes (NOT ALL OF THEM ARE PLACABLE YET, expect update later this week)
[Added] moar Saw!
[Added] New model for the PrimalPower X238/50!
[Added] TP 4070 brushless motor, small but long... very capable!
[Added] By popular demand: Dual A28-150, as found in Skorpios and Defender!
[Added] A smoll RC receiver! only six channels but it will actually fit in your Beetle... It was a beetle right? Wait a 150gram? Bruh... It will fit tho...
[Added] More things that can be made into bot parts by other dear devs that have much better internet then me at this moment in time
[Added] PrimalPower X238/100! An even thiccker and more powerfull version of that flat pancake brushless motor
[Added] Added Super 5Ah Batteries! from 1S till 13S
[Added] Dual CAT X1020[Change] Arena damage is now calculated based on entire robot weight instead of the piece
[Change] Default Arm Damage and Arena Damage are set to 0%
[Change] Increased/reworked the metallic effects on metal materials
[Change] Changes some material textures to make them more realistic
[Change] slightly altered the looks of chains
[Change] Tweaked metallic effects on some motors
[Change] Rebalanced the peak power of TP100, CAT 30010, Motenergy
[Change] Rebalanced spinner bite
[Change] Changes to make wide and medium to big sized beaters and drums bite better
[Change] Shortened axle on beetje brushless gearbox
[Change] Nerfed the Motenergy to 500a continous, but it burns out too fast on solenoid so needs more fix
[Change] Small code tweaks to improve performance
[Change] Optimised AI scripts for better performance when using player only bots
[Change] Optimised velocity limiter to improve performance
[Change] Excluded some code in ComponentWelder that might not be required but massivly reduced performance
[Change] Reworked Spinner bite to be more satisfying and responsive
[Change] Made the outwards impulse on spinners much more sophisticated: HS glance and ping off angled surfaces and verts shoot things backwards instead of always up
[Change] Spinner to spinner collisions now sway more towards the spinner with the higher tip speed, still WIP till it feels right
[Change] Removed some unused calculations fro spinners to slightly increase performance
[Change] Improved edge detection on spinners
[Change] Reworked damage output on spinners to give more damage on a good hit
[Change] Both stock arenas now have roofs
[Change] RR2 UK has Bigger floor zone
[Change] RR2 UK now has one OOTA at the far end of arena and one by the entry gate
[Change] RR2 UK Pit and flipper much smaller
[Change] RR2 UK now has better lighting and camera angles
[Change] RR2 UK flipper and pit are now swapped so the pit is near the OOTA
[Change] RR2 UK flipper activates 2 seconds if you stay on it
***Note: If the arenas don't update, go to your arena folder (not the one in the game files) and delete the rr2 and rr2uk arenas so the game can put the new ones in.***
[Bugfix] Open Game Folder and Open User Robots Folder should now work on Mac
[Bugfix] The WeldHelp setting now toggles in all settings menus
[Bugfix] Parts from spinners and arms now have the correct friction again
[Bugfix] Broken parts from actuated groups nopw have the correct friction again
[Bugfix] Thin custom shapes now get a correct material thickness equal to the one in the UI
[Bugfix] Motors now correctly mute when the game is paused
[Bugfix] Spinners will always make a collision sound instead of sometimes
[Bugfix] CAT 30100 is now rated for 285a continouos to bring it to its realistic cont power of 17kw
[Bugfix] Fixed some bugs with spinners suddenly triggering a huge recoil on very light objects
[Bugfix] Fixed the edge detector sometimes getting stuck in the opponent
[Bugfix] Fixed rpm limit on 3-inch brushless
[Bugfix] Fixed weight from Goose insect weight splitter
[Bugfix] Fixed stats and weight on Goose S2838 motor
[Bugfix] Fixed sizes on some Pro Batteries (10S till 13S are now slightly smaller)
[Bugfix] Fixed a small error in the LEM 130 stats
[Bugfix] Fixed the resistance of the TP100, it needs some tweaking to have its correct peak current
[Bugfix] Fixed a bug that created allot of lag on bots with many basic shapes
[Bugfix] Spinners now properly trigger a collision sound (perhaps a bit spammy sometimes)
[Bugfix] Dual CAT x1020 no longer floats when placed
[Bugfix] parts attached to the Dual CAT 30100 are no longer .002 off center
[Bugfix] TP4070 is no longer scalable and should have correct weight
[Changed] Googly Eye no longer moves
[Bugfix] Dual A28-150 is now classified as a multi-motor and has 2 esc inputs
[Revert] Reverted arena damage to not calculate the mass of the entire bot for every contact point, needs more thought or an integral sulution
[Optimisation] tiny optimisation to combinemeshes to not set layers every frame for every component
[Bugfix] Fixed spinners biting super hard on loose parts
[Added] Goose MAD TORQ brushless motor, as a slightly smaller outrunner compared to the PP
[Added] Added the spinner impulse slider back. Yall wanted to engage in more dumb hits.
[Added] Options to adjust Rotation, Movement Tracking, and Zoom for Cameras.
[Added] Option to disable Immobility Countouts.
[Added] Option to hide Timer in matches.
[Added] Ability to change countdown and timeout text and sounds.
[Added] New animation trigger that is triggered when the countdown starts. (Intro sequences, anyone?)
[Added] New utility script that allows a GameObject to track a players bot position. If the player slot is empty, the GameObject will disable.
[Added] New utility script that allows a GameObject to rotate to face a players bot. If the player slot is empty, the GameObject will disable.
[Added] New utility scripts that allows a GameObject to track and/or face the midpoint between all bots.
[Added] New sound triggers for Timer, Zone, and Countdown. Now you can have custom sounds play whenever, wherever! (Pit button release klaxon. mayhaps)
[Added] Centre of Mass indicator in BotLab, accesible from the sliding options menu.
[Added] Added functionality to increase the directnesOfHit with high bite distance and increase the impact angle, this makes run-up hits much more satisfying
[Added] Telemetry now highlights red when: a motor current more then the continous current is drawn, when a motors max rpm is exceeded and when it overheats!
[Added] Added a blow out effect on gas tanks when they are hit
[Added] Small boi flamethrower for beetles
[Added] Tungsten Carbide material! Tungsten carbides in a Cobalt matrix to be very exact: super heavy, super hard, super brittle!
[Added] Magnesium Alloy! Not entirly the stuff that wants to explode in water: its like lightweight Aluminium, but a little less strong.
[Added] S7 Steel! The famed, the infamous, the wanted, the controversial: Hardened till 54 Rockwell C, as holied by Ray Billings: harder then AR/Hardox, but more brittle.
[Added] TPU! the new surge in lower weightclasses: 3D printed TPU 95A, very flexible and wear resistant, minorly grippy.
[Added] Carbonfiber Nylon/NylonX! Some call it black aluminium...! Perhaps in toughness, but the strongest plastic available!
[Added] Polyurethane Rubber! For those who like casting their own tires! Extremely grippy, but slightly less reliable as classic rubber!
[Added] PLA! The absolute giant of 3D printing, a surprisingly high tensile strength... but we know what happens when it is hit...
[Added] Different looks for each material, if peoples have opinions about these please let me know!
[Added] BroccSC 200A HV! this boi going up to 50v
[Added] Nine new PrimalPower outrunners! Ranging from 370W to 3770W they provide allot of spin for Beetles, Feathers and anything in between!
[Change] Twitter icon to X (blegh)
[Change] Enabled incremental garbage collection, which spreads garbage collection accross several frames, reducing frame spikes
[Change] Nerfed the 300A brushless ESC to 500A peak, its 1000A limit made the Veggmaster obsolute
[Change] Moved Countouts Visible option to Battle Select Screen instead of Settings.
[Change] Match Time, Timer Visibility, Countouts Active, and Countout Visibility now save their state between sessions.
[Change] Complete rewrite of Camera Controller.
[Change] Trigger Zones can now have a delay before they become triggerable.
[Change] Made the Press Start to Begin "button" fit in with the rest of the battle UI.
[Change] Tweaked some logic to improve bite for overhang/exposed weapons
[Change] Sligthly increased the bite of the losing weapon in a spinner to spinner collisions to improve horizontal vs vertical hits
[Change] Blueprint material is now a physicial material that welds and has collisions. its as strong as cardboard and as heavy as aluminium
[Change] Reworked ALL motor smoke particle systems to be less obnoxious, glitchy and more subtle and make them derive from one source
[Change] Reworked ALL ESC and CO particle systems to be less obnoxious, glitchy and more subtle and make them derive from one source
[Change] Reworked ALL Battery particle systems to be less obnoxious, glitchy and more subtle and make them derive from one source
[Change] Changed all component particle systems to the new versions (this was so much more work then expected lmao)
[Change] Reworked the spark effects from spinners to let sparks fly faster and further, makes spinners look more impressive on glancing hits
[Change] Renamed several materials to be more technically specific or more generic (Hardox is now AR500, Titanium is now Titanium Gr. 5, Steel is Mild Steel etc.)
[Change] Reordered the material list: low tier/weaker/lightweight materials working up to exotic/heavy/strong materials and ending with the "specials"
[Change] Minor changes to some material stats: in the back im adding more functionality for said stats, these will come slowly in play!
[Change] Once again a new take on the spinner system using unity's animation curves to tune bite which comes with benefits: very precise control of bite response and much faster to calculate then intricate calculations
[Change] Rebalanced bite with the new curve control: more grinding and less spasm at very low engagement speeds, much better bite for mid range bite and reach weapons, less likely haymakers
[Change] Spark effect speeds are now tied to weapon tip speed
[Change] Fixed stats on many BroccSC's since I had some wrong weights (several became a little lighter!)
[Change] Increased flat spinner impulse efficiency to reduce the amount of "slacking" hits, this should improve the bite balance between bars and discs as well
[Change] Reduced the maximum impulse cap to reduce the impulse of gigantic spinner impacts to 6 times the robot mass (was 7.5)
[Change] Tweaked some impulse modifiers to make better spinners impacts with the arena and glancing impacts
[Bugfix] Dual CAT x1020 collider is now correct
[Bugfix] The build text works again!
[Bugfix] Broken Parts now properly despawn in BotLab on Bot Reset or when leaving a Test Area.
[Bugfix] Weird jump when switching cameras.
[Bugfix] Black cylinders missing from left and right gears in Main Menu.
[Bugfix] Animation Trigger Zones and Timers not working in game.
[Bugfix] Arena Previews not loading in Arena Select screen.
[Bugfix] Fixed some impact reduction values being applied twice causing an excessive reduction of spinner impulse compared to the damage output
[Bugfix] Fixed another bug in spinner vs arena hits, now they are pretty good
[Bugfix] Fixed material names in spinner scripts so that correct spark effects are triggered
[Added] Botlab Panning can now also be done with right mouse button
[Added] PrimalPower E105-10 and E105-20: more outrunners in the 5000-9000w range!
[Added] "P1 Telemetry" Toggle to bot select screen (formerly Test Match mode)
[Added] 3x new PrimalPower NM motors based on the Neumotor 8000 Series and 1x 12000 series motor!
[Added] By popular demand: 3 dumb, disgustingly powerful brushless motors in the PrimalPower X series... 80KW, 100KW and 200KW peaks...
[Added] 90 degree fillet
[Added] 45 degree fillet
[Added] Filleted box
[Added] Box with hexagon hole
[Added] Filleted hollow hexagon
[Added] Filleted hexagon hole box
[Added] Hollow corner 1/4, 1/2 and 3/4
[Added] Hollow corner 1/10, 2/10, 3/10, 4/10 and 6/10
[Added] Hollow box witt internal fillet
[Added] Round hollow box
[Added] Tetrahedon
[Added] Box with filleted triangle hole
[Added] Seperate catagories for brushed and brushless motors! should make finding things at least a little easier for now
[Added] Seperate catagories for brushed and brushless ESC's
[Buff] Upped Motenergy to 500a Cont, which is more then its irl rating but should hopefully make it last for an entire fight with a solenoid
[Changed] New Manipulation Gizmos in BotLab (What's that? You wanted to be able to see the object you're manipulating?)
[Bugfix] Fixed NPC T64 designed voltage to be 24v
[Bugfix] CoM indicator not indicating CoM
[Bugfix] Fixed camera smoothing not working properly in match
[Bugfix] Fixed camera zoom not working properly when switching cameras in match
[Bugfix] Fixed some issues on small scale PrimalPower outrunner models
[Bugfix] Set PP X240150 Dual to be brushless
[Bugfix] Commented "UnityEditor.Experimental.GraphView" in CameraController to allow compilation to work
[Added] Hobbyweight weightclass at 5.4kg/12lbsWindows: https://drive.google.com/file/d/1xixIa3uyoiBbNQGMpAzTVQvFme1uUmep/view?usp=sharing
[Added] The well known sizes of pneumatic tanks as always in game, but with their correct physical volumes and weight! Smaller, lighter, more powerful! 0.5 1.0 1.5 2.0 4.0 liters!
[Added] Prototype for damage decals, currently commented out in spinnerCollisionHandler (this is not active yet)
[Change] Recalculated all weights from the pneumatic cylinders, they all got lighter! (except for the straight cylinder HAHAHA)
[Change] Corrected all stats for pneumatic cylinders, they all have correct diameters now.
[Change] Camera now has a deadzone before moving
[Change] Camera now tracks bots origin instead of Bounds (should fix the headache inducing jittering with HUGE likes)
[Change] Changed existing pneumatic storage AND buffer tanks to stay the same volume but with higher capacity and less weight! They are perfectly inline with the new tanks but allow full backwards compatibility. Old bots stay the same physically but get more capacity! 1.2 1.8 2.6 5.5 liters!
[Change] Pneumatic storage tanks had their pressure increased from 3000 to 4500 PSI, inline with comercial high pressure vessels used in combat robots.
[Bugfix] BrocSC 200A HV no longer scalable
[Bugfix] Fixed telemetry and AI aditor being able to be active at the same time
[Bugfix] Fixed spinner components not having their collision restored once broken off
[Bugfix] Belts are now properly removed when their parent motor is destroyed
[Bugfix] Broken off motors now behave properly when broken off and no longer have their axles rotate with the original bot
[Bugfix] All high speed spinner colliders and spinners scripts are now properly removed when a spinner is broken off, removing ghost spinners and a whole bunch of glitchy side effects
[Bugfix] Fixed spinner destroy spinners colliders being called from the wrong script, preventing them from being destroyed every frame
[Bugfix] Removed the "reverse" mesh from initiated bot parts, this should give a massive performance increase to loading/decimating/simplifying/rendering and combining meshes since everything was done twice per part!
[Bugfix] Fixed a UI issue where double pneumatics displayed only half their volume