[1.8.x] KSPWheel - Physics Based Alternate Wheel Collider [API Only]

[SpannerMonkey(smce)]

On 11/12/2019 at 9:22 AM, Dundrogen said:

Made using KSPWheel.

I love a bit of wheel porn,  especially when it's because you can,  nice one buddy

[Dundrogen]

1 hour ago, SpannerMonkey(smce) said:

I love a bit of wheel porn,  especially when it's because you can,  nice one buddy

Thanks dude. I actually learned quite a bit from sifting through a few of your and @Shadowmage old threads. Came across a topic where @lo-fi  was showcasing and sharing config code simulating curved suspension arc from 2014. Much easier to implement now with KSPwheels flexible constraints. You guys are crazy 

[ss8913]

On 8/14/2019 at 5:27 AM, Agustin said:

well, those wheels are just low tech... thats why they brake easily. I dont have bouncing with the wheels either... maybe try kerbal Foundries mod wheels?

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?

[TheKurgan]

4 hours ago, ss8913 said:

it hangs loading as is tradition for incompatible-with-1.8 stuff.

I found that it only hangs on the loading screen, in my case, when MechJeb is also installed.

Other than the dust effects (that @SpannerMonkey(smce) pointed out to me), I don't see any other major issues using this in 1.8.1

[Manul]

22 hours ago, ss8913 said:

and it hangs loading as is tradition for incompatible-with-1.8 stuff..

It's not tradition, it's  MechJeb. It became violent in 1.8 and conflicts with everything it dislikes

[Jacke]

1 hour ago, Manul said:

It's not tradition, it's  MechJeb. It became violent in 1.8 and conflicts with everything it dislikes

That's not fair.  With all the major changes between KSP 1.7.3 and 1.8, @sarbian decided to suss out when things were failing--in this case .dll's loading--and be explicit about pointing it out, rather than leave potential major faults to fester and later during a KSP session seriously cock things up.

[sarbian]

1 hour ago, Manul said:

It's not tradition, it's  MechJeb. It became violent in 1.8 and conflicts with everything it dislikes

And that's a plain lie. The problem is not with MJ and I am tired of explaining it to armchair devs.

 

Edited November 18, 2019 by sarbian

[Manul]

4 minutes ago, Jacke said:

and be explicit about pointing it out, rather than leave potential major faults to fester and later during a KSP session seriously cock things up.

So is this behavior intentional? Just disrupting loading process because there might be some problems (and might not be as it happens with KSPWheel). It created some sort of panic in my local community ("the game is not loading we are gonna die!" and similar posts everywhere)

[Lisias]

2 minutes ago, Manul said:

So is this behavior intentional? Just disrupting loading process because there might be some problems

Things are not that simple.

Due some intrinsics on KSP guts, exceptions can kill the loading thread depending on which moment it happens. Some Add'Ons need to put themselves between others Add'Ons and KSP in order to function, and then become prone to be messengers of that problem.

It's a chain of events, that individually are harmless. you broke a single chain and the crash is avoided.

The best way to break that chain of events is to find the perpetrator - but since removing the Screaming Victims from the scene also break tha chain and it's usually easier, it's what most people do and call it a day.

 

 

18 minutes ago, sarbian said:

And that's a plain lie.

It's a mistake. MJ is one of that links of the chain, but since it's also the Screaming Victim, it's who gets the attention.

[Jacke]

1 hour ago, Manul said:

So is this behavior intentional? Just disrupting loading process because there might be some problems (and might not be as it happens with KSPWheel). It created some sort of panic in my local community ("the game is not loading we are gonna die!" and similar posts everywhere)

What I'm tired of is whenever I look at a KSP session in depth (which I haven't done in a while), I see a whole lot of faults happening.  Are they critical?  Do they screw up something in the game?  Are they mangling things behind the scenes and will come back to bit me in the cheeks?  Why aren't mod authors paying more attention to these and *fixing* them?!?

As a coder and system administrator since ancient times, I hate when things get swept under the rug and ignored, because they always come back to haunt in some way.

That's how so much of KSP modding has been done so far.  And the Unity transitions (KSP 1.4, KSP 1.8) are just the situations that tear back the carpet and expose what's been ignored (and likely corrupting KSP games) for so long.

So ModuleManager and MechJeb are going to test and as @Lisias puts it, see if there's Screaming Victims that aren't being noticed and try to find out what's wrong closer to the root causes.  Because getting closer to those root causes and finding them and *fixing* them has been ignored far too much.

