Murdabenne

Magnets are once again your friend in the day and age of the SSD.

I miss the days of my Amazon Prime actually being meaningful for fast shipping.

Metadata is lagging on quite a few things. @linuxgurugamer Is there a problem with these mods or with CKAN?

I'd say let stock comets do their job, and defer the implementation in Kopernicus until other issues are addressed and stable. Comets are new enough to where they should not be all that vital for mod packs compared to stars, planets, moons and asteroids. Plus, they do have a stable system for handling them already in stock game, no use in duplicating that at the moment, since it seems sufficient to the task, unless its trivial to do so (which it appears not to be).

I noticed the only version that comes up on CKAN is the old 1.8.1, is there a different thing I need to be looking for, or should I go with a direct download? I'd guess stick with manual updates if this version 1.9.1-9 isn't going to stick for long or is undergoing significant functional/API changes. I dont use any of the extra stars stuff. Or should I move to 1.10 and use the new branch? I've been waiting since 1.7.3, so I can be patient, although I'd rather not be. I guess what I really am looking for is: what version is safe for me to do a longer term career restart with using Kopernikus+OPM as my baseline and some of my favorite mods like Roverdude's and Nertea's stuff, and of course a pile of Linuxgurugamer's varied maintained mods.

Just a question about how CKAN is handling forks these days. Specifically, I'm talking Kopernicus, which has had a hard for off a dead end 1.8.1 compatiple version and jump to the fork for 1.9.x compatible. There are dependencies that will be affected as well. I see the 1.8.1 listed in CKAN, but nothing of the version linked below. There are also "unofficial" forks being done by maintainers of other mods, like Jesus' version someone linked to in another forum post (part of RO?). Anyway, whats the process for continuing a no-longer-developed version into a current forked one going forward, and the dependencies which all apparently point to their dependencies to the old version (things like OPM, EVE, Scatterer, Distant Object Enhancement, Planetshine, JNSQ, et al.), yet appear to work on the new fork?

I saw mention of changing CKAN, when will the fork replace the stale version?

Can we get them to take over Kopernicus so we can run stuff like OPM on the most current releases? Yeah I know - and it might be off topic. But a guy can dream...

And the Kraken will eat you if you dare try it on 1.10 once it comes out in a couple weeks. Texture changes in the planets mean even more problems for Kopernicus.

I may give it a go next week.

Is that actually viable for an otherwise stock career game with OPM? I don't care for RO, personally I get enough "realism" in my daily life as a cardiac nurse - but mainly because I find the gameplay is just fine with the original scaling, and I dont want to have to tinker with my addons to force them to work with RO values. Then perhaps this should be closed off? And a bit more clarity about the RO fork would be nice - is is "stock" when used with stock, or is it OP as hell because everything is changed fo RO values? If the latter, then it is NOT really a successor, because it cannot be used in the stock game as-is. Just saying.

Posing for 1.9.1, it seems to work OK so far.

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.

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.

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.

If its LGG, it will be in CKAN sooner or later.

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.

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.

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. :-)

All the more reason to simply install the full KSP AVC for consistency, and Zero MiniAVC to kill all of the competing mini versions you may not even know you have. Oh, BTW, CKAN shows KSP AVC 1.4.1.4 is max version 1.8.1 compatible, is it OK with 1.9.1? I suspect so.

OPM is the "OG" for planet packs that expand the system quite a bit. It is also well supported by other addons that I use, so to me its the "best fit". YMMV. <snip>

is the 3.0.2 version compatible with KSP 1.8.1?

Does 4.1.3 work with KSP 1.8.1?

New thread or continuing on this one?

@linuxgurugamer Would BLSG-renewed addon conflict with S.A.V.E addon?