Cataclysm-dda: Disable or complete vehicle fault system for 0.D

Created on 28 Feb 2017  Â·  18Comments  Â·  Source: CleverRaven/Cataclysm-DDA

The vehicle fault system isn't complete. It doesn't allow scavenging parts from engines and seems that Perfect Reliability mod is broken (at least it is reported as broken on forums).

No one is working on it right now and it didn't get many cheers back then when it was alive, so I'd disable it and even consider fully dropping it - if anyone decides to reimplement it, the current implementation won't be of much help.

<Suggestion / Discussion> Mechanics Change Vehicles

Most helpful comment

Nah, we'd just need an engine lift requirement, just like we have jacking for tires. Heck, as a stop gap, you could use jacking. It's a perfectly valid method to support the engine on jack stands, remove it's connection to the engine compartment, jack the front of the car up, drop the jack stands and yank the engine out from underneath.

All 18 comments

I had looked into simple ways to disassemble engines for parts, but there is now easy way at present for a recipe to change components returned based on the faulty item status.

In quality of life terms, engine faults are a minor annoyance but do not significantly increase the odds of an otherwise ideal vehicle spawning in unusable condition. Compared to the difficulty of finding jacking quality, I have encountered few cases where engine faults have caused me any problems.

That said, if they are feature-incomplete and the mod to disable them is no longer working, it should be hidden or dropped for the next stable release, even if I personally would rather see jacking quality go sooner.

"Incompleteness" has never been a rationale for removing something, if it
were we'd just delete the game and call it a day.

Mods disabling features are the responsibility of people who care about
disabling them, and their failure certainly isn't a reason to disable the
associated feature. If you want them to keep working, test them regularly
and report breakage, and monitor new PRs that add functionality to the
disabled features.

If you think vehicle faults as implemented are bad for the game, make your
case for that, don't pretend there's some objective development rationale
for removing it.

"Incompleteness" has never been a rationale for removing something, if it were we'd just delete the game and call it a day.

0.D is supposed to be stable. Stable implies a certain degree of local completness.
For example, I'd like the bionic slot system to eventually land, but for 0.D I'd rather disable everything associated with it and keep it debug-only.

If you think vehicle faults as implemented are bad for the game, make your case for that, don't pretend there's some objective development rationale for removing it.

There is an objective rationale for not bundling them with stable. Them being bad for the game is a separate thing.

On Wed, Mar 1, 2017 at 3:08 AM, Coolthulhu notifications@github.com wrote:

"Incompleteness" has never been a rationale for removing something, if it
were we'd just delete the game and call it a day.

0.D is supposed to be stable. Stable implies a certain degree of local
completness.

No, it doesn't, it implies stability. "Complete" is a property that is
never achieved in software, software is "finished" or "good enough", it's
never complete.

I'm at a loss for what you're trying to get at, because you seem quite
certain of it, but it makes no sense, maybe you mean "consistent"? Even if
so, that requires the same burden of proof, namely that the inconsistency
has some impact on the player.

For example, I'd like the bionic slot system to eventually land, but for
0.D I'd rather disable everything associated with it and keep it debug-only.

That's a circular argument, you find this argument compelling in another
context, so that makes it compelling here. I don't find it compelling in
either situation.

If you think vehicle faults as implemented are bad for the game, make your
case for that, don't pretend there's some objective development rationale
for removing it.

There is an objective rationale for not bundling them with stable. Them
being bad for the game is a separate thing.

That's nonsense, if there is no negative impact on the player, it's
irrelevant whether it's enabled or not.

That's nonsense, if there is no negative impact on the player, it's irrelevant whether it's enabled or not.

It does have a negative impact on the player, but it in context it is minor. That a valuable, otherwise functional vehicle may be ruled out due to an engine fault would obviously be a challenge to the player, that would be a negative from their perspective. The issue is whether that negative is an acceptable challenge or merely an annoyance.

