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

[Maniaex]

1 hour ago, OhioBob said:

From my experience, you don't calculate the orientation.  You just figure out by trial and error what best fits the surrounding terrain.

Ok, just did that, works perfectly. Brylliant!

[Murdabenne]

Just wondering what the target is for release by the addon developers  And no, I dont mean a date but target version.

Is the target 1.9.1, or will this wait until 1.10 KSP  Shared Horizons, July 1, and essentially start the update process over again?  If the latter, then I fear I may not live to see my beloved configurations with OPM and associated addons in anything resembling a current version.   COVID hasn't killed me ...yet.  In hospital for 17 days, and wrecked physically nearly completely for twice as long,  but if that damnable virus comes back again, and there is no immunity from either a vaccine or having had it prior, then I'm worried.

Anyway, keep doing whatever it is you're doing. I'll wait.  One good thing: when I actually started to recover, I ended up getting a new laptop that I could play KSP on.  That was nice, even though I was exhausted after playing for only 30 minutes, at first.  :-)

 

 

Edited June 7, 2020 by Murdabenne
I forgot

[Murdabenne]

One thought: if Kopernicus has become this complex, perhaps it is time to refactor the project.  Clean up the code, analyze the design, if there is one, and split off functionality, especially since its likely an 80/20 issue: the simpler uses, like new planets (OPM, Etc), and scaling probably are consuming 20% of the brainpower and effort, while the multiple stars are naturally consuming 80%.  Yet, I wonder if most users are like me, mainly using planetary stuff and simple scaling, and not multiple stars, say, 80/20?  This means you're doing 80% of the work for less than 20% of the base.

One solution is to break the hard entanglement/interdependencies that I am sure have developed (those make for incredibly brittle pieces of code) - and by using well defined interfaces, with well defined and limited functions, separate the 3 primary functions of Kopernicus: adding/modifying planets in the Kerbol system, rescaling the Kerbol system and all bodies in it, and adding multiple star systems. A refactor would benefit the developers a lot in future releases. If you're going to need 6 months to patch together changes in a rickety code base that will still result in a lot more work needed, you may as well refactor it, split it into the more well defined functional modules in the process, and maybe split it into "Extended Kerbol system no scale changes", "New scaled system", and "multiple star systems".  Call it the Kopernicus-XS, Kopernicus-NSS, and Kopernicus-MSS.  1st release would be to dig out and isolate the most common used and simplest, and release it.  The "XS" version. From there, the "NSS" version follows naturally, and can likely leverage the refactoring done for the XS core.  And lastly, the difficult MSS would be the last, but with the prior 2 already existing and redone, it might prove easier to code and maintain MSS in that light.

Just a thought.  If I get stuck in quarantine, and have the energy, I'll pitch in.  Right now, I'm just happy to be home, breathing, and able to go fishing with my son.

Edited June 7, 2020 by Murdabenne
speling iz fune

[KerikBalm]

51 minutes ago, Murdabenne said:

 

 

1 hour ago, Murdabenne said:

but if that damnable virus comes back again, and there is no immunity from either a vaccine or having had it prior, then I'm worried.

It is very likely that you will be protected against reinfection for around a year, possibly 2-3.

After that, you should have a couple years of protection against severe reinfection, but admittedly, this is extrapolation without experimental confirmation.

Severity of symptoms seems to correlate with the level of neutralizing antibodies after infection, so if it has hit you bad, you are probably going to have a pretty good immunity for a while.

Its those asymptomatic individuals that may be fertile breeding ground for the virus  again in only a matter of several months... or so we think based on preliminary studies and studies of the previous common coronaviruses.lockquote widget

Edited June 7, 2020 by KerikBalm

[Gargamel]

Ahem....

 

 

[Murdabenne]

3 hours ago, Gargamel said:

Ahem....

 

 

Topic being the addon, and perhaps in light of the complexity, Kopernicus should be refactored into 3 more easily maintained mods, instead of continually patched.  And the question Is the target 1.9.1, or will this wait until 1.10 KSP  Shared Horizons release as its update target?

Target!  Sabot UP!  On the Waaaaay! Boom.

[Jacke]

2 hours ago, Murdabenne said:

Topic being the addon, and perhaps in light of the complexity, Kopernicus should be refactored into 3 more easily maintained mods, instead of continually patched.

Without examining the code, there's no certainty the functions can be separated without having most of the code shared anyway.  All this is volunteer effort done in people's spare time, including any refactoring.  I covered this more extensively already a week ago.

 

2 hours ago, Murdabenne said:

And the question Is the target 1.9.1, or will this wait until 1.10 KSP  Shared Horizons release as its update target?

I'm not in the know, but I would imagine Kopernicus for KSP 1.9.1 will be released, else there would be no support for software that takes as long or longer to update, like Realism Overhaul.

 

