ss8913

OK so I have been using Konstruction/Ground Construction (in conjunction with USI) a lot... design a base, make it into a DIY kit, land that kit somewhere, take a construction spaceplane there which contains a workshop and materialkits, unpack the box, build, etc. I do this often. Until today. I noticed that the latest update to the mod lets me constrain the DIY kits by one of the three dimensions, ostensibly so it can fit into places, and that's cool. I thought nothing of it until I tried to build something on the Mun just now. I brought the construction craft in range, and pushed DEPLOY on the workshop window, as usual. The kit started expanding, again as usual. But it only expands along 2 of the 3 dimensions now, whereas it used to expand evenly. That'd be ok if it ever STOPPED expanding. It just keeps growing and growing and growing, to a size far larger than the footprint of the base I'm trying to build... and then it starts sliding, and then it explodes. This is obviously .. not good. Anything else I should be trying or is this a known bug?

good point; i got 'konstruction' and 'ground construction' confused ><

OK so I have been using Konstruction a lot... design a base, make it into a DIY kit, land that kit somewhere, take a construction spaceplane there which contains a workshop and materialkits, unpack the box, build, etc. I do this often. Until today. I noticed that the latest update to the mod lets me constrain the DIY kits by one of the three dimensions, ostensibly so it can fit into places, and that's cool. I thought nothing of it until I tried to build something on the Mun just now. I brought the construction craft in range, and pushed DEPLOY on the workshop window, as usual. The kit started expanding, again as usual. But it only expands along 2 of the 3 dimensions now, whereas it used to expand evenly. That'd be ok if it ever STOPPED expanding. It just keeps growing and growing and growing, to a size far larger than the footprint of the base I'm trying to build... and then it starts sliding, and then it explodes. This is obviously .. not good. Anything else I should be trying or is this a known bug?

So I'm apparently trying to be ... more ambitious with some of my designs than TCA seems to expect.. and I've come to a conclusion; I really need the 2.x behavior back where it just balances the *engines* and doesn't touch the *RCS thrust limiters at all*. Even if I put the engines in Thrust mode, turn off all the VTOL assists, and turn off all the modes in TCA except the master switch, it still wants to "adjust" the RCS thrust limiters, for some reason. This has no noticable ill effects on light craft with standard RCS blocks, but when I'm dealing with 1,500t - 40,000t starships with very powerful RCS thrusters upon which the craft relies for orientation, it becomes a BIG problem where TCA will limit the RCS down to 5% or so and will leave them in a bad state even after TCA is disabled. Is there any way to completely disable TCA's touching of RCS? Like it used to be many years ago? ... and if not, could we maybe get a button in the UI that would disable the RCS functions as described above?

alright I did some testing on a heavier craft (my lighter craft are so powerful that they can make 3G all the way to 70km on positron reactors since they can make 20+G lower down in the atmosphere)... so my 800t construction/cargo spaceplane... if I launch from the SPH and limit acceleration to 30m/s/s it can pull that acceleration all the way to 62km altitude. If I revert to launch, it only can do it up to about 21km altitude which seems like the correct behavior. Now, the wrench in this is that I *am* using FAR, which hasn't officially updated in a while, although I have recompiled it against 1.4.5 (it didn't work at all, until I did), so the issue may be with the way FAR is modeling the air density between restarts(?) but it could also be something else. Can anyone else repro this with stock aero?

I take it back, it worked properly *once*. now it's back to how it was.. I'm going to research a bit and see if this is one of those weird things that works when you 'revert to launch' and doesn't work out of the gate; I've seen that behavior before. I did find that the asymmetrical thrust thing goes away if I put a single reactor on the craft and drive all the engines with it, as opposed to separate reactors for each thermal engine, which is why I think there's something weird going on with the reactors in the case #3 that I described earlier.

The col not appearing isnt the worst part. You will get no lift or drag either. Until you recompile far against 1.4.5, then it will work, and your col will show up again too

I'm taking the easy route on this and just using the [free] community visual studio, since it seems to be set up for that, as most mods are. you basically just have to load the .sln file into VS, add references where you point it at your KSP install's dlls . the references thing, you right click on the references and add references, point it at your ksp dir's ksp_data_x64/managed/ and the DLLs you need are in there. add the references that it asks for until there are no warning symbols on any of the listed references. then just F6 to build, and you'll have a binary now somewhere under your source tree; copy that to the appropriate place in your KSP install. to get the source, look at like CKAN or the first page of this thread, download the .zip of the 'master' branch from github.. extract it somewhere; it uses long pathnames so somewhere like C:\temp\ is good to avoid windows's limit on path length. Then do as above with VS.. VS community edition is a free download from microsoft. I'm sure you can do this with monodevelop as well but I wouldn't know the specifics.

apparently the maintainer of KK was stumped by 1.4.4; he said it would take significant effort to find and fix KK for that release, but apparently it was actually a *bug* in 1.4.4 which was fixed in 1.4.5; I didn't even have to recompile KK for 1.4.5, the same version that worked in 1.4.3, didn't work in 1.4.4, worked again in 1.4.5 without me having to touch a thing. That said, there were a couple of things that DID break; my 1.4.x-rebuilt FAR for example, which worked in 1.4.0 through 1.4.4, did not work at all in 1.4.5; however a recompile against 1.4.5 fixed that. (even though FAR does not officially support versions past 1.3.1)

