#light touch between a small and large crafts have extreme and comedic consequences (bug)
51 messages · Page 1 of 1 (latest)
Not really a bug, that's just how melee damage works now. Speed is mostly irrelevant and if you have too much then that turns into a bad thing. Mostly just comes down to mass, where the fattest thing always wins.
even so, that it can destroy blocks it doesn't touch doesn't make much sense
He's not dead he's just been sent to another dimension
Sounds like the "touch-damage" is now of the type that spreads to neighbor blocks until runs out of damage.. Maybe it could work better if it only did damage to a block it touches (even if insane overkill), and add some kind of forces to both parties (bigger of course doesn't change much, smaller would get nice slow down, thus limiting how many blocks end up touching and breaking).
I.e. damage amounts wouldn't change (per block-on-block interaction), but total damage actually caused would get limited with the speed changes.
Fast enough small vessel would still end up vaporized (as it would not slow down enough), as expected, but a very slow small vessel might fully stop with just one to few blocks broken.
@tawny saffron bro my ship looks like its been scraped off from all the metal LOL
Just gonna say, its how the game works, if you touch something you get thump damage (also melee damage) when that tiny guy touched the ship, it recieved a shitton of thump damage
And thump damage does not stop until all of its kinetic damage is gone, this ended up being sent into another dimension because it could not sustain such absurd amount of damage
Touch damage is thump damage I believe. Same as hollow points and rams. To my knowledge that's been true since 2016 or earlier.
I know
I basically just lost my entire tsunami division in that battle because of them touching the side of the craft, it's happening a lot lately
But, it sounds like this would be feature request, not really a bug. (It works as intended, though that intention has revealed out to be garbage.)
better then melee being completely broken overpowered like before
Though it sounds to me like its just as broken overpowered now, too... just in a different way. (Probably more difficult to abuse, though; making a huge ship to ram into a smaller one is not as easy as the other way around. And easier for the small one to avoid it.)
it is very easy to abuse. hovercraft HA brick can just land on stuff and vaporize it
and anything big should just be set to combat distance 0 cause worst case it's an even trade
so it means pretty much anything big is at least partially a frontsider, which makes them easier to design and gives some advantages
the touch of death
the dim mak
Depending on the movie.. In a specific one, dim mak interpretation applied to FtD would mean that 80% of ship survives (the side closest to the collision), and the part furthest away vaporizes.
the touch of destined death 🗿
Seems to me like the damage should just go both ways. If you do heavy damage to something with a part that isn't designed to be used as a melee weapon, why wouldn't it also take significant damage? You know, Newton's third law: for every action, there's an equal and opposite reaction.
going both ways would be overpowered for the tiny craft, I'm just saying the trade shouldn't swing with relative size, but something else (I'm not one to confidently make a suggestion there but some formula stopping it from being stronger while avoiding total anhilation of non-ramming tiny crafts)
How would it favour small craft? The same amount of damage it takes to cripple and/or destroy a small craft isn't going to do the same thing to a larger one. It might not even be enough to completely penetrate it's armour, depending on how thick it is and what it's made of, but it should at least do enough that it isn't completely pointless to try. If a thump projectile (such as cram or missile) can do noticeable damage, you'd hope that a whole craft would also do a non-negligible amount of damage when it rams something. Doesn't necessarily need to be practical, just so long as it's not literally useless
basically rams make the smaller craft not take damage, so if they're on a purely speed dependent formula then multiple smaller crafts get an advantage, which I think was the old way it was
I never said anything about it being dependent on speed
I just wish the damage was somehow in a way there isn't enough thump to obliterate a whole tiny non-rubbered/non-ramming craft distributed but that small crafts don't excessively gain in power
What if the damage formula is reverted back to mv² (or something similar that doesn't make mass scale the damage so much, like sqrt(10000m)v?), but the more massive a craft is, the less damage it takes? Maybe a damage multiplier similar to this graph, where it's full damage at 0 mass, and does less the more mass the "target" has?
In this example, the x axis represents thousands of mass.
In short, this would mean that small fast craft can still deal a lot of impact damage, but the damage is significantly reduced when the target is massive.
could have speed scale regularly for normal velocity and then have it sharply decrease in effective damage that way regular gameplay isn't bothered much but high speed collisions don't deal ludicrous damage
yeah, issue is if just slight touches get to do a good damage amount it's a bit ehh
But I wouldn't be too hasty about "solutions"
it's just important to bring awareness that it's not an issue for just pissy people but an actual one
since everybody in ftd has to face collisions between their crafts, it's just inevitable right now.
needs to be some sort of cube root function methinks to make sure that rammer swarms aren't OP but that it also doesn't go out of control with big things
The closest my brain could comeup with would be similar to the Laser reduction formula so you get an ever increasing effectiveness reduction idunno
and that big things hurt eachother still (which i've found to be a very good change that big things ramming eachother can do some proportionately good damage now)
Wouldn't the idea I explained earlier work? I.e. let the collision cause damage only to the colliding blocks, and add a force (with the obvious direction of "away") that naturally ends up slowing the relative movement towards collision, which ends up limiting the damage on the basis of masses and speeds. (And if either craft keeps on pushing really hard, it can keep on doing damage longer, for both.)
Damage caused (per step) can then be more easily balanced and based on whatever wished, since the speeds will be naturally limited (neither side will not insta-vaporize).
issue with that imo is if one of the craft is so fast it starts clipping a bit
I think there was a reason why it became such heavy thump
can't quite remember
If there is clipping (for whatever reason), perhaps apply the damage to all blocks that are clipping (and calculate the force as sum of forces over those multiple blocks). I.e. basically sum of individual block damage and force effects over the simulation step.
I do admit I haven't thought all that fully through at technical level, but at least it sounded more straightforward, yet being a method that can't do totally unrealistic level of damage to distant parts.
Sure, thump damage is just as fine.... IF that thump damage was calculated with a well balanced formula. Which it obviously currently is not.
the issue is more of what the game and engine can handle without years of work or insane CPU loads
Well, the way I suggested shouldn't be insane CPU load; the force simulation is already part of it all, so it would just be one extra force per step, comparable to explosion "jolts", should be trivial.
The damage calculations and applying to blocks should actually be less than currently (full ship thump damage vs. just a small fraction of ship getting damage).
Might require some work, though, to make the "which blocks to give damage on collision".
Biggest issue with that is performance. Rather than a collision checking once and dealing damage once, it does it for every single block, one at a time.
It could easily require more than 10-100 times as many calculations in the same timespan, just for the same collision, which would cause a noticeable slowdown whenever there's a collision, especially if both craft have lots of blocks in contact.
It's a similar logic to why the motion of craft are simulated as a single entity with many components, rather than many entities all trying to do the same thing. It's unnecessary workload for little to no practical benefit.
Eh, it should not be that bad.
First, it would not do it in the same timespan (unless the collision is very very high speed, like moving more than 10 blocks per frame, which afaik would correspond to 400m/s). Current method may end up traversing the whole ship (and lots of block in the other party, too) "instantly". My method would handle typically much less blocks per simulation step, though the per step calculations may need a bit more calculations to find the intersecting (i.e. colliding) blocks. And there are plenty of optimization opportunities for that, and even more than usual since this game doesn't even try to do realistic simulation (i.e. crude estimations can give good enough results).
My method would do more collision checks than with the current method, but the game already does the necessary initial collision checks. But instead of doing thumb damage travelsal, it would check how many more blocks would collide in that step (this is the costly part). Apply damage to those, calculate estimated single force impulse for that step based on the damage done and collision directions. Both of those are linear effort, basically trivial.
My initial suggestion approached this as block-by-block, and that might have been impossible to optimize well; but the later note that vessels can move per frame more than one block's distance lead to needing to handle a volume of blocks per frame, and that allows optimizations. No need to do full standard collision check for all the blocks around...
But, it might need quite a bit of work to implement efficiently. (Unless there are ready made algorithms for at least some parts of the problem.)
Though this is starting to sound more of a #tech_discussion topic 😛
My understanding of physics sims is that collision checks are definitely on the more expensive side of things. If you've ever seen a simulation/game that has lots of loose objects, more often than not, the performance will noticeably tank if you make a massive pile of stuff collide with itself/each other.