2 hours ago, Murdabenne said:

Target!  Sabot UP!  On the Waaaaay! Boom.

"SABOT, Tank in open, ON!"

"ON!"

"LOADED!"

"FIRE!"

"Firing NOW!  Target!"

And so on....

[Murdabenne]

I am fairly aware of what I'm asking (having been an aerospace software systems integration engineer and test manager in a previous life) , thats why I was suggesting a refactor instead of continued patching.  Refactoring it might allow the entangled brittle code to be better designed and isolated. Because it looks like every update is an ordeal for the developers due to the nature of a "grown not planned" codebase that has functionality glommed onto it, and layer after layer of patches applied.  Comes a time where you have to realize that it would probably take less time to simply redo it than contatnly chasing bugs and such.  Ease of maintenance is seldom a concern for hobby code, but for something like this, a little professional software engineering framework would probably make life a lot better for users and devs, alike. Just my $0.02 worth. Although I do have some code still out there in orbit in "non-airbreathing overhead intelligence assets" (dont ask), Im not in the game anymore now  that im well over over 40  - in software you are flung into management or flung out of the job you love.  that's why Im that I became a Cardiac specialist RN now for my 3rd career.  My 1st, 19D regular army, then combat medic in guard, set it up for me - that's were I did table gunnery M1A1 in Graf filling in for the loader who was sick - I still remember to this day, humping rounds flip over and in (use fist not fingers unless you want to lose em),   and trying to keep from getting killed by the breech block, left hand by the lever, and stop knocking my right knee into the switch. Long time ago.  Good tymes.  Beat the hell out of humping a TOW missile to a 100m dismount from the M3 yeah Im that old, we even had the Kawasaki dirt bikes for a while  (Scouts DISMOUNT!).  Breaking track sucked either way.

Edited June 8, 2020 by Murdabenne

[Jognt]

2 hours ago, Murdabenne said:

I am fairly aware of what I'm asking (having been an aerospace software systems integration engineer and test manager in a previous life) , thats why I was suggesting a refactor instead of continued patching.  Refactoring it might allow the entangled brittle code to be better designed and isolated. Because it looks like every update is an ordeal for the developers due to the nature of a "grown not planned" codebase that has functionality glommed onto it, and layer after layer of patches applied.  Comes a time where you have to realize that it would probably take less time to simply redo it than contatnly chasing bugs and such.  Ease of maintenance is seldom a concern for hobby code, but for something like this, a little professional software engineering framework would probably make life a lot better for users and devs, alike. Just my $0.02 worth. Although I do have some code still out there in orbit in "non-airbreathing overhead intelligence assets" (dont ask), Im not in the game anymore now  that im well over over 40  - in software you are flung into management or flung out of the job you love.  that's why Im that I became a Cardiac specialist RN now for my 3rd career.  My 1st, 19D regular army, then combat medic in guard, set it up for me - that's were I did table gunnery M1A1 in Graf filling in for the loader who was sick - I still remember to this day, humping rounds flip over and in (use fist not fingers unless you want to lose em),   and trying to keep from getting killed by the breech block, left hand by the lever, and stop knocking my right knee into the switch. Long time ago.  Good tymes.  Beat the hell out of humping a TOW missile to a 100m dismount from the M3 yeah Im that old, we even had the Kawasaki dirt bikes for a while  (Scouts DISMOUNT!).  Breaking track sucked either way.

I believe Thomas did a refactor around the time of the 1.7.3 release.

I agree with your statement in that it would be worth it in the long run. I'm however also quite aware of the fact that it costs me only 10 seconds to say that and it would cost quite a bit more to be the one to execute it.

Having said that, I've seen several people offer their help and have offered mine in the past (though I'm admittedly not as experienced/knowledgeable as would be good to have onboard), so maybe a Community Guided Great Refactor can be a thing.

On the COVID note. Glad to hear you appear to have made it through the worst bit. I hope you recover quickly and without lasting lung damage. Can't imagine how it must've been. >_<

Edited June 8, 2020 by Jognt

[KerikBalm]

Well, As warned, I was using a recompile, and it seemed to work at 1x, but it does not work with Sigma's Dimension rescale mod... So just a warning to those that think a simple recompile is all that's needed.

works at 1x:

Spoiler

Not 3x:

Spoiler

 

[Murdabenne]

Thats why this needs to be broken apart.  3 different things: adding/moving planets, simple, its good ol Mr Newton.  Scaling them and the system involves fundamental physics changes due to size issues, not just distance.  And the 3rd part is adding completely extra centers with their own bodies, with issues for multiple origin systems, requiring transforms and translocates and can get messy quickly.

Ideally, this needs to be broken up sooner rather than later.

[Jacke]

2 hours ago, Murdabenne said:

