Nertea

Beautiful! Early 2021.

No, you need to follow the documentation. A new module needs to be added in the config first.

Are you sure? It might be worth checking. It's not installed in your log, and you have a lot of errors related to loading TAC's resource set in there, indicating that the required resources (food, oxygen, etc) are not present in configs.

Why yes, if you use a WIP framework mod you will have to do work yourself. That's like installing ModuleManager and expecting it to turn your game into RO.

This is intended behaviour. The offsets are shortcuts for the root object only - if you modify it with a modifier, the modifier becomes the primary controller. If you want to use offsets AND modifiers, target the lower objects in the hierarchy with the modifier. This seems to work fine for me (tested this morning). I placed a Scale modifier set to Replace, with values of 1, 1, 1 tied to throttle I placed a Scale modifier set to Multiply, with values of 1, 1, 1 tied to throttle As expected, this set the plume scale to 1,1,1 and multiplied it by 1,1,1, so no change. Changing the second effect multiplied the values of the first correctly (halved at 0.5, doubled at 2.0). Modifiers don't have a concept of single, double, etc axis at all, so definitely when using the use randomness function - that's a shortcut to allow easy use of randomness. If you want to use specific, axial randomness, you will use a separate modifier set to multiply, using a curve set to 1 on the axes you don't want to multiply. When using randomness, ensure the editor has appropriate randomness sample boxes set. Default is 0,0 so you won't see any effect unless you change those. When verifying this I noticed a bug where you can't put negative values in there so I'll look at that. I think you really could use some screenshots here, I *think* I see what you mean but it took like 5 minutes of squinting I learned by looking at other people's projects. Lots of source on Git - check out a simple one to get started. I disagree, you're operating with the mindset that all that is available is what KSP gives you. That is not true! I see, so you're realistically looking for a way to lock a transform's position to another transform with a specific offset. That's likely possible. Great! I really suggest you don't release anything until this mod is at least version controlled.

Great thing to try to learn with! I have a lot of projects, the scope of this is staying where it is. Just needs a shader. I prototyped this years ago (a number of modders have over the years), it's not terribly difficult abd should be supported by this system quite well. I disagree, suffice to say that KSP does not implement any of the capability and performance features that Unity's modern systems use. Implementing those would be a first step. Black smoke is definitely possible. You can make linear curves, you just need to use the tangents in the curve editor correctly (the last two numbers). Gimbals, you can already do by parenting the effect to the gimbal transform, unless you mean something else.

In the past (idk about now), RO has focused on surface to orbit and a limited amount of recreation of concept missions. I don't think we were in that bucket. At one point I provided NathanKell with a whole set of hypothetical performance numbers for realisticish versions of the engines and got a similar reaction of ambivalence. Thanks! I should probably add something to the OP or similar though.

It is very easy to author resource distribution configs, and easy to patch distributions for different scales.

I have been working hard on KSP stuff, perhaps too hard but I've made really solid progress on Space Dust, so I'll share some info Goals Make atmospheric and exoatmospheric prospecting logical Allow more interesting and varied distributions Exploration mechanics Add visualizations to help guide harvesting and exploration Distributions Resources are organized into Bands which sit around planets. These bands have shapes defined by distributions - I've written a new distribution specification system that expands on what stock provides. It is now possible to specify much more interesting distributions, like rings, shells, atmospheres... etc. It's also expandable with more distribution types as needed later. Exploration This is where the fun begins. Stock scanning is limited - you get a value by moving a scanner into an area with resources - done. Space Dust resource bands have three states - Undiscovered, Discovered and Identified. Most bands start out Undiscovered, with the exception of atmospheric resources on the homeworld. Exploration causes you to Discover and then to Identify bands - Discovery tells you a resource is present nearby with lower fidelity, unlocking a low-resolution visualization, and Identification tells you everything you need to know. Exploration abilities depend on scanners you use. There are two types of scanners - Local, which includes atmospheric samplers, sounders and similar and Remote, which includes telescopes. Send Local scanners mounted on probes to SOIs you are interested in - depending on the exact scanner, you will detect and identify resources in that SOI. Local scanners could need to actually fly into the resource belt to sample it, or might be more advanced and be able to image it from a distance. Remote scanners can target SOIs with an atmospheric survey, which take some time to complete, but when done will reveal resources around a target. Visualization I've been developing some ways to visualize the resources you've discovered on the map view. Here's a set of resources floating around Kerbin - you can see that we have discovered some ?, and identified Argon and Xenon nearby. Only the Xenon distribution is shown Here we can see all the distributions, including a faded, mystery ? in grey The Mun has resources around it, but you can't tell because it hasn't been discovered yet. Currently the Exploration mechanic is about 90% done and working well. Visuals are at maybe 50% - lots of improvements I want to make. Harvesting is at 0% - fairly simple though so I don't expect it to take forever. In terms of parts, well I have the two FFT detectors done now. I need to complete the two harvesters, and potentially two Space Dust specific parts. Once this is done I can release FFT betas.

