I don't like Unity (Split from "Blocker features in KSP2")

[runner78]

2 hours ago, sturmhauke said:

Not exactly. Those are both subtypes of NativeContainer, and Unity has a garbage collector that runs in the background. When instantiating a NativeContainer, you have to specify the Allocator type, one of which (Persistent) tells the garbage collector to leave it alone until called or the application ends. So you can still be careless and request a bunch of memory and then forget to dump it later, but you at least have to think about it first.

https://docs.unity3d.com/Manual/JobSystemNativeContainer.html

No, there is no garbace collector in background. If you use the native collections, you must clean the memory yourself with the .Dispose() method. Unity give you errors if you forgot or choise the wrong allocator.

1 hour ago, ronson49 said:

Unity can't even do that well!!! 

https://www.youtube.com/watch?v=DDsRfbfnC_A&t=105s

https://unity3d.com/book-of-the-dead

 

Edited October 24, 2019 by runner78

[Superfluous J]

2 hours ago, ronson49 said:

Unity can't even do that well!!! 

And roads can't drive fast. 

[DStaal]

5 hours ago, runner78 said:

No, there is no garbace collector in background. If you use the native collections, you must clean the memory yourself with the .Dispose() method. Unity give you errors if you forgot or choise the wrong allocator.

Does that immediately free it, or does it reduce some retention counter?  (Honest question - but the latter could be part of a garbage collection system.)

[runner78]

Yes, that immediately free it, a garbage collector make no sense in this case. With .Dispose() the allocator knows the memory is no longer in use. A garbage collector check objects whether they are in use or not, that is expensive, not the clearing itself.

The later part are to use different allocators for specific use cases. The concept of different custom allocators exists in C++ and often used in games.

[DStaal]

6 hours ago, runner78 said:

Yes, that immediately free it, a garbage collector make no sense in this case. With .Dispose() the allocator knows the memory is no longer in use. A garbage collector check objects whether they are in use or not, that is expensive, not the clearing itself.

Thanks.  It just sounded like it could be part of a reference-counting GC system, which are low-overhead but a bit more manual.  I've worked with them in the past - a decent compromise in many cases.

[HansAcker]

On 10/21/2019 at 6:45 PM, Arugela said:

Edit: This problem also seems to be related to the number of older engines on a ship

Not trying to re-rail this thread or anything, but, have you tried updating the old engines to use the newer ModuleEnginesFX module with some MM patch? That should make the engines use the new code.

[R-T-B]

Just a quick thought from me while I was thinking about this last night:

We have, as a community, benefitted majorly from the open nature of Unity, and the ease of which Unity games are modded.

If we had KSP2 in a custom engine, there is no promise modding would be easy, or indeed even possible.  That'd be up to Take Two, and honestly, do you trust them?

It wasn't but 10 years ago in gaming history that every game used it's own engine and modding was a proverbial hell.  Mods were the exception, not the rule...

Food for thought...

Edited October 26, 2019 by R-T-B

[DMagic]

On 10/24/2019 at 2:10 AM, mcwaffles2003 said:

do you think its possible in an update to incorporate something like this? or will we be back to the "its too deep into the code" which would require a KSP 3 rebuild?

No. DOTS and the ECS system would require a complete rewrite of how KSP works. Combining DOTS coding with standard Unity Game Objects is very tricky, the primary issue for KSP is that anything running on DOTS would be using either Havoc physics or Unity DOTS physics, which exist in different worlds from PhysX, so anything physics related would need to be on the same system (or require some really hacky workarounds).

The coding itself is also entirely different, anyone familiar with standard Unity coding would have to learn a lot to use DOTS effectively.

And, for now, there is the much bigger problem of DOTS not being anywhere near production ready. Things like animation and sound don't work with it. The coding syntax has been changing drastically between Unity updates. So nothing like KSP (or KSP2) would be released using such a system.

And in any event, I don't think any of this gets around the basic problem with KSP, that vessels are constructed as a single chain of rigid bodies that can't be considered in isolation. That has nothing to do with Unity or PhysX, that is a design decision on the part of the KSP developers. DOTS isn't going to fix that.

Edited October 26, 2019 by DMagic

[runner78]

5 hours ago, DMagic said:

And, for now, there is the much bigger problem of DOTS not being anywhere near production ready. Things like animation and sound don't work with it. The coding syntax has been changing drastically between Unity updates. So nothing like KSP (or KSP2) would be released using such a system.