Thats why this needs to be broken apart.  3 different things: adding/moving planets, simple, its good ol Mr Newton.  Scaling them and the system involves fundamental physics changes due to size issues, not just distance.  And the 3rd part is adding completely extra centers with their own bodies, with issues for multiple origin systems, requiring transforms and translocates and can get messy quickly.

Ideally, this needs to be broken up sooner rather than later.

That may be true.  The problem is you're pushing the point.  That's equivalent to keeping asking for a release for a new version of KSP, which is against the forum rules.  In the past, it has alienated mod devs.

I understand your position.  But you either need to get the current maintainers on board or fork the code.

Edited June 8, 2020 by Jacke

[Nightside]

6 hours ago, Murdabenne said:

Thats why this needs to be broken apart.  3 different things: adding/moving planets, simple, its good ol Mr Newton.  Scaling them and the system involves fundamental physics changes due to size issues, not just distance.  And the 3rd part is adding completely extra centers with their own bodies, with issues for multiple origin systems, requiring transforms and translocates and can get messy quickly.

Ideally, this needs to be broken up sooner rather than later.

Your plan already exists to some extent.
Scaling of bodies and systems is already handled by another mod, Sigma Dimensions. 
And there is a “extra features” mod called Kopernicus Extensions for some more elaborate features, ie footprints, etc. Maybe multiple system support could move there.

That said given that the author hasn’t been around the community for a few months, I’d wager the issue is lack of time/interest.

PreCovid, I’d have said the mod was abandoned, or at least severely neglected, certainly LGG has adopted mods with a shorter downtime. I would be surprised if someone who has devoted so much effort to make something that is so critical to the community would just drop it without passing the torch, but there is lots of precedent. 
Given the immense value this mod adds to KSP, I’d think someone at Squad would be willing to help untangle whatever new issue have arisen with changing game version.

@Murdabenne, best wishes for your recovery.

[ItsJustLuci]

hey, is there any up-to-date tutorial on making cubemaps to replace kopernicus planet textures (in my case RSS) ? would this be a job for EVE? I have the textures made for a couple of 64k planets and I'm just trying to find a way to apply them to the respective planetary bodies

[Guest]

7 hours ago, Nightside said:

That said given that the author hasn’t been around the community for a few months, I’d wager the issue is lack of time/interest.

Actually, if we're talking about the author, I haven't seen him around in years (internet cookie for anyone who remembers him).  The current maintainer, however, does appear to have lost interest in the mod. 

I find it odd, though, that similar cases are not nearly as common or as notorious. Kopernicus is unique in that, despite being in the same essential category as ModuleManager, it invariably takes ages to update, when even complex plugins like Kerbalism are usually ready quite promptly, and even Principia doesn't typically lag one version behind. If complexity is the primary reason, then it's definitely an argument for splitting the plugin up. 

14 hours ago, KerikBalm said:

Well, As warned, I was using a recompile, and it seemed to work at 1x, but it does not work with Sigma's Dimension rescale mod... So just a warning to those that think a simple recompile is all that's needed.

 

That might also be a problem with SD not being updated for the recompiled version of Kopernicus. IIRC, it has its own plugin.

TBH, rescaling is an odd thing to separate, because it ties directly into replacing existing bodies. I suppose you could split replacements from additions, but I don't know if that's a good idea. However, that would enable removal of version locking from the part doing additions, at least, since the save wouldn't be completely trashed on the off chance it doesn't work between versions. Moving multi-star support to extensions (along with accompanying solar panel code and all the other related hacks) definitely sounds like a good move. This is a niche feature which, I think, is more or less solely responsible for updates taking so long.

[Nightside]

1 hour ago, lk00david said:

hey, is there any up-to-date tutorial on making cubemaps to replace kopernicus planet textures (in my case RSS) ? would this be a job for EVE? I have the textures made for a couple of 64k planets and I'm just trying to find a way to apply them to the respective planetary bodies

Looking through the Real Solar System Github and wiki is a good place to start. That said, aren't most textures just a regular 2D image, projected onto a surface? Why would you need a cubemap? I'm certainly no expert on this stuff though.

[ItsJustLuci]

Just now, Nightside said:

Looking through the Real Solar System Github and wiki is a good place to start. That said, aren't most textures just a regular 2D image, projected onto a surface? Why would you need a cubemap? I'm certainly no expert on this stuff though.

thanks for the idea, and as far as cubemaps are concerned I kinda have to. Unity limits filesize of textures somewhat and I'm doing 64k resolutions. this means I have to use 4x16(ish)k res files, in addition to two at the poles which helps w texture stretching

 

[Nightside]

3 minutes ago, lk00david said:

thanks for the idea, and as far as cubemaps are concerned I kinda have to. Unity limits filesize of textures somewhat and I'm doing 64k resolutions. this means I have to use 4x16(ish)k res files, in addition to two at the poles which helps w texture stretching

 

