Devnote Tuesday: Wednesday Edition II

[Majorjim!]

17 hours ago, Mad Rocket Scientist said:

Just wait until I unveil the multi-stage version...

I have actually built something like this before. It does not work.. The wheels are not fast enough to do anything exciting with it sadly. You can drive lifts with the wheels, people have done this many times before, you just cannot fling anything fast with it.

16 hours ago, Columbia said:

If you could surface attach things to rover wheels.. You'd have a hinge, assuming the wheel physics are correct.

Just a thought. 

I'll be able to deal with the delay of all those things if it means getting 1.1 out as rushed efficiently as possible.

You wont be able to. Reading the dev notes the new wheels are not wheel shaped either..

[Azimech]

1 minute ago, Majorjim said:

I have actually built something like this before. It does not work.. The wheels are not fast enough to do anything exciting with it sadly. You can drive lifts with the wheels, people have done this many times before, you just cannot fling anything fast with it.

Unless you build a wheel out of the small landing gears, put them all on parking brake and ... use a turboshaft to drive the wheel.

[Majorjim!]

Just now, Azimech said:

Unless you build a wheel out of the small landing gears, put them all on parking brake and ... use a turboshaft to drive the wheel.

LOL. that's over engineering alright! A rocket or jet mass driver works better than any wheel driven launcher.

[Azimech]

Just now, Majorjim said:

LOL. that's over engineering alright! A rocket or jet mass driver works better than any wheel driven launcher.

True that. It just gave me an idea for something else though.

[Red Iron Crown]

1 hour ago, sackfalte said:

What I care about is lag and framerates. I have an i7 4790K, 16GB RAM and a GTX 980Ti (not a reference system, but definitely above average) and from 150+ parts upwards, the lag really becomes noticeable.

Physics time is set to the absolute minimum. If I remember correctly, hyper-threading is enabled via launcher script (not sure about that one).

Setting the physics time to maximum rather than minimum should improve things a bit. The number represents the maximum length of a physics frame, so a bigger number means better performance (at the cost of less accuracy).

1 hour ago, sackfalte said:

What's the hold-up? Why can't my EUR 1500 PC deal with this game once I build anything even remotely more complicated?

What good are 8 cores if only 1 is used, or if the performance boost isn't x8 (yeah, too simplistic, I know..)?

The hold up is the type of problem that a KSP craft represents. Physics calculations on a constrained chain of rigid bodies do not thread easily, and there aren't any implementations that do so outside of academia.

Your four FP cores (assuming you have an AMD) might see more utilization under Unity 5, but it certainly won't be a 4x improvement.

1 hour ago, sackfalte said:

Could the GPU aid in physics calculation as it can in parallel-processing for - say - calculating hash-tables?

GPU processing is not supported by the current engine or Unity 5, so no. I sincerely doubt that hash tables are a limiting factor anyway.

1 hour ago, sackfalte said:

Are there other/better physics engines that would be more suited for this kind of game?

Possibly, but a complete engine change is not feasible at this stage of development. Look at how long it's taking just to move to a new version of the same engine, a move to an entirely new one would take much longer.

Maybe when/if they make KSP 2, who knows? I'm sure the devs are as frustrated by Unity limitations as the rest of us.

All that said, U5's benchmarks show a marked improvement in single thread performance too, so I'm optimistic that the new version will perform better than the last.

[Ser]

1 hour ago, sackfalte said:

I play KSP x64 on Linux, so I don't really care about x64 functionality for Windows (other than not having to reboot every time).

 

What I care about is lag and framerates. I have an i7 4790K, 16GB RAM and a GTX 980Ti (not a reference system, but definitely above average) and from 150+ parts upwards, the lag really becomes noticeable.

Physics time is set to the absolute minimum. If I remember correctly, hyper-threading is enabled via launcher script (not sure about that one).

 

What's the hold-up? Why can't my EUR 1500 PC deal with this game once I build anything even remotely more complicated?

What good are 8 cores if only 1 is used, or if the performance boost isn't x8 (yeah, too simplistic, I know..)?

Could the GPU aid in physics calculation as it can in parallel-processing for - say - calculating hash-tables?

Are there other/better physics engines that would be more suited for this kind of game?

 

Btw, don't get me wrong, I love the game, and I know some of my statements may over-simplify matters, but... come on 

All that stuff including x64 is managed by the engine which is Unity. You may install 128x processors with 8 cores each but if Unity doesn't support hyperthreading then only one still will be used. Just because Unity is the common engine trying to suit everyone's needs it just cannot be optimal for KSP only. That's the tradeoff of universality.

"Are there other/better physics engines that would be more suited for this kind of game?" - KSP is built on Unity like a house is built of bricks. To have it made of concrete means rebuilding it from scratch.

"Physics time is set to the absolute minimum" - why? Doesn't default setting satisfy you? I think that might be the reason of your lags.

[Darnok]

11 minutes ago, Red Iron Crown said:

Setting the physics time to maximum rather than minimum should improve things a bit. The number represents the maximum length of a physics frame, so a bigger number means better performance (at the cost of less accuracy).

