[WIP] Nert's Dev Thread - Current: various updates

[Streetwind]

Confirmed - deleting partdatabase.cfg fixed it, the Tau works again.

How very odd, I upgraded from a game state where the Tau was working correctly. I wonder why it changed the database so that it stopped working, but upon forcing a regeneration, writes the correct values again.

[Captain Sierra]

Okay I have another bug to report. This one is an issue I've had seemingly forever so this is not new and not specific to the current version of NF Propulsion (yes, this is specific to propulsion).

You know how when you tweak fuel levels, it snaps to certain percentages? Something in NFP is causing fuel tweaking to become accurate to the hundredth of a unit. This might be an undocumented feature, but it makes tweaking stock LFO tanks rather difficult since I cant snap them to the same levels of LF and Ox.

[Nertea]

I'm really busy again for a few days, but I've implemented a new scaling that should make the radiator behaviour when there are no heat sources a little more transparent.

Also made the base temperature 300k, room temp. Should be a bit more logical seeming.

Okay I have another bug to report. This one is an issue I've had seemingly forever so this is not new and not specific to the current version of NF Propulsion (yes, this is specific to propulsion).

You know how when you tweak fuel levels, it snaps to certain percentages? Something in NFP is causing fuel tweaking to become accurate to the hundredth of a unit. This might be an undocumented feature, but it makes tweaking stock LFO tanks rather difficult since I cant snap them to the same levels of LF and Ox.

That's KSPAPIEs business. Can't really affect that.

I'll look into the vw10k size, but I haven't historically had much luck fixing ksps icon sizes.

Confirmed - deleting partdatabase.cfg fixed it, the Tau works again.

How very odd, I upgraded from a game state where the Tau was working correctly. I wonder why it changed the database so that it stopped working, but upon forcing a regeneration, writes the correct values again.

Well, do me a favour and if it does it again, check the database entry and post it here. That way I can see what might be happening.

[Streetwind]

Thankfully the mods feel more or less done - I haven't had any showstoppers, besides the strange thing with the Tau radiator that ended up being easy to fix.

Meanwhile, two questions -

First, I've made a small MM config that flat-out halves all electric engine thrust. I made this for myself, so I feel a bit more of a difference between them and other engines (a bit more of that long burn experience). Want to include it as an optional extra in NFP?

Second, I'm going to poke at proper CKAN configs. As far as that goes, there's three levels of referencing other mods: required (auto-selects other mod, cannot be unselected), recommended (auto-selects other mod, but can be unselected) and suggested (does not autoselect other mod, but points it out). While dependencies like ModuleManager are obvious where they belong, some other things are more ambiguous. Like, for example, how much do you want to push the CTT? It could be listed as suggested, or it could be listed as recommended. It could even vary by pack... a pack that makes do with stock nodes wouldn't reference CTT at all, a pack that has only a few things would suggest it, and a pack like Electrical which heavily utilizes extended nodes would recommend it. How does that sound?

Also, for CKAN to go over well, the conflict with HotRockets! needs to be either indicated or eliminated. I'll try reworking the stock ion patch to sidestep the conflict.

[KwirkyJ]

I've encountered a minor bug(?) with NFE x4.14:

when any of the deployable radiators are attached to a vessel, the debug log is spammed with one of the update() calls, a single "[Log]: 0.001", and each call thereafter "[Log]: 0.00100000004749745" (probably a rounding thing). This seems to appear only when the radiators are attached to and disappears when absent from the vessel. The value is identical for both 2250 and 550 models in all situations encountered thus far.

[veber]

Nertea. All .dll files necessary for the functioning of Near Future Propulsion?

- Assembly-CSharp.dll

- Assembly-CSharp-firstpass.dll

- Assembly-UnityScript.dll

- Assembly-UnityScript-firstpass.dll

- Boo.Lang.dll

- Mono.Cecil.dll

- Mono.Security.dll

- TDx.TDxInput.dll

- TrackIRUnity.dll

- UnityEngine.dll

- UnityScript.Lang.dll

Since log, you can see the following:

[ERR 05:44:23.337] Failed to load assembly D:\KSP\GameData\NearFuturePropulsion\Plugins\Assembly-CSharp.dll:
System.Security.SecurityException: Assembly D:\KSP\GameData\NearFuturePropulsion\Plugins\Assembly-CSharp.dll tried to use forbidden type System.Diagnostics.Process!
Allows launching of external processes.
  at AssemblyLoader.ScanForBadTypeRefs (System.String file) [0x00000] in <filename unknown>:0 
  at AssemblyLoader.LoadExternalAssembly (System.String file) [0x00000] in <filename unknown>:0