DOTS are C# job system, Burst and ECS, the first 2 are production ready and the ECS core are planned for Unity 2020.1. 

For Unity 2019.3 comming is close to production ready ECS core, and previews for animation, sound and multiplayer.  During the Unite 2019 they presented a  DOTS demo with animation, sound and multiplayer.

KSP2 could using DOTS in some cases like orbit simulation (that does not use any physic engine) With an early ECS preview i have testet it with simple newton gavity, i have simulatet arount 200,000 visible objects at 30 fps.

[Francois424]

On ‎10‎/‎23‎/‎2019 at 6:24 PM, mcwaffles2003 said:

Game clock vs Real time Clock is at 1 second : 3 seconds for me actually, I'd consider that playable

Not bad, but I hope KSP2 does better.  1-3 does get on my nerves, but that's a personal threshold.

[Concodroid]

10 minutes ago, Francois424 said:

Not bad, but I hope KSP2 does better.  1-3 does get on my nerves, but that's a personal threshold.

I have 16 gigs ram and a Ryzen 1500x, the game typically runs at 1:1, (if we're talking about the same thing; green time text means that it's 1:1, right?)

[Francois424]

2 hours ago, Concodroid said:

I have 16 gigs ram and a Ryzen 1500x, the game typically runs at 1:1, (if we're talking about the same thing; green time text means that it's 1:1, right?)

Yes.  But the problem starts when you start going over 300 parts.

Stock KSP makes most Kerbin and Mün round trips, and even Duna/Eve single trip feasible with such low part count.  In fact, most probe or flyby missions to say, the Moons of Jool will be fine.
The problem starts when you do huge Apollo-style mission with a 7.5-10k dV mothership (and lots of nukes so bad parts count) + Lander + Mining refueler + Habitat Ring for looks or utility.  I'm usually in the 400-475 range when that happens and I run a semi-modded game.
As soon as I hit 300, I start getting yellow clock.  330-350 I get 1-to-1.5 or 1-2.  400 and I'm at 1-3.  500 is usually 1-4. 

It's definitely manageable, but it makes 5min burns into 20 minutes burns and that is where I get bored real quick. 
To me that's a blocker because I don't want yellow clock, and anything decent (ie: to my linking) to do Jool/Sarnus/Urlum tour (Jool/Sarnus-5 and the likes) or a science grand-tour is always 475-550 parts... then I just... can't.
It's definitely better since I upgraded my PC, and removed ground scattering in the options which was really heavy on performace... I can do 300 in green now.  When 1.2(?) hit, I could hardly do 200 anymore and that is when I took a very long break.

To each their own.

Edited October 27, 2019 by Francois424

[ronson49]

On 10/27/2019 at 5:11 AM, Francois424 said:

Yes.  But the problem starts when you start going over 300 parts.

 

For me personally, that is the killer to the game and why I stopped playing it.   I don't have an interest in sending a few satellites.   I am after a long term colonization. 

 

It is guaranteed that I am not going to get that while the game is using Unity.  It is like a promise from the developers that I am going to be bitterly disappointed. 

[Guest]

51 minutes ago, ronson49 said:

 

For me personally, that is the killer to the game and why I stopped playing it.   I don't have an interest in sending a few satellites.   I am after a long term colonization. 

 

It is guaranteed that I am not going to get that while the game is using Unity.  It is like a promise from the developers that I am going to be bitterly disappointed. 

I'll try from a different angle.

In 8 years ksp has received 3 parts specifically thought for space stations (the lab, the hitchhiker container and the cupola), no part at all for ground bases, no parts either for giant space ships (not even big LF tanks for nuclear engines) and a whopping 2 parts for large ground veichles, one of which is the variation of the lander can added a few months ago.

It's pretty clear that Squad never wanted to incentivize hight part count structures, especially not on the ground.

Now, compare this to the KSP2 announcement trailer that's centered around enormous colonies and huge interstellar ships being built by giant stations. Pretty insane if they know that the game will have the same limitations that KSP1 has.