That makes sense. A rectangle definitely does not stretch over a sphere gracefully. I have seen hi-res surface textures used before, but I don't know the source or methods. 

[ItsJustLuci]

20 minutes ago, Nightside said:

That makes sense. A rectangle definitely does not stretch over a sphere gracefully. I have seen hi-res surface textures used before, but I don't know the source or methods. 

cubemaps, in my experience at least. RVE64k does it that way, and I want to basically do what that mod is doing but for almost every rocky body in the solar system

 

[Xt007]

Maybe no 1.9.x Kopernicus means they're waiting for 1.10.x, maybe it's a soft boycott for all the unfixed bugs Squad has been forced to relegate to the community to fix, maybe it's a soft boycott for Take Two's handling of Star Theory, maybe the maintainers who don't get paid have decided the investment of their time is better spent elsewhere.  All we know is until a new release comes out those of us that want to play a modified solar system are on 1.8.x and all others can enjoy the new versions of the game. 

[ItsJustLuci]

59 minutes ago, Xt007 said:

Maybe no 1.9.x Kopernicus means they're waiting for 1.10.x, maybe it's a soft boycott for all the unfixed bugs Squad has been forced to relegate to the community to fix, maybe it's a soft boycott for Take Two's handling of Star Theory, maybe the maintainers who don't get paid have decided the investment of their time is better spent elsewhere.  All we know is until a new release comes out those of us that want to play a modified solar system are on 1.8.x and all others can enjoy the new versions of the game. 

 jesus has a working version of kopernicus for 1.9, not perfect but good enough

[Murdabenne]

Nice work by SD, I hand't paid much attention to that, since I dont change size or add new solar systems in my career game.  Likewise as for the 1.9.1 pic in the post above I was previously unaware of that ((must resist "Jesus Saves" pun...).

Typical of the community to think it through and come up with a better solution on its own and already partially implement it. Thats one of the things Squad did right: it built the community and involved us. I wonder how hard it would be to simply carve out the "add/change/delete" a planet functionality and put it into a separate addon that would support OPM, or any other non-scaling Kerbol-only mods?  After all, this is how Kopernuicus originally functioned, yes?

And please don't mis-characterize what I am saying.  I'm not bugging for a release, but maybe for a formal "I am abandoning this" statement from the maintainer, so others can fork or take over. There's no shame or pressure - everyone seems to lose interest sometimes. And if the passion for the project isn't there, its probably better to simply drop it and let someone else take over, and spare yourself the stress.  There comes a time when its best to step away, and thats usually the point at which it feels like an unpaid job.  Step away and start having fun again.  Often the "Im abandoning the addon" post is what will stimulate the community to either fork it, adopt and fix it, or let it die a deserved merciful death.

Anyway, I need to work on getting to Mun Duna and the inner bodies again (unsure how many career restarts this makes!) before I have to worry with my preferred OPM planets, and Im going with an attempted recompile for 1.9.1 since apparently that works enough for OPM, and I'm not doing anything that changes system scaling and mass changes, nor with additional star systems, which is where the problems seem to live.

Edited June 9, 2020 by Murdabenne
tyops tpyos typos

[JoshTheKerbal]

I am trying to make a mod that adds comet like bodies to KSP

Version 1.7.1

All mods updated

Kopernicus throws a null reference exception

 

https://drive.google.com/file/d/1uq9GsmdHKvdoGVMUM0CgXHvHooDgw-rY/view?usp=sharing

 

Contains ksp.log, kopernicus logs, and modulemanager.configcache

[JoshTheKerbal]

I am trying to make a mod that adds comet like bodies to KSP

Version 1.7.1

All mods updated

Kopernicus throws a null reference exception

 

https://drive.google.com/file/d/1uq9GsmdHKvdoGVMUM0CgXHvHooDgw-rY/view?usp=sharing

 

Contains ksp.log, kopernicus logs, and modulemanager.configcache

[Bej Kerman]

On 6/7/2020 at 6:34 AM, Murdabenne said:

Just wondering what the target is for release by the addon developers  And no, I dont mean a date but target version.

Is the target 1.9.1, or will this wait until 1.10 KSP  Shared Horizons, July 1, and essentially start the update process over again?

Precisely what I'm wondering. I've got a bunch of mods on 1.9 and I couldn't bear to see Kopernicus skip over the particular version I just installed all of my mods on.

On 6/7/2020 at 6:34 AM, Murdabenne said:

If the latter, then I fear I may not live to see my beloved configurations with OPM and associated addons in anything resembling a current version.   COVID hasn't killed me ...yet.  In hospital for 17 days, and wrecked physically nearly completely for twice as long,  but if that damnable virus comes back again, and there is no immunity from either a vaccine or having had it prior, then I'm worried.

No worries, you should be immune once you get better.