[ERR 05:44:23.345] Failed to load assembly D:\KSP\GameData\NearFuturePropulsion\Plugins\Boo.Lang.dll:
System.Security.SecurityException: Assembly D:\KSP\GameData\NearFuturePropulsion\Plugins\Boo.Lang.dll tried to use forbidden type System.Diagnostics.Process!
Allows launching of external processes.
  at AssemblyLoader.ScanForBadTypeRefs (System.String file) [0x00000] in <filename unknown>:0 
  at AssemblyLoader.LoadExternalAssembly (System.String file) [0x00000] in <filename unknown>:0

[Nertea]

Thankfully the mods feel more or less done - I haven't had any showstoppers, besides the strange thing with the Tau radiator that ended up being easy to fix.

Meanwhile, two questions -

First, I've made a small MM config that flat-out halves all electric engine thrust. I made this for myself, so I feel a bit more of a difference between them and other engines (a bit more of that long burn experience). Want to include it as an optional extra in NFP?

Second, I'm going to poke at proper CKAN configs. As far as that goes, there's three levels of referencing other mods: required (auto-selects other mod, cannot be unselected), recommended (auto-selects other mod, but can be unselected) and suggested (does not autoselect other mod, but points it out). While dependencies like ModuleManager are obvious where they belong, some other things are more ambiguous. Like, for example, how much do you want to push the CTT? It could be listed as suggested, or it could be listed as recommended. It could even vary by pack... a pack that makes do with stock nodes wouldn't reference CTT at all, a pack that has only a few things would suggest it, and a pack like Electrical which heavily utilizes extended nodes would recommend it. How does that sound?

Also, for CKAN to go over well, the conflict with HotRockets! needs to be either indicated or eliminated. I'll try reworking the stock ion patch to sidestep the conflict.

1) Sure, I'll try to package it if I remember

2) Recommended: NFE, NFP. Suggested: NFSpacecraft, NFSolar, NFConstruction [note: feel like doing this for CryoRockets and SSPX too? )

3) Aye!

I've encountered a minor bug(?) with NFE x4.14:

when any of the deployable radiators are attached to a vessel, the debug log is spammed with one of the update() calls, a single "[Log]: 0.001", and each call thereafter "[Log]: 0.00100000004749745" (probably a rounding thing). This seems to appear only when the radiators are attached to and disappears when absent from the vessel. The value is identical for both 2250 and 550 models in all situations encountered thus far.

No so much a bug as a leftover debug call for when I was testing the heat conductivity. The fact that you see 0.001 all the time, incidentally, means that the'res no bug with said conductivity.

Nertea. All .dll files necessary for the functioning of Near Future Propulsion?

- Assembly-CSharp.dll

- Assembly-CSharp-firstpass.dll

- Assembly-UnityScript.dll

- Assembly-UnityScript-firstpass.dll

- Boo.Lang.dll

- Mono.Cecil.dll

- Mono.Security.dll

- TDx.TDxInput.dll

- TrackIRUnity.dll

- UnityEngine.dll

- UnityScript.Lang.dll

Since log, you can see the following:

[ERR 05:44:23.337] Failed to load assembly D:\KSP\GameData\NearFuturePropulsion\Plugins\Assembly-CSharp.dll:
System.Security.SecurityException: Assembly D:\KSP\GameData\NearFuturePropulsion\Plugins\Assembly-CSharp.dll tried to use forbidden type System.Diagnostics.Process!
Allows launching of external processes.
  at AssemblyLoader.ScanForBadTypeRefs (System.String file) [0x00000] in <filename unknown>:0 
  at AssemblyLoader.LoadExternalAssembly (System.String file) [0x00000] in <filename unknown>:0

[ERR 05:44:23.345] Failed to load assembly D:\KSP\GameData\NearFuturePropulsion\Plugins\Boo.Lang.dll:
System.Security.SecurityException: Assembly D:\KSP\GameData\NearFuturePropulsion\Plugins\Boo.Lang.dll tried to use forbidden type System.Diagnostics.Process!
Allows launching of external processes.
  at AssemblyLoader.ScanForBadTypeRefs (System.String file) [0x00000] in <filename unknown>:0 
  at AssemblyLoader.LoadExternalAssembly (System.String file) [0x00000] in <filename unknown>:0

I don't really care about sanitizing the VS output for dev versions. If I'm strapped for time (as I am now) I generally forget.

