whitespacekilla

A better Waterfall artist than me will have to tell me if I get this wrong but I'm not aware of a built-in way to inherit waterfall templates. However, ModuleManager allows you to copy and override config nodes easily enough. This actually points out a quirk in many mod introduced config nodes, where they use an identifying name and name it something other than `name`. The MM syntax is simpler if `name` is used (don't have to use `HAS[#theName[someName]]` syntax). Maybe someone knows why authors opt for this.

The NEEDS[!Restock...] qualifier is per part. It can just be left out for parts Restock doesn't change the model on. Are you saying I've misunderstood the architecture and the original approach was not to add effects to any engine when Restock was installed? Or even that Restock adds/removes remodeled engines too often to do this safely? Is it common for Restock users to disable mesh updates for certain engines and then you'd like them to get StockWaterfallEffects applied? I'm missing something here and I doubt it's really worth your time to explain to me but I still feel like we're talking past one another so I'm having trouble letting it go. The easiest way to get started is by using pre-built `EFFECTTEMPLATE` definitions. Waterfall comes bundled with a bunch of them at `GameData\Waterfall\Templates\`. So does StockWaterfallEffects (these are really complicated ones with beautiful, realistic looking shock cones etc.). Pick a template either based on engine type/performance/fuel type, similarity to another engine it's applied to, affection for how the template looks on other engines, or just plain whimsy. You'll add this effect template in your own MM config. Here's a config I made to add a kerolox lower effect template to all Rattite engines (a few clusters are available) in SpaceY/SpaceY Expanded. So, you'll start by applying that cleanup and waterfall module, substitute the template name that makes sense, and either use position and scale from a similar engine as a starting point or zero them out (x,y,z triplets). Then, launch the game (I use CKAN to maintain a "Waterfall Studio" game version with minimal mods installed so it loads fast and I can find the parts I'm editing quickly), start a sandbox game, and put together a silly structure with the engines you want. You really don't need anything but the engines because you can use the waterfall editor to "override" the atmosphere depth and throttle. In flight mode, click the waterfall mod button. It will bring up the currently active waterfall modules (this is why you have to add them BEFORE you try to tune them). From here, you'll be tuning the position and scale (and very rarely, rotation) of the engine effects until they sit at a good looking spot with the right scale for the engine bell they are used for. Be sure and test a range of throttles and atmo depths. Once you have a position and scale you like, there's a button to export position, scale and rotation (or you can note them manually). Either way, you need to overwrite the x,y,z triplets from position, scale, and rotation with the ones you find in the flight scene. Like I said, StockWaterfallEffects contains some beautiful but complex and harder to reuse effects with more layers built in. Once you get comfortable using the templates from the base waterfall set, you might look at StockWaterfallEffects' templates. The in-game waterfall editor will give you a way to interact with the various layers of each effect template, such as turning them on and off, so you can see what they do. Building your own effect template is more complicated but it's basically just compositing simpler effects to get something more complicated and beautiful.

No one understood what I was saying so my communication is most likely the problem here. Moving from StockWaterfallEffects 0.5.0 to 0.5.1 (as seen in this comparison), you changed `NEEDS[Waterfall&!ReStock]` to merely `NEEDS[Waterfall]` on every engine that has a potential Restock model. In effect, you moved from avoiding applying your effects on conflicting models when Restock was installed to applying your effects and assume WaterfallRestock would take care of it. This works fine (if a little wasteful when the MM cache isn't being used) if and only if WaterfallRestock is installed. If the user hasn't installed WaterfallRestock (which I am not condoning or recommending) the Restock engines will get StockWaterfallEffects effect applied to a Restock model, which will be wrong. This could be considered a regression. I'm half-asking if I understand the change correctly and half-arguing that the pre-0.5.1 way to protect against this, :NEEDS[!Restock...], was superior because even if a user failed to install the proper mods, they just wouldn't get Waterfall effects instead of getting the wrong Waterfall effects. I'm not reporting any bona fide bugs in StockWaterfallEffects.

I'm submitting some pull requests for compatches with a few mods (OPM, GEP, StationScience, TST) to your github repo but it appears a little unloved (for one, it doesn't have the latest changes). Let me know if there's a better way to discuss/contribute. It took me a while using this to figure out it was the source of the (much more sensible to my mind) science body multiplier changes I was seeing. It has led to my favorite play-through of all time where the design challenges stay fresh with each transfer window to a farther planetary system. I'm using TST, StationScience, SSPX/R, and DMagic which all add a little science, so I've got the science rewards turned down to 50%. No science labs houserule. With a life support mod, every crewed mission is quite challenging and I've got to send an unmanned suite of missions to new systems before manned. This really effectively complements what you've tuned here. Thanks for producing this!

