This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - cjbruce
Pages: 1 ... 4 5 6 7 8 9 10 [11] 12 13 14 15 16 17 18 ... 49
201
« on: February 16, 2020, 10:17:24 AM »
The motor reversion looks like it is working flawlessly. I'm hoping to have a rough cut out in the next 12 hours. The new meshes are missing for the new versions of the A40-300 and F30-400, but I'm hoping to have that fixed before we publish the build.
The old versions of the motors will no longer be visible in the list of motors, but will still exist in the game so that the old robots don't break.
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. :)
202
« on: February 16, 2020, 08:30:37 AM »
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.
Awesome! Its good to hear that immobility is starting to feel right. Mobility is key to the entire fight in real life. -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.
That's what I'm thinking too. I'm just wondering if anything should go there. Gas? A robot tree status showing what remains? Nothing?
-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 can vouch for this. In our real-life robots, the 1/2" polycarbonate we used as side armor would just explode the instant it was glanced by a spinner. We stopped using polycarbonate last year and haven't looked back. -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.
Roger. It is pretty simple to make the effect happen mechanically. Just need to write a few lines of code. I wanted to see how everyone feels first though. --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.
The tree structure that we came up with has been 3 years and thousands of development hours in the making and is the core of the whole game. It is a pretty sweet (and complicated) bit of tech at this point. If we are going to change anything about it at this point I want to be darn sure it is worth it. @something, please correct me if I'm wrong, but Battlebots robots are actually multiple robots in a single chassis. They use multiple people running independent transmitter/receivers, each controlling completely isolated electrical systems. If one system breaks, the rest can still work. Multibot battles are already in the works. Maybe down the road we can think about making 2 multi bots into a single robot?
-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.
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. Whatever broken versions of shapes exist in our game must be made by a computer-generated algorithm. I haven't seen/found/developed one that meets our needs yet. Hopefully with the larger team we will be able to put our heads together and come up with something. 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%?
Motors need to be a lot less robust than they are now. The casing on an Ampflow A28-150 is reasonably thick, but it doesn't stand a chance against a direct hit from a spinner in real life. Thats why motors go on the inside. (I'm looking at you, Nightmare! :)) [ Quoting of attachment images from other messages is not allowed ]
New version of this arena coming soon! The lighting only shows up correctly on a mac. I mistakenly assumed it was working on Windows before I published it. I promised the real version is much more colorful!
203
« on: February 16, 2020, 08:00:20 AM »
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 will see what I can do today. Guldenflame is right. You can not expect a piece of software in the Alpha state to remain static. If so that is bad because it means that the software has been abandoned and will never reach release and maintainance. There are times when we are going to have to change or remove things that are going to completely invalidate some robots. Case in point: the flail. It is broken. There is no easy way to get it working without a LOT of effort. This isn't effort that is worth the time considering how many other higher-priority things we have to do. You are also right. It absolutely sucks to see hundreds of hours of work become deprecated by a software decision someone else made. If there are any Flash developers still out there, they know what I'm talking about. With that being said, I'm going to try to restore the AmpFlow motors to the way they previously worked, but hiding them in the process. If I succeed, they will still exist in your old robot and still work, but will no longer be available in the list. If you accidentally delete the motor, it is gone and you will need to use the new version.
204
« on: February 15, 2020, 06:45:23 PM »
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.
205
« on: February 15, 2020, 03:58:46 PM »
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?
206
« on: February 15, 2020, 02:41:49 PM »
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.
207
« on: February 15, 2020, 01:37:53 PM »
Hopefully all SvL entrants are safe...
Oh man! I'm so sorry! Eep! 
208
« on: February 15, 2020, 01:36:46 PM »
FWIW, 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.  Thank you for being patient. Growing pains! Game is improving! Yay!
209
« on: February 15, 2020, 01:32:44 PM »
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.
WhamettNuht, please correct me if I'm wrong, but I'm pretty sure the scaling errors of the components was a mistake in the last build. In your commit notes from 9 days ago you had written: "Updated the Geo Cylinders scaling issues." Wasn't this a fix put in place in the current build to address the problem that Arcane mentioned about the 05February build? Arcane said, "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." Its always a little risky to build with brand new components. They have a higher chance of being tweaked down the line as we find bugs.
210
« on: February 15, 2020, 01:22:18 PM »
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 bound to screw something up. The motor sitting at a right angle is definitely not right.
211
« on: February 15, 2020, 11:44:44 AM »
The AmpFlow motors have been facing the wrong way ever since they were first put in the game. If you check out the photos on AmpFlow’s website you can see what I mean.
In addition they previously could be mounted on either side. As part of the cleanup process we fixed this so that they can only be mounted where the bolt holes lie. To be honest, this has been driving me nuts for years and I’m happy to have it fixed.
Mounting should now only occur in one side where the bolt pattern is, and the models are now flipped.
Let me check through the notes on the poorly scaled shapes, but I believe they are the correct size now.
212
« on: February 15, 2020, 11:13:15 AM »
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?
213
« on: February 15, 2020, 10:19:38 AM »
I LOVE the new look of Kat 3!  I have no idea what caused that, but would be happy to take a look. Would you mind sending the .RR2Bot for it?
214
« on: February 15, 2020, 09:09:29 AM »
The 15February2020 Alpha Build is out! https://robot-rumble.itch.io/buildsIt comes with a pretty big list of changes. Thank you to everyone on the team and to everyone on GTM who contributed so much in the past few weeks!  [Updates in the February 15th Build] [Added] Chassis armor Shape_Plates now pop off when their associated DamageableObject have health < 0. This means that it is now possible to break off the protective armor plates of the chassis, exposing the motors on the inside. [Added] ARENA MODDING TOOL: Arenas created with the Arena Modding Tool are now playable. [Added] WHEEL BUILDER: This is a new tool available in the Robot Workshop that allows you to create custom wheels. Try it and see what you think! [Added] New Robot Workshop Hotkeys: Added hotkeys for the Electronics - Extras sections, including using wasdqe to use the move/rotate/scale components. When adding components, wasdqe can be used to rotate the component before attaching it to the robot. [Added] 33mm Brushless Motor [Added] New mesh for the AmpFlow A30-400 [Added] New mesh for the AmpFlow F40-300 [Added] New Motenergy motor [Added] New Heavy Brushless motor [Added] New Pancake E-Tek motor [Added] LET THERE BE LIGHT! Some LED's for the Extras. The lights are baked to reduce strain on the CPU, but despite this they still look really good! [Added] New Component: Ball Caster. Should eliminate a lot of driving and mobility issues. [Changed] Changed the direction of the NPC and A28 motors [Changed] Updated materials for 33mm Brushless Motor [Changed] Tweaked position of AmpFlow A28-150 gearbox so that it sits flush with the motor. [Bug Fix] Fixed bug where Blur Cylinders were erroneously added to custom-made wheels attached to drive motors. This was caused because Robot_Reconstruction only checked to see if the previous component had a Control_Motor_ script attached. It now checks recursively up the "previous component" heirarchy to see if any of the parents have the script. [Bug Fix] Set the hinged rigidbody's angular velocity to zero immediately when all of the attached components break off and only the axle is left. [Bug Fix] Fixed problem with the Ampflow A28-150 gearbox axle moving out of it's position. [Bug Fix]Found and fixed the root cause of a series of gyroscopic effect bugs clearly outlined by CodeSilver23 on GTM: The root cause is that when a rigidbody doesn't contain any colliders, its inertia tensor is set to (1,1,1). This is an ABSOLUTELY MASSIVE set of moments of inertia. When the rigidbody gets up to several thousand RPM, the gyroscopic effects become overwhelming. The fix was to set the MOIs to 0.00001.
215
« on: February 15, 2020, 08:51:16 AM »
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:
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.
216
« on: February 14, 2020, 05:23:21 PM »
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.
To be honest, I'm not a skilled enough programmer to figure out how to split the biggest CPU loads over more than a single core. Physics is the biggest load right now, and it is notoriously difficult and/or impossible to split it over multiple CPUs. 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
Would it be possible for you to run the plain-vanilla version of the game without the KupaTec hack? On my end the screen resolution settings work. The resizing/scaling is wonky, but KupaTec is actually planning to do a rewrite of this for the near future. On my end, the more I boost up the resolution, the more the frame rate drops. Graphics quality doesn't have nearly as big of an effect as screen resolution, indicating my poor laptop GPUs are definitely fill rate limited.
Then i tried gfx quality settings.
Mid/ High are the same, low however
It might be shadows or post processing that is making stuff lag.
Its hard to say. It is surprising that your computer has issues with graphics settings on low. What kind of a graphics card do you have?
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:
Let me look into this. I suspect the crazy high RPMs are throwing off the wheels. It might not be easily fixable. Let me think about it a little bit.
217
« on: February 14, 2020, 04:59:19 PM »
Also, for those who don't know what I'm talking about, here is a basic visual:
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.
218
« on: February 14, 2020, 06:39:49 AM »
Sorry for being incommunicado. I’ve been out with the flu for the past few days.
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.
219
« on: February 10, 2020, 08:33:39 PM »
uh...
there seems to be a glitch with the A28-150 gearbox
Wow. Nice catch! I'm taking a look at it now.
Fixed the A28-150 gearbox for the upcoming build!
220
« on: February 10, 2020, 09:25:57 AM »
uh...
there seems to be a glitch with the A28-150 gearbox
Wow. Nice catch! I'm taking a look at it now.
Pages: 1 ... 4 5 6 7 8 9 10 [11] 12 13 14 15 16 17 18 ... 49
|
Show Posts