[veber]

I don't really care about sanitizing the VS output for dev versions. If I'm strapped for time (as I am now) I generally forget.

No claims for you, thank you for what you are doing. I just wanted to make sure that among these files is not needed for modification.

[Streetwind]

[note: feel like doing this for CryoRockets and SSPX too? )

While I'm at it, why not?

But, problem: NF Propulsion includes KSPAPIExtensions as a single file in the plugins directory and not in a separate folder. To comply with CKAN standards, I need to be able to define a NFP install without any dependencies included. This works fine as long as none of the NFP folders have dependencies in them, because I can point to individual folders within the download, but KSPAPIExtensions sits in a folder that must be installed.

So in order to support CKAN, the folder structure of Propulsion must change =/

Also, question:

Interstellar Fuel Switch comes in two variants on CKAN. Once as "core", which is standalone, and then a variant which depends on Core and on Module Manager. Do you know off the top of your head which of those you need as a dependency for Construction and Cryogenic Engines?

Edited May 25, 2015 by Streetwind

[Nertea]

I can adjust the location for KSPAPIE I suppose.

ISFuelSwitch, I assume the variant contains the various configs that FreeThinker added. I'm pretty sure the one I want is just Core.

Lastly, if we're going to do this, might as well create a new "mod" called NearFutureNuclearRockets to hold the hydrogen NTRs. NFP would recommend that.

[Captain Sierra]

And the above is testament to why if I ever mod, I'm not bothering with CKAN.

Still working on compiling a personal version of APIE that does not include that damn fuel tweaking 'fix'. As an SSTO builder it is a huge pain in my behind.

Does this mean an official release is coming soon? Be weary. 1.0.3 is coming Soon (actually in about a week or so) and will probably break lots of plugins. You sure you wanna release now and have to do more fixing in a week?

[Fraz86]

1.0.3 is coming Soon (actually in about a week or so)

Where did you get that information? 1.03 was supposed to be released last week. There were several Steam DB changes Friday morning, which usually immediately precede a release. Later on Friday they reported a "work emergency," which apparently prevented them from getting 1.03 out the door, but it would seem reasonable to assume the patch should be ready early this week. Unless they've put out a statement to the contrary?

[Streetwind]

Lastly, if we're going to do this, might as well create a new "mod" called NearFutureNuclearRockets to hold the hydrogen NTRs. NFP would recommend that.

Well, it's either "install the entire Extras folder at once", or "list every extra individually on CKAN, in which case they need to be in individual folders in the download" (even if it's just individual subfolders of the Extras folder). What you name them is ultimately not important.

The amount of different packs, extras and choices you offer is actually a bit overwhelming, there might be 3-4 entries for Propulsion alone at this rate, at least two for Electrical, and so on and so forth... I'm kinda hoping that it won't create an unmanageable mess that'll bite me in the bum come whatever massive overhauls 1.1 will bring.

Does this mean an official release is coming soon? Be weary. 1.0.3 is coming Soon (actually in about a week or so) and will probably break lots of plugins. You sure you wanna release now and have to do more fixing in a week?

Yes, we've been keeping an eye out for that for the past 1.5 weeks. But I highly doubt it's going to break much, it's supposed to be a hotfix release. The great horror will be 1.1 with its Unity 5 port. Now that will break things like no tomorrow.

[Jivaii]

The great horror will be 1.1 with its Unity 5 port. Now that will break things like no tomorrow.

From my understanding of what Squad's put out, even models might break after the port, so everything will need to be restarted from scratch almost if that's the case.

But I haven't a clue, plugins are sure to be shattered into a million little krakens, all coming for our souls while Jeb orbits Mun laughing and Val's on Minmus trying to decide if she wants to jetpack home or just wait for Jeb to get around to picking her up. Bill and Bob are somehow in orbit around Jool, after launching with Jeb, they're not sure what happened either.

[PickledTripod]

I really hope there's nothing interesting in 1.1 other than Unity 5, I've been waiting so long for all my essential mods to come back for 1.0 so I can start my modded career...

[Captain Sierra]

I really hope there's nothing interesting in 1.1 other than Unity 5, I've been waiting so long for all my essential mods to come back for 1.0 so I can start my modded career...

Unity 5 is going to break EVERYTHING, possibly even parts-only mods too. Its also going to take Squad a while to port (we could be looking at upwards of 4 months). I'd suggest starting it now and seeing what you can get done in that time.

[MatterBeam]

