[1.2] OSE Workshop - KIS Addon: (v1.1.0 - 2016.11.03)

[taniwha]

I haven't read everything (too much interesting stuff to read) but there is a reasonable way to implement the "sensible recovery" mechanic: every part has a launchID. launchID is used by the contract system to check that parts in a station are newer than the contract. It is set from HighLogic.CurrentGame.launchID which is incremented every time a ship is launched (EL uses the same launch logic so this happens automatically when EL spawns a ship). If OSE sets the launchID of its spawned parts and increments HighLogic.CurrentGame.launchID appropriately, then that will be OSE taken care of. Once that is done, all we would have to do is detect when ships are launched from KSC and record the launchIDs. Then, on recovery check the launchID of the parts: any part with a launchID in the set was launched from KSC and thus gets normal recovery treatmet. Any part with an unknown launchID came from elsewhere (EL, OSE) and thus should be treated as a purchase (or sale, depending on your point of view).

The tricky bit is figuring out when a ship is launched from KSC (not helped by kerbinside).

Anyway, the main point of this post is there is a way to do it without clunky part modules (which KSP would mess with anyway). This is good because part modules are expensive both in memory and cpu cycles (even if Unity just says "nope, no code to run here, next!"). A single addon module that records launchIDs (can be a bitset: 8kB gets you 64k launches. anybody hit 1000 yet?) and watches for launches and recoveries. Very efficient .

The only problem is resources, though maybe total outgoing resources can be balanced against incoming: excess incoming becomes a sale/purchase instead of a refund.

[ObiVanDamme]

That sounds like the most elegant solution. If I want to go the way of "no refund for ptinted parts" I will definately try to implement it that way.

[Angelo Kerman]

I haven't read everything (too much interesting stuff to read) but there is a reasonable way to implement the "sensible recovery" mechanic: every part has a launchID. launchID is used by the contract system to check that parts in a station are newer than the contract. It is set from HighLogic.CurrentGame.launchID which is incremented every time a ship is launched (EL uses the same launch logic so this happens automatically when EL spawns a ship). If OSE sets the launchID of its spawned parts and increments HighLogic.CurrentGame.launchID appropriately, then that will be OSE taken care of. Once that is done, all we would have to do is detect when ships are launched from KSC and record the launchIDs. Then, on recovery check the launchID of the parts: any part with a launchID in the set was launched from KSC and thus gets normal recovery treatmet. Any part with an unknown launchID came from elsewhere (EL, OSE) and thus should be treated as a purchase (or sale, depending on your point of view).

The tricky bit is figuring out when a ship is launched from KSC (not helped by kerbinside).

Anyway, the main point of this post is there is a way to do it without clunky part modules (which KSP would mess with anyway). This is good because part modules are expensive both in memory and cpu cycles (even if Unity just says "nope, no code to run here, next!"). A single addon module that records launchIDs (can be a bitset: 8kB gets you 64k launches. anybody hit 1000 yet?) and watches for launches and recoveries. Very efficient .

The only problem is resources, though maybe total outgoing resources can be balanced against incoming: excess incoming becomes a sale/purchase instead of a refund.

Nice! I didn't know KSP had that feature.

[Qigon]

I haven't read everything (too much interesting stuff to read) but there is a reasonable way to implement the "sensible recovery" mechanic: every part has a launchID. launchID is used by the contract system to check that parts in a station are newer than the contract. It is set from HighLogic.CurrentGame.launchID which is incremented every time a ship is launched (EL uses the same launch logic so this happens automatically when EL spawns a ship). If OSE sets the launchID of its spawned parts and increments HighLogic.CurrentGame.launchID appropriately, then that will be OSE taken care of. Once that is done, all we would have to do is detect when ships are launched from KSC and record the launchIDs. Then, on recovery check the launchID of the parts: any part with a launchID in the set was launched from KSC and thus gets normal recovery treatmet. Any part with an unknown launchID came from elsewhere (EL, OSE) and thus should be treated as a purchase (or sale, depending on your point of view).

The tricky bit is figuring out when a ship is launched from KSC (not helped by kerbinside).

