Shadowmage

https://github.com/shadowmage45/SSTULabs/blob/master/GameDataDisabled/SSTU-OptionalPatches/Stock/PartRemoval-Stock.cfg Note: As this was one of my personal patches, it has not been updated in quite some time, and will be missing many of the reworked stock parts. Yuck. Sad. Me either if they continue down that path. I'm not interested in wobbly rockets, and especially not interested in the poor performance that per-part joints will induce. In short: All of the bad things that I hated about KSP1 craft construction.

Yeah, they definitely put some resources into it from the little bit that I watched. I mostly skimmed it though, as trailer footage really doesn't interest me that much (now, real gameplay footage on the other hand....). Nothing wrong with Unity per-se; most of the issues KSP1 experienced with Unity were due to their (incorrect/incomplete) use of it, their refusal to update to newer engine versions, and their insistence on using features not intended for their design (e.g. the built-in WheelCollider was entirely unsuitable for use in KSP, and they should have written their own rather than using VPP which was merely built on-top of the terrible Unity WheelCollider). Unity is perfectly cable of being a top-tier game engine, but only if properly utilized and implemented.

Whether or not I do mods for KSP2 will depend entirely on if they have fixed the largest engine-level issues that KSP1 has. Notably: Performance dependent upon part count -- part count should not be a limiting factor for any sort of reasonable design (10k parts or so; at which point you likely hit poly/rendering limits) Floppy Unity RigidBody Joints -- should not be something players are subject to. Wheel Colliders being terrible -- absolutely will not get involved in that terrible mess. No working wheel-collider = no purchase. (By working, I mean does not have arbitrary limits on rigidbody orientation, # of wheels, and doesn't do any silly 'dynamic' adjustment garbage; e.g. functions just as the Unity-4 wheel colliders did, but with improved friction model). Garbage Collection Stutter -- Why people have put up with this for so long is beyond me. Had I known it was a thing with KSP1 I never would have bought that game either. Drives me absolutely crazy every time it lags. If they haven't fixed those issues, I likely won't even be buying the game. And if they -have- fixed those issues, there really won't be much of a need for SSTU's primary goal (lowered part-count for performance). I may still do some modding for 'modular' parts, perhaps some KerbalFoundries type stuff if not in the stock parts, and likely a full implementation of part-recoloring, but probably nothing complex to the extent that I'm currently maintaining. Either way, we have a long ways to go before we'll know more. They say 'releasing in 2020', but that is likely winter of 2020 knowing how marketing drones term things.

Ahh, yep, that'd do it. Likely the RO patch is running in a FOR[RealismOverhaul] block, which is alpha-sorted before the FOR[SSTU] block of my internal RF patch. Hence the cloned tanks would not have the updated config values from the SSTU patch.

That is what I thought as well (that the SSTU included RF patch handled everything needed), however I recently had someone contact me through PM regarding the issue in an RO install; I told him to patch those lines again (e.g. set the 'subtractMass = false'), which resolved his issue. I figured the same thing was happening here (even though the entire situation is illogical). Really though -- its RO related, so, I have no clue, and really don't feel like spending any further time or effort on it. It works when I install RF alone (or at least did when I tested the solution), which is where my support obligations end. (nothing personal; just so very sick of all of the RO support issues that get brought to this thread)

I'm not sure there is any other way to implement multiplayer in a title such as KSP, which is based on travel times ranging up to potentially decades. So... I'll second this sentiment. It doesn't matter how they implement it, it will be wrong for one reason or another (either physics will be broken, or gameplay will suffer) for a large portion of the playerbase. Two irreconcilable and opposing concepts. But... I'm personally curious how they have 'solved' this issue. I cannot personally see how it can be solved properly, so am genuinely interested in what they have worked up.

I do not support RO/RSS, and any such fix will have to come from them (or through requests from their team for additional hooks into SSTU code). As far as I'm aware the issue had been resolved in SSTU, and RO merely needed to update their patches to implement the fix (the same patch/fix I provided to someone via PM a few days back). As per my previous response, I do not support or endorse RO. Please ask in the RO thread. From your log -- there is an issue loading ModuleManager. AssemblyLoader: Exception loading 'ModuleManager': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded. at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0 Without ModuleManager, pretty much none of the rest of SSTU or its dependencies will load or work properly. You'll need to resolve whatever is causing that error. Second, I cannot support RO installs. Please see if you have the same issue on an otherwise stock + SSTU install, and I will gladly provide assistance for that. Otherwise please report the error to the RO team.

Not really. TexturesUnlimited is a nearly-full implementation of Unity Standard shaders in KSP, bringing the option to use Physically Based Rendering methods and basic Global Illumination. With some extra features on the side for the 'recoloring' system. PlanetShine simply introduced colored ambient (maybe it was directional?) light depending upon what body you orbited, using preconfigured color maps or values taken from the celestial body data constructs. TexturesUnlimited unlocks the full potential of environment-mapped reflections, which uses the actual rendered environment to determine what lights and colors will show on your craft; up-to and including fully reflective surfaces with pixel-accurate reflections of the surroundings. So, yes, TU does duplicate the visible function of PlanetShine, but only as a side-effect of its more modern rendering techniques and shaders.

I can only hope, honestly, that SSTU will not be needed for KSP2. If they fix the issues with KSP1 regarding part-count-induced performance degradation, then the main reason for SSTU's existence will be moot. And if they haven't fixed that issue, then why would they even be making a KSP2? (read: marketing, multiplayer; they probably don't give two hoots about performance)

The selectable mount sizes are all calculated dynamically based on configuration values, and depend on bot the mounting area on the engine (e.g. how much space it takes to mount) and on the mountable area of the mount itself (e.g. the flat area where the engine sits). Does the mount in question visibly look like it would fit for the motor at 1.25m? In the end -- you can always click the 'clear mount' button to remove the mount entirely, and then use whatever model you desire from stock/SSTU parts.

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.

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.

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.

Unfortunately I cannot provide any answers there. I don't think that expansion pack has been maintained in recent years. Both SSTU and BDB have been through many revisions since then, and I would actually be amazed if it worked at all. Notably SSTU uses a different PartModule for the modular part system than it did in the past, so any patches that use that old module would be broken (which I'm guessing is that entire expansion pack).

Glad you are enjoying it. To be fair, I cannot take all of the credit -- the original models and textures are all from other authors ( @lo-fi, @Gaalidas, @TiktaalikDreaming ). I'll gladly take credit for the plugin work though (the physics of how these wheels work), as that was my end of the fun

If you use the 'wheel group' function, you can change gears on multiple wheels at the same time. In the PAW for each wheel there is a selection for 'wheel group'. Setting this to '0' means 'no group', any other value specified (e.g. 1, 2, etc) will create a 'group' of all wheels that are assigned that number. Most of the functions in the PAW will then effect the entire group when activated (spring/damper changes, gear changes, enable/disable motor...likely others I'm forgetting). Yeah, I really don't understand why stock doesn't include some sort of scaling functions for most parts. The least I could do was solve the issues for wheels while I was working on them Should be quite... physically based... as well. The amount of EC input, and torque output, is all based on standard brushless motor equations. More power output demands more power input, all consistent and logical. Yeah, that is unfortunately nothing that I can solve on this end of the code. Any solution would have to come from MechJeb in the form of special-case handling code -- the same kind special handling code that was written for the stock wheels would need to be duplicated to work with these wheels. Without looking at MJ's stock wheel interop code, I would wager that it would be doable for KSPWheel, but time consuming. Certainly would be nice at some point though.