In practice, there are already so many things that can generate damaged or broken that, in my own experience so far, I have only encountered a small number of vehicles that would have been perfectly usable were it not for a faulty engine. Non-functional wheels, damaged controls, fuel tank damage, etc are all vastly more common.

"Complete" is a property that is never achieved in software, software is "finished" or "good enough", it's never complete.

Not sure what your argument is here. Software is never 100% complete so cleaning up WiP features for a release is stupid?

I'm at a loss for what you're trying to get at, because you seem quite certain of it, but it makes no sense, maybe you mean "consistent"?

It makes sense to majority of developers. Not sure what is so hard to grasp here.
Release builds are not experimental builds. Not "let's try if it works in release build", but "no time, just cut it out". It's an incredibly common thing in gamedev to cut features that didn't make it to release.

That's nonsense, if there is no negative impact on the player, it's irrelevant whether it's enabled or not.

Negative impact on the player is additional level of complexity that offers nothing of value, is misleadingly anti-realistic (replacement parts are much rarer than working engines with those parts in them) and achieves only tedium and annoyance by adding an extra step to verifying if a car works.
It's a "feature" that is only low on annoyance because it is rarely triggered. If all broken engines were faulty and repair system for them offered feasible alternatives to plain installing a different engine, it could be something more than a different, more annoying, way to mark an engine as broken.
It has characteristics of an idea that wasn't fully implemented yet, has plans for it, but sucks enough in current incarnation that it isn't even universally enabled (affects only a rare subset of cars).

Hence my idea: finish, disable or fully drop.

Ok, reasons, and as expected they boil down to "I don't like the feature".

additional level of complexity that offers nothing of value

Totally subjective, it's an attempt to say WHY engines are failing in addition to just saying that they are, and have the repair process be meaningful (scavenging parts and installing them as opposed to "apply welder to engine"). I'm really sick of this kind of over-abstracted bullshit in games, and it's why I'm working on DDA in the first place, so there's at least one game that takes this shit seriously instead of stripping so much detail out of the world that it's meaningless.

replacement parts are much rarer than working engines with those parts in them.
If all broken engines were faulty and repair system for them offered feasible alternatives to plain installing a different engine

Valid, so the feature ask is ability to strip a replacement part out of a working engine and rebalance numbers to make these failures significant. (in that order of course)

Hence my idea: finish, disable or fully drop.

Finish, if the mod to disable is broken, feel free to fix it, dropping isn't really an option.

Considering the low rate of failures, I don't buy the argument for this being a 0.D blocker.

I'm really sick of this kind of over-abstracted bullshit in games, and it's why I'm working on DDA in the first place, so there's at least one game that takes this shit seriously instead of stripping so much detail out of the world that it's meaningless.

Some abstraction is necessary, or else the game ultimately will become a real life simulator, only with the addition of an apocalypse. It is just a matter of opinion as to which elements are desirable, and therefore your own belief that vehicle faults are essential is also just as subjective as the belief that it is pointless realism.

Do you believe that the game needs for player character to urinate and defecate as part of their survival needs? If not, then you consider it better to abstract away that need, despite your claims that the game should not contain "over-abstracted bullshit," even if in this example (please excuse the pun) the bullshit would potentially be literal (in the case of bovine-mutant characters).

Totally subjective, it's an attempt to say WHY engines are failing in addition to just saying that they are, and have the repair process be meaningful (scavenging parts and installing them as opposed to "apply welder to engine").

Not "apply welder to engine", but "replace engine with a different one because majority of faults are almost fatal and fixing them is harder than replacing the engine".
Note that faults do not appear on their own, but only in spawned vehicles.

Faults do not add depth to game. They add complexity.
Complexity of having to make a different check for the same result: part doesn't work. Whether it doesn't work because it is damaged or lacks an irreplaceable part ("replaceable" but rarer than power armor) - that doesn't matter when the effect is the same.

IMO as a player the fault system is flawed. Not in concept but implementation.