Unity 5 is going to break EVERYTHING, possibly even parts-only mods too. Its also going to take Squad a while to port (we could be looking at upwards of 4 months). I'd suggest starting it now and seeing what you can get done in that time.

What about .cfg file? What about things that deal with UI, like Contract configurator?

[Streetwind]

Nobody knows the details. Maybe not even Squad does at this point. They're learning as they go.

We users will just have to sit tight and keep our fingers crossed that the devs can preserve as much common functionality as possible.

[zengei]

While I'm at it, why not?

But, problem: NF Propulsion includes KSPAPIExtensions as a single file in the plugins directory and not in a separate folder. To comply with CKAN standards, I need to be able to define a NFP install without any dependencies included. This works fine as long as none of the NFP folders have dependencies in them, because I can point to individual folders within the download, but KSPAPIExtensions sits in a folder that must be installed.

So in order to support CKAN, the folder structure of Propulsion must change =/

Also, question:

Interstellar Fuel Switch comes in two variants on CKAN. Once as "core", which is standalone, and then a variant which depends on Core and on Module Manager. Do you know off the top of your head which of those you need as a dependency for Construction and Cryogenic Engines?

No folder structure changes are required to support CKAN. What issues do you see with the current metadata?

[smjjames]

From my understanding of what Squad's put out, even models might break after the port, so everything will need to be restarted from scratch almost if that's the case.

But I haven't a clue, plugins are sure to be shattered into a million little krakens, all coming for our souls while Jeb orbits Mun laughing and Val's on Minmus trying to decide if she wants to jetpack home or just wait for Jeb to get around to picking her up. Bill and Bob are somehow in orbit around Jool, after launching with Jeb, they're not sure what happened either.

They did warn us that it'll probably break everything. Heck, they don't even know to what extent things will break. Hopefully they give the modders a heads up on what will break and how so that they can prepare for them.

- - - Updated - - -

What about .cfg file? What about things that deal with UI, like Contract configurator?

I think they said that they were going to redo the UI, which apparently is a relic of the early days.

[nightingale]

What about .cfg file? What about things that deal with UI, like Contract configurator?

Contract Configurator is a UI mod now?

