Lisias

I prefer not to touch what's working, unless needed by a new feature. We already have our hands full, no need to be overloaded by Zero Sum changes - what essentially is what migrating from mesh is without the need of the new features of the MODEL. Since Stock still uses it, I see no reason to think it will be dropped I the next release (if it is going to happen).

sooner or later someone will find a hidden project from them strapping a naval gun on a plane, a blimp or something....

15 minutes to locate where to put TweakScale code. 30 minutes to figure out what would be that code. 3 hours trying to understand why it was not working until I realise that the code was fine, it was something else on DOE the problem 2 hours to fix the DOE problem. Yep. Pretty easy…. Using DOE and a craft using Tarsier on LEO, and two Rockomax tanks scaled to 20M on the LaunchPad. The DOE problem was, essentially, what I had said before: it only knew how to handle the older mesh value (still used on Stock), but didn't know how to handle the new MODEL section. I didn't made a very good job on this one, because I'm just taking the first model value from the MODEL section, and I remember seeing some pretty complex Parts with many models on the MODEL, so these more complex parts will not be rendered correctly. But what we get now is way better than what we had before, so I will call it a day! @Alexsys, I don't know ReStock, so I can't say if this will fix the problem for them too. But I think that at least some parts from ReStock will be rendered now. If you find something not working, ping us (me, the DOE maintainer and the ReStock maintainer) so we can see what need to be done. This will need to be a Team Work, as probably none of us have all the knowledge needed! I'm working on a Pull Request to the DOE's repo now. Cheers! — — POST EDIT — — Pull Request for TweakScale Support: https://github.com/TheDarkBadger/DistantObject/pull/11 Pull Request for the MODEL fix: https://github.com/TheDarkBadger/DistantObject/pull/12 Ping @TheDarkBadger!

The heavy lifting is already done. The whole DOE is already made, I only need to find the right place where to shove a small code that would take TweakScale current settings and apply them on the scaling of the mesh - assuming, of course, that there's not something else hiding waiting to bite our SAS... just realise that only the root part is being drawn here, the other parts of the test craft are being ignored… DistObj ERROR: Could not load part model Squad/Parts/FuelTank/RockomaxTanks/ So, not so easy as it appears. There's something else happening here, some debugging is scheduled to be done later, after work - I think that I found the problem! The code that keep track of the models only understand the older configuration, using the "mesh" value! [Rant about testing - please ignore. ] The mess is that at lower orbits, when it's easier to see something, the linear velocity is too high for the SAS to be stable. On higher orbits, when the linear velocity is slower, the meshes start to colapse due the floats rounding errors. It's pretty entertaining, to tell you the true… Stay tuned, the problem I found above may the reason the ReStock parts are caput - pretty few configs still uses the value "mesh" to read the model!