Thanks for letting me know. This can be fixed by a relatively simple MM patch. Personally I would prefer that Kopernicus ship such a patch and handle the curation of it as they are causing the break in the first place. As a specific note, this breakage occurs because the switchable solar panel targets ModuleDeployableSolarPanel. If it is changed, when Kopernicus is installed, to target the appropriate module, everything would be fine. The line in question is here.

I think the challenge with those mach effects would be that they are very dependent on the geometry of the plane, making a flexible thing that would adapt to the whole craft would be a towering challenge. Wingtip vortices are best handled with trail renderers for sure. Smoke is tough. Volumetric particles are best, but it is hard to get performance with those. I have some ideas but they're a ways off.

The patch hasn't been updated because the long term goal is to remodel the methalox engines and put them as models in another mod. Been taking longer to get to that than I would like though

Nice work! Are you talking about smoke? This method is not super well suited to that, I have some other ideas on how to accomplish it. It will likely work ok back to 1.8.1. prior to that, the .net framework version change will make it non-functional without a recompile at minimum, and probably a lot more fixes.

moduleID = Wet // This links the effects to a given ModuleEngines engineID = basicEngine This is your problem. ModuleID is the ID of the plume module. engineID is the ID of the... engine. Make sure that all moduleIDs are unique (they don't matter in specifics, just how things are shown in the UI) and that the engineIDs match the engineIDs in the engine. There is an art to this, which involves fine control of how you apply the fresnel effects to the two meshes. It's not perfect, it's the best I can make it at the moment. I continue to try to improve this, but hey, if I liked 100% of how it works it wouldn't be in the Development forum. The Dynamic method will do you a bit better in this respect and we are trying to port some of its improvements to the other shader. Repro steps would be nice, I didn't see any issues with this when I was working on things last night. Glad you're using the tools, at least. Feedback helps improvement.

Can you be more specific? Textures seem to work fine for me. How are you assigning them - in config or using the ingame editor? Perhaps some screenshots of what you're seeing? I have some mode switching engines working fine in FFT. I can check again with a more traditional engine but the basic idea is that the effect is controlled purely off the engineID. Will investigate. That's... honestly expected, the UI is really barely 'good enough', not designed to handle gameplay. You shape things by using the various effect modifiers on the parts of the plume. Again, really suggest you load up an existing effect (the mainsail and LV-N are good examples) to see how this set of modifiers works. Each of the models looks like this: https://github.com/ChrisAdderley/Waterfall/wiki/Bundled-Basic-Effect-Modules The green items are bones that can be scaled and positioned with Position, Rotation and Scale Modifiers. The white items are meshes that can be controlled with Float and Color Modifiers. Unfortunate, those are keyed to transforms that only exist in the restock model.You can still look at the config to see how the modifiers are laid out, or you can adapt it to the weird stock one by changing the ParentName in the config. It'll probably be positioned and scaled wrong though .

The Dynamic shader is not very well documented and fairly new to the project. You should think of each shader as a different workflow for effects. At the moment, I would look at the mainsail plume for a good example of the non-Dynamic workflow, and the Poodle plume for an example of Dyanmic. The Dynamic workflow only works with the basic cylinder model.

That is up to the developer, I'm sure clever MM can account for both. Zorg helped define the spec, he's involved in the project. Eventually, there's a really large amount of work to do that though. I can say that this runs all the plumes in FFT.

It's not really hard to write a thermal simulation thing, but it is hard to try to write one that is robust and comprehensible.

