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

[jinks]

Here's my MM config I use for KSPI Lite. It's loosely based on the one from the KSPI tree.

Use at your own risk!

@PART[AMIReactor] {
    @TechRequired = specializedElectrics
    @MODULE[FNFusionReactor] {
        @upgradeTechReq = experimentalElectrics
    }
}

@PART[AntimatterCollector] {
    @TechRequired = advScienceTech
}

@PART[AntimatterReactor] {
    @TechRequired = advScienceTech
    @MODULE[FNAntimatterReactor] {
        @upgradeTechReq = experimentalScience
    }
}

@PART[AntimatterTank] {
    @TechRequired = advScienceTech
}

@PART[FissionReactor] {
    @MODULE[FNNuclearReactor] {
        @upgradeTechReq = metaMaterials
    }
}

@PART[FusionReactor] {
    @TechRequired = metaMaterials
    @MODULE[FNFusionReactor] {
        @upgradeTechReq = nanolathing
    }
}

@PART[PFissionReactor] {
    @MODULE[FNNuclearReactor] {
        @upgradeTechReq = metaMaterials
    }
}

@PART[*WarpDrive] {
    @TechRequired = experimentalScience
}

@PART[PlasmaDrive] {
    @MODULE[ModuleEngines] {
        @upgradeTechReq = experimentalScience
    }
}

@PART[*MPD] {
    @MODULE[ElectricEngineControllerFX] {
        @upgradeTechReq = experimentalScience
    }
}

@PART[ThermalTurbojet*] {
    @MODULE[FNNozzleController] {
        @upgradeTechReq = hypersonicFlight
    }
}

@PART[Vista] {
    @TechRequired = experimentalElectrics
}

[UAL002]

Ok. As far as tree mm cfgs go I'm a newb. What do I do and will it affect all saves trees?

[jinks]

Ok. As far as tree mm cfgs go I'm a newb. What do I do and will it affect all saves trees?

It's no different than any other MM cfg. Every part.cfg defines where it should appear in the tree, this cfg just changes those lines.

Put then content into InterstellarTreeFix.cfg and stick it somewhere into the GameData directory (I put it in the Interstellar directory). Make sure to get rid of any TreeLoader.dll that's still hanging around.

[UAL002]

Kk very helpful. I'll report back if there are any further issues. Wish me luck.

[Poofer]

seems we finally have a solution! http://forum.kerbalspaceprogram.com/threads/98293-0-25-TechManager-Version-1-0

[UAL002]

some other questions. I have Infernal robotics which requires tweekscale and also requires me to overwrite KSPAPIExtensions. Interstellar lite has tweakscale bundled. So what do I do? Also, I dont really want anything but IR scaleable unless Interstellar light needs some scalable items. Definatly dont want squad parts as such. Any suggestions?

[Poofer]

well interstellar lite needs scale for its reactors/engines/etc. but as far as i know the version is currently bundled with is broken with .25, so i don't know how to go about it.

[blindcoder]

I use the current version of Tweakscale with KSPI Lite just fine.

[gh7531]

Wave you should probably look at this if you don't have already.

http://forum.kerbalspaceprogram.com/threads/98293-0-25-TechManager-Version-1-1

and

http://forum.kerbalspaceprogram.com/threads/98409-Planning-Community-Tech-Tree

[AetherGoddess]

Wave you should probably look at this if you don't have already.

http://forum.kerbalspaceprogram.com/threads/98293-0-25-TechManager-Version-1-1

and

http://forum.kerbalspaceprogram.com/threads/98409-Planning-Community-Tech-Tree

i'm sooo excited! i've been waiting for someone to solve the tech tree problem so i could break back into my .24 KSPi_LITE .12 save. do we know if .12.3 works with .25? is wave planning an update?

giddy like a schoolgirl.

[RoverDude]

@Wave - can you do me a favor and summarize what the gameplan is with KSPI-L? i.e. is this something you intend on keeping rolling past beta, and I would like to know your plans for where resources will be tied (KSPI or CRP/ORSX). Asking for a couple of reasons

Since KSPI does not use CRP and there are some differences in what we did vs. where KSPI is (water being an example but not the only one), assuming (and I have no skin in the game either way) that you go the KSPI route for compatibility then I can shave off a huge chunk of CRP, since most of the resources there were for KSPI's benefit, and it's not particularly neighborly to risk breaking KSPI resources if Fractal changes anything down the road.