Have you taken a look at the source repo, specifically the changesets affecting these MM configs? They used to just not apply stock waterfall effects to engines restock remodeled if restock was installed. That seems like the perfect way to handle it. Now they apply the stock effects either way and assume WaterfallRestock will strip them off. Because of this, if you have Restock + Waterfall + StockWaterfall but not WaterfallRestock, you will get meshed up Waterfall effects (meshes that don't match the position, size, and number of engine bells/nozzles) where with the old approach you would just not get waterfall effects on engines Restock had changed (much preferred, IMO). So, it seems like a regression in 2 ways: Applying MM edits to parts that you expect to have stripped away by another mod when properly configured (wasting a tiny amount of load time) Incorrectly configuring waterfall effects on restock modified engines as if they weren't modified The first is mitigated by MM caching, the second is mitigated by the fact that the user did mess it up by not installing the recommended mods. That's why I was politely asking KSJ if there was a maintenance reason to introduce those regressions when the old `NEEDS[!Restock] `system for each of those parts worked just fine.

Good advice. The free time I have is probably better suited to applying fitting transforms for existing templates on mods that haven't gotten attention yet than trying to craft new combination effects for first stage engines. Any chance you can speak to why you changed your approach to applying waterfall effects in the presence of restock? Seems to me like the previous `!Restock` specifier saved work in loading and prevented the issue I've seen a few posters have where they have Restock, StockWaterfallEffects, and messed up remodeled engines. "Easier to maintain and develop" is the only thing I can guess (perfectly valid reason, of course).

I've been applying templates to other mod added engines and have really enjoyed how easy and powerful this framework is to use. So far I have a set of configs I really like for SpaceY and USI, hoping to make those widely available this weekend after some time playing with them. Thank you! In my configuration of SpaceY, I got a little overzealous and started preparing files for the SRBs. I deleted those when I was looking for SRB examples and didn't find any and remembered, "oof, this mod says it's for chemical rockets, I really missed the mark by even starting down this path." THEN I thought about the fact this mod has great configs available for thermal and ion rockets. Reel me in a little. Is this mesh based visual framework a bad fit for the SRB propulsion systems by their very nature (particles might be a better framework) or with some creative/original templates, could it be a worthwhile project? @RyanRising's post about the exhaust effects in KSP2 made me think that air-breathing engines from mods that haven't gotten a waterfall treatment yet should be a high priority for me to target adding effects to...

That's fair. Perhaps I assumed too much tone from our miscommunication. If I write, "the mod 'BackgroundResources'", though, I won't ever mean the mod "BackgroundProcessing". I will always mean the set of folders, DLLs, and module manager configs named in such a way (BackgroundResources subfolder of gamedata, BackgroundResources.dll, `FOR[BackgroundResources]`, etc.) as to constitute the BackgroundResources mod. I still disagree that it's not a separate mod on that naming basis, on it's separate licensing, and because it is included in other mods (at least TACLS, no?). I finally located the source code for BackgroundResources, also. I failed at a combination of google searching and looking at your repos and did not expect it to be at REPOSoftTechKSPUtils. Please forgive my statement saying the source was unavailable. I know you don't support CKAN installs. I myself used to think CKAN was a bad way to get mods but reversed that position over time, so I'm sympathetic to modders and users with criticisms AND creators' rights to support those distribution methods they choose. Many users will find your mods on CKAN, though, and never see your warning. It's more accurate to say that BackgroundResources is a separate mod on which TAC-LS and DeepFreeze rely that happens to be bundled with both if users get them from your preferred channel. Communicating the dependency that way would have probably resulted in correctly configured CKAN metadata. Thanks for producing and maintaining the many high quality mods in your portfolio.

I know none of the information I'll provide is going to change how you operate this mod, nor do I need help getting the mod to work, I've got a local fork that doesn't rely on BackgroundResources now anyway because the source didn't seem available. That said, I'm talking about BackgroundResources. It's a separate mod by all the definitions I'm aware of - its source isn't included with the source of DeepFreeze, DeepFreeze loads and presents a UI and functionality that actually work until you save and load with frozen kerbals without it, it's housed in a different directory with a unique name and matching DLL, and (this will be the most controversial element to you) it's available separately on CKAN as only a "Recommended" add-on for DeepFreeze. That you don't think of it as a separate mod, support CKAN, or include it in the source code repo is definitely up to you but obviously leads to installs that don't have it. I don't see how attempting to talk down to another programmer trying to help one of your users or pretending people removed part of the mod (that appears to many to be 2 separate mods and is distributed through a channel you don't control in that manner) is constructive, though.