KSP 1.12.x Waterfall [0.10.3] Last Updated October 13, 2024 I make a lot of engine effects, particularly for vacuum engines, which are really poorly handled by a traditional particle system, much less the gnarly butchered version of that system that KSP provides. Smokescreen helps, but when we're talking about really large, fast moving plumes, the number of particles you need to create high fidelity effects is really high. Performance gets low. To that end, I and some others (primarily @Nessus_ and some porcine aviator dude who shall not be named) have created a cool new way to create and drive engine effects. Project Goals Design a framework to create mesh-driven engine effects for smooth rocket plumes Support for atmospheric expansion and all kinds of dynamic effects Cross-compatible with SmokeScreen for adding smoke effects Ingame editor to create and drive effects. Provide a set of template effects for modders to use on their engines. Please note that this mod is a framework it doesn't change anything or provide anything by itself, but provides the ability for you to do things. Screenshots/Videos Here's a few screenshots and videos from development over the last few months (credits to @Nessus_ and @DylanSemrau ) For more, check out this Imgur album or look through the thread Templates A lot of preconfigured templates are available for anyone to use. These should cover most chemical engines in most mods. How to Use Documentation I wrote documentation. Read it! This is a work in progress and I have a bit of trouble keeping it up to date with new features that are added weekly. If you're having issues please review the thread and ask here. Ingame Editor To design plumes, you'll have a pretty fully featured editor to work with. It exists in the game. Downloads Frequently Asked Questions Q: I installed this and nothing happened, what gives? A: Make sure you have mods installed that actually use the plugin. Dependencies (Required and Bundled) Module Manager Licensing All content is distributed under a CC-BY-SA-NC-4 License. All bundled mods are distributed under their own licenses. Download Mirrors Tertiary (GitHub) Issue Tracking and Source Supported Mods You need configuration packs for this to do anything. Currently there are only one; other mods will likely ship configs for this. If you release a mod that supports Waterfall you can let me know and I'll add it here. WaterfallRestock: Provides patches for most Restock and Restock+ engines. This requires Restock. Near Future Technologies: Near Future Propulsion, Spacecraft and Launch Vehicles provide Waterfall configs Kerbal Atomics: Full support CryoEngines: Full support Far Future Technologies: Full support Stock Waterfall Effects: Provides support for stock

I'll look further into this but in your example, if you change a loop 0 part to loop 1, it should bump ALL your loop 0 parts to the next available loop (Loop 2). Loop 1 parts should stay unchanged. I have not designed the heat simulation to be numerically stable like that. I have concerns that would need a lot of testing. I spent many hours trying to logic out how to send heat from one loop to another and it was not fun at all. It is on the roadmap, but nontrivial.

Ugh, so I mean you can do that. Your game might explode: The code handling aspects of that engine has been modified and replaced, and is no longer present in the new plugin Using both the old and the new plugin at the same time will not give you a good user experience[*] I guess you would need to update the config of that part to use the new stuff. That might be nontrivial. * your game will crash

Update with fixes for the bugs reported above Fix simulated reactor throttle and damage being propagated to flight from editor Fix reactor throttle for engines keying off requested rather than actual throttle Fix heat simulation using wrong external temperature Fix radiator display Fix fission engine mode switching for multimode engines

Thanks for testing! This is a fun one, the KSP data field I was using seems to look at vessel surface external temperature. So as you're rising through the atmosphere, this value goes to thousands of degrees, and its used to factor in to loop temperatures. Looks like some simulation values were persisting through vessel rollout, so if your reactor invisibly melted down in the VAB, that was getting persisted to the pad. I'm open to suggestions to make it clearer. Options might include the ability to turn on and off loops, or something? I don't know if those parts are useful, which is why i haven't done a lot of work on the models. The heat sink vs radiator is easy, beyond some bugs. Sinks have max capacity, radiators do not. I see the timewarp bug, but I don't think I've ever tried to fill one up to 100% so I need to see what's up there. The storage temperature is only relevant when discharging the sink, it controls how hot the output is. I could hide it, not really important to the player. Coolant tanks increase the volume. With more volume, it takes longer for a loop to heat up so if you only need bursts of utilization followed by cooling periods, you could use this option with less radiators. The use case for the compressor is ill defined. The original intent was to provide a way to make the loop temp *lower* than nominal, for life support purposes generally. The system has no concept of ordering and I don't want to add one, so you can't increase the temperature of radiators without increasing the temperature of everything. Can't say I have a great solution here. The intention is that this only changes the ID # and nothing else. When ships dock, their loops merge if they have the same ID, this allows you to ensure that doesn't happen (or does, depending on goal). I found a bug with the display, but this is intentional to make design a little easier. Radiator output is keyed to loop nominal temperature, not current temperature. I could go the other way around - i haven't tested the stability of the simulation like this, but the problem with that is that it's quite difficult to know what your temperatures will stabilize at beforehand. I will get through these bugs tomorrow and get some updates out. Thanks again!

You should pretend this new version is a different mod. As I've mentioned a few times, there will be no deprecation, compatibility or legacy parts.

New development version: Compatibility with DBS Electrical display (needs DBS 2.1.8+) Fix for Harvester NRE Temperature Adjuster can now be activated in the VAB and more or less works Added new Reactor rollout window (mirrors NF Electrical reactor window) The only thing that remains for feature-complete-ness is actual models for the 3 new parts. Once that is done, I will start issuing packaged releases.