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 ... 8 9 10 11 12 13 14 [15] 16 17 18 19 20 21 22 ... 49
281
« on: January 24, 2020, 04:07:44 PM »
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.
Robots that use the largest wheels are the least affected. Beetleweights are completely unplayable.
We are working on a fix now.
282
« on: January 23, 2020, 04:04:00 PM »
I found some weird things today. I should be able to post more tomorrow.
283
« on: January 23, 2020, 09:59:45 AM »
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?
284
« on: January 22, 2020, 10:57:49 AM »
Rats. I'm having trouble replicating the issue. Could you send me an updated version of either robot that shows the problem?
285
« on: January 22, 2020, 05:32:59 AM »
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.
286
« on: January 21, 2020, 08:40:15 PM »
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:
[ Quoting of attachment images from other messages is not allowed ]
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.
287
« on: January 20, 2020, 08:16:34 PM »
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...
288
« on: January 20, 2020, 08:04:00 PM »
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?
289
« on: January 20, 2020, 02:13:36 PM »
An undo system would make a big improvement in usability. I understand it isn’t a trivial thing to create but it would help a lot.
CTRL-Z to undo
either CTRL-Y or Shift-CTRL-Z for redo
Some other useful ones (I’m not sure if they are in yet):
M to move
S to scale
R to rotate
M + X + right or up key to move 1 millimeter in the X direction
If we are feeling really saucy we could copy the Blender hot keys: G, R, S, etc
290
« on: January 20, 2020, 10:32:18 AM »
What if the button didn’t actually assign a part more than one parent component, but instead linked two parts together? Would that work?
There is still plenty of work to do to get it working. I will put it on the feature request board.
291
« on: January 20, 2020, 08:12:18 AM »
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.
292
« on: January 20, 2020, 07:54:28 AM »
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?
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.
293
« on: January 20, 2020, 07:25:28 AM »
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.
294
« on: January 20, 2020, 07:24:17 AM »
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!
Awesome! I will try to take a look today or tomorrow.
295
« on: January 20, 2020, 07:05:40 AM »
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?
296
« on: January 19, 2020, 07:09:45 PM »
19January2020 Alpha Build is out! https://robot-rumble.itch.io/buildsThis one has 2 bug fixes: [Bug Fix] Fixed spinner crashing bug which caused robots with spinning weapons to crash back to the Main Menu screen. [Bug Fix] Fixed a problem with the convex chassis option which caused robots to sometimes disappear and be replaced by magenta shapes.
297
« on: January 19, 2020, 07:08:49 PM »
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!
298
« on: January 19, 2020, 10:26:45 AM »
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!
299
« on: January 19, 2020, 07:13:04 AM »
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.
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  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.
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.
300
« on: January 18, 2020, 08:26:40 PM »
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.
[ Quoting of attachment images from other messages is not allowed ]
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?
Pages: 1 ... 8 9 10 11 12 13 14 [15] 16 17 18 19 20 21 22 ... 49
|
Show Posts