Jump to content

Discussion re. renaming installation directories


Recommended Posts

As you know, I have quite a large number of mods which I've updated.

Up until now, I've tried to keep the installation directories the same.  However, this is leading to some confusion both on my part and others when using Janitor's Closet, etc.  A simple example is the Mk2.5 Spaceplane Parts, which is in a directory called RaginCaucasin.

I'm seriously thinking about renaming the directories for this and some other mods which I support.  Quite a number of authors decided to keep all their own mods in a single master directory, and to have each of their mods have a subdir inside their master directory.

The only think I think I'll have to worry about is to add a small MM stanza which provides a "FOR" statement for each mod renamed; this to avoid breaking any MM scripts which depend on or check on the existence of a mod

An alternative (for Janitor's Closet) would be for me to create a mapping of directory name to mod name.

I'm interested in hearing other views on this, please.  If good reasons are presented as to why this wouldn't be a good idea, I'll probably not do this.

 

Link to comment
Share on other sites

I tried both ways, and got hurt on all of them. 

Renaming directories with assets will lead to breakage. Some Add'ons use assets from other Add'Ons, and soon you will be overwhelmed with change requests and bug tracks.

But Add'Ons that doesn't have shareable assets (autopilots, editor extensions, etc) can cope with it better.

Such problem was kind or tacked down on that KSPe thing, but the Mono's bug on Reflection is preventing me to push it into mainstream. At least, while I don't pull out a workaround from my hat.

Link to comment
Share on other sites

Honestly? Pick a major version jump (like 1.7.0) and go rename as much or as little as you think you need to. The issues you have with the existing names aren't going to go away ever, unless you do that.

People will have to adjust, yes. That's why you do it on a major version jump, where people should expect there to be some hurdles to porting old savegames forward. There is something to be said for maintaining a status quo for the sake of backwards compatibility - but it's not like you're going to make such changes every update. There has to be room for a reorganization. Sometimes a hard cut is needed to trim the horrors of organic growth. Even unplanned interdependencies like @Lisias mentions can be tidied up that way, making things less complicated in the future.

And I say that as someone who uses a variety of mods you maintain. If I have to fix my install, I will. (But most likely I'll do a fresh install anyway.)

 

Edited by Streetwind
Link to comment
Share on other sites

35 minutes ago, Streetwind said:

There has to be room for a reorganization. Sometimes a hard cut is needed to trim the horrors of organic growth. Even unplanned interdependencies like @Lisias mentions can be tidied up that way, making things less complicated in the future.

Sometimes, the fix causes more havoc than the problem.

A lot of perfectly fine Add'Ons would just stop working, and a good amount of them are not tightly maintained anymore - but they still works. And people using these Add'Ons will, obviously, heavily complain. It's harsh enough when you make a breaking change due a critical bug fix where the damages you do by the change as less worst than the damages you get by not fixing it. Doing such breakage for cosmetics would probably cause yet more commotion.

Now that Squad managed to make a major release without too much breakage, I think it would be a better idea thinking twice, two times in a row, before doing something that would break Add'Ons unnecessarily.

IMHO, you would see people forking your job and reverting the changes, instead of jumping wagon with you.

At least until something manage to abstract the whole mess, allowing runtime (and loading time) naming solving by abstract IDs. That would allow easy changes on the file system without breakage to Add'Ons that would use the name solver. Yeah, it will still be a change-fest on the Add'Ons, but on the other hand, it would definitively solve the problem for good. This kind of stunt is easier to push, but will take more time.

Link to comment
Share on other sites

My stance would be as long as the parts still load, go ahead.  I prefer not having to drill in under GameData and to have the folder names be recognizable and related to what's inside them.  ;)

MM patches typically refer to things by name and mod name, but keeping the name the same and a FOR patch would solve that in nearly all cases.

Link to comment
Share on other sites

17 minutes ago, DStaal said:

My stance would be as long as the parts still load, go ahead.  I prefer not having to drill in under GameData and to have the folder names be recognizable and related to what's inside them.  ;)

MM patches typically refer to things by name and mod name, but keeping the name the same and a FOR patch would solve that in nearly all cases.

Not that much. A lot of Add'Ons makes direct references to assets - meshes, textures, sounds. These are not generically handled.

LGG himself already saw this on one of the Add'ons he's maintaining, as something was relying on some assets that got into zDeprecrated, and so, changed the location on the file system.  I have some of mine doing that too. And this is good, because reusing assets is always preferable as creating new ones to the same job: less time loading KSP, less memory running KSP.

See the whole whitelist stunt people from ReStack had to do, and see for yourself.

Link to comment
Share on other sites

I'll admit there are a few of those, but I don't tend to see them as common - especially in where they reference other *mods* assets.  Typically they reference *stock* assets (which is why ReStock had to worry), not assets from other mods.

There are a few that do directly reference other mods, but typically they're add-ons for the mods they reference.  And if they do something like dupe the part and then edit it, they can often even handle assets moving.  I won't say it doesn't happen - just that I don't see it as common.

Link to comment
Share on other sites

2 hours ago, DStaal said:

I'll admit there are a few of those, but I don't tend to see them as common - especially in where they reference other *mods* assets.  

How many Add'Ons? How many users per Add'On? 

I don't remember details, but most of the moduleless Add'Ons I forked was due exactly glitches and errors on referencing other Add'Ons. Or being referenced, it was easier to rollback the "offending" Add'On that changed than fix the others.

Without metrics, all we have are hunches. And a hunch from someone that keeps a lot of Add'Ons usually shadows hunches from someone that keeps one or two (or none).

Not meant to be picky or dismissive - I'm trying to be practical. Maintainers need to weight the theoretical benefits from a change against the probable damages it can cause, and this you just can't have without some background on the matter.

Edited by Lisias
Yeah. Tyops. But you already knew it.
Link to comment
Share on other sites

A general directory for all maintained mods.
Mod subdirectories with unified names, with no relation to their maiden names.
A standard mod list with unique UUID for every supported mod, its maiden path, its new path, and last version.

A check utility which is passing through the files in GameData, searching maiden directories and showing a window "You have some mods linked to obsolete paths. They are: ...".
This will not cover everything, but most of external links can be found.
Then the user will poke the bear in corresponding thread, and if the modder is interested in his mod working, he would correct the external paths in his files.

Maybe, ModuleManager should have an ability to refer to the mods by their UUID, as unlike the authors' fantasy, UUID is not limited and always unique and can be generated by various tools by everyone.

Anyway, most of mods ever existing are obsolete long ago and don't work anymore, so why not start their proper catalogization from 1.7.0.

Link to comment
Share on other sites

My feeling is if it simplifies things in the long run; do it and deal with the short term fallout. I would not complicate things by trying to make the transition graceful. I would want things to break in an obvious, easy to identify manner.

Link to comment
Share on other sites

1 hour ago, kerbiloid said:

Mod subdirectories with unified names, with no relation to their maiden names.
A standard mod list with unique UUID for every supported mod, its maiden path, its new path, and last version.

A check utility which is passing through the files in GameData, searching maiden directories and showing a window "You have some mods linked to obsolete paths. They are: ...".
This will not cover everything, but most of external links can be found.
Then the user will poke the bear in corresponding thread, and if the modder is interested in his mod working, he would correct the external paths in his files.

Maybe, ModuleManager should have an ability to refer to the mods by their UUID, as unlike the authors' fantasy, UUID is not limited and always unique and can be generated by various tools by everyone.

Anyway, most of mods ever existing are obsolete long ago and don't work anymore, so why not start their proper catalogization from 1.7.0.

If I am understanding you correctly, this would be *nice*, but highly impractical.

Its not just a simple matter of renaming/rearranging the folders.
*EVERY* part config, *every* patch, and *every* instance of a listed folder URL in a mod, or mods supporting other mods would have to be changed. Also, source code would have to be edited for every .dll that references a hard-coded URL. and then recompiled. Thats a TON of work...
Its one thing if a mod dev does their own mod, but to wholesale implement this over *every* mod would be crazy.

And if you mean each version of the mod have the mod version as part of the folder naming, that would require doing it all again every mod update... totally unrealistic.

And "most mods ever existing are obsolete long ago and dont work anymore" is just hugely not true.

Edited by Stone Blue
Link to comment
Share on other sites

8 hours ago, kerbiloid said:

Anyway, most of mods ever existing are obsolete long ago and don't work anymore, so why not start their proper catalogization from 1.7.0.

Because it would add an extra step on the porting efforts. 

And you would be surprised about how easy (however still worksome) is to fix them to.be usable on 1.7 

The UUID idea is not bad, but I think it's unnecessary. A compromise between the current statusquo and the proposed one would accomplish the same with fewer breakcage. Using symlinks perhaps.

There shouldn't never be two Firespitters installed anyway,  so "Firespitter" is already a de facto Universal Identifier.

 

Edited by Lisias
Link to comment
Share on other sites

8 hours ago, Tonka Crash said:

My feeling is if it simplifies things in the long run; do it and deal with the short term fallout. I would not complicate things by trying to make the transition graceful. I would want things to break in an obvious, easy to identify manner.

The fallout would endure for years. 

Look to the entire KSP 1.4 series for example. Lots of needed changes, and lots of breakage and cursing in the meantime. :)

for critical things, where not doing it would be fatally worse than the fallout,  OK. If you are going to "die"  do it on the less painful way possible.

but for non critical issues, it's almost suicidal in my book!

Link to comment
Share on other sites

Simple question: what is best for you the mod maker? Everything else is moot.

 

So if you choose to change to main-sub style, just give notice and some time, then do it. If people like the mods (which they do) they will adapt.

 

Just my two burnt bolts worth.

Edited by zer0Kerbal
Link to comment
Share on other sites

2 hours ago, zer0Kerbal said:

Simple question: what is best for you the mod maker? 

Simple answer: serving a good service, without promoting unnecessary breakage.

It's already harsh when you promote a needed breakage - you do it just because, and you start to loose users.

There's no need for a Maintainer for Add'Ons that no one wants to use. ;)

 