what?

[Ser]

4 minutes ago, Darnok said:

what?

It is obvious. Physics time is the frequency at which calculations are made. Less time between calculations, more of them are made per second, more load on CPU, more lag.

[sackfalte]

2 minutes ago, Red Iron Crown said:

Setting the physics time to maximum rather than minimum should improve things a bit. The number represents the maximum length of a physics frame, so a bigger number means better performance (at the cost of less accuracy).

Okay, my comment mentioning the physics-time setting probably was not so appropriate, as indeed a lower setting reduces frames in order to ensure equal physics even with higher part-count vehicles.

I (probably like 99% of all players) want the physics to be as realistic as can be, so I'll always choose physics over fps.

2 minutes ago, Red Iron Crown said:

Your four FP cores (assuming you have an AMD) might see more utilization under Unity 5, but it certainly won't be a 4x improvement.

It's an Intel, but that's okay, it doesn't really matter for the engine, I assume.

2 minutes ago, Red Iron Crown said:

GPU processing is not supported by the current engine or Unity 5, so no. I sincerely doubt that hash tables are a limiting factor anyway.

I did not mean to imply hash tables were a factor - I'm merely curious about whether this kind of parallel-processing capability could help the game in some way or another.

2 minutes ago, Red Iron Crown said:

All that said, U5's benchmarks show a marked improvement in single thread performance too, so I'm optimistic that the new version will perform better than the last.

That's great to hear. If and when Windows x64 compatibility comes, I will certainly test Windows/Dx11 against Linux/OpenGL.

 

6 minutes ago, Ser said:

"Physics time is set to the absolute minimum" - why? Doesn't default setting satisfy you? I think that might be the reason of your lags.

As I said earlier in this post, I realized that physics time only makes for better, more consistent physics at the cost of FPS, so I shouldn't have mentioned it in the context.

[Red Iron Crown]

2 minutes ago, Darnok said:

what?

The number represents the maximum game time that can pass between frames, with a range from 0.12 seconds to 0.03 seconds (default is 0.04). If the physics engine can't complete the required calculations in that time it delays the next frame and turns the MET timer yellow to indicate lag is occurring, lag in this case meaning each frame takes longer in real time than in game time (leading to a slow-motion like effect). Setting the number higher than default (or at the maximum of 0.12s) gives longer for the calculations to complete before delaying the next frame, meaning less lag.

[KerbonautInTraining]

TL;DR

Lower delta time = more MET slowdown, higher frame rates, more accurate physics

Higher delta time = less MET slowdown, lower frame rates, possible kraken bait

[Sanic]

 Is it just me or do the devotes this week seem kind of mundane?

[Ser]

4 minutes ago, Sanic said:

 Is it just me or do the devotes this week seem kind of mundane?

Some understand it as a sign of a soon 1.1 release

Edited February 11, 2016 by Ser

[Red Iron Crown]

@sackfalte For what it's worth, you can dial that setting down and not suffer much ill effect, it's really only significant during high relative speed collisions. I keep mine at 0.06 and have acceptable performance.

Anecdote: A while back I spent some time trying to simulate an ASAT mission, which puts the missile up at orbital height for the satellite to slam into. Even with the physics delta set at minimum the satellite was moving over 60m in a frame, enough to make it snap through the missile even when I managed to set up an intercept.

@KerbonautInTraining Surely you have the framerate parts backwards? The number is the maximum physics delta, it will happily run faster if it can.

@Sanic Bugfixing isn't very glamorous and is rather dull to read about, but the task is incredibly important.

[Norcalplanner]

7 hours ago, hermes47 said:

Nope, that's perfectly legit grammar. Ground truthing is when one obtains information by direct observation, rather than just via inference. Eg, the orbital survey scan can be thought of as inferring what in a certain area based on things like albedo and local gravity fluctuations, but the surface scanner directly looks and measures to determine exactly what's at a point. It ground truths.

As someone who does work IRL that is both in the office and in the field, I can confirm that "ground truth" is a part of the vernacular and is being correctly used. It's very similar to the phrase "field verify" when talking about putting boots on the ground to verify that approved plans and maps line up with reality.

[NathanKell]

Guys, I just explained that max physics time slider, it's really not what you're thinking.

http://forum.kerbalspaceprogram.com/index.php?/topic/131437-could-someone-explain-the-max-physics-delta-time-per-frame/&do=findComment&comment=2395682

