jheriko

I never use the nuclear engines... I know they are popular and they are the sensible choice, but it just feels like cheating. 909 all the way...

Some things always bug me about these kinds of discussions - specifically the idea of a speed of light and the resulting discussions around time-dilation and relativity, coupled with not really knowing what anyone really means by a speed or time? Personally I think calling it the 'speed' of light is confusing because what we think of as speed is a concept that breaks down massively at these extremes. Another way to look at the number c is a conversion factor between space and time - there are about 3x10^8 metres in a second. By remaining nearly at rest we cover almost c metres in the time-axis every second, but 0 in space, from the perspective of outside observers we may appear to be moving at any kind of speed dependent on their velocity - for one special set of observers that speed is zero. Light has the opposite experience, it travels 0 in the time-axis, but c metres through space and from the appearance of outside observers it appears that it is travelling at precisely c regardless of the observer's velocity - there are no observers who will see it move at zero speed - even other light. This strange seeming behaviour is an artefact of our looking on the 4 dimensional geometry of space-time in strange 3 dimensional slices - actually 2 dimensional projections of 3 dimensional slices as well... and coupling that with conceptualising time as an independent axis - which it is not. Speed as you think about it day to day is a useful approximation at low speeds. Its not really the whole picture - like describing colours in terms of lightness or darkness with no thought for hue or saturation. So the question of if we can travel at the speed of light, or faster than it, neither of these really make much sense because speed doesn't make much sense in that context. In the geometry of relativity going faster than the speed of light doesn't really make sense - its kind of a projective thing where infinity happens to be mapped to c. A different way to think of it is the classic analogy with the north pole - there is nothing further north of it because thats how north works... similarly there is nothing faster than the speed of light because that is how time works. Of course, assuming that special relativity is valid... Of course we are still free to travel backwards in time, and if you ignore the complexities involved then that would look just like FTL travel in our natural interpretation. I also think it would be a very interesting experiment to try - although the original question was about the speed of light I'd like to know what happens if I can go back and shoot my grandfather (well maybe not exactly that...) I feel that cosmic censorship hypotheses are a bit of a cop out. Hopefully that NASA guy builds a tiny experiment where this can be investigated whilst he is playing with warp drives...

right. ill take a look at this hopefully tonight, but maybe not until tomorrow. unfortunately... or fortunately... i have work to got to

surely using WWW is just bad practice? the potential overhead and security implications etc... best just to avoid altogether.

gl quads should be as fast as anything in game if done right... try using a vertex buffer instead of uploading the vertices to the gpu each frame, also cache the divisions by screen dimensions and multiply by the same constant. you can evaluate it once per frame instead of for every vertex. can you use a static fixed array in memory instead of the expensive list? have you tried using a triangle list instead? how about a triangle strip using pairs of degenerate triangles to connect the quads? this all means nothing if you are drawing, e.g. 4 quads though.

You know you can choose where you control the craft from and the navball changes? As long as your pod is a suitable 90 degrees from your engines it should be fine without any changes... This is very useful when docking with some 90 degree angled port, for example. Maybe by default the engine 'gimbals' point it 90 degrees out ready for take off on launch? you can cobble an orientation from the down vector and some arbitrary planar direction... or do something much better where the engine pivot transform is rotated about an axis to point straight down. Also, the problem with exact calculations and Unity physics in my experience is the integration and quantisation - analytic solutions always have small 'rounding errors' as a result of this. I can imagine it being difficult to avoid wobbling altogether although the scale of this effect might be completely unrelated to the current wobbling with asas...

i dunno, i've been trying to upload a private mod and it gives me 404 when done... maybe spaceport is broken?

i have also seen some poor behaviour from this function. might i suggest that it has bugs and it would be nice if they were fixed? other than the fuel feeds and connectivity issues there isn't anything fantastically difficult about implementing this that i can see (looking naively from the outside)...

does turning sas off altogether not just fix it? i have had explosion trouble but only when frame rate is sufficiently poor... (which to be fair, is often with station construction type stuff)

As per this thread: http://forum.kerbalspaceprogram.com/showthread.php/34157-Leaderboards-do-we-want-them-are-usernames-and-passwords-annoying I've made a mod. I've been away from the internet, games and such for a little while since then and have returned and picked this up again. its nearly finished, but i don't feel comfortable spending the effort to polish and finish without some genuine user feedback. ... to help me test my leaderboard sample return mod. Its not 'final' yet, the artwork is placeholder (i reuse existing parts) and there may be really nasty bugs waiting to be found. Also, since its testing I will be prone to wiping out the leaderboard from time to time... if interested please pm me. i will get a package together on kerbal space port to host privately in the next few hours or so.... i just need to tidy all my experiments in that project away first. Thanks in advance. p.s. sorry if there is a better place for this sort of request... EDIT: taking a while since space port seems to give me 404 for the download pages although it shows in my 'addons'

So, to explain a bit more about why distance and velocity in the orbit are related consider the simplified model where gravity is just acting in one direction, and you have an arrangement like in this diagram. v is the velocity, d is the distance - now you need v to be exactly right so that as the object falls it winds up being offset d away from the centre of mass along the horizontal direction. Of course the gravity direction varies as you go around - but all this does is make the calculation for v different - the principle remains the same. If v was greater the orbit would not be circular - it might even escape the gravity well altogether, if it was less then the same is true the orbit becomes elliptical, and if its small enough we hit the planet. Note my diagram is not great the red x should be vertically above the black one... just pretend it is.