Even by pretending that all the KSP1 problems are caused by Unity (which is false) there are a lot of workarounds that were never implemented in KSP1 like a different system for bases and stations (that's already confirmed for KSP2) or giving us a procedural tank instead of a set of smaller ones (or that they auto-weld when put together).

And no, they have no reason to lie and over-promise up to this level, they're under contract for Private Division and things get uggly for a small studio when they mess things up with a big publisher.

Edited October 28, 2019 by Guest

[Arugela]

On 10/27/2019 at 1:11 AM, Francois424 said:

Yes.  But the problem starts when you start going over 300 parts.

Stock KSP makes most Kerbin and Mün round trips, and even Duna/Eve single trip feasible with such low part count.  In fact, most probe or flyby missions to say, the Moons of Jool will be fine.
The problem starts when you do huge Apollo-style mission with a 7.5-10k dV mothership (and lots of nukes so bad parts count) + Lander + Mining refueler + Habitat Ring for looks or utility.  I'm usually in the 400-475 range when that happens and I run a semi-modded game.
As soon as I hit 300, I start getting yellow clock.  330-350 I get 1-to-1.5 or 1-2.  400 and I'm at 1-3.  500 is usually 1-4. 

It's definitely manageable, but it makes 5min burns into 20 minutes burns and that is where I get bored real quick. 
To me that's a blocker because I don't want yellow clock, and anything decent (ie: to my linking) to do Jool/Sarnus/Urlum tour (Jool/Sarnus-5 and the likes) or a science grand-tour is always 475-550 parts... then I just... can't.
It's definitely better since I upgraded my PC, and removed ground scattering in the options which was really heavy on performace... I can do 300 in green now.  When 1.2(?) hit, I could hardly do 200 anymore and that is when I took a very long break.

To each their own.

I have a 688 - 750 part to orbit cargo plane. The bigger issue is the stutter on top of this. Without stutter it would be 1-5. 5 seconds per second on an old phenom 1100t. With stutter it's at least an extra 5 second. Stutter happens each second for 1 second each. Before 1.8 for 688 parts it was 2 seconds for tripple the delay. Without the stutter this game would have been much more playable this whole time. The stutter is connected to engines parts coding. It goes away if you turn all engines off. And air mode doesn't have an effect in space. But on the ground both closed and air breathing modes stutter with even one engine on and 0% throttle. This is amplified by the number of engines with only one engine one and the rest off. There is a base coding problem or something not resolved yet. High parts count bring this out very fast. Still not sure if anyone else get this. Is it related to hardware or software. I put up a bug thing on it but nobody has responded to help figure it out.

I'm assuming these issues can be resolved in KSP1 potentially.

If it's not resolved in KSP1 first I have a feeling it will be in KSP2.

Edited October 28, 2019 by Arugela

[Guest]

36 minutes ago, Arugela said:

If it's not resolved in KSP1 first I have a feeling it will be in KSP2.

That's not how a complete rewrite from a different studio works.

Edited October 28, 2019 by Guest

[Guest]

4 hours ago, ronson49 said:

It is guaranteed that I am not going to get that while the game is using Unity.  It is like a promise from the developers that I am going to be bitterly disappointed. 

Presumably it’ll be on Steam. It has a 2-hour refund window. You will likely be able to try it for yourself and refund if the performance doesn’t meet your requirements.

[Gargamel]

2 hours ago, Brikoleur said:

It has a 2-hour refund window.

And IIRC, that's a 2 hour playtime window, and a few days to a week to actually return it?  

[GoldForest]

4 hours ago, Gargamel said:

And IIRC, that's a 2 hour playtime window, and a few days to a week to actually return it?  

Maximum playtime: 2 hours
Maximum time owned: 2 weeks* **

*Note that's 2 weeks from game launch/release if you pre-ordered/pre-purchased.
**Note that if you pre-order/pre-purchase a game, you can refund your money any time prior to release.

Edit: Confirmed information
https://store.steampowered.com/steam_refunds/

Edited October 29, 2019 by GoldForest

[Bej Kerman]

On 10/19/2019 at 4:49 PM, ronson49 said:

I certainly won't be buying KSP2 because of Unity.   So maybe KSP3 will use a bit more of a grown up toolset.

Unity is just as good of an engine as others out there. It's isn't automatically bad because more beginner developers use it than other engines. I'll be completely honest, you sound like you want to be a grown up playing grown up games on grown up engines, even though that makes no sense. If you're not going to give constructive criticism for the engine, then trying to stop money from going into KSP2 is futile as the rather good performance pre-alpha has already shown lots of potential.

Edited October 29, 2019 by Bej Kerman

[evandisoft]

On 10/19/2019 at 6:52 AM, ronson49 said:

I simply said that I can't buy KSP2 as it is using Unity, and the usual fan boys have come out moaning about it with their usual lack of evidence.   This doesn't need to be a thread of its own. 

 

On 10/19/2019 at 4:33 AM, ronson49 said:

I need 10000 parts,  not 200 and it is that which kills KSP in Unity. 

I see. You simply can't buy KSP2 because you cannot play a game at all which doesn't allow crafts with 10000 parts. Makes sense. I guess we who enjoy playing a game with ships that have less than 10,000 parts will be perfectly happy, though.

Edited November 7, 2019 by evandisoft

[HansAcker]

I was reminded of this thread when I saw this comic:

https://cad-comic.com/comic/im-canceled/

 

Quote

Red Onion - Unrestricted in-game scripting mod for ksp. Has Repl/Editor and two scripting languages: Lua and a custom language.

Thanks to this thread, I have a new mod to test. I was looking for an in-game scripting mod (vs external via kRPC) and was tempted to try and rip the parser out of KOS and replace it with a usable language, but this looks much more promising.

[evandisoft]

29 minutes ago, HansAcker said:

Thanks to this thread, I have a new mod to test. I was looking for an in-game scripting mod (vs external via kRPC) and was tempted to try and rip the parser out of KOS and replace it with a usable language, but this looks much more promising.

We came from the same situation. You're welcome to contribute as well, if you would like. I probably should have promoted the mod more.

[Thygrrr]

Don't worry so much!

Unity, especially the new 2019.3 Unity, has a  way different  internal architecture and much improved runtime. The physics system is entirely new (and was renewed at least twice over since the KSP 0.2)

The original KSP architecture was for Unity 4.x, then upgraded to 5.x, which is ~3 generations past, written by someone who didn't know the scale that the game would have.

The Engine usually isn't the problem with performance, it's your architecture and what you are trying to do with it. Also, Unity is becoming more and more Data-Oriented (with its new DOTS architecture that came from ECS, but now has DOTS-Audio, DOTS-Physics, etc.), which basically scales to better and better performance when many many objects are involved.

The fact that KSP2 will have large colony structures is great. This is also again almost exclusively an architecture question, meaning you need a bunch of really clever code to make everything semi-physical while it is static, and then physical when impacted. This is specialist game developer work, and would be tremendously difficult to add to KSP1, same as with multiplayer.

Architecture changes are usually expensive to build into an existing game, and with users of KSP1 feeling so entitled they are asking for KSP2 for free already, you can see how such an expensive change makes no economic sense in KSP1. However, for a new game by an experienced studio, this is an amazing opportunity to make things right.

 

Now here are some reasons why Unity is GREAT for KSP2:

- existing mods can quickly port their assets, animations and materials to KSP2. I cannot stress enough how important this is! It practically seeds the KSP2 mod pool to ~30-50% the size of KSP1s pool within mere weeks of the release.

- same goes for UI layouts, textures, scenes, etc, even though the new game will also be moddable via Lua, which will probably do away with Module Manager and allow for much more intelligent "parts" without having to ship DLLs that are compiled against a specific version of the game

- they can base the game and its calculations on the original calculations; even though they basically tore it all the way down, that is the way to go if you want a sequel that feels the same

- Unity 2019 physics is really good, and it's kind of what people expect from KSP.

- Unity 2019's new render pipelines are much more performant where shadow casting and physically based rendering (PBR) is required. We are already seeing some benefits of this in KSP 1.8.x

- Ever since KSP moved to Unity 2019.2 I basically had no performance issues; most of them seemed to come from Garbage Collection.

- Unity 2019 allows for different physics worlds and scenes, so that means it is in theory possible to keep simulating vessels in atmosphere while you switch to another vessel, even on rails. Again this is a change that is not feasible for KSP1, but I will eat my hat if KSP2 doesn't use this feature of the engine.

Sources:

- my experience as a long time game developer (25+ years), also with Unity, but also built my own engines, worked with UnrealEngine, etc.

- newest Unity features in Unity 2019:

 

Edited November 7, 2019 by Thygrrr

[evandisoft]

7 hours ago, HansAcker said:

Thanks to this thread, I have a new mod to test. I was looking for an in-game scripting mod (vs external via kRPC) and was tempted to try and rip the parser out of KOS and replace it with a usable language, but this looks much more promising.

I just noticed that the mod doesn't work well with 1.8 so we will be working on that.