[0.24.2] Interstellar Lite - Tweakscale Integration [v0.12.3][Sept 7]

[Tebryn]

I have a problem: Nothing works. Parts do not animate, and nothing seems to function beyond storing resources. Additionally, some parts expand uncontrollably when moused over in the parts menu in the VAB. Any idea which mod conflicts are known to cause this?

Update: Now treeloader won't load the tree, or any tree besides the "Use Stock" button in Career mode :/

EDIT: Also everything is broken again >.< On the upside: I didn't overwrite anything, so some mod is just plain-and-simple breaking the insterstellar plugin itself.

check your ORS folder, if your running KSPI-Lite 12.3 you should have OpenResourceSystems_1_2_1.dll in the folder (and only that version). Extra versions, or wrong versions will break KSPI-Lite in the manner you have described.

If you running karbonite (or MKS/OKS) then you should also have a copy of the ORS DLL that it installs in the ORS folder (v1_2_0 IIRC) you need to move this version from your ORS folder to the USI folder (if it doesn't have a copy there already)

that should solve your problems.

Also... there is a ORS_1_3_0.dll running around out there now that was pushed by FractalUK for his new version of KSPI. this version is actually Behind in features vs the ORS 1_2_0 and 1_2_1 versions that were pushed in his absence. don't use it with KSPI-Lite or MKS/OKS.

[ZonkX]

I'm gonna ask again because the problem is still there: I'm unable to transmit power from an antimatter reactor. There's enough antimatter on board, the reactor + generator is active, transceiver is set to transmit, radiators are deployed etc. but no power is transmitted. Am I doing something wrong?

Nevermind, figured it out myself. It only happens when the transceiver is directly attached to the generator. I still think it's a bug, but now I can avoid it.

[optimusjamie]

check your ORS folder, if your running KSPI-Lite 12.3 you should have OpenResourceSystems_1_2_1.dll in the folder (and only that version). Extra versions, or wrong versions will break KSPI-Lite in the manner you have described.

If you running karbonite (or MKS/OKS) then you should also have a copy of the ORS DLL that it installs in the ORS folder (v1_2_0 IIRC) you need to move this version from your ORS folder to the USI folder (if it doesn't have a copy there already)

that should solve your problems.

Also... there is a ORS_1_3_0.dll running around out there now that was pushed by FractalUK for his new version of KSPI. this version is actually Behind in features vs the ORS 1_2_0 and 1_2_1 versions that were pushed in his absence. don't use it with KSPI-Lite or MKS/OKS.

I have the correct version of ORS, but the tree loader still isn't working.

[Voodoomancer]

check your ORS folder, if your running KSPI-Lite 12.3 you should have OpenResourceSystems_1_2_1.dll in the folder (and only that version). Extra versions, or wrong versions will break KSPI-Lite in the manner you have described.

If you running karbonite (or MKS/OKS) then you should also have a copy of the ORS DLL that it installs in the ORS folder (v1_2_0 IIRC) you need to move this version from your ORS folder to the USI folder (if it doesn't have a copy there already)

that should solve your problems.

Also... there is a ORS_1_3_0.dll running around out there now that was pushed by FractalUK for his new version of KSPI. this version is actually Behind in features vs the ORS 1_2_0 and 1_2_1 versions that were pushed in his absence. don't use it with KSPI-Lite or MKS/OKS.

That did it. Thanks

Not sure if treeloader works, but screw it, I'm just gonna play sandbox until 0.25 comes out.

[joker169]

Is the New OpenResourceSystem_1_4_0.dll any better to use for this or is it still better to use the OpenResourceSystems_1_2_1.dll? Also, should the OpenResourceSystems_1_2_1.dll or OpenResourceSystem_1_4_0.dll be the only dll in the plugin folder?

Edited September 20, 2014 by joker169

[Fractal_UK]

Is the New OpenResourceSystem_1_4_0.dll any better to use for this or is it still better to use the OpenResourceSystems_1_2_1.dll?

The idea with ORS is that mutliple different versions can coexist. You should use the version which is packaged with the mod you are trying to play. It doesn't matter if you end up with a whole bunch of versioned number OpenResourceSystem dlls in your OpenResourceSystem folder as a result.

[AetherGoddess]

Is the New OpenResourceSystem_1_4_0.dll any better to use for this or is it still better to use the OpenResourceSystems_1_2_1.dll?

i think there are some bits which are dropped from Fractal's 1.3+ that KSPi_lite depends upon, but we might just wait to see what roverdude does in his next release for Karbonite. Wave and RoverDude seem to be playing from the same plans, but Fractal seems to be doing his own thing. it's kinda hard to tell right now until the release cycle progresses.

nevermind. official answer above.

Edited September 20, 2014 by AetherGoddess
nevermind. official answer above.

[Fractal_UK]

i think there are some bits which are dropped from Fractal's 1.3+ that KSPi_lite depends upon, but we might just wait to see what roverdude does in his next release for Karbonite. Wave and RoverDude seem to be playing from the same plans, but Fractal seems to be doing his own thing. it's kinda hard to tell right now until the release cycle progresses.

ORSv1.4.1 should hopefully be useable by everyone given the latest changes.

[joker169]

The idea with ORS is that mutliple different versions can coexist. You should use the version which is packaged with the mod you are trying to play. It doesn't matter if you end up with a whole bunch of versioned number OpenResourceSystem dlls in your OpenResourceSystem folder as a result.

Thanks Fractal_UK for the fast reply, I asked because i was experiencing the same issues in above post. I didn't see a ORS dll in the mod, But I will try putting one in there(maybe?) and trying again.

Edited September 20, 2014 by joker169

[Morberis]

Update: Now treeloader won't load the tree, or any tree besides the "Use Stock" button in Career mode :/

EDIT: Also everything is broken again >.< On the upside: I didn't overwrite anything, so some mod is just plain-and-simple breaking the insterstellar plugin itself.

Later edit: I think I've narrowed it down to either Karbonite, Extraplanetary Launchpads, or Part Catalogue. Could be wrong, though.

Treeloader is dead in the water, the online backend that it uses is DOA. If you or anyone wants a temporary fix look a few posts down from my link.

http://forum.kerbalspaceprogram.com/threads/53192-0-23-5-TreeLoader-Custom-Career-Tech-tree-Loader-1-1-5?p=1426160&viewfull=1#post1426160

[RoverDude]

ORSv1.4.1 should hopefully be useable by everyone given the latest changes.

It broke several interfaces in all of my stuff, and I can pretty much guarantee it broke interfaces in other mods that were built in your absence. I've gone ahead and forked my own version of ORS to prevent this from reoccurring again (the support for all of my mods has been a train wreck due to the confusion caused by 0.1.3 and up), and have taken great pains to make sure that it does not conflict with the ORS used for KSPI (or any future for that matter, since it's in a different namespace and all of the part modules are unique, so no risk of something grabbing it by accident).

Currently confirming it works with 0.25 as well as 0.24.2, then there will be a re-release of my own stuff. Also pulling out anything KSPI-only out of CRP to avoid any conflicts on that end (except for a few cases where there happens to be the same name used, in which case we'll be dealing with the usual KSP handling of resource conflicts). So going forward, in short, all of the USI stuff (and the stuff I curate) will be based on a plugin with it's roots in ORS (and the same kind of maps, etc.) but not ORS.

[Fractal_UK]

It broke several interfaces in all of my stuff, and I can pretty much guarantee it broke interfaces in other mods that were built in your absence. I've gone ahead and forked my own version of ORS to prevent this from reoccurring again (the support for all of my mods has been a train wreck due to the confusion caused by 0.1.3 and up), and have taken great pains to make sure that it does not conflict with the ORS used for KSPI (or any future for that matter, since it's in a different namespace and all of the part modules are unique, so no risk of something grabbing it by accident).

Currently confirming it works with 0.25 as well as 0.24.2, then there will be a re-release of my own stuff. Also pulling out anything KSPI-only out of CRP to avoid any conflicts on that end (except for a few cases where there happens to be the same name used, in which case we'll be dealing with the usual KSP handling of resource conflicts). So going forward, in short, all of the USI stuff (and the stuff I curate) will be based on a plugin with it's roots in ORS (and the same kind of maps, etc.) but not ORS.

The whole point of using versioned releases is that breaking changes don't actually matter. You should keep distributing the specific versioned dll that works with your code until you decide to update.

[RoverDude]

The whole point of using versioned releases is that breaking changes don't actually matter. You should keep distributing the specific versioned dll that works with your code until you decide to update.

Ohhhhh... they mattered in 0.1.3 Still dealing with that one across half a dozen mods right now, and I have no idea yet what 0.1.4 is going to do, but since it is already in the wild, little I can do on that other than focus on switching to a fork and eliminating the issue. No worries, as noted it will be completely transparent to ORS and KSPI.

[Fractal_UK]

Ohhhhh... they mattered in 0.1.3 Still dealing with that one across half a dozen mods right now, and I have no idea yet what 0.1.4 is going to do, but since it is already in the wild, little I can do on that other than focus on switching to a fork and eliminating the issue. No worries, as noted it will be completely transparent to ORS and KSPI.

See my response here: http://forum.kerbalspaceprogram.com/threads/43839-0-24-2-KSP-Interstellar-%28KSP-0-24-2-Support%29-Version-0-12?p=1427251&viewfull=1#post1427251

[RoverDude]

See my response here: http://forum.kerbalspaceprogram.com/threads/43839-0-24-2-KSP-Interstellar-%28KSP-0-24-2-Support%29-Version-0-12?p=1427251&viewfull=1#post1427251

Answered in other thread Issue was we lost our duplicate key check with 0.1.3, now I have a broken interface with 0.1.4.

Again, totally get that this is your baby, but it's current form of change management is not suiting my needs, nor is it good for the fairly large userbase that I have to have this level of uncertainty on a core dependency. I realize this is probably growing pains given that I am not aware of other popular mods using ORS other than KSPI, but in the short term I have to take care of my users first.

[Jagzeplin]

man mods are like all political and ****

edit- lol oh noes just noticed this was the 666th post. good thing im agnostic lol

Edited September 21, 2014 by Jagzeplin

[RoverDude]

man mods are like all political and ****

Politics? Nah, not really. Just doing what I have to do to avoid having the rug kicked out from under me on a too frequent basis. In any case, already finished my own fork and have most of my stuff converted to it, so a moot point. I make mods to have fun. Having my stuff break is not fun. Hence, I have taken the shortest path to fun.

Wave - I am going to assume you will migrate to ORS 0.14? If so, CRP will be incompatible with it as of o.25, so I'd suggest using whatever Fractal has in the current KSPI. I've taken measures to resolve any resource issues already, but wanted to give you the heads up.

[Jagzeplin]

yea i know i was just posting under the influence lol and i have no idea how that coding stuff works so don't take any opinion from this guy seriously just do what needs to be done keeping my awesome MKS/OKS stuff running and compatible with FAR, Interstellar Lite, EPL, and TAC-LS and all will be gravy . Btw how do you guys get to test out mods with future versions of KSP? does Squad send mod makers the next version sooner?

[Heliosmaster]

does Squad send mod makers the next version sooner?

yep, they already said in the past that they contact the makers of the most popular mods, so at launch they are more likely to have a compatible version.

[Snaps2012]

Now that the regular version of interstellar has been updated to .24 is the lite version going to be updated for future versions of KSP?

[JeffreyCor]

I sure hope so! I like this version far more than the "regular" one.

[AetherGoddess]

Now that the regular version of interstellar has been updated to .24 is the lite version going to be updated for future versions of KSP?

this is something that has been orbiting around in my mind for a while now. i was initially skeptical of KSPi_lite (yes, i am going to continue using that italic_Subscript notation until it catches on) but the more i use it, the more i appreciate the gameplay choices that Wave made. i'm still sad about some of the stronger tangential learning opportunities (like D/T/He3 and Fusion containment), but the tweakscale simplifications and reactor choice clarity are a huge improvement. honestly, after i got comfortable with it, i was hoping fractal would be occupied for a while so that when he returned, there wouldn't be this confusion over who's version was "authoritative".

as it sits, we have the worst of both worlds, Fractal was gone just long enough for Wave to come out of the shadow and start making his own improvements, but not long enough for wave to have the kind inertia that would mean fractal and wave HAD to cooperate and divide labor for the next version. i was really hoping that Fractal's return would herald the type of cooperative powerhouse that the B9 team has become; we've seen BAC, Tav and K3 smoothly (at least superficially) integrate into a tight cooperative team, and B9 is better then it ever was.

if the ORS 1.3 regression shows us anything, it's the fact that Fractal views KSPi and everything that comes from it has HIS, and woe betide those who would defy his vision. (i'm obviously overstating it hyperbolicly; i doubt there was any malice in Fractal's actions, just a casual unconcern for where everyone else was.)

My ideal mix would be Fractal in the background concentrating on the things he clearly wants to concentrate on (Engine effects, reactor modeling, and everything he's put effort into since he got back) with Wave "out front" dealing with gameplay, balance and support issues. This plays to both of their strengths, and would seem to put the people who are most interested in certain aspects in charge of those aspects. There was a recent book that talks about this type of creative cooperative and how effective it can be. (I hate sports, but Mike Pesca deals with this extensively in his non-sports podcast with the author)

Now, i'm idealistically ignoring ego, the opinions, and willingness of both parties in this example, as well as many many other factors, but i think this would be the best outcome; Pity it seems to be unlikely in the current climate.

[Fractal_UK]

if the ORS 1.3 regression shows us anything, it's the fact that Fractal views KSPi and everything that comes from it has HIS, and woe betide those who would defy his vision. (i'm obviously overstating it hyperbolicly; i doubt there was any malice in Fractal's actions, just a casual unconcern for where everyone else was.)

I think that's rather unfair. In reality, ORS compatibility issues were created because, somehow, certain versions of ORS began being distributed without their own copy of atmospheric/oceanic resource definitions, something which was never intended to be supported and broke the assumed backward compatibility to earlier versions of ORS. It was also intended (and documented) that ORS Atmospheric/Oceanic resource should be edited for the needs of individual mods by module manager not by distributing potentially duplicable custom nodes. The system I put in place was robust and changes/updates would not have broken it had that system continued to be used. ORS was designed from the ground up to allow significant API changes without breaking backward compatibility provided the systems in place were kept to. For whatever reason, they were not and that has caused a bunch of compatibility problems.

Now, that does not change the fact that ORSv1.3 was inferior to other versions that had been worked on but an ORS release is supposed to change nothing unless it is actually included and distributed in a mod; version 1.3 should have been of nothing more than academic interest to the community and would have been replaced in due course by an updated version.

Regardless, once I realised that, for whatever reason, some modders had started doing something with ORS than wasn't originally intended, I released a fix within a couple of days that was both more robust than the previous method and capable of preventing such a compatibility issue from ever happening again as well as both including and improving some of the more recent changes made to ORS. If I genuinely did not care about the needs of other modders, I don't think I would have dealt with it like that.

Edited September 22, 2014 by Fractal_UK

[RoverDude]

I think that's rather unfair. In reality, ORS compatibility issues were created because, somehow, certain versions of ORS began being distributed without their own copy of atmospheric/oceanic resource definitions, something which was never intended to be supported and broke the assumed backward compatibility to earlier versions of ORS. It was also intended (and documented) that ORS Atmospheric/Oceanic resource should be edited for the needs of individual mods by module manager not by distributing potentially duplicable custom nodes. The system I put in place was robust and changes/updates would not have broken it had that system continued to be used.

That does not change the fact that ORSv1.3 was inferior to other versions that had been worked on but an ORS release is supposed to change nothing unless it is actually included and distributed in a mod; version 1.3 should have been of nothing more than academic interest to the community and would have been replaced in due course by an updated version.

Regardless, once I realised that, for whatever reason, some modders had started doing something with ORS than was originally intended, I released a fix within a couple of days that was both more robust than the previous method and capable of preventing such a compatibility issue from ever happening again as well as both including and improving some of the more recent changes made to ORS. If I genuinely did not care about the needs of other modders, I don't think I would have dealt with it like that.

Ironically, atmospheric and oceanic resources never caused a crash... they just caused us to have more than 100% of an atmosphere. Which was a minor issue. Swapping to a pattern where we have to pick one kinda ruins Karbonite as it has atmospheric considerations at odds with KSPI - is what it is.

The issue was duplicate crustal resource keys. We fixed this. I sent you a pull request on day zero. And it was promptly disregarded when 0.1.3 broke stuff. Then 0.1.4 broke other things we depended on. Heck, I move pretty darn quick, and that one was out the door and on the street before I could even test it.

In my strong opinion, a dialog should have taken place so we all knew the lay of the land, and some consensus reached before releases went out. Things were in fact running very smoothly. Everything worked. Nothing broke. Mods worked together and there was no weirdness. In that situation, the best thing would have been to defer a release until we could all come to consensus, sort it out, and make sure we all released simultaneously if it was going to involve breaking changes.

This is not fun stuff. But it's what you have to deal with when you curate a mod that is meant to be a foundational piece of other mods (heck, there's a real fuels extension to Karbonite out there, as well as integration with RSS and EL for MKS/OKS that I have to be careful of). As it is, I was uncomfortable enough with the change management of ORS that I forked it and will continue in my own derivative work that I will share with the various teams that work on extensions to MKS, Karbonite, etc.. And even with that, my very first priority was to make sure I did not break KSPI, and also reached out to make sure I did not break KSPI-L as well.

If, once the dust settles, we all want to talk about how we bring things together, that would rock. It's better for the players. NFT and KSPI compatibility (while we had it) was nice. TAC-LS and KSPI compatibility was nice, as was everything working swimmingly with Karbonite, MKS/OKS, FTT, etc. - my job is to get us as close to that world as possible. As it stands right now, I have most of that already in place other than 1.2 of KSPI. So as noted, I'm going to make very sure that I do not accidentally break something just so people can enjoy these bits together. If we land there, that's fine. If we decide to land in a place where there's a lot more interop, even better.

As noted - I am on IRC and I have a PM.

[AetherGoddess]

I think that's rather unfair. [...]

[..] doing something with ORS than was originally intended, I released [..]

yes, i probably am being unfair; i'm sorry, i don't know how to make the point more courteously. in the end, this is your sandbox. thank you for letting me play in it.

however, i think your comments here reinforce my point. yes, you released a new version that should have been of academic interest only, but the major unstated assumption here (and in your comment, as highlighted in the quote) is that you were the only one doing anything with it. Wave has done a lot of work, and yes, a lot of that work is NOT the way you would have taken KSPi, but i think it's disrespectful to ignore his work to keep your creation working at a critical time when you were not available. fortunately, Wave and Rover are the only major mods that are pulling from ORS as extensively as they are, so the regression of Wave's work only had affect on those two things.

in corporate software, it doesn't take much of a breaking change to invalidate the trust that developers invest in an API. if Linux Torvalds were to release a new version of the linux kernal with minor academic changes from the last version he had total control over, then it would be wholly within his rights to do so, but you can guarantee Redhat and Novel would be very upset and would probably start forking as fast as they could rather then step back to 1998. again, this is almost excessively hyperbolic, but i hope the point is clear and minimally offensive. i'm sorry if it's not.