Sage
-
Posts
136 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Sage
-
-
Hello Sage, do you have any public reference material from which you worked out all the components of that engine? It would go well in the Engineer's Handbook for Modders sticky
Nope, actually I used information I found in that incredible book about engine design you linked there, plus looking at photos of the real things that you can found searching on google and wikipedia
-
Thanks everyone for the kind worlds
Wow I love it! Needs RO config :3I play with a RO-like install in 64* kerbin so I will probably do one when the new RO will come out. Other than that if the RO crew wants to use this in the mod they're free to do it, but I don't know if it fits the bill of being a RL engine
Wow your work is stunning Are you planning to do more ?Possibly yes, I've several other engines planned, but I've also several exams in my way. Anyway the next one should be an expander cycle engine for vacuum use with extensible shroud.
No sound but look great.Strange, it should be referencing stock sounds, and it works on my machine. Can someone else confirm this bug?
And BTW, if someone wants the .blend or the unity project file, or even an explanation on how I got stuff working just ask!
-
Just a quick first mod that I did for myself, but I thought that someone might find it interesting so I decided to share.
It is just an engine, with a bulkhead of 1.25m but with a thrust intermediate between the skipper an the LV-30, and a better ISP in vac, but lower at sea level
https://mega.co.nz/#F!3s0hwAIA!FAeybc3a-SC3VReaEb2cjw
drop this folder in your gamedata
INSTALL HOTROCKETS IF YOU WANT TO SEE ANY EFFECT, SINCE I REFERENCED NAZARI'S EXCELLENT WORK TO MAKE THEM
While it's not based on any particular engine, I've tried to replicate RL component and to design it by replicating piping that you see on the real stuff. Below there are the flow diagrams that I sketched (with elite paint skillz) to check if everything was modelled correctly:
you can see it's an open cycle engine, with boost pumps pushed by the high pressure fluids at the inlets and a stacked, direct, back to back turbopump design.
The fuel flow is used for active cooling, both in a descendent branch that is then fed back to the injection plate, while another part goes directly there while passing from the throat. A small quantity is used to lubricate and control the gimballing pistons and dumped as needed
Talking about pistons, the gimballing is animated correctly with flexible inlets as well:
The emissives are modelled somewhat accurately, by superimposing a map of the internal heat to a map of the cooling of a determinate part:
eyecandy render in blender
in game. the emissive are on the gas generator as well
License since I need one is CC-BY 4.0 International
-
Having consequences is a good idea, yes - you just need to be careful about the what and how. Your example with the boiloff causing vapor plumes is pretty good - not realistic, but quite suitable for a game (especially a lighthearted one). I was arguing against blind realism for realism's sake, not against implementing real concepts in a believable way
The aero thing can probably be argued, I found that especially planes got more intuitive and controllable. I also think that "my plane/rocket must be aerodynamic" is much more on the forefront of player's minds than "my plane/rocket needs to reject excess heat". But perception plays a big role in these things, and I suspect this perception would differ based on previous exposure to FAR...
Sorry I misunderstood your post then
I'm a great fan of borrowing from RL what we need without making it just for its sake too. I guess it comes down to "believability" in the end.Also I was referring to FAR, in fact I'm already playing with nuFAR installed. In stock I can't get my hands on the stability derivatives, that, while is it arguable that presenting them as hard numbers (actually the green/red is wonderful) and with mathematic description only could be a bit unfriendly, they are a must to build a plane, and once you got in a mindset that certain ones affect certain maneuvers they are pretty straightforward and fun to optimize.
Another thing that comes to mind about having something modeled against RL physics but with concession to it are radiators and engines that glow with their temperatures. It looks badass, and the first lifter engines overheat put the attention of the player on the fact that heat exists in the game, without hard consequences since the stage is jettisoned early. What is missing now is the temp readouts on parts right-click menu, to further cement this idea while in space too and to give a feedback before everything is in the red zone. Presenting the first radiators and insulators with the nuke engine or shortly before while giving hints in their description on how heat flows could be a great way to ease the player into thinking about heat management.
-
@Streetwind
While I agree with the theory of your post, I disagree that heat mechanics cannot be presented to a player without making them understandable. Stock gameplay is famous to hide information from the player -and I'm still amazed on how they managed to get the orbit thing down right (and still I think that no neophyte ever got docking right without a tutorial) . If we use your reasoning the new aero should be axed in favor of the old one, since they aren't explained at all and one was at least simple, while the new one is often unpredictable also in regard to RL.
Heat mechanics are actually much more straightforward to people - thermal mass, conductivity aren't really known by this name but a lot of people have an idea of what they are. What Squad hasn't done right is telling the player that this system exists at all, and it is a shame since it can give a new, fun challenge in building spacecraft, even in non-transient scenarios. That don't work because squad hasn't tweaked values at all initially to allow equilibrium points inside the max temperature range, and it hasn't given us critical parts needed, like radiators and insulators. Now that Nertea is adding those, along with tooltips in the VAB to signal what parts produce heat and dissipate it well (every part should have it, like the mass reading), he is having the problem that large ships ends up being the radiators of a reactor, and bumping up the heat production to fix this put in danger small ships. In the end, instead of pushing the player towards the "correct" assembly - a ship with a hot part with radiators and heat sources insulated from the cold part, the mod is juggling to accommodate every possible design.
Now, I never minded Nertea not adding boiloff - it was an unnecessary complexity where there was no need, since heat was modelled poorly and it had no integration with NF reactors. However, now that we have a "realistic" simulation environment the mod ends up not conforming to reality and our expectations of "need radiators for reactors" because large ships act as one - and people were indeed surprised that the tanks could tolerate high temperatures loads, not that the heat was flowing all over the spaceship. So, borrowing from real-life a mechanic that force the engineers to insulate the hot parts from the cold (and Nert has given us an insulators that works wonder!) could prove useful. I don't say it will solve all the problem out of the box, or that it will actually be fun in game, but now there is a reason to try it.
Oh, and again, delivery of the info to the player, and a more simple modelling to avoid unnecessary complexity can be done easily. Initially, give to LF and OX the same boiloff rate, so they keep the ratios intact, make boiloff start at a critical temp (not realistic, but this give the players an hard limit and we can have the temp bar popping out when we reach this) and add RCS effects and sounds to the surface of the tank, that start appearing when the temp reach the critical point to give visual feedback that something is wrong.
If you can tell me on how liquid boiling, a common sight in everyday life (people even know that during summer some of your gasoline disappears if you don't use your car), presented in this way is less intuitive that plane matching I'll call myself wrong.
-
Yup, and it's pretty much ready to go, their's a few things I'd like to clean up/polish and add before it's finished. Unfortunately one of those unfinished things are the pruner scripts, but those will be added in a little bit.
Fair warning though, HotRockets and Stock Revamp are having occasional fits with the RT-10 (had to change the FX transforms).
just an heads up, the RT-10 seems fixed (for me at least) with the latest Hotrockets
-
Ehm, this is pretty weird and could be my browser acting up, but I was on KSP store front page when I saw this:
I remember seeing those elsewhere, and in fact are one of Nert's first models (at the very beginning of this thread!), so, this beg the question, how exactly they have ended up over there?
-
@Nathan wanted to ask you about emissiveConstant. While tweaking the NERVA to make it non-explosive I've made something weird. First, I toned down the heat conduction to other parts to simulate cryo isolation, and then I started searching for a way to simulate cooling, that in this design is obtained by the hot fuel leaving the engine. However the engine doesn't have any simulation of something like that, (convection seems to work only in the atmosphere) and I decided to bump up the emissiveConstant to 1.2. While it is a physical abomination it is the only way without a plugin that I found to simulate this behavior within sane working temperatures, and indeed an engine dissipates more heat than simply from blackbody. There is a saner method or am I stuck with this?
-
There's no real need to model such a thing - you can just abstract it and set the engine heat production lower. Because that would be the end result anyway, and none of the heating/cooling is actually visible to the user.
I've made some tests and this is not true. Thanks to the new heat system you don't want to tweak the heat production (which is fixed and doesn't vary with the part temperature, which is the factor that determine when a steady state is reached) but the conductivity and the radiation constant in the .cfg. An engine as low conductivity since you don't want that heat to leave the engine up the stack (but if you want to give more option to the player this can be left unchanged and a separate part with low conductivity can be made) and an high radiation which abstracts both the fuel leaving the engine and blackbody radiation. If the parameters are correct the engine will get hotter and hotter, even in "hoverheat" range until the radiation flux balances the heat production. Heat production in the end only determines the kinetics of the process: the higher, the faster the part will reach the critical temperature. It's easy to make passive radiators too, they are the same but with high conductivity and no heat production. What's not possible to do is an active heat exchanger, which needs a custom module. I think it would be suited for NFT, a simple inline part that consumes EC and sucks heat from its neighbors. Attach passive radiators to it you've got yourself an active radiator
Hopefully this will be useful to decode the new thermal model, Nertea. If you need other tests just ask!
-
Thanks for the work Starwaster
That would be true for passive cooling, for active cooling it can be at ambient or even below, or at least any contact points can be.I always found the overheating engines thing odd. Why would you design an engine that can't survive it's own heat. Ok I can understand it for when you burn an engine for longer than it is designed to, but a NTR with its low TWR is, or should have been, designed for really long burn times. And I don't think it should transfer heat up the stack at all, any contact points could be cryogenically cooled by the fuel flow.
Eh? It's not dead, it's still amazing and will be more so.
Well, NTRs like the NERVA are cooled passively by transferring heat to the fuel, and they work properly because the core is hotter than the surroundings and the cooler is dumped to generate thrust
All engines tend to have overheating limits, they are usually tailored to the mission profile and you can reach a steady state in which the heat sorce (the core) and the sink (the fuel flow and the radiation from the nozzle) are in equilibrium. This is not possible to emulate with KSP current system, since a part can have only one temperature and all those pieces are one.
There are two solutions:
- letting the engine produce heat and give the player dissipators as a separate part, while maybe adding an inline heat breaker with low conductivity that shields upper part of the stack
- splitting the core and the engine nozzle into two parts to model them properly, but this causes problems on how to make the module engine work and will take an intermediate dummy resource, as I am pretty sure that engines can't run on LF+heat
EDIT: disregard the above, actually radiation in stock is indeed proportional to the temperature, so by tweaking the heat conductivity and radiationconstant in the engine .cfg is it possible to make an engine that reaches a steady state at a temperature inside its max range
- letting the engine produce heat and give the player dissipators as a separate part, while maybe adding an inline heat breaker with low conductivity that shields upper part of the stack
-
Kinda have to wait for a Firespitter update, actually, as I'm just tacking LH2/OX fuel modes onto the stock tanks for now. Pretty much ready to go otherwise.
I'm surprised on how a similar functionality isn't stock yet, especially since the LV-N now uses only LF.
-
I will say that nuFAR is awesome and should be out in a day or two. Currently I'm waiting on a stripped-down parachute module from stupid_chris (who was gracious enough to offer one) to replace stock behavior. For obvious reasons, I can't release a FAR version that results in pods impacting the ground at 180 m/s. Also, I'm too sleepy to make a good judgment call about its release state.
For those wondering exactly what nuFAR / voxelFAR / vesselCenteredFAR does compared to previous versions, it basically does away with the part-centered operation of the previous FAR versions (the same behavior that powers NEAR and newStock) in favor of a vessel-centered approach. Instead of the part-centered complications of determining the interactions between parts (which are never done exactly right) it'll create a voxel model of the vehicle to work with, like these guys:
http://i.imgur.com/th6Jd6z.pnghttp://i.imgur.com/fkxx9ON.png
From this, I can get a lot of data about how the vessel will behave in flight. Most importantly, I can implement a long-awaited feature: area-ruling. Basically, it's a requirement for transonic and supersonic flight that states that for minimum drag, a vehicle's cross-section must vary smoothly. And very small changes in cross-section can have a surprisingly large effect on transonic and supersonic drag. So for ease of use, you'll get a nice graph of cross-sectional area over the vehicle so you can see where to mess with things:
http://i.imgur.com/L3ZcDkV.png
The yellow line is the 2nd derivative of cross-sectional area, which actually goes into the math behind drag. Green is obviously cross-sectional area. Transonic area ruling consists of fiddling with the cross-section curves until you smooth out the curve to get minimum drag. For obvious reasons, some people will find this unfun given the limited design choices we have for shaping things, so there are difficulty options that include various multipliers to the total drag and smoothing functions for the area to deal with the noisiness of the voxel model itself. But to give you an idea of how this makes things go, getting supersonic is an exercise in flying through a brick wall that may tear you to shreds. I've actually had to throttle down near Max Q to prevent a very nasty, very large rocket from coming apart and destroying itself.
Besides that fun, the voxel approach also allows better resolution of body lift, which can give bodies their proper forces, rather than a simpler approximation from parts. Another benefit of the voxel approach is that cargo bays and payload fairings are emergent from the system. Rather than being defined top-down like in FAR, NEAR, or newStock, any collection of parts in a hollow arrangement will be tried as shielded from the airflow. Although the current wing model is the legacy oldFAR wing model, I also expect that the voxel approach can be used to calculate wing shapes and provide a much more accurate model of the wings as well as the fuselage.
So, yeah. Enjoy newStock for now or stay on 0.90 and keep oldFAR. nuFAR will be out soon, when I will battle the demons of what version to give it.
This is incredible :Q_
Eagerly awaiting nuFAR
-
thank you for the update, the stock fairings are a big delusion for me
Note that I'm also going to add stock-alike fairing base with part-less sides, but without that manual construction. Instead, they'll shape automatically based on attached payload and you'll be able to manually override size parameters like now. Plus switchable textures and shapes for the sides.
Can I advise you to not lose time with that? One of my main gripes with stock fairings is that all of their mass is in the base, as the side is massless, and ejecting the fairings have no advantage whatsoever until you drop the base too. In the end it's your call, but I don't know if it's worth to make something that works like stock and is just going to clutter the part list
-
http://i121.photobucket.com/albums/o222/tatersw/KSP/apollo.jpg
http://infoscience.epfl.ch/record/200444/files/thesis_ermina.pdf
Simulation of Apollo reentry.
I think the attitude might actually be closer to right than I thought… it's the shielding modeling that is wrong. They use a ray-trace, right? The shock heating is far more complex than that, so they either need to fix that, or alter the preferred orientation of the pod.
Sorry to interrupt a bugfixing thread, but the mk1 pod "stock" reentry attitude is incorrect and resemble the apollo reentry by chance. In that case the pitch was maintained low thanks to a CoM offsetted from the central axis with unsymmetrical distribution of hydrazine in certain side tanks. This allowed the pod to generate more lift and have a less steep reentry and splasdown in american waters of the pacific ocean, but it is not required to do a reentry and the CoM was still very low. If heatshields have mass (use flowerchild patch) you can replicate this with some monoprop side tanks. The mk1 pod with heatshield has the CoM too high and is way more unstable.
-
Primed for release! Well, maybe tomorrow.
man, you are an inspiration! Couldn't work on my project but you gave me an urgent urge to do so. You are waaay too good
Can't wait to get my hand on those, they are better than 1.0.
-
Curious then - what are the two large pipes down the side of the Vulcain 2 then? I assumed it was turbopump exhaust.
I had to check around myself, too, but that was the vulcain-1
while the vulcain2 is closed off, and the loop actually dumps the exhaust in the nozzle skirt, so I suggest to scale it down until it touch just barely the main wall (hopefully it won't affect UVs but maybe the AO map only)
-
Those textures looks incredible! I'm actually modelling an engine myself and I'm going at 1/10th of the speed
, and let's just say that the experience has boosted my respect for artists like you quite a lot!NathanKell wanted to know if there were transforms on the exhausts. I'll send him here to explain. Might have something to do with adding HotRockets/RealPlume effectsThat's probably what he means. You need to put a transform (like for thrust) under the exit of the turbopump, so people can add an effect (or even thrust for gimballed exhaust) to it. Naturally only open-cycle engines have this thing, and not even all of them, since some of them like the j-2, the vulcain-2 (but not the vulcain-1) or the f-1 dump their exhausts into the nozzle skirt.
-
I see what you did there.
I made this config in two minutes so it doesn't look very good and the color and atmosphere height are way overdone but here you go:
obligatory album music
That green sunrise/sunset is perfect. Magic of wavelenghts
-
Yay! I have never managed to work this fast consistently before. You are all reaping the benefits of an unprecedented amount of motivation.
Last thing for today: some FX tests for the RS-68. I really like how they turned out (not really realistic, I know, but I wanted something badass
). http://nertea.the3rdage.net/ksp/engineFXtest.jpg
What do we think? Yea? Nay?
Well, it's somewhat realistic if you use smokescreen and get rid of the star when the atmo pressure drops behind a certain point
But yeah, they look pretty badass
-
Wow, those are fantastic!
-
Nevermind you guys, I figured it out
http://i.imgur.com/teABsMf.jpg
now to make something really amazing happen with this depth buffer...
Oh, wow, are you going to add haze? You are doing an excellent job
I am actually amazed no one has thought of doing this before.
I'd say SQUAD should have done this long time ago...unu
-
Haha, this is my fourth run at the look constraints, and I get better every time. Also see the new 3.75m orbital engine in NF Spacecraft (though it's harder to see there). Colours plus AO generally gets a model at least 50% of the way there
. I didn't notice there at first! It's one of those things you spot better in motion. Nice work
The GE-N 'Liberator' Gas Core Atomic Rocket Motor!
-
I said this would start happening ~March!
http://nertea.the3rdage.net/ksp/gascore.png
Texture's pretty WIP, just colour, but fancy gimbal is all good.
HYPE!
And trying your hand at lookatconstraintFX, I see. Textures already look pretty nice
-
Has anyone else been experiencing an issue with this mod and Deadly Reentry where all the parts attached to the Mk 1-2 pod will burn up? I'm using the radial chutes from RealChute (which burn up instantly) and the docking port provided with the mod (which eventually burns up).
Edit: The pod itself explodes too eventually. The only thing I think that could be causing this is because I'm not using a heat shield, instead I'm relying on the ablative shielding of the pod itself.
Edit2: Yeah, looks likely the problem is the pod still needs the heat shield. If so I have no idea why it also has ablative shielding, unless that's the error Module Manager keeps putting up.
That's because the pod has an integrated heatshield, so it is its own heatshield and the temperature of all the capsule will rise instead of having a cool capsule and an hot shield separated. This is why I asked to Ven if he could make the Mk1-2 pod without the shield (or at least an alternate) since it would also resolve any incompatibility this mod has with the SDHI Service Module System mod
. 
[WIP]Somewhat detailed engine
in KSP1 Mod Development
Posted
Only 5k tris, I think I've decimated it fairly well
(more than most stock models, but I've played with mods that have pieces in this range. And in ksp part polys tend to add up only to relatively small numbers compared to most games, and the biggest performance hit is usually the ground of the planet you're on)