.20 And mods

[EndlessWaves]

Why the heck was all this re-formating necessary in the first place? as far as I can tell it's only reason to exist is to aggravate anyone who used mods. I've spent about an hour now trying to get all the mods I normally use to work, with no success whatsoever.

I'd suspect the main reason is to make troubleshooting and management easier, you can quickly remove some or all mods when they're not mixed together with the stock parts.

0.20 creating the Plugins/Parts/Internals folder automatically might be a bug, or may be intended to help mod users with out of date mods instead of mod authors.

I was told you could share one mesh / texture across multiple parts. I don't know if this was a feature that made it for 0.2 or was a future goal. Any info?

It is, but as far as I know we haven't had clear instructions how to use it yet.

It's probably something like:

model = GameData/Squad/Parts/RTG/model.mu

Edited May 23, 2013 by EndlessWaves

[EndlessWaves]

If config files are now generic than how far is the old folder structure actually needed inside GameData/Yourfolder?

[BigNose]

For some reason I can do whatever I want, but my Aviation Lights won't load in the editor anymore. According to the Debug Console the AviationLights.dll loads without problems, but the parts just get ignored completly.

I already rewrote the .cfgs with a PART {.cfg stuff} wrapper, and made sure the folder structure is correct. How come that complicated mods like RemoteTech and MechJeb2 work just fine after the update but things as simple as a navlight don't?

I don't get it.

EDIT: Ok, I think it's a problem with the filetype of the models. The game cannot compile the parts because it doesn't find the models anymore. Was anything changed in regard to the compatibility of mesh files?

EDIT2: Problem solved, compatibility update released.

Edited May 23, 2013 by BigNose

[Hooligan Labs]

The new way to make Part-less plugins is to use the KSPAddon attribute, like this:

...

This class will be loaded every time the scene is changed to the Editor, and Awake will be called. And it will be unloaded when the scene is changed to something else, but until then Update() will be called.

Interesting! I do want to see more game-changing addons that aren't just parts.

[Nuke]

Custom engine sounds don't play in the new system. What is the proper syntax now?

It used to work with the lines:

// --- Sound FX definition ---

sound_fspropstart.wav = engage

sound_fspropidle.wav = power

sound_explosion_low = flameout

Where the two first ones are now in the GameData\Firespitter\Sounds folder, and the last one is a stock sound.

(The last one still works, obviously)

was rolling out an updated version of my mod pack. im having the same problem. ive got all the scaling bugs fixed, everythings in a PART{}, new directory structure is set up. and this is the only thing holding me up

ive tried sound fx defs with and without the .wav extension. ive also tried copying the heirarchy in the squad folder. tried sounds in both

ksproot\GameData\*modname*\Sounds\sound_*.wav

ksproot\GameData\*modname*\Parts\*part category*\*partname*\Sounds\sound_*.wav

neither one of these worked.

i did notice one thing though, under ksproot\GameData\Squad\Sounds\ i noticed a file called 'sound_decoupler_fire.wav.meta', its a text file with some info in it. im wondering if sounds need to have these (or some other cfg) to work. to tired to play with it now, but its worth looking into.

*edit*

i was too stubborn too sleep and so i copied that meta file over to my sounds dir, renamed it to match my sound effect and tried it, didnt work. didnt try tweaking any of the vars though.

Edited May 23, 2013 by Nuke

[ThePyrateCaptain]

Sounds like I won't be upgrading to .20 anytime soon. Back ups, keep yer back ups.

[Nuke]

i also noticed that if your mod pack has example craft, they need to go under the main KSProot\ships (eg. 'ksproot\ships\*vab or sph*\*.craft') . i tried creating one under my mod folder in game data but they didnt get loaded. seems this would be a nice way to keep things tidy, i forsee a horrily malformed ships dir in the future.

of course if there is a way to have mod dir local ships, please let me know.

i wanted to roll this mod out before i went to bed, but it looks like its gonna have to wait, sun is coming up.

Edited May 23, 2013 by Nuke

[Taverius]

.dae models will not load textures, ever.

[Fel]

Sounds like I won't be upgrading to .20 anytime soon. Back ups, keep yer back ups.

Oh come on! If you can understand rocket science, you can certainly understand how to navigate a directory tree.

*I also note that, other than for flags... it seems the "Squad Folder" isn't really needed; you can just as easily put everything in the Gamedata folder (i.e Gamedata/Parts/) and make your own directory structures.

I rather suspect that the whole "PART { }" means that it doesn't matter if you have a directory structure at all; but going back to organizing for now (Being able to sort things is something I wanted for "the few months" I had KSP (That is, without making a mess)

Edited May 23, 2013 by Fel

[Conarr]

*I also note that, other than for flags... it seems the "Squad Folder" isn't really needed; you can just as easily put everything in the Gamedata folder (i.e Gamedata/Parts/) and make your own directory structures.

For now, but Squad has said they'll be phasing out the old directory structure.

[Mihara]

[23:02:19] <+Mu> also..... big change.....

[23:02:41] <+Mu> if you're putting part configs in gamedata then they have to be surrounded with PART {} nodes

[23:02:49] <+Mu> cuz gamedata doesnt know whats in there

[23:02:54] <+Mu> but... you dont have to call them part.cfg

[23:03:05] <+Mu> and you can put many configs in the same config file

[23:03:11] <+Mu> parts, resources, internals, etc

...wait, does that mean you can now provide multiple sizes of the same part using the same model file and even the same part.cfg, with different PART{} sections in it, each with it's own rescaleFactor?

I wonder if that saves memory.

[Taverius]

...wait, does that mean you can now provide multiple sizes of the same part using the same model file and even the same part.cfg, with different PART{} sections in it, each with it's own rescaleFactor?

I wonder if that saves memory.

