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 ... 16 17 18 19 20 21 22 [23] 24 25 26 27 28 29 30 ... 49
441
« on: December 20, 2019, 12:19:25 PM »
Thats grat, damage multiplier untouched i guess
Fixed! It is now a continuous slider.
442
« on: December 20, 2019, 12:10:03 PM »
New build is building right now. While we wait:
[Bug Fix] Flames no longer do damage directly. Instead they add heat by calling the takeHeat() method. Eventually this will result in damage.
[Bug Fix] Self collisions are no longer possible for a robot. Self collisions were causing robots to randomly launch themselves around. Each robot is now on its own separate collision layer.
[Bug Fix] The speed limiter for broken parts is now disabled after 0.5 seconds.
[Changed] The Damage Multiplier slider in settings now allows for continuous adjustment from 0% to 200%. [EDIT]
[Changed] Any time takeDamage() is called,
// Subtract 50% of the max health of the component from the damage.
// This should prevent any damage that is ridiculously small from accumulating.
// If the result is less than zero, set the damage to 0.0f.
443
« on: December 20, 2019, 11:31:44 AM »
Yeah 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”.
444
« on: December 20, 2019, 11:22:13 AM »
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.
445
« on: December 20, 2019, 11:09:56 AM »
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. [ Quoting of attachment images from other messages is not allowed ]
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 think I have a good permanent fix for this. I put each robot on its own layer. Any parts on this layer can’t collide with each other. I’ll try to get the fix out today or tomorrow.
446
« on: December 20, 2019, 11:04:31 AM »
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.
447
« on: December 20, 2019, 05:39:04 AM »
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)
448
« on: December 19, 2019, 09:28:32 PM »
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. [ Quoting of attachment images from other messages is not allowed ]
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 have an old version of Panic Attack from October 21st, as well as the new version you just sent me. The old version seemed to work okay. For some reason the flipper's limit angles weren't set properly in the new version. Once I set the limit angles, things seemed to work okay. My computer is really struggling with frame rate at the moment, but once I can get that under control I will try to get a video showing both versions of Panic Attack going head-to-head. Edit: Here's a gif showing how it is working in for me. Please excuse the low resolution. I had to turn things way down because my laptop is chugging: 
449
« on: December 19, 2019, 08:52:33 PM »
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.
450
« on: December 19, 2019, 12:58:48 PM »
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.
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. 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?
451
« on: December 19, 2019, 12:38:17 PM »
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
I'm really struggling with this conceptually, and could use some help with this: 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. 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.
452
« on: December 19, 2019, 11:17:49 AM »
Ok so some feedback:
1. Flame pit instantly breaks off parts
Found and fixed the problem. Thank you guys for pointing it out. I feel like I should have caught it. *sheepish* 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
Good to know. I might retune the slider to give a 25% option. 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
This might be tough to do. I will have to think about it quite a bit and ask @tashic to see what he thinks. It would require additional stuff in the .RR2Bot file. It would also require new UI. 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? 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?
453
« on: December 19, 2019, 11:10:11 AM »
oh 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?
454
« on: December 19, 2019, 09:27:24 AM »
The new build is live! It is dated 12December2019, and includes the features and fixes in the preceding post. Yay alliteration! https://robot-rumble.itch.io/buildsHere's a screenshot showing the new mirroring feature: 
455
« on: December 19, 2019, 06:02:34 AM »
Settings menus are a mess. It is going to take more time than I have today to get them working correctly in every scene. Right now settings menu in the "Test Arena" seems to work correctly. It is the only settings menu with the damage slider. All of the other settings menus are in various stages of nonfunctional. I'm going to put together the build as it is right now and push it out to itch.io today: [Added] Botlab "Mirror" function - Components and assemblies can now be mirrored: - If the option on the left of the screen is toggled on, players can place the component picked and the mirrored version of that component.
- Changes done to one of the components will be transfered to the other and vice versa (the only place when that doesn't happen yet is the "Painter" screen).
- The components that have a mirrored counterpart will have a "Mirror_Pair" script for the mirror information. For left/right side drive motors, by default the mirror version will be set as the opposite side, but an option has been added to keep both sides the same.
- Removing a component with a mirrored version present, will leave the mirrored version and remove it's mirror_pair script.
- Added a small description for the mirror options in the help for the screens where you place components.
[Added] Belts/Chain/Pulley transmission components can now be stacked. [Added] Breakage - Entire component chains can now be broken off. I.e. If a shape with an attached motor breaks, the shape, motor, and everything attached to that motor all break off together. [Added] Added a "Damage Multiplier" slider in the Test Arena settings menu. Please note that this slider only works in the test arena. Work still needs to be done to get the settings working correctly throughout the entire game. [Change] You can now make your own rubber wheels! When a shape's material is set to "Rubber", a Weapon_Blur_Cylinder is not attached to it. The weapon blur cylinder was previously attached to all spinning shapes. It was designed to handle the collisions of a high speed spinning weapon, but made wheels drive horribly. In the new build, if you select "rubber" for the material, the game assumes you are making a wheel and won't attach the blur cylinder, allowing you to create wheels that drive normally. [Bug Fix] Fixed a problem for all spinners which caused a robots spinner to collide with the rest of the robot, causing the robot to fly around wildly. This made spinners unplayable for the most part. [Bug Fix] Bubblegum now sits flat and drives correctly. This was due to a similar issue as the bug fix listed above.
456
« on: December 18, 2019, 08:54:33 PM »
Bubblegum is fixed! There were two overlapping colliders whose collisions weren't being ignored. Bubblegum sits flat and drives straight now.
I still have to get the different settings menus squared away. I'm hoping to fix those and push out the build in the next 24 hours.
457
« on: December 18, 2019, 08:33:23 PM »
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.
Yup. Found it. The UI code for the battle screens is different than the UI code for the main menu. I should have them all working properly by tomorrow.
458
« on: December 18, 2019, 06:36:50 PM »
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.
Sorry about that! If it’s any consolation, I’m still developing the game on my 2013 macbook air. If I can get it to run well on this computer, hopefully it helps others with old laptops.
459
« on: December 18, 2019, 06:33:35 PM »
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.
Maybe a hotkey to hide the UI? Can you post a marked-up screenshot of what you would like to get rid of? I should have a few hours to work on it tomorrow.
460
« on: December 18, 2019, 06:31:35 PM »
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.
Pages: 1 ... 16 17 18 19 20 21 22 [23] 24 25 26 27 28 29 30 ... 49
|
Show Posts