katateochi

Members
  • Content count

    2931
  • Joined

  • Last visited

Community Reputation

2839 Excellent

About katateochi

  • Rank
    KerbalX.com dev

Contact Methods

  • Website URL http://KerbalX.com

Profile Information

  • Location Orbiting Something
  • Interests Things, I'm interested in things.

Recent Profile Visitors

11398 profile views
  1. I will be adding mission sharing to KerbalX, but until the expansion is released I won't have any information about how missions are structured/stored so I can't start building that aspect yet.
  2. Trying to rotate spacex's Tesla in space

    I tried to right click and pan, then was like "doh, I'm an idiot", then thought "hmmm, I wonder what it's current altitude is" and hit m to go into map mode, I think I genuinely expected to see it's blue trajectory line...it's been a long day.
  3. Ksp need to fix the performance

    I can see the points of both sides of the argument; KSP's performance compared to "prettier" games is somewhat lacking, but given what KSP is actually doing it's quite impressive. But the question I have is; does KSP need to be doing all that it's doing? I think KSP sometimes forgets that it's a game first and simulation second (something IIRC @HarvesteR once said it should be). A simulation should be as accurate as possible, but a game should try and fake it and take shortcuts wherever possible. I don't know how certain things are actually implemented but I get the feeling that some of the approaches are what I'd called the "naive approach". That's not to say that the devs are being stupid, most first implementations are a naive solution, and often that is what seems the most logical or most representative of the real world aspect it's trying to mimic, but with coding the optimal solution is often quite different and even counter intuitive to the system that you're trying to model. Take part heating as an example. (I've gotta caveat this with I don't actually know how it's done, this is just speculation, I may be wrong). It seems like parts are engaged in transferring heat between their neighbouring parts and this makes perfect sense as this is what would happen in RL, hot thing next to cooler thing will transfer heat to cooler thing. but this means that at every tic each part has to first calculate which it's neighbouring parts are and then calculate what the exchange should be. Just working out for each part what it's neighbouring parts are is a lot of stepping up and down the part-association tree and unless there is a state/part change to the craft (ie from staging, docking, crashing etc) the result of that calculation won't change between frames. So does each part maintain a temporary cache index of which is neighbours are (and clears that cache on any event which changes the craft's state)? I'd hope so as that would be a small optimisation to that process. But perhaps having each part transferring heat to its neighbouring parts isn't the right way to go about it (even though it's the best representation of RL)? I think the way I'd try to approach this would be to have a "heat layer", a sort of bounding box that represents a 3D gradient (or set of vectors) and have each part interact with this heat layer rather than with its neighbouring parts. Each part can then either impart of extract heat from it's position in the heat layer depending on whether that position in the layer is hotter or colder than the part and as parts impart/extract heat that adjusts the position of the vectors. So the heat layer is a representation of sources and sinks of heat and at each tic of the game each part only has to perform a single interaction with the heat layer, rather than as many interactions as it has neighbours (and there is no need to do any walking up/down the part-tree to find adjacent parts). The heat layer could be very simple and only represent a single source/sink (which would be a poor representation, but quick to calculate), or it could have multiple sources/sinks which essentially increases it resolution/accuracy (at the cost of more calcs, but I think that would still be much less CPU intensive than doing part-to-part transfers). Part-to-part transfer of heat is also not something that lends itself to being multi-threaded as each thread would have to interact with parts that may be being interacted with by other threads and having a shared resource that could be updated by multiple threads is bad (aka non-threadsafe). tbh I'm not sure the heat-layer approach could be multi-threaded either as the heat layer becomes the common resource that each thread would have to interact with and update. Another aspect (which kinda annoys me) is landed craft/bases still have all their physics calculated at every step. Sure in RL a parked car still has a bunch of physics acting on it, but in the game context there's no need for that. When a craft/base is on the ground and stopped it should become "locked" and it should stop calculating physics for each part. The only thing it should be doing is checking to see if any internal or external forces are being exerted on it as a whole and if that force goes above a certain threshold then it should switch back to calculating physics on each part. Not only would this increase the performance and enable much larger bases to be built, it would also get rid of that annoying issue of craft sliding around on the surface. That's the kind of "faking it" that I think KSP should be doing more of and those are just two examples. I think there are several other places which could benefit from a change in mindset towards faking it rather than simulating it.
  4. SpaceX Discussion Thread

    *cold outside, no kinda atmosphere, all alone...more or less..... (great now I'll have that stuck in my head for the next 24 hours)
  5. SpaceX Discussion Thread

    So, apart from the essential modifications to the Tesla (adding a copy of the guide and a towel) what other modifications were made to it. Obviously some mounting points added, but what I'm getting at is, if you got the car back on the ground (an in an atmo), how much would it take to get it running again? Just fuel it up, or did they do other things that would make that harder ?
  6. SpaceX Discussion Thread

    oh no way, I didn't realise Scott Manley suggested that! That's so cool, the KSP community had an impact on the payload!
  7. SpaceX Discussion Thread

    I actually did a little jump of joy when I saw "Don't Panic" on the Tesla dashboard.
  8. SpaceX Discussion Thread

    That was the bit that I was most worried about, which is prob just because most of my KSP launch fails happen at booster sep. Was interested to hear that the design was to have a few ms delay between the top and bottom release.
  9. SpaceX Discussion Thread

    That twin landing!! Looked sooooo amazing. so.....what happened with the 2nd stage landing?
  10. Has anyone ever made any ksp rooms?

    I like this approach, it's just like making a film set and "faking it". It also takes care of those annoying little details like needing artificial gravity for internal enterprise scenes, and you can get rid of all your lag problems.
  11. Has anyone ever made any ksp rooms?

    Ages ago I made a large house for the three to live in. I think a lot of the parts I used in that came from the B9 aerospace pack. but perhaps more what you're looking for, (also from ages ago though), SWDennis made this:
  12. The KerbalX thing is still very much in working order and would love to have your Mech designs on it. Upload away! and if you've got any Qs give me a shout.
  13. While paying (and...in fact, throughout most of my life) I keep my brain suspended in a strong Brownian Motion producer, say a nice hot cup of tea. Yeah, tea, lots of tea (after all, I am half British, and the other half is Sri Lankan, so my heritage basically demands that I drink tea).
  14. No that's a glitch. For some reason the versions off a group of craft were incorrectly parsed. I shall sort that later. (Been away for a few days so playing catch-up with things that need sorting, but I will get to this soon).
  15. from what I understand (which might not be that much); The problems are worse for database related applications (with the vulnerability being a particular problem for machines running multiple virtual machines, so cloud computing platforms), and that's where the 30% performance hit might be seen with the fix implementation. I think that for general client end use the hit isn't going to be so bad, so from a running KSP point of view it should be much of an issue. https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html