Yes and yes.

You can also do part1.cfg part2.cfg, or blah.cfg foo.cfg bar.cfg and define any number of parts (or props or whatever) in there.

What you can't do is:

Refer to models/textures outside the directory the .cfg is in (broken)

Use PART { config = path/to/base/part @node = value } syntax to only define the values that changed from a base config (broken)

[Frostiken]

Why the heck was all this re-formating necessary in the first place? as far as I can tell it's only reason to exist is to aggravate anyone who used mods. I've spent about an hour now trying to get all the mods I normally use to work, with no success whatsoever.

Heck, if what you say is correct, and all Plugin-related files go in the "GameData" folder then, why is there a Plugin folder in the KSP folder? that's just deliberately misleading.

Hopefully this is a one-time shift. This theoretically should make it easier to manage a system by which updates can be more effectively managed for addons.

They really should've revealed this information to plugin makers ahead of time though so they could be ready.

[Mihara]

What you can't do is:

Refer to models/textures outside the directory the .cfg is in (broken)

...now that's a particular shame, because rescaling stock parts to make up for missing sizes could be done so much more efficiently then...

[Taverius]

...now that's a particular shame, because rescaling stock parts to make up for missing sizes could be done so much more efficiently then...

Yup. My mod is 90% rescales and rebalances of stock parts, and just like 0.19 I'm overwriting the stock config. In Squad/Parts/Blah. Any other mods that modify the stock values or refer to the stock models either have to replace the stock config, or add their supplementary .cfg files to the Squad directories.

Not exactly what Squad had intended, but that's the card's we've been dealt.

Hopefully .20.1 will actually do what its supposed to.

[CleverWalrus]

There is any chance the "module" names are now Case Sensitive in part.cfg?

My CleverBobCat plugin was dead until i fixed the cfg's updating the module names with correct camelcase as the modules names in C#, otherwise i must have done something i don't know that fixed it

[EndlessWaves]

What you can't do is:

Refer to models/textures outside the directory the .cfg is in (broken)

Use PART { config = path/to/base/part @node = value } syntax to only define the values that changed from a base config (broken)

Has mu confirmed this? And does it apply to the whole system or just the squad parts with their missing labels?

[Fel]

For now, but Squad has said they'll be phasing out the old directory structure.

I didn't say the base directory... I meant taking the contents of the "Squad" directory and dumping it all 1 level up.

If the loader is doing what I think it is doing (indiscriminately loading files by walking the directory tree) then it doesn't matter what kind of structure you use, the loader should manage to find the files and load them.

[Moon Goddess]

I didn't say the base directory... I meant taking the contents of the "Squad" directory and dumping it all 1 level up.

If the loader is doing what I think it is doing (indiscriminately loading files by walking the directory tree) then it doesn't matter what kind of structure you use, the loader should manage to find the files and load them.

Um why on earth would you want to do that!!!!!

The whole point is to separate out the mods into different directories so you always know what parts came from what mod. the old system was a disorganized disaster zone. Sure it's possible to go back the old way but any mod that does will certainly discourage me from using it.

[Fel]

Um why on earth would you want to do that!!!!!

The whole point is to separate out the mods into different directories so you always know what parts came from what mod. the old system was a disorganized disaster zone. Sure it's possible to go back the old way but any mod that does will certainly discourage me from using it.

The game organizes parts based on the directory / filename structure.

That means I can do this:

GameData\Parts\Pods\a_Cockpit\SQUAD

GameData\Parts\Pods\b_Manned\SQUAD

GameData\Parts\Pods\c_Lander\SQUAD

GameData\Parts\Pods\d_Other\SQUAD

GameData\Parts\Pods\e_Probe\SQUAD

And the parts will be organized as such, other mods that are added in will now fall into categories rather than being swept all over the place (and it is fairly simple do do a directory search for "ClairaLyrae" (KSPX); I SUSPECT that I can turn "part.cfg" into "part.off"; but organizing things right now.

*And it is wonderful having all the engines grouped and on the same page, no more flipping around just because I removed or added a mod.

[Supernovy]

Might be of help, but not necessarily representative of current .cfg syntax.

http://pastebin.com/n44A4gCd

The sample .cfg that Mu posted way back in 0.18-time.

[Soulshifter]

Why the heck was all this re-formating necessary in the first place? as far as I can tell it's only reason to exist is to aggravate anyone who used mods. I've spent about an hour now trying to get all the mods I normally use to work, with no success whatsoever.

Heck, if what you say is correct, and all Plugin-related files go in the "GameData" folder then, why is there a Plugin folder in the KSP folder? that's just deliberately misleading.

The plugin folder in the KSP folder is for legacy plugins, if you read the info about the changes they tell you that the old folders are still there because of backward compatibility. Eventually they will be removed. Sooner if you do like I did and uninstall KSP so I could start with fresh folders. The new changes are a pain this time but from now on it will make things much easier. Now they just need to add a menu to enable/disable the mods from the game and make the spaceport install them to your game folder then there will be no need for an external program to manage them.

Edited May 23, 2013 by Soulshifter

[CaptRobau]

It's all a bit confusing, but how would I go about changing something in a stock part. I got it to work by overriding the original file (or use JSGME), but I haven't been able to put it into another folder. The change only works if I keep the changed part.cfg in Squad.

[Gaius]

I noticed that the "mesh" folder (in the same folder as my .dae file) is no longer being populated. Is this intended? Everything seems to be working regardless. As long as if I make changes to the COLLADA file, it actually gets made in the game (I used to ensure this by deleting the contents of the "mesh" folder)...

[Cilph]

Not sure if this is entirely new with 0.20, but I found a static GameEvent class that lets you register delegates for a whole ton of events.

https://gist.github.com/Cilph/baab143258211f852dfe