Shadowmage

I would hope not. Unity is perfectly capable of targeting Linux / OSX.

My only thoughts are concerns to if the pressing issues with KSP 1 have been addressed (you know, all those #BlameUnity problems....). Wheel Physics -- Unity Wheel Colliders are unusable for KSP-style 'build-your-own' craft. Has a custom wheel solution been devised that does not rely on the Unity/PhysX WheelCollider mess? Part-Based physics -- Has the per-part physics overhead been addressed (rigidbody joints between parts)? Is part-count still a limiting factor in craft design? How, precisely, has this been addressed (details, please)? Modular/Procedural/Dynamic parts -- Is there a proper implementation for dynamic parts? Can features be added/removed from any given part smoothly, at runtime? (e.g. a command pod can have its RCS nozzles toggled on and off, without massive plugin hackery) Garbage Collection -- Does the new Unity version still lag every X seconds for garbage collection? Doe the new Roslyn based JIT/GC system work any better? DX9 -- Please tell me that DX9 support is long gone, and that this new project targets modern graphics APIs and features? (PBR shaders, global illumination, preferably compatible with deferred rendering, availability of standard post-processing options) Weather / atmosphere -- Yep, needs to be there. Planetary activities / exploration -- something to do on planets. Surface science & deployed-science x 100 for every landable body. Preferably with some randomized generation to facilitate some differences between playthroughs. What resources will be available for modders? The lack of legal access to view the source for KSP1 combined with no official modding API has greatly hindered the advancement and development of many features. Note, I'm not saying modders should have full unrestricted source code access, merely noting that without a well documented and published API, that full source access is the only other way to go (e.g. the situation with Java Minecraft modding; there was no official modding API, but you could view the full source and recompile your own versions for debugging if needed). Really want to be excited, but this announcement gives me more causes for concern than excitement. I'll hold off any official opinion until after much more information is released.

Yeah, stock does some funny things with transform scales and effects. Never could figure it out myself. SmokeScreen supports scaling though, and should be able to load whatever models/prefabs you are using with the stock system

This discussion was regarding the use of the newer particle system; so no, an older version of Unity would not help. If you are looking for information on creation and use of the legacy particle system, sorry I can't really offer any assistance there as I've never used it myself. There might be some links around in one of the forum sections, or perhaps even try contacting one of the authors of the mods who has used the system. Check the authors list of the legacy RealPlume particle models.

The models were not created with the ability to have bogey movement on that axis. Not something that I can solve without redoing the entire model (and plugin). Long story: Those are AdustableLandingGear models, created by @BahamutoD many years back. When they got merged in with KF, I took the existing models and textures, and wrote a new plugin to make them work with modern KSP. At no point have I attempted to 'fix' any of the issues with the original models, nor do I have any such intentions for the future. Not my models to fix.

I've been waiting for that update for... years now. Not particularly holding much hope for it to ever happen, but still dreaming of the day when DX9 can be a fading memory. I have a strong suspicion that is the main reason they stopped the engine upgrade cycle with the 2017.x Unity version currently in use -- any later, and they would be forced to drop DX9.

You can continue to use the older releases if you don't want TexturesUnlimited. They will not be receiving any continued support or updates, but they should work for the foreseeable future; they should even continue to work with updated versions of the KSPWheel plugin. All future releases will have TexturesUnlimited as a required dependency.

Is this a craft file that you could share? (or files I suppose as it involves multiple craft) Preferably stock + KF parts only? I've had a few reports of oddities with cargo bays before, but I've never been able to reproduce them; I've also never had someone be able to provide me a craft that had the issues though, and my designs likely don't hit the same problems. One thing of note -- KSPWheel always has the equivalent of 'same vessel interaction' enabled, so ideally, when the rover is 'docked' you want the tracks to be fully suspended / in the air, and unable to touch any other part of the craft. Otherwise, the tracks will push on the craft itself, which could easily cause breaking problems if the joint on the docking port was stronger than the suspension's max load value.

QFT = 'Quoted for Truth'. Joke or not, it is past time that stock included some sort of clouds on atmospheric bodies. They look a bit silly without them, likely even moreso with improved ground textures.

Likely minimal / unnoticeable on any hardware that has sufficient VRAM to hold the larger textures. Sampling from a larger texture isn't much more expensive than smaller textures; it is all fill-rate at that point. That is assuming they didn't increase the actual vertex count / terrain detail levels. More verts to process would likely have a larger impact than higher res textures, but even then, should be minimal on any decent hardware. The icing on the cake is that currently KSP leaves large portions of the graphics subsystem idle most of the time, so a few more verts to process shouldn't impact much either. QFT

Thanks for the report. Indeed -- likely related to the scaling feature and some improper configs for that part. Yeah, that was about the behaviour I saw when I was testing the Unity WheelCollider functionality when developing KSPWheel. If you took a rigidbody and configured wheels for it, you could change the mass of the rigidbody and the wheel behavior would not change as expected (e.g. would not change at all) -- the suspension would maintain the same compression even with body mass changes (whereas, if it were newtons, the compression should change with changes to mass). Which would lead me to believe that they are using some abstracted specification, not using newtons directly, but some body-mass-scaled value; more of a 'ratio' than an actual specification of a physical force. That was one of the reasons I decided to roll my own. When you can't even get physically correct specifications for the 'stock' systems... time to look somewhere else.

Back in the Pre KSP 1.1 days, these problems didn't exist. It was only with the upgrade to Unity 5+, where Unity upgraded to a new PhysX version, that these problems started occurring. PhysX changed their wheel-collider system, and Unity didn't re-implement their end with equivalent features of the old version (if it was even possible). Unfortunately it isn't even a 'KSP' problem, but one that exists in the game engine and its use of the physics library; it is not a problem caused by KSP code, nor is it one that can be solved by KSP code.

Most likely there are errors interfering with proper functioning of the mod. First, I would suggest updating to the latest versions of KSP and SSTU; I cannot really support old versions, and I'm not aware of any legitimate reason to be using an older version of KSP. Second, if you would like further direct support, I will need a copy of your KSP.log file, which should contain more information regarding the errors. This file can be found in the same directory as the KSP executable on Windows. Upload the file to a file-sharing site like dropbox/google drive/etc, and post the link here. With luck, the log will tell us exactly what needs to be fixed.

Part of the bounce is just a part of Unity joint physics, and mostly 'unsolvable' (without resorting to silly stuff like stock's 'locked autostruts'). But yes, part of the bounce is due to the stock models themselves, not being created with Unity physics in mind, with extremely short suspension ranges. Combine a short suspension range with a high spring value (for a scaled up wheel), and you'll get something that will want to bounce around a bit, esp. when combined with the previously mentioned joint issues. Creative use of (auto)struts can often mitigate most of the bounce (if caused by joints), and playing with spring/damper settings on the wheels can generally get them into a stable regime from there (if caused by model suspension length). To note, I don't get bouncing on my craft either. I've noticed on all the craft where it has been reported, that the craft has wheels mounted out on some skinny / light / long thing with many joints between the wheel and the root part. All the joints add slop, which causes bouncing when physics interaction starts up. Most of my craft have the wheels mounted directly to a fuselage / main structural element, which then applies the forces directly to the fuselage; no extra joints = no extra bounce/jitter/slop. But yeah, the wheel code isn't perfect (I don't think it can be with the limited access to the PhysX side of things that I have), but in most cases it is more reliable and less 'wierd' than the stock wheel code

Not that I can think of, certainly not recently. If you do have suggestions for the default max load/speed/torque values for parts at their default scales, feel free to post it up to a github ticket. Need to do/finish a balance pass on everything at this point anyway.