ss8913

This mod seems to be *actively* incompatible with 1.9.x - is that just due to a version checking string that needs to be updated (ie, if I changed that string and recompiled, it'd work?) or is the incompatibility deeper than that and requires some work?

I'll do some tests using the plane that definitely did it last time, and see how reproducible it is.

so.. cannot 100% confirm it's this mod doing it, but since installing the latest update i've had a new problem I've never had before... i'm *in orbit*... try to accelerate time, "cannot warp faster than 1x while moving over the ground" - like it still thinks i'm on the ground somehow. Anyone else having this issue? EDIT: logs have nothing useful to say. nothing at all to say, really.

it's not just you, had the same thing happen to me.

@FreeThinker I believe I have found a problem with the IXS cockpit (not just the lights issue) - I launched a ship using this cockpit.. didn't play KSP for a few days, came back... loaded up the ship from tracking station... it goes to the IVA view. It won't let me OUT of the IVA view by any of the normal means of doing so. Other ships do not have this problem, only the one with the IXS cockpit. I'm going to try to save my crew out of it with another ship, but.. unfortunately this craft, perhaps anything using the cockpit, is functionally useless if you want it to persist between sessions; it didn't have this problem in the session in which it was launched. UPDATE: forget this entire thing. it's something else, the other craft I checked didn't HAVE IVA at all so.. they defaulted to doing the right thing. some other mod is causing me to get locked into IVA whenever IVA exists, but I don't think it's this mod.

@linuxgurugamer thank you for re-extending this mod

The beta/pre-release 1.8.1 DLL for kspwheel fixes the issues 100% and works with the existing version of kerbal foundries2 that's on CKAN... nice job

it does seem to do exactly that, yes i guess the only real 'bug' here is that the cockpit lights don't work. not sure how hard that is to fix or if it's worth doing..?

So @FreeThinker I notice that KSPIE comes with the IXS cockpit... tried to do my own version of that artist's rendition of the warp ship that's been going around the internet - I got it to work although mine's a bit uglier since artists don't understand heat radiators or apparently the need for ejection mass, etc... so anyway, I got it to work, but I have some minor issues regarding the IXS cockpit: 1. it has another type of electrical resource "kilowatt hours" - why? this seems out of place in the mod? 2. the cockpit lights don't work 3. the little door on the front works but I'm not sure what this is intended for.. there's no ladder that comes down from it, is it supposed to be like an airlock or something for EVA? despite those issues, the craft works, using two 3.75m "large" alcubierre drives, two 3.75m beam-core antimatter reactors, and two 3.75m charged particle electric generators.. plus 4 more beam core reactors and plasma nozzles for sublight propulsion. thing weighs about 1250t and can accelerate at 6G, and obviously go faster than light as well... I think it's a KER problem. MJ2's dV view can calculate dV for KSPIE engines correctly, but only when a non-atmospheric propellant mode is selected.

I've had this problem before - propellant modes for those engines are *unlockable* ... you likely have not researched the node necessary to unlock the ones you want to use.

Is that the problem, or is it that you're using 1.8.x ? the latest modulemanager calls out game-breaking DLLs on the loading screen, and it calls out the latest KSPWheel.dll as being explicitly incompatible with 1.8, and it hangs loading as is tradition for incompatible-with-1.8 stuff.. not sure if it needs more than a recompile but I'm guessing with the new Unity it probably needs some significant dev time to work with 1.8.x?

I'm guessing not, since it depends on configurable containers (core), which last time I checked, is not updated and will keep 1.8 from loading. So we shall wait for Allista to update his suite of stuff (TCA also requires ATUtils, also not yet updated).

it means a mod is incompatible with 1.8 and needs to be recompiled and relinked against the new ksp and the new unity. what you're seeing is what i was also seeing when trying to use mods not recompiled for 1.8. it's possible that some part-only mods might work from older versions? but I havent verified that. 1.8 is a more major update than anything we have had since 1.0 or 1.1 or whenever it was that they last updated Unity.

shouldnt need to edit the ALG part configs.. just tweakscale them up a bit and I havent had problems even on spaceplanes up to 3000 tons or so.

in 1.8, using incompatible mods causes this. many of the mods listed on ckan as being compatible with "any" version actually arent, and will cause this, plus of course the ones specifically called out as 1.7.x or earlier.

so I've done some flight testing... my stock altimeter displays no numbers, but I uninstalled FAR and tried again, can confirm that FAR is *not* responsible for that issue (not sure what is). Everything in SPH looked to be pretty good, the debug voxels do show up, just.. very small. Flying the plane is .. possibly a problem; the graph in SPH said this particular plane should be able to hold level at 0.35M at 8 degrees AOA... in reality it would drop out of the sky at speeds far in excess of 0.35M (calculated in SPH at 1000m, flight was around there, as I said though my altimeter was broken) so perhaps there is a problem with generating enough lift? was using all stock parts for the plane. I'll doublecheck on the NREs. Would you mind telling me what you had to do to the mod to make it work right with 1.8/new unity?

I will eagerly do so tonight and confirm results.

woohoo so... yeah loaded up the source in visual studio 2019... resolved all the references in both ferramGraph and ferramAerospaceResearch, set the target to .NET 4.0 ... tons of unresolved unity symbols.. "consider adding a reference to this class" (referring to Unity). C# is not my forte, nor is visual studio. seems like there is.. a lot to do here, and unfortunately it's beyond me to fix. Happy to help test, though, @dkavolis, once you're at that point.

is it likely that *code* changes will be needed? I'm going to try a recompile with visual studio using the 4.0 framework and the new KSP 1.8 libraries and see what I get... the existing version doesn't keep 1.8 from starting or displaying the FAR(c) button, but it's non-functional.. will let you know if I can get this working, although i'm expecting there to be some code incompatibilities tbh.

@MOARdV - definitely not the right forum for this, but what module owns GameData/moarDV/* ? I can't find a reference to this path anywhere I've looked in CKAN, but whatever module it is, is causing me some grief and I'd like to know which modules use that path so I can figure out what the hell I'm even asking for help with I figured you might know...

if it's actually not working in 1.8 (sometimes mods say they are incompatible but work anyway)... recompiling it with the free visual studio against 1.8's DLLs *may* fix it. works for some mods, sometimes, but you kinda have to know a few things about visual studio to get it going.. although not THAT much.

I don't want them to be independent.. on my plane with the 4 engines, i want the action group to switch propellant on all 4, like it used to, and which it is currently incapable of, if there are more than 2 groups (of any size) of engines on the craft. What's weird is that if I have 5, in 2 groups, with 4 in one group and a single engine by itself, the action group will switch the single engine, but not the group of 4. I've double checked all the AG assignments, they're correct...

@FreeThinker here's a new one.. this is definitely new... it seems that if there are 2+ groups of KSPIE engines on a craft, ie, i have 4 thermal ramjets but they're in two symmetry pairs.. I assign an action group to all four of them bound to "Next Propellant" - it doesn't work. right clicking the parts, i can switch propellant, but not from an action group. If there is only a SINGLE symmetry group, ie, a single engine or a group of two, it's fine. All other functions such as engine toggle, etc, work fine, it's only next/previous propellant that has this problem, and it's *recently* new, like... last version or two of KSPIE.

thanks! makes sense.

so @FreeThinker I'm again using some parts that I hadn't used in a while (hyperdrives) and also going some places that I don't usually go (Eve), and some behavior is.. concerning to me; some of it seems *new*, some of it may have always been this way; anyway, if you could please help me understand the following: 1. on Eve, a thermal ramjet nozzle can produce 0 thrust in the lower atmosphere, on closed-cycle hydrogen-peroxide fuel mode. Why is that? it works in space and in the upper atmosphere. It works fine on Kerbin as well. (but as we know, Eve's atmosphere is thicker, so wanted to know if "these engines don't like really high atmospheric pressure" or if "this is a bug in KSPIE" ) 2. warp drives propel the craft forward while *charging them*. ie i'm in orbit, i "start charging" on the warp drive, and my orbit starts changing. fairly significantly, over the time it takes to charge the thing. I'm 99.999% sure charging them didn't change your orbit, last time I used these? 3. is the warp power-to-mass dependent at all upon the reactors/generators used to charge the warp drive, or only dependent upon the size of the warp drive unit itself?