I was sent by the Krakens to fight NaNs, InFs and Divisions By Zero on the Physics Engine, as well another pestilences that plague KSP as NullReferenceExceptions and Crashes to the Desktop!! Behave, Code, or I will debug you!!! (hummm.. where is my medicine?) It is. If I didn't manage to pull this out if the hat, it would be due lack of better knowledge. The tricky part is to understand how to rezise the mesh by brute force - on TweakScale, it's easy, I just ask KSP to resize the mesh and it does it for me! [Nah, nailed it. It's as simple as it can be!] Nope, because that fix is for Add'Ons that directly depends from Stock Part and Textures, what's not the case of DOE. What it does is, essentially, kinda to reimplement a "mini vessel engine" in order to visualize the craft when it's on Rails, out of the "normal" game engine. What we need to do is to "teach" DOE to understand ReStock parts, more or less the same way I'm "teaching" it to understand TweakScale.

I felt a great disturbance in the Force… I think I know the reason. When a craft it far away, it's "extracted" from the Physics Engine and "put" on rails, a special state where the craft "does not exists" for the game engine, but still "exists" for the KSP engine. When in Rails, the craft follows a precomputed path (as it was a planet) and that's it. When a craft is put on rails, the "craft entity" is saved into a thingy called ProtoVessel - that is where the KSP enging handles these crafts. In order to visualize a ProtoVessel, DistObj had to draw it itself, the line of code that does it is here. If you are curious, this code check the type of part in order to know how to draw it (gears, solar panels, etc, they need special handling when being drawn). DistObj needs to do everything by itself without relying on KSP (as we modders do when writing PartModule). From the relative position of the part related to the root, to its rotation (and more). But the size is not handled at all, see the code: GameObject cloneMesh = Mesh.Instantiate(clone) as GameObject; clone.DestroyGameObject(); cloneMesh.transform.SetParent(shipToDraw.transform); cloneMesh.transform.localPosition = a.position; cloneMesh.transform.localRotation = a.rotation; // No size handling!! So, while drawing, the code finds an unexpected situation when TweakScale (and ReStock) is involved and since this situation is not handled, the net result is the mesh being drawn with a 0 size (or something like this). In the case of ReStock, I'm guessing the problem is the Textures - this code appears to rely on the texture specified on the Mesh, and ReStock changes that in runtime - so I'm guessing that DistObj is drawing invisible meshes (on TweakScale, I think it's drawing meshes with 0 size). I will give this a shot, let's see if I had learned enough about KSP and Unity to fix TweakScale support on it.

I don't remember if I already post it here, but here it goes nevertheless: House of the Rising Sun. Sing it like an Animal, or don't sing at all!

Welding is an alternative, yes, but not exactly the answer the OP is looking for. (not to mention that the thing is not working fine on modern KSPs - besides you still can weld parts on older ones and then migrate the welded parts). What he means is tricky, but can eliminate the need for the welding tool for some use cases, i.e., when you don't mind the physics when no collisions are possible, but want them back when they are possible - once you weld parts, you lose the ability to explode only one part, you lose the whole shebang. What follows is pure brain-storming, without too much care about feasibility. This may not even be the right way to go, but this is why we do brainstormings - ruling out bad ideas before trying them is also a help. On KSP, there's a thingy called "Physics Significance". Part without Physics Significance don't generate drag, for example - perhaps it could be possible to dynamically set all parts of a vessel (but the root) to have no Physics Significance, while giving the root part a spherical "soft collider" those radius cover all the vessel. Once the "Soft collider" is hit, instead of blowing things up, it would trigger a code that would restore the vessel original state and remove the "Soft Collider". I'm not exactly sure how then Physics Significance works - we need to do some research on the matter, and we need to check if we can change it on a living part - but I think this can be promising...

Announce Some Companions were updated! TweakScale Companion for Near Future was rebranded to TweakScale Companion for Post Kerbin Mining Corporation (TSCo-PKMC for short). All the PKMC add'ons will be supported on this rebranded Companion. Eventually. But not the Frameworks, these ones will be supported on a new Companion, currently on the works. SystemHeat is currently Work In Progress, stay tuned, @ProgorMatic! The rationale is that the Frameworks are going to be supported too by 3rd parties, and so users of these frameworks may not have any of the PKMC Core installed! Small updates on the existing patches for Near Future Technologies Adds support for SSPX (Stockalike Station Parts Expansion Redux) Downloads here and in the OP. Happy Scalings!

ANNOUNCE Release 2.4.5.9 is available for downloading, with the following changes: Adds (missing) patches for 3 parts that I left behind: LV-T30 Reliant V2 LV-T45 Swivel V2 Ground Anchor (in Experimental yet) Ongoing savegames still using the ‘V1’ parts didn’t noticed the bork, because these parts still exists on the game (they are only hidden) and are being scaled normally. Only new crafts and savegames were being hindered by the absence of these two patches. See OP for the links. — — — — — This Release will be published using the following Schedule: GitHub. Right Now. CurseForge. Right Now. SpaceDock. Right Now. Being a maintenance release, all Distribution Channels were updated at once.

Well, Tundra Space Center came first. So TweakScale Companion will need a new abbreviation. TSCo appears to be fine.

Moved to the TSCo thread.

(moving from another thread) YES! Everything under the Post Kerbin Mining Corporation brand will be handled by TSC-PKMC. You can help on beta testing, writing the patches may be 75% of the work, but testing them is where I really need help!! In time, @ProgorMatic, this thread is where every TweaskScale support for 3rd parties will be handled (TweakScale itself will handle only Stock and DLCs, everything else is migrating to here). Get a grasp in which we have already done on the OP, and on the posts here - I pretty sure some of them will be of your interest! Cheers!

Hi, there's a beta for SSPEr (and updated support for all NFT) available here. I think this will provide what you want (and more) with less trouble for you. Let me know if you find anything wrong, I plan to release this one to the public this WeekEnd!

A flying boat is already Kerbal enough. Flying around Kerb err the World is yet more Kerbal. Flying a flying boat around the World is incredibly Kerbal. Doing that by accident after telling the wife you are going to be a bit late for dinner is Jebedyah Level of Kerbaliness!!

Point taken. The problem I see is not on making a pull request, is on accepting it. LGG has hundreds of add'ons on his tenure, and some of them are getting behind due his high load of work. My guess is that these runway definitions will end up rusting on the distribution, with some frustration on the users and also the maintainer itself as changes happen. I think we need a better way of handling these situations.

Not the best of the ideas. By doing that, every time he does any change on his add'on, you will need to update yours. Unless you plan to change the format of the RunWay (a situation in which you would induce him to update his add'on), the best line of action is keeping the artefacts that change with the Add'On on the Add'On.