Link to comment
Share on other sites

48 minutes ago, Lisias said:

Simple answer: serving a good service, without promoting unnecessary breakage.

It's already harsh when you promote a needed breakage - you do it just because, and you start to loose users.

There's no need for a Maintainer for Add'Ons that no one wants to use. ;)

 

however, people do want to use them. he isn't being paid or compensated. So what is best for him is what I suggest he does. Snowflakes will melt no matter what; reasonable notice is more than polite. Remember, the modders are doing We the players a favor by releasing these at all. Not being harsh, just realistic. I thank him for even asking. With that being said, if it breaks I won't use until it is fixed.

Edited by zer0Kerbal
Link to comment
Share on other sites

12 minutes ago, zer0Kerbal said:

however, people do want to use them. he isn't being paid or compensated. So what is best for him is what I suggest he does. Snowflakes will melt no matter what; reasonable notice is more than polite. Remember, the modders are doing We the players a favor by releasing these at all. Not being harsh, just realistic. I thank him for even asking.

People will use what serves them best. On Open Source you just can't force them to something they don't want, as they will just fork the thing and you will see your users going away.

Yes, they are paying nothing to you - we usually rely on donations and patronage. However, if people fork your project and start to use the fork because it serves them better, you will see that the same people will have less reasons to keep supporting you.