[Skylar']

so sad to hear that satelites update is suspended. i hope remotetech developer will susport mod on 1.1

[HMIC]

Wow, things have really progressed since the last time I posted.  It's exciting that KSP 1.1 is now in QA. 

@KasperVld
Things are rolling great with the Unity 5 migration from what I'm reading, last time I visited, I sent a message in spanish to some of the Squad members congratualting them a few months  back.  So now as a follow up I just have a question:

 Will I still be able to operate KSP 1.1 while drunk?  Or will I have to change my habits? 

 

Message in spanish for Mexican Squad members: "TECATE!! Todo con exceso, nada con medida .... ok, ya ando pedo.. a seguir jalando ..  saludos de Monterrey, NL!!"

Edited February 11, 2016 by HMIC
Posted some of this on the wrong thread, moved it here.

[Mad Rocket Scientist]

5 hours ago, Majorjim said:

I have actually built something like this before. It does not work.. The wheels are not fast enough to do anything exciting with it sadly. You can drive lifts with the wheels, people have done this many times before, you just cannot fling anything fast with it.

You wont be able to. Reading the dev notes the new wheels are not wheel shaped either..

That's seems to be true, sadly. 

@Azimech's idea might work, though.

[Majorjim!]

1 hour ago, Mad Rocket Scientist said:

That's seems to be true, sadly. 

@Azimech's idea might work, though.

It may indeed, alas if the end goal is launching stuff, a jet or rocket mass driver is the best way to do it.

Edited February 11, 2016 by Majorjim

[TriggerAu]

11 hours ago, Warzouz said:

That's a cool feature to have to background separated from the foreground. I suppost KSPedita will allow modder to create some kind of ingame help for their mod. I suggest to allow the background to be used for those to-be-created help. I also soggest some kind of way to show clearly if a feature is stock or modded (maybe some automatic mod name embeding in the background (?)

Will you publish a basic toolkit (a PSD-like file) so modders can create images with coherent design ? (Image quality, size, font-type, font size, colors..)

Finally, something you can't change, but I regret you uses images to be embeded. It's very static, not language translatable, and finally. You should have looked into Nadeo (Trackmania) emebedeed browser they used few years ago (in Trackmania United) called MANIALINKS. At that time, it was a simple XML (that could be generated by a HTTP server) which could handle images, textes, internal links (not URL nor script, for security, if I remember ). The feature was even able to install mods, tracks and car models without exiting the game. This feature allowed website to show contents directly in the game.

I must point that Nadeo was a 12 people team at that time.

Adding/adjusting content is on the design list yes, so people can add content and also localise it (The text is not an image, its another layer that is text in Unity). When we get to that point I'll quite happily share any and all info on how people can make up their own - but for now its getting the basics in

 

11 hours ago, Speadge said:

as for the KSPedia, please make sure not to switch "you can use" and "we can use" that often. it really confuses people (at least me)
=> i.e. on the orbital ore scan screens.

Thanks for that, tis one of the things on my list when I proofread the pages (yet to do) same as - am I missing full stops at end of sentences, missed punctuation in contractions (or too many contractions - apparently my Aussie comes through a bit too much in first cuts), strange capitalization, use of incorrect names, ... and the list goes on

[Superfluous J]

 

11 hours ago, Luis said:

The fifth screen has a sentence that reads:

"Once we've touched down we can use this scanner to ground truth the planet and improve our orbital survey accuracy." (my emphasis)

I'm pretty sure that's an extreme grammar issue, since I have no idea what it's trying to say.

10 hours ago, hermes47 said:

Nope, that's perfectly legit grammar. Ground truthing is when one obtains information by direct observation, rather than just via inference. Eg, the orbital survey scan can be thought of as inferring what in a certain area based on things like albedo and local gravity fluctuations, but the surface scanner directly looks and measures to determine exactly what's at a point. It ground truths.

And considering its an odd, industry-specific term that could appear to be incorrect grammar, the tutorial for the game is the best place to make that term bold and underlined with a hover or link to another entry to explain it. It's what another -pedia I know of would do.

[TriggerAu]

The whole game has odd terms , and I find more all the time. This is only the start of KSPedia, so dont stress too much around it, and KSpedia is only one way of learning.

That said, avoiding misunderstanding is an important things and once people give it a proof read you may see that sorta term disappear, or it may be that a glossary is added, or something else

[Benoit Hage]

I know I should have asked this last week on the previous devnote, but:

Quote

. On Monday the two then met with Sarbian (maintainer of the Mechjeb mod)

Any future project out of this lunch in Paris?

Also, can we have some feedback on the Unity 5 testing concerning performance? Did you guys @SQUAD notice some major differences?

[FullMetalMachinist]

1 hour ago, Benoit Hage said:

Also, can we have some feedback on the Unity 5 testing concerning performance?

This is probably one of the most frequently asked questions about the 1.1 update. Squad is being very tight-lipped about it, and I think that's the smart move.

Right now they're only doing QA, which means they're testing small pieces of the game looking for bugs, I doubt that they even have a full build of the new update yet. Also, there are relatively few people involved in QA, so that's a pretty small sample size of computers to base performance increases off of. 

Once 1.1 hits experimentals they will be working with a complete build of the game, and more people will get their hands on it. At that point they may give some conservative numbers of performance increases, but I doubt it. Better to not get hopes up rather than promise something they can't deliver. 

Now, having said all that, there are lots of people on the forum (I'm not one of them) who have computer programming/software engineering experience, and they're pretty much agreed that we'll see some better performance, but it's anyone's guess exactly how much.