The Mamas & The Papas - California Dreamin'

As a matter of fact, I think it's safer to remove the Near Future Props and reinstall it. I don't know NFP enough to be sure about (it may be some patches to add Props to Tundra), so I think it's better to err to the safe side: reinstall it. If after reinstalling NFP that folder is back, then it's part of NFP for sure! Cheers!

There's no problem on opening a Question for asking support for TweakScale, but I usually respond faster when the cry for help is done there - had you didn't mentioned the thread here, I would miss this one for sure! Thanks for flagging it! Yep, found them: [LOG 22:09:19.125] [TweakScale] INFO: WriteDryCost Concluded : 2466 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 14 Show Stoppers found; 0 Sanity Check failed; 1080 unscalable parts. 14 FATALities, being them: [LOG 22:09:18.905] [TweakScale] ERROR: **FATAL** Part TT.19.IRI.BODY (IRD-66 "Dysprosium" Probe Core) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 22:09:18.906] [TweakScale] ERROR: **FATAL** Part TT.19.NH.BODY (OST-3 "Paneer" Probe Core) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 22:09:18.906] [TweakScale] ERROR: **FATAL** Part TT.19.NH.Generator (PB-TT-NUK Radioisotope Thermoelectric Generator) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 22:09:18.906] [TweakScale] ERROR: **FATAL** Part TT.19.NH.RCS.1 (RC-TT-0101 RCS Thruster Block) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 22:09:18.906] [TweakScale] ERROR: **FATAL** Part TT.19.NH.RCS.2 (RC-TT-0102 RCS Thruster Block) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 22:09:18.906] [TweakScale] ERROR: **FATAL** Part TT.19.NH.RCS.3 (RC-TT-0201 RCS Thruster Block) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 22:09:18.906] [TweakScale] ERROR: **FATAL** Part TT.19.NH.RCS.4 (RC-TT-0202 RCS Thruster Block) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 22:09:19.028] [TweakScale] ERROR: **FATAL** Part TT.19.IRI.BODY (IRD-66 "Dysprosium" Probe Core) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 22:09:19.028] [TweakScale] ERROR: **FATAL** Part TT.19.NH.BODY (OST-3 "Paneer" Probe Core) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 22:09:19.029] [TweakScale] ERROR: **FATAL** Part TT.19.NH.Generator (PB-TT-NUK Radioisotope Thermoelectric Generator) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 22:09:19.029] [TweakScale] ERROR: **FATAL** Part TT.19.NH.RCS.1 (RC-TT-0101 RCS Thruster Block) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 22:09:19.029] [TweakScale] ERROR: **FATAL** Part TT.19.NH.RCS.2 (RC-TT-0102 RCS Thruster Block) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 22:09:19.029] [TweakScale] ERROR: **FATAL** Part TT.19.NH.RCS.3 (RC-TT-0201 RCS Thruster Block) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 22:09:19.030] [TweakScale] ERROR: **FATAL** Part TT.19.NH.RCS.4 (RC-TT-0202 RCS Thruster Block) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 Well, this one appears to be a new for me - I don't remember diagnosing something with the TT parts... I have a problem, however… I don't know who is patching these parts, because MM is being loaded from the cache, a situation where the information I need is not on the KSP.log: [LOG 22:05:02.026] Loading from Cache [LOG 22:05:04.416] Cache Loaded I'm not the only one complaining about it, by the way! [LOG 22:09:19.189] [Filter Extensions 3.2.0.3]: TE.19.F910.S1.Engine duplicated part key in part path dictionary [LOG 22:09:19.189] [Filter Extensions 3.2.0.3]: TE.19.F910.S1.Tank duplicated part key in part path dictionary [LOG 22:09:19.189] [Filter Extensions 3.2.0.3]: TE.19.F910.S2.Engine duplicated part key in part path dictionary [LOG 22:09:19.189] [Filter Extensions 3.2.0.3]: TE.19.F910.S2.Tank duplicated part key in part path dictionary USUALLY I would need the MM Patch log (usually on KSP/Logs/ModuleManager folder), but since the very same parts that borked on the Filer Extensions also borked on TweakScale (or vice-versa), I had a hunch - I think you installed Tundra Technologies twice. And… Ooooh, That's a bingo!!! You accidentally installed Tundra Exploration twice, one on the proper place: [LOG 22:06:02.590] Load(Texture): TundraExploration/Agencies/Tundra [LOG 22:06:02.595] Load(Texture): TundraExploration/Agencies/Tundra_scaled [LOG 22:06:02.596] Load(Texture): TundraExploration/Categories/Bagorah [LOG 22:06:02.597] Load(Texture): TundraExploration/Categories/Ghidorah9 [LOG 22:06:02.598] Load(Texture): TundraExploration/Categories/Gigan [LOG 22:06:02.599] Load(Texture): TundraExploration/Categories/GiganXL [LOG 22:06:02.600] Load(Texture): TundraExploration/Categories/Mk4 [LOG 22:06:02.600] Load(Texture): TundraExploration/Categories/Mothra [LOG 22:06:02.602] Load(Texture): TundraExploration/Categories/Rodan [LOG 22:06:02.603] Load(Texture): TundraExploration/Categories/Tundra <yadda yadda yadda> But another one inside NearFutureProps folder! [LOG 22:05:33.861] Load(Texture): NearFutureProps/TundraExploration/Agencies/Tundra [LOG 22:05:33.868] Load(Texture): NearFutureProps/TundraExploration/Agencies/Tundra_scaled [LOG 22:05:33.872] Load(Texture): NearFutureProps/TundraExploration/Categories/Bagorah [LOG 22:05:33.877] Load(Texture): NearFutureProps/TundraExploration/Categories/Ghidorah9 [LOG 22:05:33.880] Load(Texture): NearFutureProps/TundraExploration/Categories/Gigan [LOG 22:05:33.885] Load(Texture): NearFutureProps/TundraExploration/Categories/GiganXL [LOG 22:05:33.889] Load(Texture): NearFutureProps/TundraExploration/Categories/Mk4 [LOG 22:05:33.892] Load(Texture): NearFutureProps/TundraExploration/Categories/Mothra [LOG 22:05:33.896] Load(Texture): NearFutureProps/TundraExploration/Categories/Rodan [LOG 22:05:33.900] Load(Texture): NearFutureProps/TundraExploration/Categories/Tundra <yadda yadda yadda> The proper one, however, appears to be incomplete…. To err on the safe side, completely remove the following directories <KSP>GameData/NearFutureProps/TundraExploration <KSP>GameData/TundraExploration And then reinstall again the newest copy you have, on the right place this time. Cheers!

