Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Oh Scrap!/Scrapyard support? #493

Open
baldamundo opened this issue Aug 18, 2019 · 3 comments
Open

Oh Scrap!/Scrapyard support? #493

baldamundo opened this issue Aug 18, 2019 · 3 comments

Comments

@baldamundo
Copy link

@baldamundo baldamundo commented Aug 18, 2019

Wondered if anyone has given this any thought?

Oh Scrap (https://forum.kerbalspaceprogram.com/index.php?/topic/160854-17x-oh-scrap-a-scrapyard-based-part-failure-and-reliability-mod-163-22062019/) is an incredibly good part failure mod, which ties the failure to how many times you've built copies of that part, as well as how often that particular instance of the part has been re-used. This gives a huge amount of depth to a career game, encouraging using common hardware across your stable of vehicles, giving an actual reason for test-flights, significantly nerfing/balancing reuseable vehicles, etc.

At present, the two mods seem to be perfectly compatible, and actually seem to complement each other quite nicely since the Oh Scrap failures only happen while a vessel is loaded - so generally concentrated around launch failures - while Kerbalism's happen in the background and thus better representing long-term decay.

Ultimately the Oh Scrap system is much deeper than Kerbalism's, but Kerbalism has two advantages:

  1. Part failures in Kerbalism can occur during background simulation.
  2. Failed parts in Kerbalism are displayed in the Kerbalism UI.

Is it at all feasible to integrate the two systems better? I'm guessing that either adding background simulation to Oh Scrap or part history tracking to Kerbalism would be very much non-trivial, but at a minimum, is there a way for Oh Scrap to plug into Kerbalism's API and show its failures in the Kerbalism UI?

@gotmachine

This comment has been minimized.

Copy link
Collaborator

@gotmachine gotmachine commented Aug 18, 2019

I'm guessing that either adding background simulation to Oh Scrap or part history tracking to Kerbalism would be very much non-trivial

Non trivial indeed. For now we don't have plans to expand/change the reliability feature, although there has been discussions about the inclusion of a few "activity" based failure mods (obvious example : separate failure mode for in-use engine). We are focused on other things currently.

is there a way for Oh Scrap to plug into Kerbalism's API and show its failures in the Kerbalism UI?

What do you mean by "show its failures in the Kerbalism UI" ? The failed part red/yellow highlighting ? The yellow/red malfunction icon in the vessel list ? There is not much more in terms of the Kerbalism malfunction UI.

@baldamundo

This comment has been minimized.

Copy link
Author

@baldamundo baldamundo commented Aug 19, 2019

What do you mean by "show its failures in the Kerbalism UI" ? The failed part red/yellow highlighting ? The yellow/red malfunction icon in the vessel list ? There is not much more in terms of the Kerbalism malfunction UI.

Yeah, I just mean the little yellow/red icon in the Kerbalism vessel list.

@SirMortimer

This comment has been minimized.

Copy link
Contributor

@SirMortimer SirMortimer commented Aug 27, 2019

My general approach regarding support of other mods is: don't. But allow for other mod(s) to talk to Kerbalism.

What this means in practice is that we can come up with a few API functions that will let Scrap tell Kerbalism to display failures on part X of vessel Y, maybe with an optional repair option (don't know if Scrap! allows repairs done by EVAs) and a failure message. It will also mean that the talking to Kerbalism needs to be implemented in Scrap (or any other mod).

The reason I'd like to do it this way is that Kerbalism already has quite a large code base, and adding support for a multitude of mods that all do very different things will quickly result in a maintainability problem. We already have hard coded support for RemoteTech and ConnectedLivingSpace, which both are problematic since none of the active developers use either mod themselves. The API approach works fine, f.i. there are some RealismOverhaul mods that basically do what RemoteTech does.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.