I find generally that the burn times are always off to some degree, even during a burn. The most noticeable is when doing long partial ion burns, say at 25%, and you can watch the timer countdown 1 second for every 4 seconds of real-time. Before starting the burn it is often much more wildly out... I've also seen the burn times be overestimated when using nodes during launch or in low orbit, when I still have super powerful engines attached. My guess is that as well the time being based on full throttle, it doesn't account for mass loss from fuel either.

Why does everyone believe that its impossible to calculate n-body gravity quickly? There are very few bodies and the calculations would be trivial. It would break all the gameplay but it certainly wouldn't strain your computer... it wouldn't even be a strain for a 20 year old computer for that matter. If we are talking about modelling a pointlessly accurate gravity with GR and taking into account the shapes of planets etc. then yes it would be difficult, but using newtonian gravity and spheres - which is a fantastic approximation - is very practical. The alternative, one used by astronomers and space programs is to actually calculate everything in advance and create rails that include all the small perturbations, like VSOP87 or DE206 etc. I know from experience (i.e. I have done it and can point at other software that does, e.g. celestia, stellarium... ) that these things can be very happily run at interactive framerates with small data files if you are willing to sacrifice accuracy a little...

When at the lowest point during the slingshot you can make some very large changes to trajectory cheaply so that when you exit you have a close encounter with a target. The effect is so strong that you will often have to wait a bit later before making fine adjustments since even the fine control on rcs will send your trajectory towards/away from encounter far too much.

As others have suggested this could work, but not by simply placing an invisible planet. What you want I think would be something to cancel out gravity within an SOI. Because you need to calculate 100000 steps per frame? With clever use of a rails system this becomes a non-issue, you have a wide enough time-step with interpolation so that the calculations fit within frame time. You can solve this problem by calculating splines, which do have a closed form, and maintaining them during updates. Why is everyone so inclined to come up with (poor) reasons why this impossible? I still don't want it in the game, but seeing a lack of knowledge accompanying such strong statements is... frustrating.

I wouldn't plan to make a living on youtube, but stuff like this will help you get a real job in the industry somewhere (film/video games). I've met enough graduates who couldn't code/draw/design their way out of an open airlock... examples of work trump everything else if they are good. Trust me I am basically uneducated and have been working as a programmer in the games industry on and off for about 4 years now, I'm pretty sure that 'my demo is a very complete first person shooter game engine' is part of it.

NaNs somewhere?

There are some great tutorials over on the wiki - although they may be a little out of date, or simple for what you want, they are a good starting point. The most valuable skill is always learning how to teach yourself imo. Google is your friend... although back in my day we didn't even have the internet. Count yourself lucky.

IMO the vanilla game takes too long to load even ignoring the known issue. :/ I think Unity is tying the devs hands somewhat, but also that there is a lack of polish in this area anyway...

Is this from using UnityEngine.WWW for loading files? It seems to me, naively, like a really, REALLY bad idea to load files through this mechanism and file:// URLs... considering that threading is somewhat alien in the world of Unity, the fact that it kicks off an asynchronous process also seems rude.

These kinds of answers are a little frustrating. I very strongly doubt that it is impractical to solve this problem in a way that would be good enough for KSP. I base this on having 1000s of points gravitating with each other @ 30fps 10 years ago with mediocre programming skill at best. With the clever optimisation of having a fixed path when not accelerating and having the planets be on rails I'm confident that it could be implemented whilst giving a similar quality of experience to what we have with the conics atm - manoeuvre nodes and all - and without a severe impact on framerate. Personally I would not want this though - it adds little value besides being able to do weird and wonderful things at Lagrange points and actually breaks lots of niceness like being able to have simple, stable orbits around all bodies, having orbits be periodic, only having to worry about gravity inside of the relatively small spheres of influence etc. This is a good answer.

yeah, i'm not sure i understand the objections either. unless people are spamming out versions of mods this shouldn't become spam... the benefit i expect is not having to trawl through outdated discussions when looking at info for the latest version of a mod. if anything this would reduce visible 'clutter' on the forum. I think what spaceport provides is fine btw. But the error messages from upload are non-descript as mentioned - but i've found checking my inputs carefully is sufficient. Also mod authors can keep their submissions their up-to date - having version specific comments etc. is not really what i want and i don't think its valuable - i just don't like the huge threads we have for the popular plugins, i find them unfriendly.

Okay, so now I have used this I am worried about people using it without understanding what they are doing and why this can create huge stalls. UnityEngine.WWW starts an asynchronous process when instantiated. To dumb that down a bit - it makes a thread on 'new'. What this means for you is that you are now writing timesliced or multi-threaded code, and you must account for the case of a single hardware thread where you need to yield to allow execution - implementing efficient spin-waits is a subject all of its own, but luckily the C# devs did it for you. Unfortunately that mechanism doesn't work in KSP :/ EDIT: just realised i missed the 'linking information' - file i/o is always at least partly asynchronous and thread-safe! which explains why not doing this will result in stalls... EDIT++: actually the code I gave actually doesn't work in KSP, although it works fine in general unity/.net... for whatever reason KSP can't load SpinOnce from mscorlib.

what the title says. navigating large threads from the end going backwards is not convenient, and i don't think we really gain anything practical by having huge threads all the way back to 0.1 versions of mods.

This isn't my intent - I was trying to draw analogy between 'life' and 'sentience' and things like 'space' or 'time', rather than analogising with some unknown theory of everything - i.e. as things that only make sense in coarse, practical day-to-day descriptions and not when you investigate them more closely. The alternative analogy with the same meaning is perhaps that a theory of intelligence is analogous to classical physics... it only makes sense approximately, and only at a very coarse scale. Sorry, just being nitpicky.