Sarbian changed the topic of #kspmodding to: Welcome to #kspmodding - the channel for discussing, and learning about, modding Kerbal Space Program. Code of Conduct: https://git.io/vSQh6 | Always provide logs. | *** PSA: https://kerbalspaceprogram.com/api/index.htm | Someone is writting a Phd dissertation on KSP modding please fill out this survey https://goo.gl/forms/1vrkPYH4az8l32sb2 - I have met him and it s legit
_whitelogger has joined #kspmodding
hashashin_ has quit [Read error: Connection reset by peer]
hashashin_ has joined #kspmodding
hashashin_ has quit [Read error: Connection reset by peer]
_whitelogger has joined #kspmodding
ferram4_ has joined #kspmodding
ferram4__ has joined #kspmodding
ferram4__ has quit [Remote host closed the connection]
ferram4 has quit [Killed (NickServ (GHOST command used by ferram4_))]
ferram4_ is now known as ferram4
ferram4_ has joined #kspmodding
stupid_chris has joined #kspmodding
stupid_chris is now known as stupid_chris_
stupid_chris_ is now known as stupid_chris|AFK
stupid_chris|AFK is now known as stupid_chris
stupid_chris has quit [Quit: THE BEES]
stupid_chris has joined #kspmodding
<stupid_chris>
so I've been told this is where the good modding stuff at now?
<SilverFox>
yes
<stupid_chris>
hello SilverFox
<SilverFox>
heya
<stupid_chris>
how have you been you ontarian
<SilverFox>
I've been well
<stupid_chris>
good
<stupid_chris>
would you happen to know if KSP has migrated to .NET runtimes 4.X with Unity 2017 or did they keep the old Mono 2.0 equivalent?
<SilverFox>
haven't touched ksp even remotely in the past year
<stupid_chris>
rip
blowfish has joined #kspmodding
<stupid_chris>
<stupid_chris> would you happen to know if KSP has migrated to .NET runtimes 4.X with Unity 2017 or did they keep the old Mono 2.0 equivalent?
<stupid_chris>
^If anyone at some point sees this and has the answer lmk :)
_whitelogger has joined #kspmodding
<blowfish>
stupid_chris: I don't think they did anything
<stupid_chris>
yay, I love being stuck in an archaic runtime anyway
<stupid_chris>
thanks tho!
<blowfish>
JPLRepo might be able to say more (or not) about why that hasn't happened
Lyneira has joined #kspmodding
<stupid_chris>
probably because the new runtime was still in experimental phase back then
<stupid_chris>
Being serious, it probably was a risky move given it wasn't perfectly safe at that point
<stupid_chris>
A man can hope though
<stupid_chris>
Hopefully if 1.5 is actually built on a 2018 version of unity this will be changed since it has since left experimental status
<lamont>
i think they did bump the runtime but its just to a later 4.x
<lamont>
err sorry, later 3.x?
<stupid_chris>
no that was already the case
<stupid_chris>
3.5 is the default supported runtime
<stupid_chris>
which lacks a ridiculous amount of featuresa
<lamont>
we did get a runtime bump at some point in 1.3 or 1.4 i think
<stupid_chris>
I've been coding on 3.5 since 2013
<stupid_chris>
(for KSP mods)
<stupid_chris>
the other option is 4.X, which actually targets 4.6 with the mono compiler
<stupid_chris>
Unity is still looking into adopting Roslyn which would allow to bump all the way to 4.7.X
<stupid_chris>
I do know a package exists to do this manually though
<stupid_chris>
this supports .NET 4.7 and C# 7.3 even in Unity 2017.1, by replacing the compiler by Roslyn
<JPLRepo>
you can read between the lines regarding - .Net 4 being experimental in Unity 2017... and 32 bit is now officially dropped... and there is also been an announcement of regularly updates to KSP.
<JPLRepo>
that's about all I can say. ;p
<stupid_chris>
I'm gonna guess it'll come soon haha :P
<stupid_chris>
gotcha
<stupid_chris>
but yeah, this above would mainly be for you guys
<stupid_chris>
this does nothing on the mod side, but this would put you guys up to par with recent runtime and language features
<stupid_chris>
it's essentially a wrapper around the Unity compiler
<stupid_chris>
given how much C# has changed in the recent two years, I'm sure you guys could use the update
<JPLRepo>
KSP has to stay on Unity supported platform and compiler, etc. adding complexity of third party, other licensed, code.. just makes things complicated.
<JPLRepo>
in Unity 2018 .net 4.5 is no longer experimental.
<stupid_chris>
it's WTFPL, so licensing wouldn't be an issue
<JPLRepo>
licensing is an issue for any commercial product... and not one I decide on.
<stupid_chris>
and since it's simply a compiler wrapper, the end result (compiled binaries) should be exactly the same
<stupid_chris>
it *shouldnt* affect anything
<stupid_chris>
but yeah, I understand where you're coming from
<JPLRepo>
why do KSP mods need .net 4.5 btw?
<stupid_chris>
don't *need*, just want :p
<stupid_chris>
a lot of stuff has been added since 3.5
<JPLRepo>
yeah I fully understand.
<JPLRepo>
the devs wants vs the products needs are two different things as well.
<stupid_chris>
sure we can work around everything, but the libraries now come with a lot of very handy stuff
<JPLRepo>
as a Dev I agree.
<JPLRepo>
let's see what further updates bring.
<stupid_chris>
one thing I ran into earlier was that IReadOnlyCollection<T> was added in 4.0
<stupid_chris>
so I can't really make my own .NET supported readonly collection
<stupid_chris>
I can work around it for sure
<stupid_chris>
but it'd just be more convenient ¯\_(ツ)_/¯
<JPLRepo>
Unity 2017 still supports DX9 and 32 bit... Unity 2018 does not.
<JPLRepo>
well.. DX9 is but it's legacy.
<stupid_chris>
that's good, means the migration would be a lot easier now that it's not supported by you guys either ;)
<JPLRepo>
so you have to think about all the investment required in upgrading a product for that... and what is your return on investment for doing so.
<JPLRepo>
and I'm speaking just from a general business sense there.
<stupid_chris>
yeah
<stupid_chris>
im p sure that the actual runtime version of 2018 is 4.6
<JPLRepo>
it is
<stupid_chris>
the main difference with 4.7 is that value tuples are bundled in the runtime
* stupid_chris
<3 value tuples
_whitelogger has joined #kspmodding
<stupid_chris>
So I'm rebuilding RealChuteModule as a state machine
<stupid_chris>
rather than being event driven (checking for parameters, and switching parachute deployment when a certain treshold is reached), each parachute has a set of states
<stupid_chris>
and they transition from one to another as they each reach their individual triggers, smoothed over time
<stupid_chris>
this is so much simpler code wise
<stupid_chris>
RealChute was an absolute spaghetti code mess
blowfish has quit [Quit: Leaving]
ferram4 has quit [Read error: Connection reset by peer]
ferram4_ has quit [Read error: Connection reset by peer]