Anyway, the main point of this post is there is a way to do it without clunky part modules (which KSP would mess with anyway). This is good because part modules are expensive both in memory and cpu cycles (even if Unity just says "nope, no code to run here, next!"). A single addon module that records launchIDs (can be a bitset: 8kB gets you 64k launches. anybody hit 1000 yet?) and watches for launches and recoveries. Very efficient .

The only problem is resources, though maybe total outgoing resources can be balanced against incoming: excess incoming becomes a sale/purchase instead of a refund.

Neat trick, it sounds elegant.

I'll suggest instead that you track all parts produced out of Ksc instead. If not, whatever is launched before the player installs this MOD will not be tracked by it, thus its recovery cost will be zero.

However I don't know how it would behave if for some reason the player removes /reinstalls the MOD. I don't even know if there's a legitimate reason for doing that (maybe troubleshooting some ksp errors?)

[taniwha]

ObiVanDamme: I'm actually against removing refunds for printed parts. At most, adding in some market simulation to make producing too many too quickly counter-productive (price drops).

I see no problem with players taking cheap resources, processing them into expensive parts and recovering them for massive profits, even if they never leave the pad or runway and just time-warp as this is actually pretty realistic, except for one thing: time is free in KSP (no wages, no rent, no loan payments...).

That's not saying that RocketParts is realistic, but I was rather stuck at the time. Now that EL has recipes, having different resources for different parts, or even better, different combinations of resources, is now possible. I actually want do do away with the concept of "Parts" resources and instead use resources like Alloys, Ceramics, Plastics, Electronics (signal/logic), Electricals (power), Hydrolics etc, most of which would not be overly expensive. I plan on adding KerbalHours to recipes allowing things like tanks and trusses to be build fairly quickly, but gravioli detectors to take quite some time to produce one (let alone 200 }:>).

Qigon: it does not matter which you track, you still get the same problem. Also, there is no reason the system cannot assume that all parts existing before initialization were launched. Tracking launched parts is better because there are only two ways to launch from KSC: from the editor (VAB/SPH), or from the space center (click on pad/runway). There are already two ways to create parts away from KSC, and who knows, more may come (there was a third: the Orbital Construction (Redux) mod).

[ObiVanDamme]

ObiVanDamme: I'm actually against removing refunds for printed parts. At most, adding in some market simulation to make producing too many too quickly counter-productive (price drops).

I see no problem with players taking cheap resources, processing them into expensive parts and recovering them for massive profits, even if they never leave the pad or runway and just time-warp as this is actually pretty realistic, except for one thing: time is free in KSP (no wages, no rent, no loan payments...).

That's not saying that RocketParts is realistic, but I was rather stuck at the time. Now that EL has recipes, having different resources for different parts, or even better, different combinations of resources, is now possible. I actually want do do away with the concept of "Parts" resources and instead use resources like Alloys, Ceramics, Plastics, Electronics (signal/logic), Electricals (power), Hydrolics etc, most of which would not be overly expensive. I plan on adding KerbalHours to recipes allowing things like tanks and trusses to be build fairly quickly, but gravioli detectors to take quite some time to produce one (let alone 200 }:>).

Qigon: it does not matter which you track, you still get the same problem. Also, there is no reason the system cannot assume that all parts existing before initialization were launched. Tracking launched parts is better because there are only two ways to launch from KSC: from the editor (VAB/SPH), or from the space center (click on pad/runway). There are already two ways to create parts away from KSC, and who knows, more may come (there was a third: the Orbital Construction (Redux) mod).

that approach is the dream and i bet roverdude will love it as well. the problem i have is, that most people liked the simplicity of the "parts" implementation.

[sashan]

I have a stupid question - how do I open the interface? I have printing workshop, and there's no special buttons in its right-click menu and such.

[ObiVanDamme]

I have a stupid question - how do I open the interface? I have printing workshop, and there's no special buttons in its right-click menu and such.

the context action is named "open workbench". if that is missing make sure you installed the correct versions of kis and ose. you can send me the output.log from the ksp_data folder. with that i can help you

[taniwha]

ObiVanDamme: yes, people like simplicity, but so long as things don't get too complex, most people find a bit of complexity to be more interesting.

[sashan]

