Jump to content

WarriorSabe

Members
  • Posts

    351
  • Joined

  • Last visited

Everything posted by WarriorSabe

  1. Yeah basically the reason that exists is that Scatterer thinks the settings config is a sunflare, and so spams the log with errors about not being able to find the body it goes on (causing performance issues and making the log hard to read). And so I had to give it a body to attach an invisible sunflare to in order to fix it
  2. I haven't modified them, but in testing it appears they generate in the general vicinity of Dres, just a bit outside of its SOI so they're orbiting Corelian on similar paths
  3. From what I've seen from earlier tests Blackrack did a while back, its somewhere on the order of twice the impact of normal EVE, iirc
  4. I know I'm a bit late but I think that's about it: the contrast and the sorta uniformish spotty clumpiness it has. I think more variation in the scale of structures would help a lot, as well as perhaps some tweaks to the Scatterer integration to blend a little better (perhaps have a little more of the haze come from higher in the atmo?)
  5. Layer thickness will be customizable so you can probably make one that's super thin. Also I think the old system will also be retained for backwards-compatibility and low graphics settings
  6. Take the StrangeNewWorlds folder inside of the GameData folder in the download, and put that inside of the GameData folder contained in your root Kerbal Space Program folder. Installing its dependencies should work similarly
  7. That's fair, maybe I'll just dig through the code to find the api myself, since I frankly have no clue what half the things I use actually do
  8. Also curious, will you be making a wiki like for Scatterer? I've had a pretty hard time trying to figure out how to make configs through reverse-engineering, and a major rework like this seems like a good opportunity
  9. Ah I actually think I do get what you mean, I'd probably have to read the code to see the actual specifics but I've some experience with modulating noise wrt terrain generation and I think I know what you're referring to here. You mention a remap, I presume you keep some intermediate alpha for soft edges. So something like when I do this in gimp I would presume (but probably with a different noise source and with more than just five seconds of effort)? And what I meant was I was thinking maybe the clouds were something akin to a voronoi with seed points that were columns the height of the deck, and the curve determined the spread from them, but you've got something better it would appear. It sounds like the curve then does multiply the values in the map, before being passed to the remap? Also, new question, how will colors be handled? Will they be in the same map as the density (with density in alpha presumably), or what?
  10. Curious, how exactly will this float curve work? Like, what actually is output by the curve to be turned into that by the renderer? My first instinct is it's a multiplier to the intensity in the placement map (which I assume is now more of a density than an opacity), but I'm not quite sure how that'd get reliable results like that. So is it more like, the clouds are generated from columnar seeds, and the curve defines the width of each "nodule"? Just looking to get a deeper understanding of how these're made so I know what I can look forward to people being able to do (not that I have much understanding of how to make base EVE configs to begin with; I'm more curious about the engine internals and possibilities here)
  11. Well, relatively at least - there's still tritium coming out of that (though that's much less of a concern than the alternative), and the actual fusion reaction within the exhaust itself produces massive neutron fluxes that'll turn anything remotely near your engine into radioactive waste itself. Really, the main advantage is that its fuel doesn't want to become a nuclear bomb at the first opportunity. With a NSWR you've gotta fill the tanks with control rods and any leak is catastrophic, while with a LSWR there's no such need. It's also slightly higher Isp due to lower molecular weight exhaust. Downsides are primarily the extra weight of the separate nuclear reactor you already mentioned, but also slightly lower thrust and more expensive duel (lithium-6 deuteride). Basically, it's still just as liable to lay waste to everything around it but the ship itself will be safer, and it also acts a bit like a hydrolox to the NSWR's kerolox
  12. Actually, since you've decoupled this part from the reactor, it will be an enormously powerful cooling element. Think about it - there's no combustion, since it's a thermal engine, and you've explicitly moved the heat source *out* of the part, so all it does here is take heat and put that into propellant, which it then gets rid of. And if you want a whole ton of info on thermal rockets, and probably more than can be reasonably fit into mod mechanics but hey it's good to know where you're deviating from reality at least: To quantify, you can use its thrust power, which is is basically the kinetic energy of the exhaust, over time to get power, and so can be found by one half of mass flow times exhaust velocity squared - if you use kg/sand m/s, you'll get watts. This must be supplied (and is consumed) by the engine, and in this case, that takes the form of heat taken from reactors and such. You'll notice that the thrust power is actually gargantuan - the reason thermal engines need cooling is not because you generate more heat in the engine part of it, but because the reactors it takes to run them are so massively powerful that even just the tiny bit lost to inefficiency adds up. An engine of 10km/s exhaust velocity (corresponding to about 1000s of Isp after converting units) and 10 kg/s of mass flow (multiply by exhaust velocity to get idealized thrust of 10 kn) is eating a half-gigawatt of heat, meaning it needs a reactor outputting a half-gigawatt to run. Generally, what you'll do is run slightly too much fuel through, to ensure that absolutely every bit of heat you can is put into it, cutting the efficiency losses as small as absolutely possible. But of course, this does mean if you run your engine at a lower throttle without first throttling back the reactor, you'll suddenly find yourself with a huge heat excess your ship probably isn't built for. The exhaust velocity will directly determine your Isp - the theoretically ideal nozzle will have them equal, but nozzle design and atmosphere will reduce that (and with it true thrust from ideal). The exhaust velocity, in turn, will be determined by the temperature of the propellant, which ideally will match the temperature of the reactor (but it may not heat up all the way, this is where those aforementioned losses come from). If you pump more fuel through, you'll increase thrust, but with it you also increase thrust power and thus the amount of heat the engine consumes. If you pump too much fuel through and the engine starts to cool more than the reactor can heat, the temperature of the reactor and thus of the propellant will drop, causing the exhaust velocity to decrease until the thrust power matches the reactor power (after thermodynamic inefficiencies of course). And of course with that loss comes lower Isp, as well as thrust, but if you do the math you might notice that Isp drops less than flow rate increases, which means pumping more fuel through than the reactor can handle does still net you a thrust increase, it just comes at the cost of efficiency. Its a square root relation, so if you double the mass flow rate of an engine operating at peak power, you only increase thrust 41%, which equates to Isp dropping to 71% of what it started with. Expanding this info to airbreathing engines gets a fair bit more complex, though, especially once you start really needing to factor in the serious hits to heat transfer efficiency with a propellant starting in the gaseous phase and potentially moving hypersonic. However, while I can't easily provide any full way to determine performance, all the basics will still hold here - it'll dump massive amounts of heat and thus need a massively powerful reactor to keep up with, with all the associated thermal margin concerns, and pumping excess fuel (or intake air) can increase thrust at the cost of efficiency (one important thing to note unique to airbreathing engines is that a reduction in exhaust velocity also corresponds to a reduction in maximum useful speed)
  13. Oh? I wonder why, maybe EVE updated or something; it worked for me last time I checked at least. And, I've not abandoned this, for anyone dismayed at the lack of updates - it's just being done really slowly, since I've got a lot of stuff in my life in the way as of late
  14. Does anyone know of a non-RO patch to add Near Future Propulsion tanks?
  15. Well, the minimum depends entirely on how much lag you can handle. My card's supposedly equivalent to a 1030 and run at least the current mods perfectly fine, it's just a matter of not minding it being at vaguely lowish framerates
  16. Yeah but like might as well go faster, right? I'm not sure how much the GPU accelerates things so even going slower maybe it'll be faster overall
  17. I don't actually know enough about GPUs to be able to tell about individual aspects of performance, I just looked up a comparison that said the GTX 1060 3GB is about 3x better than my MX150 2GB
  18. Oh wow, that's better performance than I expected. My card's significantly worse but based on that it should still be comparable to current performance
  19. Oh, being able to create our own data would be quite cool. For smaller GPUs, I wonder if it be possible to, like, chop the thing into chunks that are each processed in sequence, trading memory for time? I've only got a 2 gig laptop GPU which'd mean it'd need to run at a 4x4 resolution or maybe even 5x5 if you're right and it does scale like that, but what if the map was in like 4 quadrants at 2x2 resolution and it ran 4x as long? Personally at least I don't mind leaving my computer on for a week if need be (tho the computer might). I'd also be very interested if anyone finds a more customizable version of the exoplanet model
  20. That was probably because of Jool - they're trojans of Jool, and as such have an identical sma to it. You'd be best to move them an absolute bare minimum in order to keep the orbital period as near to identical as possible
  21. As far as I'm aware, compatibility is provided on Dreskiller's end. I'd check on that thread
  22. Alright, 0.20.0 is out after adding a couple last minute changes. Visuals now need Scatterer 0.0822 or later, and the skybox now also works with Texture Replacer (thanks to @TheGhastModding for the fix). The Kere revamp is also included, as well as a few other things - full changelog is on the github.
  23. Ignoring how insulting that comes across, SSPXr does have all the container parts you need, and Kerbal Planetary Base Systems has its own version of all the functional EL parts you need except the survey station (which takes the appearance of a hitchhiker anyways)
  24. A preview of the Kere revamp coming for the next update: (expect more craters when completed) Also a revamp of the alternative sunflare, which'll become the new default flare (the anamorphic beam one will still be available, just no longer default) The actual release is predicated on the next Scatterer update however, so don't expect 0.20 to come before then.
×
×
  • Create New...