(Off-topic, but I doubt there will be much issue with getting Contract Configurator working in 1.1. Wider Contracts App relies on hacking into a bunch of holes in the crappy legacy UI, and there's an extremely high chance that it will die in 1.1.)

[Streetwind]

No folder structure changes are required to support CKAN. What issues do you see with the current metadata?

The whole point of CKAN is high confidence dependency and conflict resolution. A dependency should exist as a separate entry on CKAN, and you point towards it via a reference in the metadata. Conflicts are likewise indicated in the metadata as pointing to existing CKAN entries, and handled on that level.

For dependencies that are shipped in their separate folder in the download, this works because you can simply tell CKAN not to install that folder (or rather, you don't explicitly tell it to install it). However, Near Future Propulsion currently distributes a dependency within its own plugins directory. You cannot simply not install that folder; it's absolutely required for NFP to work.

This breaks CKAN's model of dependency and conflict resolution. Another mod that depends on KSPAPIExtensions will not know that it already exists in the Near Future Propulsion directory, and will trigger CKAN installing a second copy. This leads to multiple installs of the same mod, potentially of differing versions, which can crash the game. Additionally, a mod that explicitly conflicts with KSPAPIExtensions won't know that it exists in NFP's directory either, and CKAN will happily install it despite the conflict it creates.

[FreeThinker]

Interstellar Fuel Switch comes in two variants on CKAN. Once as "core", which is standalone, and then a variant which depends on Core and on Module Manager. Do you know off the top of your head which of those you need as a dependency for Construction and Cryogenic Engines?

Interstellar Fuel Switch Core should be enough, the depenendancy on MM is no longer required, but pretty much everyone has it anyway.

[zengei]

The whole point of CKAN is high confidence dependency and conflict resolution. A dependency should exist as a separate entry on CKAN, and you point towards it via a reference in the metadata. Conflicts are likewise indicated in the metadata as pointing to existing CKAN entries, and handled on that level.

For dependencies that are shipped in their separate folder in the download, this works because you can simply tell CKAN not to install that folder (or rather, you don't explicitly tell it to install it). However, Near Future Propulsion currently distributes a dependency within its own plugins directory. You cannot simply not install that folder; it's absolutely required for NFP to work.

This breaks CKAN's model of dependency and conflict resolution. Another mod that depends on KSPAPIExtensions will not know that it already exists in the Near Future Propulsion directory, and will trigger CKAN installing a second copy. This leads to multiple installs of the same mod, potentially of differing versions, which can crash the game. Additionally, a mod that explicitly conflicts with KSPAPIExtensions won't know that it exists in NFP's directory either, and CKAN will happily install it despite the conflict it creates.

I've written many metadata files for CKAN, if a file exists in a folder you don't want installed it can be filtered out; it doesn't have to be put into its own folder. See for example the entry for KW Rocketry's Legacy Fairings, which I wrote. CKAN goes to extraordinary lengths to make sure it can work with any sort of complex structure a mod may be distributed in.

If problems exist with how the current NF mods are packaged, can you raise the specific issues on GitHub and we can sort it out there? Advocating structural changes to how a mod is distributed is rarely done unless totally necessary and is generally done to make the mods better in general, not just for CKAN.

[Dazpoet]

So in order to support CKAN, the folder structure of Propulsion must change =/

Based on the discussion so far in this thread I cannot see any need for this, I think you have misunderstood how the filtering works, stuff does not need to be in seperate folders to be filtered, you can filter on a file level.

Interstellar Fuel Switch comes in two variants on CKAN. Once as "core", which is standalone, and then a variant which depends on Core and on Module Manager. Do you know off the top of your head which of those you need as a dependency for Construction and Cryogenic Engines?

We currently use -Core for Cryogenic engines since it then matches the exact composition of the Cryogenic Engines .zip downloaded from KerbalStuff. Construction should be the same but I don't have that one in as fresh memory.

I can adjust the location for KSPAPIE I suppose.

ISFuelSwitch, I assume the variant contains the various configs that FreeThinker added. I'm pretty sure the one I want is just Core.

Lastly, if we're going to do this, might as well create a new "mod" called NearFutureNuclearRockets to hold the hydrogen NTRs. NFP would recommend that.

We currently have all the hydrogen conversion configs in a seperate mod named NearFuturePropulsion-Extras which is suggested (not recommended, but that is easily fixed) as was approved here http://forum.kerbalspaceprogram.com/threads/52042-1-02-Near-Future-Technologies-%28NFSolar-NFSpacecraft-NFConstruction-hotfixed%29?p=1807385&viewfull=1#post1807385

I will admit it's currently batch-installs all the conversion configs at once, I wasn't aware doing so would be a problem (is it?) but it should be easily resolved with some smart filtering.

The whole point of CKAN is high confidence dependency and conflict resolution. A dependency should exist as a separate entry on CKAN, and you point towards it via a reference in the metadata. Conflicts are likewise indicated in the metadata as pointing to existing CKAN entries, and handled on that level.

For dependencies that are shipped in their separate folder in the download, this works because you can simply tell CKAN not to install that folder (or rather, you don't explicitly tell it to install it). However, Near Future Propulsion currently distributes a dependency within its own plugins directory. You cannot simply not install that folder; it's absolutely required for NFP to work.

This breaks CKAN's model of dependency and conflict resolution. Another mod that depends on KSPAPIExtensions will not know that it already exists in the Near Future Propulsion directory, and will trigger CKAN installing a second copy. This leads to multiple installs of the same mod, potentially of differing versions, which can crash the game. Additionally, a mod that explicitly conflicts with KSPAPIExtensions won't know that it exists in NFP's directory either, and CKAN will happily install it despite the conflict it creates.

You can, as zengei points out below, easily filter the .dll without having it in a seperate folder. You might find https://github.com/KSP-CKAN/NetKAN/pull/938 relevant which was closed since we couldn't guarantee a certain version of KSPAPIExtensions but https://github.com/KSP-CKAN/CKAN-core/pull/120 will resolve that problem once it's merged. KSPAPIExtensions is something of a headache but currently we list no mods which conflict with it so that part isn't a problem at this and shouldn't be until the version resolver code is in.

I've written many metadata files for CKAN, if a file exists in a folder you don't want installed it can be filtered out; it doesn't have to be put into its own folder. See for example the entry for KW Rocketry's Legacy Fairings, which I wrote. CKAN goes to extraordinary lengths to make sure it can work with any sort of complex structure a mod may be distributed in.

If problems exist with how the current NF mods are packaged, can you raise the specific issues on GitHub and we can sort it out there? Advocating structural changes to how a mod is distributed is rarely done unless totally necessary and is generally done to make the mods better in general, not just for CKAN.

I agree here, please open a github issue and reference the reports of faulty installs so we can fix whatever is broken.