It appears from your log file that, much like me, you do not have the mod "BackgroundResources" installed. Some time around the KSPv1.7 update of this mod, BR became a hard dependency (at least if you want DF to work through a save and load). I need to do a tiny bit of investigation before creating an issue and maybe a PR (problem being I'm not as motivated to make it work with BR as I am without...) on github.

I fixed this in a fork once but abandoned it. I was trying to generalize the ability to launch based on what you'd achieved before, very similar to how WOLF simplifies resource generation by abstracting it, I gave up on the UI programming. I also wanted KCT and USI-LS compatibility and those turned into Reflection rabbit holes. The staging never exists in the first place because of the way the vessel is spawned. I don't believe it ever worked. I fixed it by using the vessel spawn code Allista has in AT_Utils as a reference point. See https://github.com/allista/AT_Utils/blob/4d667ac2b2889a710d692b5729c32480fb0f4c79/Addons/VesselSpawner.cs for details. I think `StageManager.BeginFlight()` needed to be called to get it working. I had physics problems with my KSTS spawned vessels then, too, which I was able to fix using AT_Utils as a reference, too. I can't recreate those today. It's possible that other physics plugins like PersistentRotation or whatever plugin I had to help with the Minmus Quake was just exacerbated by how KSTS spawns vessels.

I'm just telling you that's not an explanation. With 100% certainty.

This is not what csproj files do. They just tell msbuild where to find important build assets. Those references don't do anything at runtime. There are some games that only work on the C drive but this is not something I've experienced with KSP or strategia. In copying the files to another location, you did something that fixed your issue.

While that may be just one of many issues, private methods are not a true barrier to use. Reflection allows you to use whatever methods you want, it's not even that hard once you know they're there (i.e. have the source code). There's no way in a distributed assembly to make a method "impossible" to call, really. Private elements are more guidelines than rules.

If you do a careful examination of mod added models and textures, you'll see that the mod added ones are not only higher quality but also better organized, take better advantage of unity and ksp features, etc. I would not count on a daedalus texture added in stock ksp2 saving modders much if any time and I have doubts as to ksp2 being "better suited" to modding just because one of the public facing team members (who doesn't generally code) said it. I look forward to the refactoring they've supposedly done to the physics system, I hope they stop shipping obfuscated code and/or document the interfaces available for modding, and ship a non-horrible UI modding framework. I'd say colonization systems are as likely to be worse than mods already available for ksp1 as not. Interplanetary systems I give a lower chance still although calculating thrust while unloaded would be a big improvement.

It's not a nozzle. It needs a large amount of MW electricity. It will scale its thrust with the available electricity and there's also a maximum due to technology upgrades. To get the listed thrust, you need the maximum listed power and all upgrades.

Cool. I have a mod in-development which would have been pretty in-depth and have been my first serious project using their (somewhat difficult to use) UI toolkit but I've pretty much given up on it since I don't know how well any of that work will translate to the KSP2 (I've heard in some interviews that it's a total, ground up re-write and in others that specific systems got a big overhaul, seems like the guys giving interviews just don't know what they're talking about).

Can't you just use the normal transfer to work around this? I'm kind of on the fence about any but the smallest KSP1 modding efforts since KSP2 was announced.

This is about when I figured out I was going to engage in an argument about joints in Unity with a bunch of people who have never developed in Unity and decided to just go on living my life.