Here's my log: https://www.dropbox.com/s/31bbaugbhx3bf7i/output_log.txt?dl=0

KIS seems to be the latest one. Still no button.

[ObiVanDamme]

ObiVanDamme: yes, people like simplicity, but so long as things don't get too complex, most people find a bit of complexity to be more interesting.

your system is very flexible i think. may the best idea is to have a simple default implemantation and make the additional complexity optional

[taniwha]

That is, actually, one idea I've had from when I first started thinking about recipes.

[ObiVanDamme]

That is, actually, one idea I've had from when I first started thinking about recipes.

do you think it is possible to implement all that in a way, so that i can use EL recipes if it is installed and my own default if not. i had problems referencing an optional assembly in the past but i think i saw something similar with kis in the EL source code. may i contact you about this issue when the default is ready?

[taniwha]

ObiVanDamme: I just checked and all the necessary classes and members are public, so it should be fairly easy. The KIS wrapper code is the better example to follow (the Kethane wrapper code is horrid: I wrote some KIS stuff first, then wrote the Kethane code, learned a lot, then rewrote the KIS code). However, the Kethane wrapper code has examples of getting at properties. I should tidy it up (rewrite it similar to the KIS wrapper).

In the meantime, BuildControl.cs and GUI/ShipInfo.cs (probably easier to read) are good to study for how to get the resources (including KerbalHours) necessary to build a vessel. For a single part, just feed only a single part into BuildCost (check Recycler/StateMachine.cs, PartResources()) and grab the cost report. However, it's as simple as:

BuildCost resources = new BuildCost ();
foreach (Part p in ship.parts) {
    resources.addPart (p);
}
return resources.cost;

(hmm, ship is ShipConstruct, not Vessel (and I went to the effort of initializing the vessel). I smell a bug, or at least a potential future one)

Feel free to contact me at any time.

[ObiVanDamme]

taniwha: thank you for the hints. I will take a look at that when time comes. First thing will be the default implementation and finally removing the KIS dependancy that causes my mod to crash each time someone uses a different assembly than the one i used during compile time.

[sashan]

Okay, somehow I got the menu to show, but then the game crashed for some unknown reason and without error notice. Now I see "workshop - active" in right click menu but no button to activate it.

[physicsnerd]

Um, I can't seem to print anything. There's no options on the 3D printing module. Probably been asked before, but any thoughts?

[ObiVanDamme]

Um, I can't seem to print anything. There's no options on the 3D printing module. Probably been asked before, but any thoughts?

make sure you use the latest KIS and please attach the output.log from ksp_data folder forfurther help

- - - Updated - - -

Okay, somehow I got the menu to show, but then the game crashed for some unknown reason and without error notice. Now I see "workshop - active" in right click menu but no button to activate it.

can you attach the outout.log again that shows the crash?

[sashan]

Well, I've launched KSP since that already.. So no log. Stupid of me, I know.

[ObiVanDamme]

Well, I've launched KSP since that already.. So no log. Stupid of me, I know.

If you have any problems in the future make sure you save the log and attach it, because I cannpt give you support without it.

[Enceos]

Sneak peek of upcoming model changes:

• No more pesky glass shield which hides all the goodies, now you can touch dem gears and hot magnets.
  
• New look of the busy mechanism.
  
• Window lights and reorganized airlock lights.
  
• Rivets and frames around the indent edges.
  
• Better normals all around.
  

And much better gears on the Converter:

Edited September 7, 2015 by Enceos

[Sahadara]

Any update on part recipes to add another level of challenge, and to prevent the part recovery fund 'exploits'?

[DocMop]

Workshop looks way better!

[ObiVanDamme]

enceos: great work as always

sahadara: I am done with understanding taniwhas system and almost finished working on some additional infrastructure I need (KIS wrapper, EL recipe re-implementation, default recipes config, etc). Implementing all those bits and pieces in my processor will take some more time and a lot of testing. I might publish an experimental release on github so you all can grab it and have a look at it. Notification of this will of couse be posted here

Edited September 8, 2015 by ObiVanDamme

[RoverDude]

Obi - let me know where you land on that. I ping'd Taniwha RE what he was thinking RE resources, but in either case we should make sure you and I are at least in sync