[Manul]

24 minutes ago, Lisias said:

Due some intrinsics on KSP guts, exceptions can kill the loading thread depending on which moment it happens. Some Add'Ons need to put themselves between others Add'Ons and KSP in order to function, and then become prone to be messengers of that problem.

 Didn't know that MJ is fully involved in addons loading, I used to think it just makes a check of compatibility. I guess, when addons with minor problems are being loaded KSP throws some exceptions MechJeb can't handle (or MJ tries to access mod's DLLs and receives an error). Is it a right guess or things are much more complex?

[Manul]

28 minutes ago, Jacke said:

As a coder and system administrator since ancient times, I hate when things get swept under the rug and ignored, because they always come back to haunt in some way.

This time we only have some particle effects missing. I don't mean to say that MJ is responsible for other mods problems... but I'd prefer to have a red lamp indicator not an explosive charge. I know, the explosion attracts more attention than just a flashing light but that hurts.

[Ger_space]

5 minutes ago, Manul said:

This time we only have some particle effects missing. I don't mean to say that MJ is responsible for other mods problems... but I'd prefer to have a red lamp indicator not an explosive charge. I know, the explosion attracts more attention than just a flashing light but that hurts.

It's only that other mods need the assemblies (.dll files) to be loaded without errors and will fail to work correctly if something will go wrong. But then we have the situation that modders get flooded with false bugreports. "Your mod failed", yes it did but only because another mod is not released for 1.8 yet and people still use it.
This can be very frustrating and annoying for the mod owner and I can totally agree with Sarbians approach in handling the situation. 

Pro-Tip: If you want to use this mod: Compile it for KSP 1.8. Visual studio is free. If something needs changed. Change it and submit a bugreport to ShadowMage and send a pull request or a .diff file just explain what you changed to make it work. My guess: It only needs a recompile against the now split unity references. then also the dust will work again. 

Bonus points for posting a link here in this thread to your compiled binary if its working without issues. 

There is no need to blame the people that work several hours a week for free to create mods. If I had time to play KSP I would have posted an update already, but I'm busy enough coding on my other projects. 

[Lisias]

52 minutes ago, Ger_space said:

.But then we have the situation that modders get flooded with false bugreports. "Your mod failed", yes it did but only because another mod is not released for 1.8 yet and people still use it.

This is another misconception. Add'Ons in need to be updated are just a subclass of the trouble makers. Anything getting an unhandled exception on the right "time" can play havoc. This is happening, to my knowledge, since 1.4 and this behaviour is consistent since then. I have a library of mine that surfers from this plague for an year already, and just know I realized the reason.

You take a perfectly fine Module, delete something it needs or inject trash on it at the right time, and this Module will bork the same, with the same collateral effects. I managed to make ModuleEngines to kill the loading thread, exactly as MJ, by using a maliciously crafted patch. You don't even need MM, you can create a "hard" PART that does the same.

Simplifying the problem to "Old Mods" is just smoke and mirrors.

 

52 minutes ago, Ger_space said:

Pro-Tip: If you want to use this mod: Compile it for KSP 1.8. Visual studio is free

It's useless. KSP 1.8 it's the first KSP version EVER where recompiling could do something beneficial.

I'm sistematicaly trying compiling Add'Ons using different Unity and Assembly versions, from 1.2.2 to the latest and vice versa, and every time I got the very same binary identical to the others [as long you use the same compiler version]. As long the function you need is available on the runtime, things will work no matter what and where you compiled the thing [and the KSP functionality didn't changed].

This frenzy to recompile the World every single KSP version was not only useless, it induced us to the error by wasting efforts doing placebo instead of looking for misbehaviours.

Hint: I took an Add'On, migrate all the References to Unity 2019 and KSP 1.8, compiled it using Mono 3.5 and the freaking thing worked fine downto 1.4.1, the oldest I bored to test.

Hint2: I took a 1.2.2 Add'On, compiled against 1.2.2 DLLs using Mono 3.5. Then compiled again against the Unity 2018 and 1.7.3 DLLs. Both binaries were byte identical.

 

Edited November 18, 2019 by Lisias
Needed clarification. Between brackets. **2

[Manul]

28 minutes ago, Ger_space said:

Pro-Tip: If you want to use this mod: Compile it for KSP 1.8. Visual studio is free. If something needs changed. Change it and submit a bugreport to ShadowMage and send a pull request or a .diff file just explain what you changed to make it work. My guess: It only needs a recompile against the now split unity references. then also the dust will work again. 

I didn't notice any problems with this mod both in game and in a log (had to watch logs for several hours to find problems with other mods) because I'm not using MJ and switced off the dust effects (potato computer is so potato). I just want to know why some mods don't work with MJ, not only for my own curiosity, some guys in my local community begin to panic when the game doesn't load at all blaming Squad, modmakers, aliens or Unity. So some information could be useful to stop false rumors.

[Starwaster]

16 minutes ago, Manul said:

I didn't notice any problems with this mod both in game and in a log (had to watch logs for several hours to find problems with other mods) because I'm not using MJ and switced off the dust effects (potato computer is so potato). I just want to know why some mods don't work with MJ, not only for my own curiosity, some guys in my local community begin to panic when the game doesn't load at all blaming Squad, modmakers, aliens or Unity. So some information could be useful to stop false rumors.

Because KSP 1.8 - not because MJ

Coincidence does NOT equal causality.

By itself, it is vaguely, remotely possible that a mod might work with KSP 1.8 that wasn't explicitly recompiled for it. In the past updates KSP updates usually haven't been game breaking for mods (mod version checker code notwithstanding) But when you start throwing multiple mods at it then sooner or later some function call is going to throw an exception somewhere which breaks things for other mods later on down the chain.

There are two reasons why version mismatching is more problematic this time around. 

One is Unity itself. KSP updated the version of Unity it's using and some Unity code either has been deprecated or split off from UnityEngine.dll into a multitude of other libraries. Where previously a mod might have to reference 2-3 Unity libraries it now might have to reference a dozen. 

A second is that the 1.8 update is using .NET 4.x instead of .NET 3.5 - this is huge because it affects everything.

There's plenty of information (more detailed than my intentionally vague explanation) about this on the forums already and it hasn't done a thing to stop false rumors.

TL;DR it's more important with KSP 1.8 that you use mods explicitly updated for KSP 1.8 but it's a quadrillion times more important that ALL your mods are updated for KSP 1.8 - don't try to mix and match because you will run into trouble. 

[Manul]

55 minutes ago, Starwaster said:

Because KSP 1.8 - not because MJ

I'm not trying to blame MJ in all troubles, I just want to say that if mod lost it's compatibility with MJ it doesn't mean it's totally broken (as a lot of people think). I've heard an opinion that all mods are broken due to Unity update and they should be forgotten until they get an update (if they do). But there is an opposite side of a question: Squad did all they could do provide backwards compatibility, .NET has backwards compatibility (I know that old code sometimes fails in 4.5 but not so often), unfortunately  Unity 2019.2 hasn't but not every single DLL from mods refers to Unity. Not all mods will get their updates soon, not all mods can be updated at all due to license or unavailable source. I think these mods should not be removed and forgotten as "outdated" without giving them a try.

[Lisias]

3 hours ago, Starwaster said:

Because KSP 1.8 - not because MJ

No. This time we are the ones borking.

Being the misbehaviour a bug introduced by Squad long time ago, or something that they had to do to prevent a worse problem, this misbehaviour is consistent and it's bitting us since 1.4.0 at least .

It's about time we get a hold on ourselves and start to look for the problems in our own garden.

Everybody borks. Including us collectively.

[sarbian]

First let me make something clear so we do not waste time: I disagree with @Lisias about the source of those "stuck loading". We exchanged before and still disagree so you can think that he is right or I am. No need to try to convince me again since I am quite sure that my view is the right one (obviously )

I just had a look at KSPWheel and it does indeed uses the old particule system that was removed from Unity 2019:

1>------ Rebuild All started: Project: KSPWheel, Configuration: Debug Any CPU ------
1>KSPWheel\PartModules\KSPWheelDustEffectsOld.cs(87,17,87,32): error CS0246: The type or namespace name 'ParticleEmitter' could not be found (are you missing a using directive or an assembly reference?)
1>KSPWheel\PartModules\KSPWheelDustEffectsOld.cs(88,17,88,33): error CS0246: The type or namespace name 'ParticleAnimator' could not be found (are you missing a using directive or an assembly reference?)
1>KSPWheel\PartModules\KSPWheelDustEffectsOld.cs(90,17,90,32): error CS0246: The type or namespace name 'ParticleEmitter' could not be found (are you missing a using directive or an assembly reference?)
1>KSPWheel\PartModules\KSPWheelDustEffectsOld.cs(91,17,91,33): error CS0246: The type or namespace name 'ParticleAnimator' could not be found (are you missing a using directive or an assembly reference?)
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

As I explained in an other thread it creates a problem for reflexion call that puts Unity mono in an instable state which then breaks the extension loading that does a lot of reflexion. MJ uses some stock code (KSP.IO) that do reflexion and trigger this but other mods could do it. And it could also break stuff in game silently and mess up saves.

The mod need some new code to move to the Shuriken particle system. Either @Shadowmage has the time to do it soon-ish or some else feels up to it. I did this migration in SmokeScreen a while ago and I guess I could do it but it does require time which is a limited ressource. My recommendation here would be to have a version of KSPWheel without KSPWheelDustEffectsOld.

Given the name it may not even be used anymore and it just need a recompile without this file.

 

3 hours ago, Manul said:

Not all mods will get their updates soon, not all mods can be updated at all due to license or unavailable source. I think these mods should not be removed and forgotten as "outdated" without giving them a try.

This is why I added some code to catch this problem in the last MM. This way we can identify the problematic mods and either fix them or avoid them.

Edited November 18, 2019 by sarbian

[Shadowmage]

15 minutes ago, sarbian said:

I just had a look at KSPWheel and it does indeed uses the old particule system that was removed from Unity 2019:

Excellent, thanks for the info, and apologies for asking you for it (I should know what is in my own code...).  Thought I had entirely removed all of those refs, but apparently they are still present in the assembly (even if not being actually used by anything); but being present in the assembly is enough to cause errors.

Indeed -- that file can be removed from the source, and after a recompile, the rest of things should likely work just fine (barring any other changes in the KSP or Unity APIs that I've not had a chance to look at yet).  IIRC, I had left that file in place in case I needed any references to what the old particles did while I was reworking them for the new system, and the file itself should have been removed long ago.

18 minutes ago, sarbian said:

No need to try to convince me again since I am quite sure that my view is the right one (obviously )

From what I understand of the problem, at least in this case, you are correct.  The issue is not with MJ, or MM, but lies entirely within the KSPWheel DLL and its linked references.

 

I'm hoping to get some time to update many of my mods this week/weekend.  Shouldn't be too much of a stretch to get KSPWheel and possibly TU updated;  KSPWheel at least should be doable, as it doesn't have any other dependencies, and has minimal interaction with the KSP API.

[Shadowmage]

Initial 1.8 recompile is available:

https://github.com/shadowmage45/KSPWheel/blob/dev/GameData/KSPWheel/Plugin/KSPWheel.dll?raw=true

(download the DLL and replace the one in your current install; AVC might still complain as the metadata is not updated yet, but meh...)

Fair warning:  I have done zero testing on this.  Merely updated the references, deleted the deprecated particle-effects referencing file, and recompile vs. the newer libraries.  I'll do some testing before I package and publish a release, but feel confident enough that this recompile will work fine, that I'm willing to post up the link here for anyone interested.

[TheKurgan]

@shadowmage help  I have messed with the settings in game, and I want to put the defaults back in.

Where are the settings stored? I can't find them in the KSP settings file.

[Shadowmage]

Updated dev version is available:

• Fixes shader references to use the 'LegacyShaders/XXX' shader names.  Will update to use the equivalent newer shaders as time permits.
• Tested to work under KSP 1.8.1; loads properly without any new/unexpected errors, and dust-effects work while in-flight.

Updated DLL is available from the dev branch, direct download link:  https://github.com/shadowmage45/KSPWheel/blob/dev/GameData/KSPWheel/Plugin/KSPWheel.dll?raw=true

I'll be doing some further testing this evening/this week, and package and publish an actual release if it all appears to be working.

 

On 11/20/2019 at 5:19 PM, TheKurgan said:

Where are the settings stored? I can't find them in the KSP settings file.

Likely they are stored in your save game file.  The mod provides default values for if no existing value is found, and then KSP stores the value in your save game data (as the settings are all per-save-game).

To find what the defaults are, you can look here: https://github.com/shadowmage45/KSPWheel/blob/dev/VSProject/KSPWheel/PartModules/KSPWheelSettings.cs#L9

(subsequent lines will have the default values for other settings)

[TheKurgan]

1 hour ago, Shadowmage said:

To find what the defaults are, you can look here:

Perfect! Thanks.

[ss8913]

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