Lisias

ANNOUNCE Release 2.1.0.0 is available for downloading, with the following changes: Preliminary version under Lisias' Management No new features or bugfixes. Yet. See for the links. — — — — — This Release will be published using the following Schedule: GitHub. Right Now. CurseForge. Right Now. SpaceDock. Right Now. The rationale for the scheduling is to avoid confusion by publishing things into the Mainstream without proper announcements.

Hi, guys! From now on, and under @TheDarkBadger agreement, I'm the New Management™ for DOE. New thread: New things are going to be implemented (hopefully without new bugs!). This include ReStock, @Alexsys! Stay Tunned!

As from 2021-0930 and under @TheDarkBadger agreement, I'm the New Management forDOE. From now on, it's all officially my fault! (again) In a Hurry: Current Release: 2.2.0.2 for KSP >= 1.3.1 (2024-0803) Works from KSP 1.3.1 to 1.12.5. really! IMPORTANT read this post before updating! Announce for 2.1.0.0. (2.1.1.1 to 2.1.1.4 were experimental releases) Announce for 2.1.1.5. Announce for 2.1.1.6. Announce for 2.1.1.7. Announce for 2.1.1.8. Announce for 2.1.1.9. Announce for 2.1.1.10 (Experimental). Announce for 2.1.1.11. Announce for 2.1.1.11r2. Announce for 2.1.1.12. Announce for 2.1.1.13. Announce for 2.1.1.14. 2.1.1.15 wasn't announced. Announce for 2.1.1.6. Announce for 2.2.0.0. 2.2.0.1 was withdrawn. Downloads on GitHub (and KSP-AVC users). on CurseForge . on SpaceDock . Description: Distant Object Enhancement /L is a visual enhancement mod that makes objects realistically visible over large distances. BASIC FEATURES Flare effects for planets and nearby satellites, properly calculated by size, distances, phase angle, etc. Flare effects are colored for each planet, which makes for easy identification. On-rails vessels up to 750km away are visually rendered (no intensive physics calculations necessary) Background stars dim when looking at the bright surface of a nearby planet, just like in real life! If you have blizzy78's Toolbar plugin, a settings window is available with several options to improve performance or tweak visuals. Full compatibility with custom planet mods -- with flare color definitions included for Real Solar System, PlanetFactory, and Alternis Kerbol. It is the follow up from TheDarkBadger's Distant Object Enhancement Continued, that by itself is the follow up of MOARdV's Distant Object Enhancement bis, which is the follow up of Rubber Ducky's Distant Object Enhancement. Support: I need help in order to proper help you. Open the spoiler for instructions about how to get support:

The HTTP Certificate had expired. Click on Advanced and then tell Chrome you want to access the site nevertheless. You will have to use an Administrator password, if memory servers me well. [My bad, you are using Chrome - what I said works on Safari and FireFox. Here you will find instructions about Firefox. If you can't use an alternative browser, clicking on my link below is your best option] [My bad again - the certificate was said to be good, see below. It was a bork on some devices due am old CA (or something) from Let's Encrypt being revoked). Alternatively, I keep a personal mirror here: https://github.com/net-lisias-ksp/ModuleManager/blob/Archive/Archive/KSP18/ModuleManager-4.2.1.zip - using the HTTPS certificate of github. This is the very same file available on the original URL, but you will have to take my word on it. (don't download anything else from that repository, everything not on that specific folder is experimental, 99% of chances you don't want to use it). — — On a side note, why such a important piece of software doesn't have a Nice Entry™ on SpaceDock and CurseForge is beyound me.

This is one way. Another is having to scale them. I have a personal mantra: do not automate what you don't master doing by hand. UbioWeld is, essentially, an automator: there's nothing on it that you can't feasibly do by hand (it's a part generator, in essence). Create a part merging two wing panels. Then merge two fuel tanks. Then merge a fuel tank and two wing panels in symmetry, and so goes on. NotePad++ to the rescue. Essentially what you need to type to make thins work is what the tool will need to write too.

Ouch… That's bad. Dude, I don't have very good news for you. The Silicon Shortage is not going away, at least until 2023 as I'm reading. Now it's not the Pandemics, but the consequences from Pandemics - China, our currently main supplier of chips, is facing now controlled blackouts due lack of Electricity, and some factories are being hit by the energy rationing. Not being bad enough, now we are facing a shortage of passive electronics components (capacitors, coils, etc) that are also badly needed to tie up all that silicon together. This time, the problem is the raw materials' supply chain, the fabrics that are working are not receiving the raw materials due problems on the Global Transport. Pretty messy. Unless something changes (and a lot), or unless my sources are wrong (we can hope, at least), the MSRP will not drop in the near future. It may even rise… So I'm afraid you are going to burn some serious money on a new GPU - unless you are willing to risk something on the second hand market. There're some relatively decent offers out there (compared to the absurd prices of the new cards), but there're also some risks - China had shutdown a lot of criptocoins miners, and they flooded the marked withe their now useless GPU cards. They are used, they are a bit beaten, but still in working conditions - there's a FUD telling that each year working on a mining farm reduces the GPU's performance by 10%, but this was disproved. But this doesn't means that the cards will be in mint conditions, some will probably need some workmanship (as replacing the fans). In a way or another, we (yep, I'm looking for one too) are between a rock and a hard place.

