Citizen247

I was wondering if I could get a bit of help with a patch I'm writing to add KSPWheels to stock (and a few other mods). Seems to work great on the ones I've done so far, except the stock fixed gear. The gear itself performs great, but the rolling animation flops around oddly. It's hard to show on a static image but you can sort of see the ghosting as the wheel wobbles here: Basically it oscillates as if the axle is off centre. I noticed that the "wheelcollider" and "wheelpivot" are not aligned in the model. There's a wheelColliderOffset field in the KSPWheelBase which I thought might fix it but seems to have no effect. So I was wondering if anyone had any ideas or could point me in the right direction?

I have noticed that it takes a lot of thrust to get some things moving on water. I was playing with a sub earlier that needed nearly 300kn to start moving, but as soon as it hit 1m/s 30kn kept it accelerating. Suggests that maybe far too much drag is being applied at low speeds.

Have you got AJE installed? The TPR curves are defined by AJE in the /AJE/Inlets/TPRCurveDefaults.cfg file. I've just checked and nothing has changed in the latest version so the only reason I can see for those errors is if AJE isn't installed (or not correctly installed).

They're given a category of none. But the only engines removed are ones that have AJE-extended equivalents.

It should work, but the engines aren't integrated with RP-1 at all, so I can't promise they'll fit properly in the tech-tree.

I've only tested it briefly but it seemed to work. These are configs that configure other mods, so in general if the other mods work on a release this should as well.

Pistons model the way an internal combustion engine behaves, and you set things like manifold pressure, horsepower etc for the engine sim and a suitable propeller config. Jets set things like compression ratio, max design thrust etc. I was going to say that the jet sim only works for jets using thrust, you can't add a prop to them, and the propeller sim only works for piston engines. Which is true, but I've just now realised there is another engine module: rotors. They're designed for, obviously, helicopter rotors, but the engine sim is turbine based. It might be possible to beat that into working as a fixed wing turboprop. I have no idea though, I've not really done any configuration with rotors and it may not be possible to make the rotor sim work for a prop. I'll take a look at the code and see what I can do. I could also probably make a pass at checking the prop configs are the best for the task.

I've tested with a few test craft on 1.8.1 and everything I've tested thus far is the same as other versions, so it's basically a balancing issue I think. Specifically, the PT6 configs are largely lifted directly from AJE, so it may be worth asking there as well. Honestly it's really hard to get any prop engines below 1000hp (or above 5000hp) to work anything like correctly. I'll take a look but I can't promise anything. Especially with turboprops, because the only way to do turboprops in AJE is basically to try and get the piston engine simulation to do turboprops. I'm really not sure what to with turboprops basically. The lower end ones always seem to need a HP boost, but the higher end ones start to break the game.

Sorry about the late reply. Just got back to KSP, still short on time ATM. I'll take a look, but there's no reason I can see they'd be under-powered after a version change. I've done some limited testing with a couple of engines while looking at other things in 1.8.1 and they seemed fine. Can you give me some more information on your setup (do your have FAR installed for instance?).

Thanks, sorry I've not been around, I've got this fixed on my configs, I'll try and push a bug fix update in ASAP. I'll also try to get some actual updates done in the not to distant. Unfortunately I'm a key worker and doing a course and doing training so I'm a little short on time and motivation at the moment (and the last like, six months...)

Is it wrong that the thing I'm most excited about with KSP2's colony mechanic is the possibility of building things like Artic bases on Kerbin and possibly underwater outposts?

I'd say on average engines need to be around the 30% mark of real world engines in the same niche. That's where they've generally been falling while I've been working on engine configs for real fuels for 10x rescales. Though that includes a 1.6x rescale in most instances. I don't know. I think the twin boar is more reminiscent, both in size and niche to the atlas v common core, rather than the pyrios booster. If that were the case it's thrust is about 48% of the atlas V which makes it slightly overpowered. Which is probably a design choice made so that orbital burns aren't slow, long and boring. That's a choice made throughout the KSP orbital engines. That doesn't mean they're unbalanced, just that the game designers made different game balance choices to strict real world comparisons. The kickback and wolfhound are balanced within their categories rather than with their real world counterparts. In KSP orbital engines are more powerful so orbital burns don't take as long, while launcher engines are less powerful because rockets are significantly smaller and lighter than real world counterparts. The balancing logic is different for the two categories so they're not directly comparable. I mean the IX-6315 "Dawn" has in the region of a thousand times more thrust than the most powerful experimental ion drives ever tested. The point is if you balanced orbital engines to the same level as launcher engines then you'd either have stupidly overpowered launchers or boringly weak orbitals. That might be great for those of us who are realism junkies; but not so much for casual or I think the majority of KSP players. I'd also note that, while the wolfhound is (and in fact most parts are) about 60% the size of real-life counterparts, the kickback is around 30% of the size of its real-life counterpart. Which means 5.5% thrust is roughly correct compared to similar engines and it's greater scale reduction. In fact all the SLS themed parts are much smaller than the standard KSP scale. It's something worth remembering when comparing their performance to other parts and their real-life counterparts.