7/10 - Kerbals are not humans, stop pretending you are one. You Kerbal. --- Cedo, ergo sum.

I built a deep space probe, to be launched by a Mün Shuttle Mission hitchhiking it to take advantage of a sparing cargo space. (shuttles going to Mün is dumb by itself but, hell, is way more fun!) So I launched the damned shuttle using a reusable booster, then inserted the shuttle into a transmünar trajectory where the external fuel tank was also a probe, able to come back to Kerbin, do a controlled reentry , splash down on chutes and be recovered. It took some days of playing until I get everything right to do it properly without cheating. Then I decoupled the probe after the transmünar injection burn, put it on a prograde attitude, hit the Ion Drive and gone for dinner. Nearly an hour later, I came back and to my horror I realised that I had attached the Ion Engine backwards! So by accelerating into a prograde orientation, I was essentially retrograding! But the burn looks normal, I was going towards a Kerbin escape trajectory… Then I realised that I also had attached the Remote Guidance Unity backwards too… So the blunder kinda worked nevertheless….

I also found the Control Wheels annoying. When accelerating, the Control Wheels "pushes" the car's nose into the ground, and the rear wheels kinda lose traction - pretty annoying on high speed turnings. But without the Control Wheels, keeping the car's tires spinning on the right side of the ground is also harder. If anyone has a fancy controller, I would suggest tying the accelerator to it and avoid using the W/S control keys to avoid triggering the Control Wheel.

Luka, Susanne Vega.

Nope. Probably a new bug on KSP itself. They are unrelated to this problem. You is being bitten by multiple bugs, as it appears. Your KSP has a tick problem! Yep, it makes sense! I managed to fix the craft!!! I managed to fix the E.craft by removing parts and I got lucky, as the first 2 I removed solved the issue. Inspecting the parts themselves, I managed to fix the craft doing: From RadialDrill_4292763876, I removed lines 12633 and 12634: sym = RadialDrill_4292763416 sym = RadialDrill_4292778732 From RadialDrill_4292778732, I removed lines 12373 and 12374: sym = RadialDrill_4292763876 sym = RadialDrill_4292763416 (remove the lines from bottom to top, to keep the numbering consistent as you remove them) And now the craft loads! Was you using any Editor Add'On as Editor Extension Redux or similar? Otherwise, I think we found a (new) bug on KSP itself, it's messing up the symmetries somehow….