Because people are speculating on using SS to bring things down. And I'm argumenting that the descent cargo capability is way less than the ascent. Yep. But the heavier the vehicle are, harder is for the fins to do their job timely (if at all, too much weight, too higher terminal velocity, way harder for the fins' actuators to work!!). You see, I'm not disputing the technical viability of the vehicle to land. I'm disputing how much cargo it can bring down from space.

And as a consequence of such feature, the descent cargo capability of the vehicle is hindered, and this was the whole point of my argument that started on the following post: Yes, it's a big deal because it impacts negatively on the cargo capacity of the vehicle. If I'm going to need 20 extra tons of fuel on landing, this means that I will have 20 tons less cargo capacity available on the ship - both for ascent and descent, being this the whole point of my argument: you can't bring down the same weight your vehicle can send up. And in the case of Starship, this difference appears to be pretty significant.

But such L/D on subsonic speeds will not hold, and the thing would fall as a rock. Not to mention that the damned thing still needs to land! The Shuttle could fly into an airstrip and land on her wheels on it, again thanks to her wings that would be working to the very end. The SS needs to do a flip and land standing on her feet - what means that the total weight at landing must not exceed the available thrust (and maneuverability) from two engines - otherwise you would need yet more fuel on landing, what implied on less payload on descent (and on ascent too!).

A boat with tracks. Definitivelly something I would had done with the SMCE naval add'ons!

But have no doubt that these huge wings helped a lot on increasing the descent cargo capability of it!

Both. I don't remember code for B9PS on the time I gave this a try. You are going to have a hell of a crash test course, my friend! You will need to understand how Modules works too, because you will need to know how to "merge" them - you will sum the module's values, or you will keep two modules, each one with its own values? (See how multi-mode engines work!). I'm pretty used to these situations due my tenure on TweakScale, and I can tell you that the mess can be a bit daunting at first - but it's manageable once you get a grasp on the thing - and welding is not a runtime flyingtime action, and this make things extremely easier. From the many reasons for not taking over this, this one is the biggest. I'm a professional, and under the U.S.A law, doing pro-bono work is also a commercial activity (as you are promoting yourself, and promotion is a commercial activity). This is not a problem on my country, but Forum is under USA legislation and, so, I need to follow these rules while publishing things here. And there's nothing it can be realisitically done except by starting over from scratch, as it's absolutely unfeasible that we could reach every single committer on UbioWeld and ask him for relicensing the work (not to mention people that helped in other ways, as testing and documenting and bug reporting). Starting from scratch while trying to avoid doing things the same way (to prevent copyrights strike downs) ended up being too much of a problem for me at that time, as I already had my hands full with TweakScale (and I still have - I didn't finished everything I want to do on it yet. )

Drag, not lift. The Space Shuttle managed to get way less heat and stress (proportionally) than a hypothetical Mercury style capsule of the same size because it could control how fast it would sink in the atmosphere by using lift and then staying a bit longer 'up there' where the air friction is sensible less. Time is the key. You don't want to dissipate all that speed at once (ask the few Cosmonauts that had to do a ballistic reentry). But the heavier you are, more drag you will need to prevent that. But there's a limit on the size of the fins you can attach to SS. It's not only the weight of the fins, but also that hydraulics to move them.

Nope. The descent cargo capacity is usually way less than the ascent! You forgot a 4th constrain. Time. When you ascend, the vehicle has about 10 minutes from launch to orbit, only about 2 or 3 inside atmosphere on the initial stages of flight when the speed is the lower. When you descent, you need to dissipate almost the same amount of energy in about 2 minutes (taking Mercury as benchmark - the Space Shuttle had wings, SS does not!) - inside the atmosphere. The amount of heat and stress the structure needs to withhold are considerably higher than on ascent. So this affects the payload. If (I'm guessing) the descent structural stress is twice the ascend, then the payload to descend will be the half - unless you oversize the vehicle to allow this - but by then, you are wasting fuel on the ascend due the extra structural mass. (and I'm ignoring the particularities of the vehicle - since it will enter atmosphere belly down, it need to have the CoM cautiously positioned, otherwise the fins will not be able to keep it on the needed attitude and the thing will burn up - so, without the fuel on the tail, there's a well defined limit of how much mass you can carry down on the nose without having to add some ballast somehow on the fuel tanks).

Oukey so. Since I already sink my teeth on it, I'm in. We will proceed on PVT! Cheers!

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.