[1.8.1-1] [PLEASE FORK ME] Kopernicus & KittopiaTech

[Rover 6428]

1 minute ago, Tonka Crash said:

Yes

noooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

[Jognt]

I'll just answer the question before it gets asked:

Kopernicus will be released for 1.7.2 two weeks after the KSP 1.8.0 release, with a month added for every 1.7.1 release done, and a week added for every time the question gets asked.

[Giezer1984]

The solarpanels are not working for me in 1.7.2 again. Naturally i openend my savegame accidentially in 1.7.2.

Now I am trying to understand where to put the "  = false " in the config file but its not very clear to me. Did somebody manage to do this succesfully? I mean where can I find the module node?

@PART:FINAL
{
    // This will replace all instances of ModuleDeployableSolarPanel with the Kopernicus version
    // that has proper support for multiple lightsources
    // 
    // If you want to keep your ModuleDeployableSolarPanel, add "useKopernicusSolarPanels = false" to the MODULE node
    // That will stop Kopernicus from replacing it
    @MODULE:HAS[#useKopernicusSolarPanels[*]]
    {
        @useKopernicusSolarPanels,* ^= :F:f:
        @useKopernicusSolarPanels,* ^= :A:a:
        @useKopernicusSolarPanels,* ^= :L:l:
        @useKopernicusSolarPanels,* ^= :S:s:
        @useKopernicusSolarPanels,* ^= :E:e:
    }
    @MODULE:HAS[#name[ModuleDeployableSolarPanel],~useKopernicusSolarPanels[false]]
    {
        @name = KopernicusSolarPanel
    }

}
 

[4x4cheesecake]

1 hour ago, Jognt said:

I'll just answer the question before it gets asked:

Kopernicus will be released for 1.7.2 two weeks after the KSP 1.8.0 release, with a month added for every 1.7.1 release done, and a week added for every time the question gets asked.

Don't forget the bonus points collected by Thomas P for releasing 4 versions on the same day, each point is the value of one week delay

22 minutes ago, Giezer1984 said:

The solarpanels are not working for me in 1.7.2 again. Naturally i openend my savegame accidentially in 1.7.2

Kopernicus is version locked and unloads itself if the version of KSP and Kopernicus don't match so everything which is related to kopernicus, incl. the solar panels stop working. The solar panels are replaced by a MM patch (the one you have posted) and this patch will be applied even though kopernicus isn't loaded into the game.

In order to fix this, you can:

• wait for an update
• uninstall kopernicus
• revert KSP back to 1.7.1
• add a custom patch to disable the kopernicus panels:

@PART:BEFORE[Kopernicus]
{
    @MODULE:HAS[#name[ModuleDeployableSolarPanel]]
    {
        useKopernicusSolarPanels = false
    }
}

IMO, uninstalling or reverting KSP should be the best solution

 

[Tabris]

1 hour ago, 4x4cheesecake said:

Don't forget the bonus points collected by Thomas P for releasing 4 versions on the same day, each point is the value of one week delay

Kopernicus is version locked and unloads itself if the version of KSP and Kopernicus don't match so everything which is related to kopernicus, incl. the solar panels stop working. The solar panels are replaced by a MM patch (the one you have posted) and this patch will be applied even though kopernicus isn't loaded into the game.

In order to fix this, you can:

• wait for an update
• uninstall kopernicus
• revert KSP back to 1.7.1
• add a custom patch to disable the kopernicus panels:

@PART:BEFORE[Kopernicus]
{
    @MODULE:HAS[#name[ModuleDeployableSolarPanel]]
    {
        useKopernicusSolarPanels = false
    }
}

IMO, uninstalling or reverting KSP should be the best solution

 

shouldn't that be @PART:AFTER[Kopernicus]

because if you load it before kopernicus then when kopernicus loads it will overwrite the above patch.

[4x4cheesecake]

3 minutes ago, Tabris said:

shouldn't that be @PART:AFTER[Kopernicus]

because if you load it before kopernicus then when kopernicus loads it will overwrite the above patch.

No, the kopernicus patch will be applied if the MODULE "ModuleDeployableSolarPanel" does NOT contain the key "useKopernicusSolarPanels = false" so you have to add this key before kopernicus runs.

[Superfluous J]

2 minutes ago, Dragon01 said:

I'm pretty sure it's easier to write a proper compatibility test than to convince Squad to fix their version numbering scheme.

I'm pretty sure it's easier to use Steam as a backup and copy your real game to a different directory so you're in control of what version you are running.

[4x4cheesecake]

12 minutes ago, Dragon01 said:

Except you usually can't revert a minor version. I'm not a Steam user so I'm not sure if that's the case now, but it probably is. 

On steam, that's no problem at all. Quite a lot versions are available via the beta program:

Spoiler

but by using the console, you can get every version which was released on steam.

12 minutes ago, Dragon01 said:

Which is exactly why version locking, especially to a minor version, is wrong.

I disagree. The difference between 1.7.0 and 1.7.1, even without the DLC, is huge and there are already some mods which required an update specific for 1.7.1 and these versions are not backward compatible to 1.7.0. Just imagine what will happen, if you play in a solar system which replaces all the stock planets. Loading such a game into a broken kopernicus will destroy this savegame you definitely don't want to deal with people comlaining about broken savegames caused by an incompatibility.

Edited June 12, 2019 by 4x4cheesecake

[gap]

1 hour ago, 4x4cheesecake said:

 

IMO, uninstalling or reverting KSP should be the best solution

 

 

20 minutes ago, Dragon01 said:

Except you usually can't revert a minor version. I'm not a Steam user so I'm not sure if that's the case now, but it probably is. 

Minor versions are not as easy to get as major ones, but they can still be downloaded from steam, as shown to me a few days ago by the same 4x4cheesecake:

On 6/4/2019 at 6:33 PM, 4x4cheesecake said:

...if you need a version which is not listed in the beta dropdown menu, there are a ton of tutorials how to do it, for example this one:

https://steamcommunity.com/sharedfiles/filedetails/?id=1086279994

 

17 minutes ago, 5thHorseman said:

I'm pretty sure it's easier to use Steam as a backup and copy your real game to a different directory so you're in control of what version you are running.

That's a good workaround!

Probably old news for you KSP veterans, but this time I managed blocking the updated by selecting the game property option that makes updates to only happen on game launch, and by exiting steam before running the game. Not a perfect solution indeed, but it worked for me

Edited June 12, 2019 by gap

[Guest]

Then don't load your savegame after you realize Kopernicus didn't load properly (which should be known once you enter the main menu). Which, BTW, is exactly as it works right now, except the check is incredibly crude, literally the simplest possible. In fact, if the planet mod in question affects Kerbin, it's immediately obvious if something goes wrong, because Kerbin would revert to its stock appearance. Alternatively, it could quit KSP without saving once you detect that the save didn't load as it was supposed to (it would have the benefit of protecting saves made with a different planet pack, but on the same version). What we have now manages to be both inadequate and oversensitive.

1.7.1 should be 1.8 under any sane numbering system. Squad doesn't have a sane numbering system. This just disqualifies version numbers completely as a compatibility checking tool. We've even had one update that didn't change version numbers at all.

Workarounds involving Steam console, copying your KSP out Steam folder and the like are just that: workarounds. Not a solution to a problem ultimately caused by an obvious misfeature.

Edited June 12, 2019 by Guest

[Superfluous J]

11 minutes ago, Dragon01 said:

Workarounds involving Steam console, copying your KSP out Steam folder and the like are just that: workarounds. Not a solution to a problem ultimately caused by an obvious misfeature and Squad being silly with their versioning.

Yeah but what problem?

Steam's problem, that people never update and then complain to Steam about problems caused by old versions? Steam fixed that problem by forcing updates.

Squad's problem, that they can't handle this much web traffic every update? They solved that problem by using Steam.

Kopernicus' problem, that it's far more likely for an update to break something than not, and sorting "I didn't read the instructions" from "I have a legitimate bug" posts was too much for people working for free? They solved that problem by version locking.

Or your problem, that you allowed these 3 things to break your ability to play your modded game? It's up to you to solve that problem. Not anybody else.

Edited June 12, 2019 by 5thHorseman

[Jognt]

2 minutes ago, 5thHorseman said:

Yeah but what problem?

Steam's problem, that people never update and then complain to Steam about problems caused by old versions? Steam fixed that problem by forcing updates.

Squad's problem, that they can't handle this much web traffic every update? They solved that problem by using Steam.

Kopernicus' problem, that it's far more likely for an update to break something than not, and sorting "I didn't read the instructions" from "I have a legitimate bug" posts was too much for people working for free? They solved that problem by version locking.

Or your problem, that you allowed these 3 things to break your ability to play your modded game? It's up to you to solve that problem. Not anybody else.

Though your post has solid points I’d like to point out that you’re not replying to the person whose save broke.  

Now, I know we’re all suffering from severe Kopernicus withdrawal, but let’s stay civil shall we?

 

[Guest]

Just now, 5thHorseman said:

Kopernicus' problem, that it's far more likely for an update to break something than not

This is false. Might have been the case around 1.4-1.5, but not anymore. 1.7.1 was a special case, since they added a DLC that touched planets. This reasoning is long obsolete.

The problem is far from limited to me. In fact, I use Kopernicus for eyecandy, and the warning is just annoying, since I can proceed to load the save just fine. If I were to fix it just for myself, I'd have compiled from source with the check nuked, like I outlined earlier in this thread.

[4x4cheesecake]

2 minutes ago, Dragon01 said:

Then don't load your savegame after you realize Kopernicus didn't load properly (which should be known once you enter the main menu).

You don't even have to wait for the main menu, the warnings are more then obvious:

Spoiler

Nyan cats, screen message and a popup window (and at least the window will stay there until you click on "OK")... that should be enough already to prevent anybody to load the savegame but it still happens. If I remember correctly, it's called a "layer 8 issue"

You can argue that it's a bit too much to unload the assembly and maybe it is but how does a warning look like in this case? "Your savegame may break, good luck to find out"?

15 minutes ago, Dragon01 said:

1.7.1 should be 1.8 under any sane numbering system. Squad doesn't have a sane numbering system. This just disqualifies version numbers completely as a compatibility checking tool.  

I agree, 1.7.1 should be 1.8, similar to 1.4.1 and 1.5. but if you cannot use version numbers to check for compatibility, what else is left?

[Superfluous J]

5 hours ago, Jognt said:

Though your post has solid points I’d like to point out that you’re not replying to the person whose save broke.  

That post was really directed at anybody thinking that the Kopernicus devs (and everybody else in the chain) don't have reasons for doing what they're doing.

You can complain about Steam. To a lesser extent you can complain about Squad. You gave them money. But Kopernicus? No. You have zero ground to criticize the free thing they gave you.

5 hours ago, Jognt said:

Now, I know we’re all suffering from severe Kopernicus withdrawal, but let’s stay civil shall we?

I thought I was quite civil. Stern, sure, but civil.

[Kerenatus]

Sweet mother of mercy, i just finished setting up my planet mods for 1.7.1 half a day ago, and now 1.7.2 comes

[Giezer1984]

10 hours ago, 4x4cheesecake said:

Don't forget the bonus points collected by Thomas P for releasing 4 versions on the same day, each point is the value of one week delay

Kopernicus is version locked and unloads itself if the version of KSP and Kopernicus don't match so everything which is related to kopernicus, incl. the solar panels stop working. The solar panels are replaced by a MM patch (the one you have posted) and this patch will be applied even though kopernicus isn't loaded into the game.

In order to fix this, you can:

• wait for an update
• uninstall kopernicus
• revert KSP back to 1.7.1
• add a custom patch to disable the kopernicus panels:

@PART:BEFORE[Kopernicus]
{
    @MODULE:HAS[#name[ModuleDeployableSolarPanel]]
    {
        useKopernicusSolarPanels = false
    }
}

IMO, uninstalling or reverting KSP should be the best solution

 

This actually worked and fixed my solar panels issue, thanks cheesecake !! I believe the guidance in the .cfg file should be more informative like your explanation was. 

So just to be clear I had a broken savegame file on 1.7.2 and I am stuck on kopernicus 1.7.1. This way my solar panels where not working anymore. Adding the useKopernicusSolarPanels = false in the SolarPanels.cfg file of Kopernicus fixed the solar panels not charging. And strangly enough it looks like everything is working now on 1.7.2 even though I have a warning about kopernicus 1.7.1 not working on 1.7.2. 

I will now opt out any updates on KSP via steam and I will make a back up of KSP. I only use Kopernicus becease of the GEA V7M2.0.4 eyecandy mod. Thanks guys for putting some light on the issue. If you don't want any issue with every update and want to play casual one can always play just default. No harm intended for all de modders that try and make the game even more great, but just note that the mods that really change the game can also be quickly broken by an update. 

[BlueZed]

If I copy my KSP 1.7.1 (with Kopernicus 1.7.4) game folder to continue playing, will I need to amend my later save game file in any way to keep it usable once KSP 1.7.2 (with Kopernicus 1.7.>4)?  The first line of the .sfs file has the version number.  Thank you.

 

[jbarry39]

...and....1.7.2 breaks Kopernicus...shocker

[StarStreak2109]

And here I was just starting to update JNSQ to 1.7.1... smh

[Cruesoe]

1 hour ago, jbarry39 said:

...and....1.7.2 breaks Kopernicus...shocker

It doesn't break Korpernicus as such. There was never a hope it would work. It's version locked. It will only ever work on the exact version it's built for.

[Artfact]

I only really noticed when I got up into the upper atmosphere that the JNSQ Kerbin was...not there.

Oops.

[Kerenatus]

Let's be grateful to the developers who make this great mod to the public FOR FREE 

and let's not forget that they have no obligation of any sort to fullfill everyone's or anyone's want/need/preference.

They make decisions for this mod they see fit, simple as that.

[snip]

Edited June 14, 2019 by Snark
Redacted by moderator

[Rover 6428]

I love that SQUAD is now more lively with working on their game, but this is getting a bit irritating

Edited June 13, 2019 by Rover 6428

[Thomas P.]

[Moderator's note: This thread has been extensively pruned due to off-topic kvetching about Kopernicus' version lock, after a moderator request to cease doing so. However, Thomas' comments here are particularly cogent, since he's the author, so this post has been left in place for future reference, after anonymizing the quotes involved.]

Quote

However, what I want is a solution to the problem, not a workaround.

The solution to the problem is removing the checker and maintaining it like every other KSP mod without version locking. However, for various reasons that I keep posting every KSP release, I am not willing to do that. If someone shows up and takes Kopernicus out of my hands I am heading for the airlock faster than you can blink. I am still maintaining it because - as you said - people depend on it and I don't want to leave them standing in the rain, but as for myself, I have lost almost any interest I have in KSP. I am not going to spend my time with user errors that happen because of obscure errors that a new version introduced.

Quote

I have a million ways to work around this problem, what with me being a KSP Store user and having dabbled in programming. In fact, under the terms of its license, I could fork the blasted thing and do the checking properly, if I really wanted to.

Fine. If you can tell me any way, how to properly unit test a blackbox that can change at any time (hint: KSP updates do that, rumors say), without knowing anything about how this blackbox changed, and that at runtime, every time the game is launched, without lagging it to death, then I will happily accept it. Given that this test doesn't end up being bigger than the entire mod.

For those of you who don't know it: KSP's planets (and basically the entire game) consist of objects that are parented to each other, creating a tree-alike structure. Each of these objects can have multiple scripts attached that are executed each frame. What KSP does is storing a copy of one of these trees, with all planets parented to it. At some point in the loading process, it takes this tree, and searches it's children for a predefined planet structure, and spawns them into the planetary system. Those planet prefabs have multiple sub-trees, like the PQS object, the scaled space etc. etc., all of which are spawned into different trees at runtime. (ScaledSpace for example is seperated from the PQS so you can disable and enable them independently).

Kopernicus edits this prefab tree and lets KSP spawn the planets, so they are spawned exactly like KSP would like to have them. Spawning them manually has been tried before (=> Planet Factory), and yeah, it is even more chaos than Kopernicus is. But the spawner just copies objects and restores some references, everything else is assumed to be correct.

At runtime, KSP then assumes that some things exist, like certain components that interact with each other etc. That is not a problem for Squad because they know (I hope) how their planets work, and can adjust to changes. But because Kopernicus uses stock components all the time to build the planets, if it doesn't create or edit one correctly - or in the right place, everything can break and kill your savegame. For example, the colliders on the terrain are a component. If Squad would change the place where that component goes, Kopernicus would still add it in the spot that worked before, and none of your bodies would have terrain colliders. And you wouldn't notice until it is too late and you loaded your vessel which is now falling into the void.

Of course this is all a huge oversimplification, but I hope it gets the point across. Actually, an even simpler example: It is like figuring out if a car works or not, without actually starting the car. Even if you are a top class mechanic, you will have problems doing this when your car is a huge gigantic blackbox, that you cannot open, and you don't even know whether it drives with gasolin or rainbows. When you only see the surface you have no idea how things work behind it, and therefor cannot test for it.

Quote

That's what development betas are for (it's user testing, is it not?). Which many modders do, too, and not only ones making part packs.

There are people who can test unlocked versions of Kopernicus and do so. However, the moment I release unlocked betas, people will think (or want to think) that they are stable. People are not reasonable.

Quote

The "4 releases in one day" thing is an obvious consequence of not having a dev build circulating, actually (not that it's disagreeable in itself, just at odds with the usual line of pro-version lock argumentation). Besides, subtle bugs can happen even if versions do check out.

4 releases in one day is an obvious consequence of me touching every file of the codebase and being an idiot sometimes (=> forgetting to update my build scripts, see 1.7.0-2 ). Game breaking bugs can get catched by testing. If there are obvious errors in the loading process (as in: code errors instead of logic errors in the KSP blackbox), you get greeted with the same warning to not load your saves. Yes, we make errors too, and yes we don't catch everything. We are just humans too. But some testing feels better than none at all.

Quote

In fact, as I often stated, problems with Kerbin can be diagnosed by looking at the planet in the main menu. 

You forget that Kopernicus can be used for much more than just visuals. I could install an entire galaxy in KSP and populate it, and still start from Kerbin. If I don't edit Kerbin, there is no change to the main menu kerbin. But if all other bodies stop loading (for example with Outer Planets Mod), every vessel orbiting them is moved to the trashcan. Again, try figuring out how that hypothetical car work without actually starting it and seeing if it explodes or turns into a pumpkin.

 

So, we will probably never agree and thats completely fine. Maybe it is possible to unit test KSP. I don't know. But I don't have the time to care about it either. My solution works for me and seemingly the majority of the people. If it wouldn't work, people would fork it and remove it. Thats the beauty of opensource after all.

[One final moderator reminder, folks. This post by the mod author has been left in place as a useful reference.  Please do not attempt to respond or continue the argument. Thank you for your understanding.]

Edited June 14, 2019 by Snark
Redacted by moderator