For this reason I would vote for dropping in favour of a more gun like system for combustion engines.

Engines could have the exact same faults as now, but could offer the added complexity of gun mods.
In this system you could have slots for drive belts, air filters, immobilisers, etc. if these are missing or broken, engine fails, but could be scavenged and found from other engines. Could even be replaced with "better" versions of said parts.

An "accessory" slot or two opens up the engines to the possibility of tuning and modding for those that way inclined. As I understand it, it may be too difficult as turrets never "use" the mods status from guns, but are fixed values, if these things are tied in the vehicle code, it may be time to re-examine it, to free both things to work?

Not "apply welder to engine", but "replace engine with a different one because majority of faults are almost fatal and fixing them is harder than replacing the engine".

Yeah, I'd say that is a good reason to drop it right there. In almost all cases it is just plain easier to find a whole replacement engine than to find a replacement part. When the player's first thought is "Well damn, better strip out the engine for a new one" rather than "damn, I gotta find a fix" something is broken.

Which, come to think of it, says something more about the ease of replacing engines than anything else, but still.

On Mar 2, 2017 12:49 AM, "Coolthulhu" notifications@github.com wrote:

Not "apply welder to engine", but "replace engine with a different one
because majority of faults are almost fatal and fixing them is harder than
replacing the engine".

That is itself a problem, in reality, replacing an engine is monumentally
difficult. It is made artificially easy because otherwise you would be
forced to discard a vehicle if the engine were destroyed. The faults
system is there to introduce fixable faults to engines to break this
deadlock. The final form would have engine installation be appropriately
difficult, and engine maintenance be relatively routine.

Note that faults do not appear on their own, but only in spawned vehicles.

This is for now yes, but eventually all engine breakage other than total
destruction should be handled with it.

("replaceable" but rarer than power armor) - that doesn't matter when the
effect is the same.

Yep, need to be able to harvest them from existing engines.

Yep, need to be able to harvest them from existing engines.

Can we count on that occurring before 0.D? Stable with a disruptive yet incomplete feature is bad code quality.

Nah, we'd just need an engine lift requirement, just like we have jacking for tires. Heck, as a stop gap, you could use jacking. It's a perfectly valid method to support the engine on jack stands, remove it's connection to the engine compartment, jack the front of the car up, drop the jack stands and yank the engine out from underneath.

I'd like to see a bit more of an expansion on the engine fault mechanics, at the moment it's simply not worthwhile to hunt garages for obscure parts.
Being able to disassemble engines would be a good start, of course there is always the level of complexity to flesh out.

Perhaps being able to 'scavenge' parts from an existing engine(rendering it broken in some way) would a better interim feature, as that would at least make repairing faults more worthwhile than simply swapping the engine.

Engine addons would be an interesting feature, perhaps one could find some rare modifications to attach to an engine that alter it's stats in some way.

On Mar 3, 2017 6:56 AM, "Wayde" notifications@github.com wrote:

Perhaps being able to 'scavenge' parts from an existing engine(rendering it
broken in some way) would a better interim feature, as that would at least
make repairing faults more worthwhile than simply swapping the engine.

That's what I was thinking of, remove a spare part foo you need from an
enginw, and the engine gets a "missing foo" fault.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
https://github.com/CleverRaven/Cataclysm-DDA/issues/20412#issuecomment-283974880,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA0gdFip0Qxc2tgm_-AkwFehXLsFw2Mfks5riColgaJpZM4MOSwO
.

Can we count on that occurring before 0.D?

This seems easy at first glance, so I think so.

Closed in favour of #18419

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Taberone picture Taberone  Â·  3Comments

busterbogheart picture busterbogheart  Â·  3Comments

ituluwituluwzev picture ituluwituluwzev  Â·  3Comments

Taberone picture Taberone  Â·  3Comments

BorkBorkGoesTheCode picture BorkBorkGoesTheCode  Â·  3Comments