steve_v

It's an interesting (and amusing) read, freely available. That explains it then. Sounds fun.

Have you been reading Ignition!, @Zosma Procyon?

There is always a way. Whether there's a sensible or economical way is another matter. For many things, no. You can write your own as plugins, it's just a bunch of work. The possibility of replacing unity's wheel code has been raised before, and a plugin that might do the job suggested. The response was, IIRC, "That's not something that can be bought in the unity store and used right now, getting it to work with KSP would be a lot of work." I can't help wondering if developing a custom wheel plugin would have taken 2.5 years, because that's about how long they've been fiddling with the one unity provides, and it's still nearly as awful as the day it landed. Sure, unity source-code licences were available last time I checked. Game developers modify engines all the time, and they've been doing it since IDtech 1 and Heretic. Purchasing one was suggested repeatedly in discussion of the "double-free or corruption" crashes 1.1 suffered, the licence was deemed too expensive and debugging unity's code too difficult. One would think so. My guess is that they either do not test sufficiently before committing to a target version, or new unity releases have brought things they absolutely wanted for a new feature and someone decided it was a reasonable tradeoff. In the case of the update that came with 1.4 and borked joystick support on GNU/Linux, I suspect it was the latter, and that the feature was something needed for the DLC. This suspicion is one reason this particular issue annoys me as much as it does.

+ Is what got my goat. And we were right too, 1.0 aero was a shambles and the new thermal system didn't get fixed until 1.1 - which crashed so much it was unplayable.* *I think I have my releases right, it's been a while. Correct me if not.

I'm in the blame unity (and those who pick buggy Unity releases) "camp" for things that are unity problems. Wheels spring to mind, as does joystick support going AWOL, various longstanding physics bugs, the release that crashed constantly with memory-management errors, the release that crashed initialising audio, and the release that crashed people's window managers. That's in no way a complete list. My primary problem with Unity is that every engine update seems to bring new problems, especially for the GNU/Linux and MacOS builds, and that Squad refuses to do anything about them. Perhaps this is partially due to Unity not cooperating, but regardless of who is to blame engine bugs consistently remain unfixed for entire release cycles. Indeed. I agree that what KSP is doing is a tall order for any game engine, particularly at the scales involved. Though you may note that my complaints wrt unity, with the possible exception of the orbit drift (which was a regression anyway) aren't related to the limitations of floating-point math. They are all either deficiencies in basic game engine - OS interfacing or in mechanisms provided by Unity - such as the wheel system, the runtime garbage collector, or the memory chewing UI. Do you remember saying it wasn't ready to go beta, or that the single beta wasn't enough? I do.

FTFY. So long as it's not built on Unity3D, bring it on.

Hey @Lisias, just stopped by to say thank you for keeping KSPAPIE and KJR alive. Your work is much appreciated. Also Is freakin awesome, right?

I do not have KJR installed at all, and I am seeing very similar behaviour with the tank module attached to a 4-way core. The tanks appear extremely keen to get out of the bay, so much so that they will fire outwards in a curious spinning dance until the attachment breaks. If autostrutted or otherwise restrained, they cause the entire craft to vibrate. I did notice that they clip into each other slightly when 4 are installed on such a core, but that doesn't seem to be it as a single tank exhibits the same behaviour with the other 3 slots empty. All module height variants were tested, but not larger cores, as this is an early career game. Can check other parts in sandbox if required. I'm not sure if this is simply an instance of the notorious physics bug with heavy parts connected to very light ones or not, but it makes the otherwise phenomenal tank wedge unusable for me. This is 1.6.0.9 on KSP 1.5.1, logs are clean FWIW.

That it does sir, that it does.

So do I. But you know, learning from history and all that. I mean, joystick support has been broken since 1.4, wheel physics has been borked in a variety of ways since 1.1, and every new release seems to include some new bug in core systems. Drifting orbits, misaligned terrain tiles, terrain collision detection problems, wheel physics every damn release, the recent part database screwup, ongoing garbage collection related performance problems. Maybe I'm just pessimistic, but I've been waiting several years now for the 1.0 stable release, and it hasn't happened. 1.3.1 was close, but no cigar... Then 1.4 came around, and instead of fixing the terrain collision detection on scene load, they broke joystick support. What the actual fark? Neither problem fixed as of 1.6.1, surprised anyone? Perhaps I should wait for 1.9? Unless an engine update screws something else before then... I'd just love to see a stable release with no serious bugs, then I'd be happy to call it a day and maybe buy some DLC or something. I don't care about new parts or texture updates. Fix the bugs and stick a damn fork in it already. 1.7 would be a fine time.

Nice to know that the "new" "improved" wheel and leg physics we got in 1.1 are still a steaming turd. You saved me from the disappointment of having my optimism and faith in Squads commitment to fixing old bugs brutally crushed, again. @SQUAD: Landing legs and wheels are still borked. They've been borked since 1.1 and your "tweaks" have not solved the problems, they crop up again in every release. Please fix.

Speaking of things that are and aren't made for gaming, I found some benchmarks and this thing gets slaughtered by a Macbook Pro. Macbooks ain't exactly the poster-child for "made for gaming" either. Frankly, this tablet looks like a big ol' waste-o-money to me, and I have no idea what market it's targeting.