I play almost axclusively in a 10x rescale of the stock system. The main problem is that engines, even with realfuels, are drastically underpowered. Most engines fall in the 200kn thrust range, when you really need engines in the 600kn thrust range for instance. I've played with a mismash of custom configs to alter engine performance for quite some time. So I've finally decided to produce a mod along the lines of Stock-Realfuels configs, but aimed at making the engines ballanced for 10x rescales. For mods that are obviously designed to produce replicas of real world spacecraft I've tried to balance tank, engine and part sizes inorder to produce launch vehicles with similar performance and properties as their realworld counterparts. For instance a bluedog Saturn V or Tantares Proton should have performance similar to the real Saturn V or Proton. For more general engines I've tried to balance them so they fill a similar niche as they do in Stock, but for a 10x rescale. I'm also trying to give more options for fuel use, including solid rockets (so we can use HTPB etc instead of "solidfuel"). At the moment I have full support for: Bluedog Tantares Stock Expansion: Making History. Near Future LV Partial support for: Stock SXT Planned support for: Near Future Spacecraft Kerbal Atomics Restock/Plus I'm at the point where testing is needed. I've tested that everything works without errors, but not done much in the way of balancing. I resize engines, tanks and sundry parts (decouplers, fins, structural etc) to keep things consistent and allow the building of realistic replicas. Bear in mind this is still alpha, so there's LOTS of gaps where I haven't configured things yet. Any ideas or suggestions gratefully recieved. Also, if you have a mod you'd like supported let me know. Current Alpha: Alpha 1 - Download This uses some code from RealFuels-Stockalike written by: NathanKell, Sarbian, and Raptor831 Licence: https://creativecommons.org/licenses/by-sa/4.0/

If you look at the differences of orbital velocity between stock and real world and the required DeltaV, stock parts are just about exactly where they should be.

Nothing I'm talking about is complex. So ok indeed.

Or you didn't understand what I was getting at. You don't need the entire scene and all it's assets in memory to do background processing.

Again, not what I'm saying. I'm talking about preventing problems of floating point precision by using separate coordinate systems for interstellar and system space. Each system would have it's own coordinate system within its Sphere of influence. If you had every system within the same coordinate space you end up with greater and greater problems of floating point precision errors. These are actually noticeable in the stock system of KSP already. Anytime something is hovering just above ground or sunk beneath it is due to floating point error. The bigger the space the more you stretch the floating point precision, the worse the error. If you're sticking all the systems in to one big coordinate space you're losing a lot of precision on effectively empty space. I was proposing a way around that issue without teleporting between systems, which is what I was arguing against. That's under the hood. From the players point of view movement and transition should be as seamless as moving between SoI in the current game.

This literally has absolutely nothing to do with anything I said. If course they can. There's no reason the ships velocity has to move the ship within the local space. I'm not talking about how is presented to the user, I'm talking about separating different contexts out to different scenes. Except for all the floating point precision problems... Plus the issue that KSP has to keep all it's assets in memory all the time and can't stream from disk. Also, the current way of adding in multiple star systems is a hack of the game engine.

You make interstellar space a transition where the ship looks like it's thrusting but isn't actually moving. To avoid issues with floating point precision. When enough time has passed the the ship transfers to the other stars SOI. I.e. the different start systems and interplanetary space would be separate scenes rather than sharing the same space.

The problem as I see it is that you can't really parrallise physics very well if at all if all the rigid bodies are always interdependent. Which they are in a ship built of discreet parts. The forces acting on individual parts are dependent on all the other parts. You can't put the physics for a fuel tank in a separate thread to the engine if it depends on the thrust forces from the engine for instance. The fuel tank depends on the engine thrust so must be calculated after those forces are calculated. What happens if, when parrallised, the fuel tank has physics applied before the engine thread gets done? The fuel tank doesn't have thrust applied to it for that tick, and next tick everything explodes because the engine has thrusted forward into the fuel tank which hasn't had that acceleration applied. The only way I can see to simplify that would be to treat the vessel as a single part unless it's experiencing enough forces to break part connections.

Personally I'd have it more like the current SOI paradigm. Once you leave a system SOI you're in "interplanetary space" where the ship doesn't actually "move", it just sits in blank space until it should reach the new system. Combining that with thrust while unloaded/warping would appear to the player like a smooth transition instead of a cheap teleport and also allow those new drives to be useful in system.

Given that the game is going to have interstellar travel and we know it has at least Orion and inertial confinement fusion drives (which both are meant to be able to accelerate for days, weeks, months or even years), it seems very likely an accelerating during time warp and/or in the background mechanic will be part of the stock game. No one is going to sit running a burn for six months real time.

It's not being published by EA so we should be ok.

I'm not sure what your point is. I was talking about why it's unlikely that KSP 2 will upscale the universe from stock KSP scale. What does this have to do with that?

You get that reduction in a universe that's already scaled to 10% as stock KSP is, was my point. Why scale the universe to a larger size to then scale it back down? It makes more sense to keep the stock scale and distances. That way while reducing travel times you're also keeping the vast difference between interstellar and interplanetary distances intact.