so, update.. 1.4.5 fixed .. something. the issue #2 I reported in my previous post is gone with 1.4.5. I didn't change anything else.

So.. I compiled a version of this back on april 4, for 1.4.x; that worked up until 1.4.5. Recompiled again (master branch from github) against 1.4.5, that seems to work. JIC anyone was interested in having this working now.

this is a new development as of today. KK has been fixed by updating to 1.4.5 and nothing else. I don't know if it's the same problem or not, and 1.4.5 has broken some other things, but it's new information and maybe something that someone, perhaps not you, cares about.

@Sigma88 if the Kopernicus problem is anything similar to the Kerbal Konstructs problem... updating to 1.4.5 fixed an internal bug, KK magically started working again; could this also fix Kopernicus (granted, would need to take out the version lock code, but)...?

so.. it's possible that KK will just magically start working now? I'll try that. Yes - I just updated to 1.4.5, kept all my mods including this one the same, fired up KSP, and KK is working again (KK + KerbinSide) ... seems like 1.4.5 cures the problem.

Personally I still think that Squad should start paying mod developers once they get past X number of downloads.. for some value of X. Even if there was then a paid DLC for supported-and-guaranteed versions of mods. could still be free ones, but there could be official versions that you could get as a subscription or something. Adds so much to the game, and TakeTwo/squad is missing out on a business opportunity here that would benefit everyone, in my opinion. Is there a way I can donate to the Kopernicus folks currently? I'm also willing to help with testing and/or coding, if there's something I can read up on what's been investigated so far...

yeah if it was just an arbitrary version lock, someone, possibly me, would have done a recompile to unlock it and gone about our merry ways; the author has said however that there's something deeper broken in 1.4.4 and it requires some looking at.

@FreeThinker I haven't been here to report any issues in a while but I've got.. three. they've been going on for a while but they're relatively minor except #3. 1. resistojet RCS blocks show the animations backwards. ie if it's thrusting to the left, the plume comes out of the left side instead of the right. this started around KSP 1.4.0, it was fine in the 1.3.x line. It can be a little disconcerting but they're still functional. Side note, I updated the part cfg for these to allow a 2.5m version of them - which works great on my 20,000-50,000t starships used to have to use 4 of the 1.2m ones and now I can use 1-2 of the 2.5m ones which saves on part count and is far mroe effective on ships that large. 2. Thermal ramjet nozzles are still able to breathe air at almost the same thrust as they get at sea level, all the way up to 70km. it falls off a LITTLE with altitude but not like you'd expect. This is only on the RAMJETS. The TURBOJETS have the expected behavior. This was reported before by myself and a couple others but it seems to remain unaddressed 3. The serious one - if I make a spaceplane with two engines (thermal ramjet nozzles) and each engine feeding off a separate thermal reactor (I'm using positron reactors in this case), the thrust isn't equal. it's like the reactors ramp up at different rates. This causes a fairly jarring yaw moment on initial throttle application. At constant throttle it's stable, but they ramp up in such a way that produces differential thrust that is too powerful for RCS to compensate for in most cases, esp. on lighter (< 500t) craft. If I use a single reactor with multiple engines, this problem goes away, so I think it has something to do with reactor warm-up rates not being equal.

Sounds like the mod install is corrupted. Reinstall the mod

if you have the source code and visual studio or a linux mono compiler setup, sure. just find the compatibility checker routines and modify them, then recompile it. I'm sure there's a good reason why it's locked though, I doubt this would have the results you're hoping for.

agreed. I was also upset that it defaults to upload to cloud; basically it took all my designs and sent them to someone else's computer (the cloud) without my consent; had to turn that off, but.. who knows. Seems like functionality of this kind could/should be released *as a mod* and not as an entirely new KSP release which breaks all the other mods. Didn't mean to insult you, @Ger_space - it sounded like you hadn't had time to look into it at all, so I wasn't sure what had or had not been tried.

has anyone tried a simple recompile against 1.4.4 ? that fixes mods far more often than I would have expected.. perhaps I'll give it a try, but before I do, has anyone else tried it yet?

When I get around to a recompile I'll let you know if it works. That's fixed a lot of mods for me, even ones that haven't been updated past 1.3.x, such as far and kjr.

Is this part of the 1.4.4 incompatibility? I wonder if a recompile against 1.4.4 would fix it? Should definitely backup saves first... lol

thanks for putting in the warning for "Kopernicus doesn't work with [1.4.4] - do not open your save games" - defnitely would destroy a lot of work for me if I'd given it a try without seeing that message!

@FreeThinker I noticed that 1.19.2 hasn't updated on CKAN; I asked on the CKAN thread, and the maintainer said, just now: "That version was indexed as 1.9.2 because that's what the author entered on SpaceDock:" - seems like a typo in the spacedock metadata?