Please, give the community KSP1's source code

[Lisias]

On 2/9/2024 at 9:32 AM, corbeau217 said:

interesting :O i had a feeling there was some weirdness with the conversion and type sizing for 64 bit

the thing i was trying to explain was kinda what you mention a little at the start? like if you used approximations until you needed the precision then chose float for fast approximate precision and double for latency heavy precision

That could work, but not due differences between floats and doubles, but from gains on using simpler algorithms.

Using a very, very crude comparison (really, really crude): let's imagine you have a million records to be sorted and easily accessed in memory: Database Theory taught us that more often then seldom it's better to split the dataset in two (or more) using some criteria that allows an uniform distribution and keep them sorted in these subsets of data instead of trying to do it on the whole shebang. Problem: this same stunt will screw you royally if you have just about 100K records to keep sorted.

Now, trying to save processing by relying on floats because they are smaller is not working anymore since 64 bits CPU became the norm. Unless we are talking about specialised hardware, no CPU wastes silicon on 32 bits math anymore - it's cheaper in silicon real state to promote smaller data into 64 bits, do the operation, and them demote the result back. And theses promotions and demotions waste CPU cycles.

In the end, you need to know in advance who will munch the data: GPUs, at least until recently, are optimised to consume floats while the CPUs nowadays are optimised to consume doubles. And do a lot of benchmarks, because most of the time your bottlenecks are not in the math anyway.

For example, if you are sorting a huge amount of data, your bottleneck is the sorting algorithm and not the data used as key.

So, yeah - measure, don't guess.  Implement both ways and check on the target platform what happens.

 

On 2/9/2024 at 9:32 AM, corbeau217 said:

honestly im curious what the difference become in the float algorithms to the double algorithms that make it that much faster. is it the size of the numbers or the fact we had more time with float and (sleepy brain cant think of other examples right now) fast inverse square root?

I think this should explain it better than me:

https://simplylaptop.com/unveiling-the-secrets-of-intel-processors-internal-conversion-of-floats-to-doubles/

Notice the extra steps the CPU does on rounding et all in an attempt to maintain accuracy.

 

— POST EDIT — 

I'm completely ignoring the SIMD instructions, by the way, in order to keep the discussion simple.

You usually have twice the number of float registers available than double ones, and depending on what you need to do, it may be better to take the promotion/demotion penalty and do your math on 32 bits SIMD registers… 

Edited February 10 by Lisias
POST EDIT

[AtomicTech]

I think it's certainly be fun to see the "can it Doom" sometimes extend to "can it KSP?" 

[Great Liao]

I can imagine a KSP 1.13 one day with all of the scrapped content added... 

and the kraken slain...

It would be a ton of optimization, but the community is up for it.

Edited April 23 by Great Liao

[AtomicTech]

With KSP 2 potentially getting the axe, now more than ever its imperative that we get the KSP source code so that we can fufill the promises made for KSP 2 in KSP.

[GGG-GoodGuyGreg]

2 minutes ago, AtomicTech said:

With KSP 2 potentially getting the axe, now more than ever its imperative that we get the KSP source code so that we can fufill the promises made for KSP 2 in KSP.

Which to me reads now even more reasons NOT to release the KSP1 source, if the rumours turn out to be true, then KSP1 would be the only way to make money off of the IP

[AtomicTech]

2 minutes ago, GGG-GoodGuyGreg said:

Which to me reads now even more reasons NOT to release the KSP1 source, if the rumours turn out to be true, then KSP1 would be the only way to make money off of the IP

There's gonna be a volumetric poop-ton of technical debt and it's going to cost a ton get it removed. At least if we do it then we've already got a start and it's free for PD. We've already outlined how we want to have access the source code and it's to the benefit of all parties involved.

[Lisias]

  

On 5/1/2024 at 12:06 PM, GGG-GoodGuyGreg said:

Which to me reads now even more reasons NOT to release the KSP1 source, if the rumours turn out to be true, then KSP1 would be the only way to make money off of the IP

Releasing the IP was never the objective. Only the Source Code.

As a matter of fact, given the current status quo, Open Sourcing KSP¹ may be their best shot to make the franchise profitable again.

See Doom, Quake, Half Life, Descent et all. The IP (including assets, as music, meshes and textures) are still being commercially explored by the current IP owners, besides the source code being released decades ago.

See the recent Tomb Raider Remastered series - they even hired the dude from OpenLara to work on it.

Things keep going as they are now, it's a matter of (short) time until things get really, really ugly - what may include, even, malicious 3rd parties trying to exploit the Community. There's no respect for the EULA already (between other problems I had detected, but can't disclose publicly), getting malware agents around here is a question of "When" and "Who", and not "If" anymore.

Having the Source Code available will push away most malicious agents from the Scene, as everything will be openly available for inspection. Of course, you will still need to trust the tool that will deliver the binaries to you - but, frankly, the Linux Scene proved again and again that it's possible to have reliable and trustworthy distribution channels for such binaries.

The worst problem, right now, is to gather trustworthy and competent people around the project. Too much damage was done in the last few years, some of them really nasty. EULAs are contracts, not licenses (no matter what they say to you) - do you will trust licensing your code to people that don't respect your EULAs?

Open Source is based on Trust and Chain of Responsibilities. And every time one (or more) of these two pillars are broken, things goes South. Badly. (Jia Tan anyone?)

Open Source is a development model, not a business model. Anyone trying to extract profit directly from Open Source sooner or later will try some scammy stunt - and, frankly, we are losing both the Trust and the Chain of Responsibility on this Scene. They need to tackle down this problem before going Open Source, otherwise the initiative will fail.

Edited May 3 by Lisias
Entertaining grammars made slightely less entertaining...

[AtomicTech]

23 minutes ago, Lisias said:

Releasing the IP was never the objective. Only the Source Code.

As a matter of fact, given the current status quo, Open Sourcing KSP¹ may be their best shot to make the franchise profitable again.

See Doom, Quake, Half Live, Descent et all. The IP (including assets, as music, meshes and textures) are still being commercially exploited by the current IP owners, besides the source code being released decades ago.

See the recent Tomb Raider Remastered series - they even hired the dude from OpenLara to work on it.

Things keep going as they are now, it's a matter of (short) time until things get really, really ugly - what may include, even, malicious 3rd parties trying to exploit the Community. There's no respect for the EULA already (between other problems I had detected, but can't disclose publicly), getting malware agents around here is a question of "When" and "Who", and not "If" anymore.

Having the Source Code available will push always most malicious agents from the Scene, as everything will be openly available for inspection. Of course, you will still need to trust the tool that will deliver the binaries to you - but, frankly, the Linux Scene proved again and again that it's possible to have reliable and trustworthy distribution channels for such binaries.

The worst problem, right now, is to gather trustworthy and competent people around the project. Too much damage was done in the last few years, some of them really nasty. EULAs as contracts, not licenses (no matter what they say to you) - do you will trust licensing your code to people that don't respect your EULAs?

Open Source is based on Trust and Chain of Responsibilities. And every time one of these two pillars are broken, things goes South. Badly. (Jia Tan anyone?)

Open Source is a development model, not a business model. Anyone trying to extract profit directly from Open Source sooner or later will try some scammy stunt - and, frankly, we are losing both the Trust and the Chain of Responsibility on this Scene - they need to tackle down this problem before going Open Source, otherwise the initiative will fail.

Yes.

[AtomicTech]

We're three folks away from getting 200 supporters 

[Bej Kerman]

On 5/1/2024 at 4:12 PM, AtomicTech said:

There's gonna be a volumetric poop-ton of technical debt and it's going to cost a ton get it removed

I doubt that could be done effectively without completely rebuilding the game - after all, if KSP 1's techdebt could be reduced with less significant amendments to the source code, then the devs would have done so already. And the point of KSP 2 was exactly this goal, provide a new codebase without the gunk tolerated by KSP 1.

[Lisias]

10 hours ago, Bej Kerman said:

I doubt that could be done effectively without completely rebuilding the game - after all, if KSP 1's techdebt could be reduced with less significant amendments to the source code, then the devs would have done so already.

I beg to differ. Some of the worst problems on KSP¹ were really, really silly mistakes buried into the code that only lived by so many years because nobody were looking for them, preferring to elect escape goats to take the blame instead.

As why the devs didn't solved these problems before, well... I will left to an exercise to the reader. A chain is so strong as its weakest link - and corporate culture can be a Sun in your Beach.

 

10 hours ago, Bej Kerman said:

And the point of KSP 2 was exactly this goal, provide a new codebase without the gunk tolerated by KSP 1.

There're some gunk on KSP¹, but you would be surprised that most of the problems that plagued this scene didn't came from them.

 

--- -- - POST EDIT - -- ---

I HAD to quote this here!

8 hours ago, kerbiloid said:

Sometimes a monkey squad can more than a division of privates.

Edited May 3 by Lisias
POST EDIT :)

[Shammyofwar]

On 2/25/2023 at 8:57 AM, WhatALovelyNick said:

Literally that.

Since the development team would and will be focused at KSP2, could you give us the source code, so we might look at it and, maybe, fix some things in it to make KSP1 a better game.

I'm begging you to do it. 

I totally agree but , I think they fear if they OS KSP 1 it will become way better than KSP 2 could ever hope to be!

Edited May 3 by Shammyofwar

[GGG-GoodGuyGreg]

22 minutes ago, Shammyofwar said:

I totally agree but , I think they fear if they OS KSP 1 it will become way better than KSP 2 could ever hope to be!

Sorry to break it to you, but it already has, and this is true even before the last couple of days. 

[AtomicTech]

4 hours ago, Lisias said:

I beg to differ. Some of the worst problems on KSP¹ were really, really silly mistakes buried into the code that only lived by so many years because nobody were looking for them, preferring to elect escape goats to take the blame instead.

As why the devs didn't solved these problems before, well... I will left to an exercise to the reader. A chain is so strong as its weakest link - and corporate culture can be a Sun in your Beach.

 

There're some gunk on KSP¹, but you would be surprised that most of the problems that plagued this scene didn't came from them.

 

--- -- - POST EDIT - -- ---

I HAD to quote this here!

PREACH!!

(I ran outta reactions lol)

4 hours ago, Lisias said:

I beg to differ. Some of the worst problems on KSP¹ were really, really silly mistakes buried into the code that only lived by so many years because nobody were looking for them, preferring to elect escape goats to take the blame instead.

As why the devs didn't solved these problems before, well... I will left to an exercise to the reader. A chain is so strong as its weakest link - and corporate culture can be a Sun in your Beach.

 

There're some gunk on KSP¹, but you would be surprised that most of the problems that plagued this scene didn't came from them.

 

--- -- - POST EDIT - -- ---

I HAD to quote this here!

I loved your write up on KSP's Autostruts; maybe what we wanna do is try to get rid of Autostrut and replace it with much stronger joints and the built-in struts in an open source KSP (or even in the current one)?

[Lisias]

1 hour ago, AtomicTech said:

I loved your write up on KSP's Autostruts; maybe what we wanna do is try to get rid of Autostrut and replace it with much stronger joints and the built-in struts in an open source KSP (or even in the current one)?

On an initial moment, fixing the auto-strut bug would be the best line of action.

Adding a better mechanism would not be out of question, but initially, we should fix the problem on the features we already have.

We build software in layers, one over the other. We left a bug lingering on a lower layer, it will bite our cheeks later for sure.

[AtomicTech]

Seeing as Dakota and Blackrack are out....

THE SOURCE MUST FLOW!!!