It's even conceivable that a passenger might leave if a certain level is not maintained (perhaps the banging starts half way to destination )Disembodied wrote:But it's definitely more of a factor for passenger contracts, where passengers would believably pay a premium not to travel in a ship with a funny smell, and/or where the drive train makes a series of intermittent banging noises every 8.4 minutes. (What we need is a TripAdviser OXP ... or an addition to the Reputations OXP where passengers can give reviews of the flight. )
Proposal for 1.82: updates to service level / maintenance
Moderators: winston, another_commander
- Venator Dha
- ---- E L I T E ----
- Posts: 329
- Joined: Sun Feb 23, 2014 11:26 am
- Location: Sweden
Re: Proposal for 1.82: updates to service level / maintenanc
Taurus Driving through the galaxy since... .
Re: Proposal for 1.82: updates to service level / maintenanc
I know it's extremely "late" in this discussion, but a slight decrease in acceleration of the player's ship at low maintenance levels might be a game balance feature as well. You can still reach top speed, it'll just take longer to get there.
- Cholmondely
- Archivist
- Posts: 5364
- Joined: Tue Jul 07, 2020 11:00 am
- Location: The Delightful Domains of His Most Britannic Majesty (industrial? agricultural? mainly anything?)
- Contact:
Re: Proposal for 1.82: updates to service level / maintenance
cim wrote: ↑Wed Dec 10, 2014 9:11 pmLooking at the discussion in the OXP thread, how about this as a potential solution for 1.82. As always, all comments and thoughts are welcome.
EDIT: A few edits to the original proposal based on discussion are highlighted
Mechanics for servicing
If we're making it possible to service early, there should be costs and benefits to doing that - and ideally in most situations it should be the wrong choice to do so.Effects of low SL
- Extend the service level (SL) range to 0-100 (currently it runs 75-100)
- Double the chance of losing a point of SL - so it'll drop to 50% about as quickly as it currently drops to 75%. (There's rescaling elsewhere so this shouldn't have any gameplay effect - I just don't think there's enough bad stuff to fill in three times as much space as we currently use).
- Above 70% SL, the effects should be trivial, if at all noticeable. You're running on the normal servicing schedule for your ship, and normal redundancy, engineering tolerances, etc. should keep things going basically to spec.
- At 70% SL maintenance starts being offered as before. The first time you dock at or below 70% SL, you get an arrival report stating that servicing is now due. Unlike in 1.80, maintenance always restores you to 100% SL. If you ignore it, the effects of low SL will get more severe, but shouldn't be too bad until you get below about 60% SL.
- Above 70% but below 100% SL, you instead get offered a "tune up" (needs a better name). This also restores you to 100% SL but the description will make clear that it's for early servicing and only really necessary if you expect to be away from a decent shipyard for a while.
- As currently, the cost of maintenance/tune-up depends on the service level of your ship and the cost of your ship + equipment.
- The Tech Level quality of maintenance servicing, instead of changing what SL your ship gets set to, sets a hidden parameter which controls the servicing decay rate. Get serviced at a TL:15 system and you might be able to go a while without another even if you put your ship above recommended limits regularly ... get serviced at a TL:7 one, and you might need another one fairly soon even if you don't do anything exciting.
- New ships (and the player when they start a new game) get the minimum servicing decay rate.
- Getting a "tune up" will increase the servicing decay rate, especially if done at a low TL system. Eventually the decay rate gets so high that "tune up" stops being offered and you have to buy a full service. (Note that this means that tuning up too often can cost you a fair bit more in the long run)
- The TL at which servicing is available will no longer be fixed. Instead, you'll need to be at a system no more than 3(?) TL lower than the TL of your ship (i.e. almost anywhere can maintain a Python, but an Asp needs a proper shipyard). We might want to adjust the TLs slightly for this, too.
- A full service takes considerably more time than before. (A week, perhaps?). Tune-ups would continue to take the 6-12 hours a service currently does. This makes planning both around time-critical activities a bit more important, I think.
There's a few extras here to make it worth having SL at all. Anything else?Things which reduce SL
- The trade-in price of your ship is reduced by the cost of a service/tune-up (whichever applies), rather than it being a multiplying factor.
- Fuel cost changes exactly as before. It's trivial at any SL and not going to be worth tuning up regularly just to avoid it.
- Once you get below 60% SL, the chance of damage hitting cargo or equipment starts increasing significantly. Before that point it'll be mostly flat. The mechanism for increasing this will be made slightly more predictable than it currently is.
- Below 50% SL the laser cooling rate worsens.
- Below 75% SL the low SL starts to show up in the player's exhaust plumes as occasional flickering. This is entirely cosmetic. Also in cosmetic changes, the occasional odd noise (e.g. the alert siren going off at condition green) though OXPs which add engine sounds could do a lot more with this.
- If "equipment disruption" is included (see optional section below), equipment stays disrupted longer below 70% SL, and may spontaneously switch into a disrupted state below 50% SL (at really low SL it may be more accurate to say it may occasionally switch into a non-disrupted state)
- Misjump chances are reduced from the current ones above 70% SL (and impossible at 100% SL, as a quick fix to ensure that a new Jameson's first jump is not a misjump, though their second might be if they're really unlucky). Between 60% and 70% SL has roughly the current misjump chances, and below 60% the chances get significantly higher.
- Contracts, especially passenger contracts, will pay less or refuse to travel altogether as SL decreases.
- We could start draining max speed / turn rate / energy recharge rate once you get below 60%. I'm not convinced this is worth doing, though.
Things which cause unusual stress to your ship, here. Any others?Equipment disruption (optional)
- As before, making witchspace jumps has a chance of reducing SL. A misjump (forced or random, but not from following someone else's wormhole) will always reduce SL.
- As before, combat damage has a chance of reducing SL if it doesn't damage equipment or cargo directly.
- Cabin temperatures in the critical zone have a chance of reducing SL (even more so if your ship is taking damage from the heat)
- Overheating lasers may reduce SL but only if you're already below 60% SL.
I've mentioned this idea before, but I think this is a better place for it, perhaps.Alternative option
- Equipment gains a state between "normal" and "damaged" called "disrupted". Disrupted equipment can't be used but will automatically return to normal after a small delay (~5 seconds).
- Not all equipment can be disrupted (e.g. heat shielding can't) - for compatibility this would have to be allowed by an explicit property on the equipment.
- Lasers can be disrupted (but not damaged) - it sets the temperature to something really high rather than having the normal effect.
- If disrupted equipment is hit by a second disruption effect before it recovers, it gets damaged instead (assuming it can be damaged).
- Disruption would normally happen only when taking internal damage, but would be quite a bit more likely than equipment damage currently is.
- Maybe add some hidden non-damageable but disruptable equipment, which is tied to various HUD dials. So there's a chance if you get hit your scanner/compass/shield gauge/etc. blinks off for a few seconds.
- Get rid of Service Level entirely and make the current JS value always return 100% SL for compatibility. It's not a very effective money sink at the moment, and the penalty for ignoring it is negligible. So, an alternative to trying to make it interesting enough to add fun, we could just take it out and simplify the game a bit.
Looking back on all this a decade later, how much was eventually implemented?
I get the impression from gameplay that virtually nothing was.
And I noticed nothing on the Announcing Oolite v1.82 post.
Musings
I could not disagree more with Smiv's comment:
If I'm only ever flying around Ceesxe and servicing my ship there (no pirates, almost never any Thargoids - and those which visit are picked off by the massive local Galcop forces), fair dibs!Smivs wrote: ↑Fri Dec 12, 2014 2:27 pmThe more I think about this the more I'm thinking maybe we should keep it simple. After all servicing my car is not a major decision hassle in my life - I know when it's due and I just do it around the right time. So I'm thinking now that a bit of advance warning is all we need, so we can plan around it (find a decent TL world) and have the option of having it done a bit early if that makes sense at the time.
But if one is traipsing around anarchies and need to escape or dogfight, then choosing servicing becomes rather more significant. Especially if it affects top speed and other stuff (as it does in Hard Way, affecting top speed, energy recharge rate and solar flux scooping rate).
Now I can see Redspear's fun arguments (or RalphHH's) coming in as an objection to all this, but not Smiv's car servicing!
I also note that this thread ignores the presence of the large
on the Anaconda, etc. who ought to be able to take care of much of the maintenance/servicing in-flight.https://wiki.alioth.net/index.php/Crew wrote:crews
I do find the lack of variation in cost of maintenance quite peculiar. For an unimproved Cobra Mk. 3 it is always 1,000₢ unless the service level slips significantly or one visits an OXP station. Seems unreal.
And of course, if Phkb implements his Thoughts on long term system stat changes and reflects the "Oolite Lore" then finding decent maintenance could be similar to getting decent car maintenance in the Gaza Strip as it currently is.
Edited to flag up my query (now in red!)
Last edited by Cholmondely on Wed Apr 10, 2024 5:28 pm, edited 1 time in total.
Comments wanted:
•Missing OXPs? What do you think is missing?
•Lore: The economics of ship building How many built for Aronar?
•Lore: The Space Traders Flight Training Manual: Cowell & MgRath Do you agree with Redspear?
•Missing OXPs? What do you think is missing?
•Lore: The economics of ship building How many built for Aronar?
•Lore: The Space Traders Flight Training Manual: Cowell & MgRath Do you agree with Redspear?
- Redspear
- ---- E L I T E ----
- Posts: 2685
- Joined: Thu Jun 20, 2013 10:22 pm
- Location: On the moon Thought, orbiting the planet Ignorance.
Re: Proposal for 1.82: updates to service level / maintenance
I'm not disagrreing with you here oh Cholmongous one, really I'm not. But I would like to make that point that it highlights an issue with real world analogies. Just when you think you've found the perfect one, someone or some thought comes along and finds that, by stretching it just a bit, it all falls apart.Cholmondely wrote: ↑Wed Apr 10, 2024 8:04 amNow I can see Redspear's fun arguments (or RalphHH's) coming in as an objection to all this, but not Smiv's car servicing!
I like analogies, I'm just of the opinion that they're more useful as mental vacations rather than domiciles.
Wow. Did I finally type a sentence here that truly explains itself?... Probably not
- Cholmondely
- Archivist
- Posts: 5364
- Joined: Tue Jul 07, 2020 11:00 am
- Location: The Delightful Domains of His Most Britannic Majesty (industrial? agricultural? mainly anything?)
- Contact:
Re: Proposal for 1.82: updates to service level / maintenance
The correct use of analogies is a tricky thing. Whether in biblical hermeneutics or in philosophical logic. But I'm amused that Smiv's analogy proves my side of the argument rather than his.Redspear wrote: ↑Wed Apr 10, 2024 2:01 pmI'm not disagreeing with you here oh Cholmongous one, really I'm not. But I would like to make that point that it highlights an issue with real world analogies. Just when you think you've found the perfect one, someone or some thought comes along and finds that, by stretching it just a bit, it all falls apart.Cholmondely wrote: ↑Wed Apr 10, 2024 8:04 amNow I can see Redspear's fun arguments (or RalphHH's) coming in as an objection to all this, but not Smiv's car servicing!
I like analogies, I'm just of the opinion that they're more useful as mental vacations rather than domiciles.
Wow. Did I finally type a sentence here that truly explains itself?... Probably not
But they are useful. Too much of the way we think about things relies on them. And in the world of Oolite, the legal system will have been derived - by analogy - from ours (space-ship trade <> ship trade; space-ship insurance <> ship insurance, etc.). As a matter of interest, the principles of ship cargo insurance were reputedly laid down in the then independent miniscule maritime republic of Amalfi (south of Naples) back in the Dark Ages!
Comments wanted:
•Missing OXPs? What do you think is missing?
•Lore: The economics of ship building How many built for Aronar?
•Lore: The Space Traders Flight Training Manual: Cowell & MgRath Do you agree with Redspear?
•Missing OXPs? What do you think is missing?
•Lore: The economics of ship building How many built for Aronar?
•Lore: The Space Traders Flight Training Manual: Cowell & MgRath Do you agree with Redspear?
- Redspear
- ---- E L I T E ----
- Posts: 2685
- Joined: Thu Jun 20, 2013 10:22 pm
- Location: On the moon Thought, orbiting the planet Ignorance.
Re: Proposal for 1.82: updates to service level / maintenance
The correct use of the word 'proves' is also a tricky thingCholmondely wrote: ↑Wed Apr 10, 2024 5:26 pmThe correct use of analogies is a tricky thing. Whether in biblical hermeneutics or in philosophical logic. But I'm amused that Smiv's analogy proves my side of the argument rather than his.
Yes, a sort of time saver to get started with something.
I think they're most useful when, having first noticed the similarity, we go on to think about how they might be different.