[1.12] HyperEdit [v1.5.8, July 10, 2018] - Cheat, Teleporter, Orbit/Planet Editor, & More

[BaelRathLian]

1 minute ago, Ezriilc said:

Same place as all versions - on our site.  http://www.Kerbaltek.com/hyperedit

Thanks.  Google search only went here.

 

[swjr-swis]

On 12/23/2017 at 8:23 PM, Ezriilc said:

Yes.  This was done to keep our mods' data (text) files out of the GameData folder, where actual game components are kept.

EDIT: The relevant note for this version:  "Moved config and info files to [KSP_root]/PluginData."

At the risk of being a lonely (and rather irrelevant, as a current stock player) voice: is there any way to reverse this decision?

We had accepted those root directories being nothing more than vestigial remains that can be safely assumed empty and useless; any actual plugin data being contained in the plugin directories themselves is as close to a standard as we have seem to come with KSP modding.

Why break convention? Why force players to now have to consider that mods may choose other places to store their data - potentially causing file overwrite conflicts if more than one mod decides to place a similar named data file in that one root dir?

[Ezriilc]

1 hour ago, swjr-swis said:

At the risk of being a lonely (and rather irrelevant, as a current stock player) voice: is there any way to reverse this decision?

We had accepted those root directories being nothing more than vestigial remains that can be safely assumed empty and useless; any actual plugin data being contained in the plugin directories themselves is as close to a standard as we have seem to come with KSP modding.

Why break convention? Why force players to now have to consider that mods may choose other places to store their data - potentially causing file overwrite conflicts if more than one mod decides to place a similar named data file in that one root dir?

Well, first off, you are not "irrelevant, as a current stock player".  I too play almost entirely vanilla - except for MechJeb and HyperEdit (both still used in limited circumstances).  As a result, I may not have understood the gravity of this change.

Secondly, I'm not married to either position, and I look forward to hearing any and all input on this issue.  @swjr-swis, please elaborate your argument, as in my holiday-addled condition, I don't feel I understand it completely, but it does seem compelling.

I therefore open debate to both sides of... leaving our data files where they were; or moving them to /PluginData.

[Poodmund]

The standard convention is for all mod files to exist within their own directory structure within the GameData folder as to be completely independent of KSP's own game hierarchy. Any mod plugins/files that exist with their own mod directory PluginData folder will operate the same as if they were located in KSP Root/PluginData.

i.e. KSP/GameData/Mod/PluginData

The decision to remove them and locate mod files anywhere other than GameData at this point seems rather strange when considering the long existing standards, conventions and behavior.

[swjr-swis]

8 hours ago, Ezriilc said:

@swjr-swis, please elaborate your argument

Main argument is that standards/conventions are good in community efforts. KSP modding is a very lively environment, with thousands of mods by now, and almost anyone can go ahead and create a mod. We need to cherish any standards we can manage to agree on... as the workings and compatibility of all our mods can and will sooner or later depend on them.

Note that I'm not criticizing the decision to relocate HyperEdit's data files -  I think it's a good idea. My remark is just about the chosen location.

The general convention for mods, for a while now, is to use the GameData/Mod/PluginData directory for mod data files. This has slowly been replacing the older convention of simply placing data files in the mod's main directory or an arbitrarily named subdir of it.

Using GameData/Mod/PluginData, all the mod's files and data can be found in the mod's subdir, which makes it easier to archive a mod and later reinstall it with all it's data/settings intact (just zip/unzip "GameData/Mod", and you're done). Removing a mod, since it affects only its own directory in GameData, should never affect any other mods (barring any hard dependencies of course).

The use of the GameData/Mod/PluginData directory I think was initially prompted as a way to exclude certain mod-specific *.cfg files from being incorrectly processed by Module Manager as MM patches. In other words: placing files there is akin to publicly stating "enter at your own risk - these files are only intended for this one mod alone". One standard named subdir to skip is easier to code for. I don't know of other mods than MM that scour the entire Gamedata tree for files to process (maybe texture optimizers/replacers?), but if one mod had reason to others may follow, so it's worth keeping in mind.

 