Assuming you are going the CRP/ORSX route, then I just need to know where you landed RE resource support and I'll change the annotation on CRP and point people here for an out of the box KSPI-like experience.

I'm tieing up a LOT of loose ends before we get into beta, and this is one of the ones lingering out there.

Lastly, I vaguely recall that this might not be supported past 0.25 (again, I am not sure if that's the case or not). If that ends up being the case, I expect there's a niche to still be filled between KSPI and NFT (They are close, but KSPI tends to be more future tech). If you want to collaborate, ping me.

[AetherGoddess]

Lastly, I vaguely recall that this might not be supported past 0.25 (again, I am not sure if that's the case or not). If that ends up being the case, I expect there's a niche to still be filled between KSPI and NFT (They are close, but KSPI tends to be more future tech). If you want to collaborate, ping me.

i don't think they're on the same spectrum. NFT is things that exist now (in proof of concept at least) implemented in a realistic way (ref: Capacitors as EC usage limits), KSPi is things that are not conclusively ruled out by conventional physics implemented in a realistic way (ref: fuel cycles and tank designs that assume an associates degree in nuclear chemistry), and KSPi_LITE is not conclusively ruled out implemented in a game-play focused way (Ref: Simplistic reactor cycles, CRP resource sharing, closer to stock balancing).

not only is there space for all three, there is good reason for a lite implementation: letting the users chose how far into the fiddly details they want their gameplay to reach. FAR has NEAR; Real Fuels vs Near Fuels; TAC-LS, Interstellar LS, and Snacks are all different positions on that axis; MKS even acts as it's own: with or without life support. Mechjeb is probably the best example of fiddly-detail-be-gone mods, as it has methods to automate almost all of orbital navigation, allowing gameplay to focus on planning, logistics, operations and other "higher-level" concepts.

i'm obviously biased, but i really hope Wave continues to release his private version for the rest of us. it seems like he spends much more effort on balance and polish the the default release, and that effort shows in easier usage and more meaningful gameplay choices.

Edited November 1, 2014 by AetherGoddess

[RoverDude]

i don't think they're on the same spectrum. NFT is things that exist now (in proof of concept at least) implemented in a realistic way (ref: Capacitors as EC usage limits), KSPi is things that are not conclusively ruled out by conventional physics implemented in a realistic way (ref: fuel cycles and tank designs that assume an associates degree in nuclear chemistry), and KSPi_LITE is not conclusively ruled out implemented in a game-play focused way (Ref: Simplistic reactor cycles, CRP resource sharing, closer to stock balancing).

not only is there space for all three, there is good reason for a lite implementation. FAR has NEAR; Real Fuels vs Near Fuels; TAC-LS, Interstellar LS, and Snacks are all different positions on that axis; MKS even acts as it's own: with or without life support.

i'm obviously biased, but i really hope Wave continues to release his private version for the rest of us. it seems like he spends much more effort on balance and polish the the default release, and that effort shows in easier usage and more meaningful gameplay choices.

Oh no debate, but it would be good to know which direction Wave is going - and either way is 100% cool, but it affects what I do. If KSPI-L emphasizes the KSPI bit (and there is really no out of the box interop between KSPI and my stuff, nor do I anticipate that changing in the short term), and his is KSPI roots with some minor changes, then I can focus on an out of the box alternative that fills the future tech gap and leave it to the community to handle interop between the mods.

If on the other hand, Wave is emphasizing the 'L' bit and it's KSPI-type stuff with some mechanics change and he's not tied to some of KSPI (water, electric charge, resource system, etc.), and he wants to play on the same playground then that's fine too - it saves me work

Again - 100% cool either way, I'm just not sure where the project stands as versions on both KSPI and CRP/ORSX have been charging forward. So I need to figure out if (a) I focus up on better KSPI-L integration (because we're on the same playground), ( focus on planning how to fill the niche myself and offer an alternative to KSPI that hits all of the major gameplay bits, or © some weird combination of both.

Working on a lot of road-mappy stuff for post-Beta and these things are important, given my own constellation is winding down in new dev (most of the big bits are there, only a couple left), and I have to figure out how best to fill the gap in power transmission, FTL drives, etc.

[Black Science Man]

I was told you could possibly help me, WaveFunctionP. I'm having trouble decompiling/compiling/editing the VistaEngineController section of the Interstellar(normal, not lite) plugin(.dll), mainly because I don't have much programming knowledge. All I want to do is change the hard-coded max thrust for the Vista engine from 1100 to like 3000 or something, because I want to make a more powerful version of the Vista. Is there any easy way to do this without having to entirely learn programming?

[WaveFunctionP]

I was told you could possibly help me, WaveFunctionP. I'm having trouble decompiling/compiling/editing the VistaEngineController section of the Interstellar(normal, not lite) plugin(.dll), mainly because I don't have much programming knowledge. All I want to do is change the hard-coded max thrust for the Vista engine from 1100 to like 3000 or something, because I want to make a more powerful version of the Vista. Is there any easy way to do this without having to entirely learn programming?

You can change the thrust in the part file under the vistaenginecontroller module.

[WaveFunctionP]

@Wave - can you do me a favor and summarize what the gameplan is with KSPI-L? i.e. is this something you intend on keeping rolling past beta, and I would like to know your plans for where resources will be tied (KSPI or CRP/ORSX). Asking for a couple of reasons

Since KSPI does not use CRP and there are some differences in what we did vs. where KSPI is (water being an example but not the only one), assuming (and I have no skin in the game either way) that you go the KSPI route for compatibility then I can shave off a huge chunk of CRP, since most of the resources there were for KSPI's benefit, and it's not particularly neighborly to risk breaking KSPI resources if Fractal changes anything down the road.

Assuming you are going the CRP/ORSX route, then I just need to know where you landed RE resource support and I'll change the annotation on CRP and point people here for an out of the box KSPI-like experience.

I'm tieing up a LOT of loose ends before we get into beta, and this is one of the ones lingering out there.

Lastly, I vaguely recall that this might not be supported past 0.25 (again, I am not sure if that's the case or not). If that ends up being the case, I expect there's a niche to still be filled between KSPI and NFT (They are close, but KSPI tends to be more future tech). If you want to collaborate, ping me.

The gameplan hasn't changed. I just have just been busy with other projects. And to be honest, replicating all the changes I made for kspil to compatible with kspi does not sound very appealing to me. I think it will happen eventually, but I don't have a timetable.

That said, the goals of this project have not changed. Compatibility and usability will always be a priority.

[RoverDude]

Awesome, that's pretty much the info I needed

Let me know when the dust settles then (trust me, I appreciate what it means to be on side bits and other projects) and we can sync up and see about getting KSPI-L and the USI mods on the same page. Saves me a ton of work, and I can just send people here. Alternatively, I can see what I can do about a pull request for you for resource sync, etc. - I assume your dev branch is the best one to go off of?

[Chyort]

Awesome, that's pretty much the info I needed

Let me know when the dust settles then (trust me, I appreciate what it means to be on side bits and other projects) and we can sync up and see about getting KSPI-L and the USI mods on the same page. Saves me a ton of work, and I can just send people here. Alternatively, I can see what I can do about a pull request for you for resource sync, etc. - I assume your dev branch is the best one to go off of?

Sorry, I'm about to pass-out so it could be all me, but I'm somewhat confused...

From what i recall his plan was to re-integrate Lite with Regular, and turn Lite into a MM config of Regular... Meaning he would be playing in Fractals sandbox, and let you do whatever you need to with ORSX.

.25 was supposed to be minor bug fixes while Fractal works out all the new stuff he wanted, before wave started turning Lite into a MM config.

So i understand retaining KSPI resources for now, but why would you need to sync up with wave when it sounds like he is going back to Fractals sandbox?

Old quotes for reference.

The two mods were trying to do separate things. We will reconverge at some point. I plan to have lite be an mm config of kspi eventually the same way I was planning to offer support of different universes through kspil mm configs.

Sorry not being as active lately. I have other project that I also work on, but interstellar is core mod for KSP to me, and as such, so long as I am playing KSP will likely find things to muck around with.

For now am letting fractal get the bulk of his ideas implimented for his version, let the version numbers catch up so that that are not confusing. It will be a big undertaking to converge the code back with fractal's branch. That is the goal, although I plan to work where I can to get more customization into base kspi so that most changed do not need to be code based. Resource compatibility will need to be addressed. It's a sticky subject, but I am sure that with work it can be addressed.

Don't expect big things very soon. .25 will likely be just enough to keep your saves working while I find time to resolve the many tiny issues that will come up.

If I do my job properly, you guys will converge with KSPI's code base completely seamlessly, assuming kspi doesn't do any part breaking changes.

[Black Science Man]

You can change the thrust in the part file under the vistaenginecontroller module.

MODULE

{

name = VistaEngineController

}

-That's all that module contains. Do you mean add a line in that module like "maxthrust=2100"?

Edit: As a test, earlier I made a copy of the vista part and just deleted the VistaEngineController module. The thrust is now showing up as 2100 and does seem to go faster. Would there be any issues with doing this?

Edited November 4, 2014 by Black Science Man

[RoverDude]

@Chyort - I read something different in "And to be honest, replicating all the changes I made for kspil to compatible with kspi does not sound very appealing to me." -

bearing in mind we were pretty much in sync (the only out of sync thing at the moment is Wave's version of CRP which is the older ORS version not the newer ORSX version).

@Wave - can you please clarify in black and white as there seems to be confusion.

(And from my standpoint I am 100% fine either way, but it does affect what I work on next - either stronger integration with KSPI-L, or new dev).

[Chyort]

And with the next sentence he says that he thinks it will happen eventually. *Shrugs*

Sort of like spring cleaning... not many people look forward to it, but a lot of people end up doing it anyways.

But yeah, i can see it going either way from the comments i have seen, thus i figured i would point out the possible confusion.

[WaveFunctionP]

The devil is in the details.

The long term goal is to be able to do a lot of customization with MM configs, but we are a long way away from that. Remember, this was a long term goal for kspil too and I exposed a lot of functionality towards that end.

For the time being, kspil will remain a separate mod until such time that I believe base kspi is flexible enough to do the things that I need it to do, including handling resource compatibility in a way that users intuitively expect, which it's not doing so hot right now. Keep in mind, that is a not a knock against fractaluk. He has a vision that has made his mod very popular. I have no doubt that continued development will help resolve these relatively minor issues. Remember, kspi is one of the larger and more complicated mods, so changes can take time.

To be clear, kspil will not remerge completely with kspi until resource compatibility has been addressed reasonably.

Edited November 4, 2014 by WaveFunctionP

[WaveFunctionP]

MODULE

{

name = VistaEngineController

}

-That's all that module contains. Do you mean add a line in that module like "maxthrust=2100"?

Edit: As a test, earlier I made a copy of the vista part and just deleted the VistaEngineController module. The thrust is now showing up as 2100 and does seem to go faster. Would there be any issues with doing this?

There is no exposed functionality to change the thrust for the vista engine in kspi. That was one of the things that I did for kspil.

[WaveFunctionP]

@Roverdude, Is my version of CRP/ORS is causing any issues? I did not think that it would, and I've not been made aware of any at the moment.

[RoverDude]

@Roverdude, Is my version of CRP/ORS is causing any issues? I did not think that it would, and I've not been made aware of any at the moment.

Easy one - CRP uses ORSX configs now to avoid stomping on ORS atmospherics, etc., so right now your CRP version is out of date. But lots of easy choices and fixes:

1. Switch KSPI-L to ORSX and use the new CRP ORSX resource maps and configs (I can't recall if you still use alumina, but we have the rest in there).
   
2. Use ORS for configs, but leverage the CRP ORSX maps (saves people loading extra stuff). If they just use KSPI-L, they see ORS. If they use MKS and KSPI-L they see both ORSX and ORS.
   
3. Use ORS for both configs and maps in KSPI-L, just use CRP for resources (downside is extra stuff is loaded, upshot is you can have different maps than CRP, though most are based or close to the KSPI ones).
   
4. 
   

• With 2 and 3 you lose the SCANSat and Resource Overlay integration.
  
• With 1 and 2 we have map sharing.
  
• 2 I think is a good option if you want to roll with ORS still. ORSX is mostly animations and continued harvesting when not in focus (no idea if Fractal ever rolled that into the root ORS), your downside is loss of mapping from third party addons.
  
• 1 gives you the maps, but pulls you off of ORS, which may or may not make sense for you.
  
• 3 helps if you want alternate maps.
  

Full disclosure, ORSX will *eventually* be replaced by a clean room implementation with some new features, and include generator code. It will also be integrated with SCANSat/Resource overlay.

(edit) The conflict would be if someone who used ORSX got a non-ORSX CRP or someone who used ORS got the newer ORSX-only CRP - the symptom would be no resources available. Not aware of anyone hitting this yet (if they merged the folders you'd just get double maps but it would work as there are no file name conflicts), but could get weird.

Edited November 4, 2014 by RoverDude