You also forget that we, Add'On Authors and Maintainers, are players too. We do play KSP too. Non authoring players are not the only one being beneficed by the works. And we, too, want to expend less time fixing things that are not broken without a good, compelling reason - as this would hinder our free time to expend it on the really pressuring issues - as showstoppers bugs and new features.

Or plain playing KSP. :) 

Some fixes are worst than the problems they aim to fix. This is probably one of these for the majority of the cases (but not all, as I had tested and proved on my Experimental forks).

Edited by Lisias
Of course… Tyops! (Surprised?)
Link to comment
Share on other sites

1 minute ago, Lisias said:

People will use what serves them best. On Open Source you just can't force them to something they don't want, or they will just fork the thing and you will see your users going away.

Yes, they aren't paying nothing to you - we usually relies on donations and patronage. However, if people forks your project and start to use the fork because it serves them better, you will se that that same people will have less reasons to keep supporting you.

You also forget that we, Add'On Authors and Maintainers, are players too. We do play KSP too. Non authoring players are not the only one being beneficed by the works. And we, too, want to expend less time fixing things that are not broken without a good, compelling reason - as this would hinder our free time to expend on the really pressuring issues.

Some fixes are worst than the problems they aim to fix. This is probably one of these.

So? what benefit other than bragging rights does one gain ??? And you answered your own - authors and maintainers are players too (at least I would hope). There is obviously some desire to do this else the OP wouldn't have posed the Q.