Are you talking about KJR? It works by adding more connections.

VERY interesting. Will you be able to describe the platform/engine, mod support mechanisms, etc.? I didn't think any of that would be interesting because I assumed pretty much the same codebase.

I think the authors of binary system mods and players who have used them would beg to differ. The SOI model certainly can handle binary systems (insofar as it handles anything else, as an abstraction). I'm confident Rusk and Rask will work the same way (with an invisible point mass body representing the barycenter). Edit: there's merit to what you're saying about just ignoring the maintenance of orbits, this is effectively already in KSP1 thanks to some rails inaccuracies that can cause orbital decay even in the patched conics simulation version. Maybe you could design a game such that when you were in a non-hyperbolic orbit, unloaded, fixed conic section orbits are used but active vessels and vessels on hyperbolic orbits (or coming from hyperbolic orbit since last active) obey n-body physics. That said, I wouldn't bet on the devs adding any of this, mostly because system design is so much harder when you have n-body physics. If I was tasked to design systems that would be stable in an n-body simulation, I would probably just steal the parameters of real world systems, I don't know that this approach is of interest to/compatible with the vision of the teams behind these games.

So far as I understand it, this is a problem endemic to unity games. It's difficult (time consuming and not always doable) to use unity's engine and tools to create "perfect joints". Especially in dynamic contexts (like where joints are created dynamically between editable parts...). Frankly, I don't think much will change game engine wise without a total re-write (which I also don't really want to see because so much that was found in KSP1 would be lost in a re-write). I'll buy KSP2 when the KSP1 community starts to fade.

Even though the ship has sailed on ALL of these suggestions if they're already demoing footage, why not add a few ideas for us looky-loos in the forums to scrap about? Modders enhancements: Don't run the code through a silly obfuscator, doesn't protect any IP (your licensing does that), bloats the DLLs a bit, makes it harder for the community to make use of the public facing APIs, makes it harder for the community to communicate to you about bugs, etc. Switch to a standard configuration file format like json/yaml, not a custom format Document at least the data models in your config files thoroughly Provide examples Provide usable, stable UI toolkits and tooling Technical enhancements: Don't allocate so much garbage memory per second Use something like a voxel based drag model (a la FAR) Build calculation intensive systems with more parallelization in mind (no one has CPUs with less than 4 logical cores these days) Load configuration/textures/definitions/other assets and data in a manner that strikes an intelligent, modern balance between memory usage, load times, performance, and stability Drop the breaking ground science deployment and inventory system entirely and/or adopt the KIS/KAS system Automation: Once I've proven some type of mission is trivial by accomplishing some milestone, give me ways to skip it, i.e. if I can put a giant station in LKO, don't make me individually launch small satellites anymore, perhaps a system based on the mass, capacity, and equipment of the stations/bases determines what kind of premium I have to pay to have the vessel I want to ship automatically delivered to some corridor near my stations (I've always wanted to make a mod that does this and have made some progress but haven't completed it) Auto-navigation of rovers so they're useful Automated re-supply at a cost Movement of resources around a well colonized celestial body at a cost Sharing of resources in short range so I don't have to make giant single vessel bases and stations (even if some time has to elapse or special equipment is necessary) Quality of life: KER's features at a minimum as far as information and readouts Better science tracking/checklist functionality Overhaul the action group interface, maybe even introduce some templating (i.e. dynamic specifications like I want re-runnable experiments mapped to this, I want multi-mode engines and air intakes mapped to this, etc) Alarm clock/scheduling system Built in transfer window / porkchop information systems, ejection angle tools visually integrated "Intuitive mode" maneuver node editing More "smart points" on orbits for starting a maneuver node

I like when people are upfront about wanting n-body physics because it helps me spot people who I won't agree with on game design at all. I'd confidently bet KSP2 won't have n-body physics. It's the kind of thing perfect for Universe Sandbox, which isn't really much of a game. I do not have ANY desire to go to my vessels in flight and keep their station. Nor do I have any desire to calculate stable orbits (within the context of accomplishing other orbit sensitive contracts, especially). Nor do I have any desire to refuel craft that slowly use resources for their own station keeping. It's not fun, I don't care, single body SOI is a fine enough abstraction for a game like this.