On the other hand, using the root PluginData, while seemingly even easier to code (literally just one directory), actually makes things more complicated: that directory would be shared by all mods (there's only one PluginData at the KSP root after all), so extra rules would need to be agreed on -and consistently followed- to ensure mods leave each other's data alone. The very real risks of filename conflicts and overwriting each others' data have to be considered.

A very simplistic example: 'readme.txt' or 'settings.cfg' are commonly used filenames - in a mod's own subtree, this is very clear for authors and users and never an issue; but in the shared root PluginData, the last installed/saving mod would overwrite all others that use those same filenames, leading to all sorts of potentially hard to diagnose problems.

Also, removing/archiving a single mod would need one to look in two places for all its files, and again the risk of affecting other mods lurks - users would need to be very mindful of which files from that one shared directory to remove. More support issues may ensue, and more detailed add/remove instructions would be required for mods.

 

Aside from the above, up to now the root PluginData directory has been empty and unused for many versions, like several other directories the game (re)creates in the root - an historical coding remnant that KSP has long ago moved away from. You're basically necro'ing a long-dead directory, and as we all know, mods frown upon necros (). Seriously though, I think I'm not the only one that keeps hoping Squad will finally remove those vestigial root dirs permanently, for everyone's sake.

[Mandella]

In relation to the directory issue, I have to say I prefer the Gamedata/Mod/PlugIn structure. Just include in the readme that if one wishes to keep one's settings on an update to not copy over the PlugIn directory. Of course, you'd have to keep in mind that often changes in the way that the settings are written might mean you *want* to overwrite the PlugIn directory on update.

A possible bug report. While the new version of HyperEdit will transfer a ship to orbit just fine, it refuses to land at any specific coordinates at all (Land Here still works). The button just does not function.

I am playing on Win10 KSP 1.3.1, but I am also playing with RSS, and with about a hundred other mods. I'll include logs if wanted, but with my nightmarishly modded game I wanted to see if anyone else is having a problem while playing in the RSS environment first.

[Ezriilc]

Well the directory structure was changed due to a suggestion by someone - I can't remember who - and I think it was related to Module Manager or a similar mod that looks at all the contents of GameData, and was tripping up on our text files.

I didn't see any issue with the change, so I went ahead with it.  I need to look back over this thread and my emails to figure out who and why I did this for.

[Stone Blue]

8 minutes ago, Ezriilc said:

Well the directory structure was changed due to a suggestion by someone - I can't remember who - and I think it was related to Module Manager or a similar mod that looks at all the contents of GameData, and was tripping up on our text files.

I didn't see any issue with the change, so I went ahead with it.  I need to look back over this thread and my emails to figure out who and why I did this for.

MIght have been due to the closing of "loopholes" in MM syntax/logic, in the 3.0.x MM updates... if thats the case, NOT really a good reason to change the folder structure of a mod, as this would just be an MM workaround, which would ultimately fail... and IMHO, would just set a bad precedent for other mods to start doing

 

Edited December 26, 2017 by Stone Blue

[Ezriilc]

2 minutes ago, Stone Blue said:

MIght have been due to the closing of "loopholes" in MM syntax/logic, in the 3.0.x MM updates... if thats the case, NOT really a good reason to change the folder structure of a mod, as this would just be an MM workaround, which would ultimately fail...

I honestly don't know, and it appears I've deleted my archived emails.

It's certainly not hard to put it back, if everyone thinks it's important.

[linuxgurugamer]

9 hours ago, Poodmund said:

The standard convention is for all mod files to exist within their own directory structure within the GameData folder as to be completely independent of KSP's own game hierarchy. Any mod plugins/files that exist with their own mod directory PluginData folder will operate the same as if they were located in KSP Root/PluginData.

i.e. KSP/GameData/Mod/PluginData

The decision to remove them and locate mod files anywhere other than GameData at this point seems rather strange when considering the long existing standards, conventions and behavior.

What @Poodmund and others have said.

The ONLY thing I would consider being ok to save elsewhere is if a file is being saved in the directory of the save file.  Other than that, all files for a mod should remain in the mod's directory in the GameData directory.

[Ezriilc]

2 minutes ago, linuxgurugamer said:

What @Poodmund and others have said.

The ONLY thing I would consider being ok to save elsewhere is if a file is being saved in the directory of the save file.  Other than that, all files for a mod should remain in the mod's directory in the GameData directory.

Well, that's good enough for me.  Without objection, I will change it back.

It looks like the suggestion came via/with a pull request from @blowfish.

[Ezriilc]

Finally, is this worthy of a patch release?  EDIT:  I just decided to go ahead and publish.

Edited December 26, 2017 by Ezriilc

[blowfish]

Could anyone here ( @swjr-swis @linuxgurugamer ) elaborate on why you think putting data in <ksp_root>/PluginData/SomeMod/ is a bad idea?

I've seen some issues with <ksp_root>/GameData/SomeMod/PluginData ... most notably, if you install via CKAN, then the mod puts some stuff there, then you uninstall, the SomeMod folder will remain in GameData (since CKAN doesn't know about those files, it won't remove them), making ModuleManager think that the mod is still installed.

If you are manually installing mods, keeping settings out of GameData also makes it easier to update a mod without loosing all of your configuration.  Consider this scenario: Version A has a particular file, version B (the next version) no longer requires that file and removes it.  To ensure that you aren't left with dead files, when installing a new version, it's really best to delete the mod's entire directory first ... except that if you're using GameData for settings, that directory also has all those settings, so you either have to re-do all your settings in the next version or figure out which files to copy over.

@Stone Blue nothing to do with MM changes, this has been a long-standing issue.

[Superfluous J]

25 minutes ago, blowfish said:

Could anyone here ( @swjr-swis @linuxgurugamer ) elaborate on why you think putting data in <ksp_root>/PluginData/SomeMod/ is a bad idea?

I'm not them, but putting anything in any folder other than GameData is a bad idea, if only for the fact that when I copy all my mods from one install to another (or delete mods to troubleshoot a problem or just to delete them) the detritus of a mod that throws data all over the place will annoy at best and break stuff at worst.

I'd much rather deal with config changes when updating, then random problems that take hours to troubleshoot even AFTER I've deleted all mods - or so I thought.

[swjr-swis]

2 hours ago, blowfish said:

Could anyone here ( @swjr-swis @linuxgurugamer ) elaborate on why you think putting data in <ksp_root>/PluginData/SomeMod/ is a bad idea?

I did, several hours and 8 posts earlier in this thread:

 

2 hours ago, blowfish said:

I've seen some issues with <ksp_root>/GameData/SomeMod/PluginData ... most notably, if you install via CKAN, then the mod puts some stuff there, then you uninstall, the SomeMod folder will remain in GameData (since CKAN doesn't know about those files, it won't remove them), making ModuleManager think that the mod is still installed.

I need to be careful how to phrase my response to this, as I am very appreciative of the work all mod authors do, especially when it comes to mods with rather crucial roles.

CKAN's choice/inability to deal with new and changed files in mod directories is -pardon my french- an issue in CKAN ... not HyperEdit. Changing HE to solve an issue in CKAN is, well, questionable.

First: one mod changing its ways regarding where its data files are stored does not solve the exact same issue happening with over a thousand other mods. And what is exactly the long-term strategy here... submitting PR's to every mod one by one until they all adhere to this new ksp_root/PluginData idea, and then we no longer need to solve the actual issue in CKAN?

Second: CKAN *needs* to learn how to deal with new and changed files, because it has been a reality of modding for as long as I remember. Open source mod managers for games with a modding environment several orders of magnitude more complex than KSP (most notably Skyrim comes to mind) have been doing that successfully for years now. Solve the problem at the source instead of trying to build workarounds into other mods... especially when the workaround comes with its own set of issues and requires deviating from an accepted community standard.

As far as I'm concerned, if CKAN refuses to deal with those files itself, it should at least tell the user about them and ask the user to decide. That way, the responsibility remains squarely with the user, and it will be no different than if they had uninstalled/deleted them (or left them untouched) manually. The exact location of the files is then entirely irrelevant for the argument.

 

A similar thing can be said about Module Manager equating GameData/<randomdirectoryname> with 'oh look, <randomdirectoryname> mod must be installed'. While that is often true, it is clearly, to this day, still not ALWAYS true - some mods name the dir something other than their plugin dll (which one should have precedence?), others deliberately put numbers and/or underscores in front of the subdir name to 'force' a specific loading order, some mods bunch together under one 'main' subdirectory in GameData or reversely, place several subdirs in GameData for just one mod, and some mods don't do subdirs at all and just dump all their stuff in GameData itself (ironically, MM itself does this, thereby deviating from a 'standard' that it expects others to adhere to).

And as with CKAN, changing HE still leaves MM's inherent issue for the hundreds of other mods that continue to use the Gamedata/Mod/PluginData convention, so the change to HE doesn't actually solve the issue you mention - it just makes HE deviate from the convention.

Let's please solve the issues where they really are.

 

2 hours ago, blowfish said:

If you are manually installing mods, keeping settings out of GameData also makes it easier to update a mod without loosing all of your configuration.  Consider this scenario: Version A has a particular file, version B (the next version) no longer requires that file and removes it.  To ensure that you aren't left with dead files, when installing a new version, it's really best to delete the mod's entire directory first ... except that if you're using GameData for settings, that directory also has all those settings, so you either have to re-do all your settings in the next version or figure out which files to copy over.

Dead files can happen with data files too, not just plugin files. So the scenario you describe basically just relocates the problem to another directory instead of solving it - you still have to be mindful of what you want to save. On top, now people have to first figure out whether the mod is storing their data in GameData/Mod/PluginData, or is one of them new-fangled fancy ones () that uses ksp_root/PluginData.

Besides, if users make a habit of archiving their ONE mod subdir before making any changes to it (like deleting or updating it), the zip will automatically contain all settings files as well, without the extra step of having to archive a second, separate data subdir. Not only does that sound easier to me, it also has the failsafe of an archive of the settings files from before the update, meaning one can easily revert to the un-updated version if for whatever reason the update is not satisfactory (or corrupts the data/settings themselves).

 

This proposed change to mod data storage location goes far beyond HyperEdit (and frankly I fail to see its relevance for HE - what specific problem of HyperEdit itself does this solve?), so I suggest we move further discussion/debate of this to its own thread. I'm all for improving standards, but randomly changing a mod is the wrong way to go about it (said the pure stock player, feeling rather uncomfortable at having to speak up).

Edited December 27, 2017 by swjr-swis

[BaelRathLian]

On ‎12‎/‎25‎/‎2017 at 5:34 PM, BaelRathLian said:

Thanks.  Google search only went here.

 

Tried several versions.  Does not seem to work with 1.2.9.

[USB4]

Is there a way to set the speed boost defaults through the config (Both key binding and speed)?

[swjr-swis]

11 hours ago, BaelRathLian said:

Tried several versions.  Does not seem to work with 1.2.9.

There isn't any. Best answer you will get: stop using a pre-release version of the game.

Very few mod authors even compile mods for a pre-release, because they are very temporary builds that often include breaking changes, so authors tend to wait until a release version. There are even less that keep such a temporary version archived even if they compiled a test version, to minimize the risk of people coming back asking for support for them.

I saw from one of your other posts requesting mods for 1.2.9 that you call it a 'free demo' - I'm pretty sure there was never a free or demo version of 1.2.9. If you like KSP enough to want to mod it, buy the game, and you can enjoy hundreds of mods on a stable version of the product. It's worth it and you know it.

[fronbow]

3 minutes ago, swjr-swis said:

There isn't any. Best answer you will get: stop using a pre-release version of the game.

Very few mod authors even compile mods for a pre-release, because they are very temporary builds that often include breaking changes, so authors tend to wait until a release version. There are even less that keep such a temporary version archived even if they compiled a test version, to minimize the risk of people coming back asking for support for them.

I saw from one of your other posts requesting mods for 1.2.9 that you call it a 'free demo' - I'm pretty sure there was never a free or demo version of 1.2.9. If you like KSP enough to want to mod it, buy the game, and you can enjoy hundreds of mods on a stable version of the product. It's worth it and you know it.

I agree. It sounds like you're using a "dodgy" copy as there wasn't a proper released version (only the pre-release for testing planned changes). And the wiki - https://wiki.kerbalspaceprogram.com/wiki/Version_history - has no mention of that version.
You should really support indie developers! and FWIW it's half price in the Steam Winter sale. Bargain!

[swjr-swis]

 

2 hours ago, USB4 said:

Is there a way to set the speed boost defaults through the config (Both key binding and speed)?

There isn't - it's hardcoded. HE remembers changes to those through a game session (even after going back to the main menu) but it doesn't save it anywhere, so the next time you restart the game it will be at defaults again.

[blowfish]

@swjr-swis I'd actually point to the fact that there is no standardized notion of how a "mod" is structured in KSP.  Some mod authors prefer to keep all their mods in the same GameData directory, others split them out, some are just a plugin, etc.  So with regard to CKAN, it's really difficult to justify the assumption that just because CKAN doesn't know about the remaining files in a particular directory, they can be removed.  ModuleManager has several ways of determining that a mod is "installed", and the GameData subdirectory way isn't going away any time soon (I can tell you from my own experience how difficult making breaking changes to ModuleManager is).

With regard to the settings files being dead themself, the difference is that KSP doesn't load them automatically, which is not the case if you e.g. have a dead texture or something - that will impact loading time and memory usage.

And finally, I'd question whether even a significant fraction of users are aware that settings are stored in GameData/<some_mod>/PluginData

@Ezriilc if the settings are going to be moved back to GameData, they should be within some PluginData directory.  Probably GameData/Kerbaltek/HyperEdit/PluginData.  Also, I think that the code I added to migrate the settings to the new location is instead deleting them on each KSP startup after your most recent change (since the "old" and "new" settings locations are now the same).

[Ezriilc]

8 hours ago, USB4 said:

Is there a way to set the speed boost defaults through the config (Both key binding and speed)?

That is a worthy idea.  I'll make an issue for it.  EDIT:  I've added this point to an existing issue here.  https://github.com/Ezriilc/HyperEdit/issues/10

 

2 hours ago, blowfish said:

 

@Ezriilc if the settings are going to be moved back to GameData, they should be within some PluginData directory.  Probably GameData/Kerbaltek/HyperEdit/PluginData.  Also, I think that the code I added to migrate the settings to the new location is instead deleting them on each KSP startup after your most recent change (since the "old" and "new" settings locations are now the same).

I was worried that I was missing something.  Can you fix me up?

As for the PluginData folder inside Kerbaltek/HyperEdit, I just left that out to avoid excessive directories.

Edited December 27, 2017 by Ezriilc

[blowfish]

19 minutes ago, Ezriilc said:

I was worried that I was missing something.  Can you fix me up?

As for the PluginData folder inside Kerbaltek/HyperEdit, I just left that out to avoid excessive directories.

I can submit a PR, yeah.

The point of having it be in some PluginData folder is that setting changes don't invalidate ModuleManager's cache.

Edited December 27, 2017 by blowfish

[fronbow]

@blowfish @Ezriilc

I've done this change in my current build - just sorting out a UI bug before I do a PR!

[Kulebron]

Using 1.3.1.1891 and Hyperedit 1.5.6, still the landing coordinates drift on other planets. On Laythe, the "current" coordinate is different from the real one (seems like opposite). When I set coordinates, after some time they differ by 1-2 degrees (do they drift?)