Anything that saves LGG a minute or two and consolidates my GameData folder (including merging mods to share code and reduce resource footprint) is all good and worth some inconvenience to me.

Looks like you disagree, and I respect that.

You have your opinion, I have mine. We have all made suggestions, and now it is up to LinuxGuruGamer to decide what is best for him, which in turn is best for us.

Anything that helps him in the long term will help us because he is maintaining ... what's the count now?

A Happy LGG is a HAPPY KSP community. :):D

Link to comment
Share on other sites

12 minutes ago, zer0Kerbal said:

Looks like you disagree, and I respect that.

It's the same from my side. We will have to agree on disagree on this matter.

Respectfully, I have the impression you doesn't fully understand some Software Development concepts. Not meant to be rude, just trying to express an opinion.

LGG is an important Maintainer on this community, but it's not wise to behave as he would be the only one. Things we do affect other people's lives. Saving a minute of mine at expense of many minutes of many other maintainers is not exactly team work on my book.

Edited by Lisias
Ah, whatveer. Yuo knwo waht happened
Link to comment
Share on other sites

28 minutes ago, Lisias said:

It's the same from my side. We will have to disagree on this matter.

Respectfully, I have the impression you doesn't fully understand some Software Development concepts. Not meant to be rude, just trying to express an opinion.

LGG is an important Maintainer on this community, but it's not wise to behave as he would be the only one. Things we do affect other people's lives. Saving a minute of mine at expense of many minutes of many other maintainers is not exactly team work on my book.

I've been coding since, well my first box was made out of wood. I no longer do it professionally, and my second career (now retired from it) was a Chef overseeing a galley brigade of 120-250. My current career is International Logistics. I would hope that I understand the 3C's of teamwork; and the laws of unintended consequences.

Saving one person x amount of time who maintains many-many-many (>100?) means saving them hours, even at the expense of a limited - and relatively unprobabilistic number of others.

To put it another way, one person maintaining a signifigant portion of mods time is worth it in my understanding of team work.

All is moot - suggestions have, and are being made. Ultimately up to LinuxGuruGamer, and I personally have confidence he won't break anything; and if he does, he will help clean up what limited fallout there is. I also believe he can do both, just pick and choose.

Communication is one of the three c's in teamwork, as is coordination and cooperation. He is communicating with this post; and if he decides to proceed, well, he strikes me as a professional who will coordinate, cooperate, and communicate to limit the fall out. I don't foresee him doing all at once if he does; rather a systematic implementation of a military precise plan is what I'd expect with lots of teamwork with other authors and maintainers. Change is good, and flat file structures are bad. :P

We've, in my opinion, monopolized enough of this thread.

Be well, and don't let Jeb drive.

Edited by zer0Kerbal
Link to comment
Share on other sites

IMO if you need to do it then do it. I agree make it a major version number bump.

As a practical example, look what happened when you decided that everything needs ClickThroughBlocker and ToolbarControl - yes there was a bit of fallout, but now people are all on the same page.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...