Citation (and benchmarks) needed. If by "mobile CPU" you mean the ARM64 SOCs commonly found in phones, sure, it's quick... For a phone. If you have the 6GB ram model, it might even have the required memory too. If by "mobile CPU" you mean current generation laptop processors, that tablet will be curb-stomped by any modern x86 laptop designed with gaming in mind, in any bench you like. The main problem for a KSP port is that A64 architecture. It's a supercharged phone processor and porting KSP to it would be akin to porting to an entirely new architecture just to support a single device. How many other A64 devices do you know of that have the horsepower to run KSP? None? Me too. That's because most of them are phones. I get it, you like your shiny i-thing. But it's not a gaming PC, however much apple's marketing would like you to think otherwise. KSP is primarily a PC game, just look how well the console port worked out. Let's not do that again, m'kay? If you wanted a gaming tablet, you should have gone with an Intel or AMD x86 based one. Not only are they cheaper than this hipster apple stuff for the same performance, they can run KSP out of the box. If apple wants to do weird things like build a high performance tablet around A64, that's apple's businesses, just don't expect everyone else to support it.

In the past, MKS/ USI Life support, which abstracts confinement / mcrogravity it into a "habitation" rating and life support into "supplies", while also introducing an interesting late-game colonisation mechanic. If you want a hardcore experience, there's Kerbalism, which includes a bunch of other stuff like radiation belts - though performance issues have so far kept me from a full playthrough with this one. Right now, I'm using TAC Life support & Kerbal Health for a bit of variety, it's working out rather fun so far and this combination covers life support, microgravity& radiation exposure, while also integrating nicely with other mods I'm running such as Nerteas centrifuges and atomic engines. For hibernation there's DeepFreeze, but it feels a bit cheaty to me when running alongside a life support mod.

So long as they are seen and not heard, no problem.

No, no, you didn't. I'm just dopey at the moment. I should have said 2.2.3.4, it's right above 2.2.3.3, too many 2s and 3s. Sigh. I'll drop 2.2.4 (which isn't on CKAN BTW) in and see what happens, I doubt it's causing this though. Possibly tomorrow. It's 9AM here and I have not slept since the same time yesterday. Or maybe later today, if that's what time it is.

I sure would shoot the dog if it had 747 barking episodes and prevented me from doing anything else. Dogs that bark in the night need to be shot anyway, they're a public nuisance.

It's the latest on CKAN flagged for 1.5.1, 2.3.3.4 is marked as incompatible. It doesn't appear to cause any problems in-game so I have not investigated further. As for replicating it, I haven't used much AGM in this install (and not at all in the run the log is from) besides checking to make sure it works. In that log I'm pretty sure I didn't even open the menu, so the only reproduction step I can provide is "install the mod".

Sorry, looks like dropbox screwed me somehow and gave me a link to a previous upload. Try this one: https://www.dropbox.com/s/q2564fgrci8iptz/Player.log?dl=0 I'm actually getting kinda liquided with dropbox too, I'll have to start hosting this stuff myself, and you cats can just suck up my self-signed cert.

More spawning is normal, allowing them to build up to the number you state and and cripple game performance is likely the result of omitting or misconfiguring a limit in the asteroid generation code. Whether that is a bug or just an oversight it should be reported and fixed, as it is almost certainly unintended behaviour.

Ahh, asteroidageddon. Haven't seen that for ages. They should disappear by themselves eventually, provided you deactivate/remove all the sentinels, on the other hand, save file editing would be my choice. And bug-reporting, this isn't supposed to happen.

I didn't do a lot of testing as I am a little liquided with KSP development at the moment and usually playing something else. However with ScienceAlert I was seeing framerates drop from 60+(vsync) to ~40 while flying over terrain. This is a fairly heavily modded game, but removing ScienceAlert alone restores FPS. Likewise [x]Science, though I have it installed now as I can endure reduced performance temporarily while the window is open. [x]Science appears to have a very similar impact, perhaps slightly less severe, but only when the "here and now" window is open. This is new to me as of 1.5.1, I have not tried any 1.4.x KSP but I can confirm that the performance hit is not present, or so minimal I have not noticed it, in 1.3.1. I don't see anything incriminating in my log, nor a likely candidate amongst the other mods I have installed. You will probably have a better idea though, so take a look if you wish. Ckan export mod list: Log (huge, [x]science installed, I am aware of the errors from AGM): https://www.dropbox.com/s/9u7qpv5jpt8gt2d/Player.log.gz?dl=0

FWIW, both [x]Science and ScienceAlert cause a considerable framerate hit for me on 1.5.1. [x]Science however only does this when the window is open and it is checking for biome changes / experiment availability. ScienceAlert appears to do these checks constantly in order to update the icon. Perhaps there's a common method causing this?

I never play without quicksaves and reverts, not so I can save-scum or revert design screwups, but so I can recover from the inevitable bug or glitch that bombs an otherwise successful mission. It always happens sooner or later, a landed craft randomly explodes on load, wheels spazz out and flip a craft over, or a kerbal mysteriously goes poof walking over otherwise uninteresting terrain. I really wish I could play ironman mode, but there is just too much jank in the game (and sometimes mods too) for me to risk trashing a months-old save over some bug or other.

Legs bouncing on scene load has been around since 1.3.1, at least. Landed vessels sliding and/or moving between scene changes has been around even longer. Both are on my list of infuriating bugs that never get fixed properly.