Tallinu
-
Posts
153 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Posts posted by Tallinu
-
-
The third cargo arch is put in the wrong height (lower than it should) due to those nodes size/snap mismatch again.
Why are you even attaching things backwards like that? I understand that you're trying to make a fully-surrounded space but the fact that KSP allows you to make parts physically overlap doesn't really mean it's a good idea. Your joints are going forward, then back, then forward and creating a much longer series of much springier connections, like a twisted up slinky.
O O-O
| | |
| | |
| | |
| | |
O-O O O-O
| | |
| | |
| | |
| | |
O-O OAny kind of bending force on that sort of construction is going to be three times as bad, making the craft far more fragile and harder to control. Even perfectly straight thrust would make it all compress (or stretch) three times as much.
Maybe a couple more versions of these parts could be put together, with this full wraparound look, to avoid "needing" to do this?
-
This gives mass ratios of 8.717. Not quite as good as cylindrical tanks, but I suspect that's the extra details causing the inefficiency. Still, much better than the previous 4.128
Hooray!
-
Do you see any blue lines coming up from the fairing base? A screenshot of what you're seeing would be helpful.
It's possible the parts were installed but the plugin isn't working or installed properly...
-
We've talked about redoing the decouplers, making them a bit taller to reduce the node issues.
The larger one is nearly perfect, it just needs to have the node which attaches to non-US-core components (such as a command pod) raised so it's nearly level with the rim of the model. As is, any normal cylindrical part "sinks in" quite a bit.
The smaller decoupler looks like just a downscaled version, which doesn't seem to fit the smaller core as nicely as the larger ones go together... That one does seem like a good candidate for a redo, although the shape of the rim still looks nice.
Speaking of the larger core though, it's an amazingly detailed model... Even in places where that detail seems practically wasted, like the "docking ports" on the top and bottom. It's beautiful - and only ever seen in the VAB or briefly once that decoupler fires. So many polygons going unappreciated...
I do love the implied crew tunnel, but most parts just have texture art for the hatches...something to consider if you're ever in a must-lower-poly-count kind of mood. 
-
Still suffering SEVERE VAB lag when the doors are in motion, or when moving your parts around.
I can second this. Dragging too many cargo frame pieces around as a unit, or grabbing the cargo bay out of the parts list (which makes it start moving its doors) while there are one or more other cargo bay parts on screen, causes pretty severe slowdown. Additionally, attaching and removing large sections of cargo frame causes everything to freeze for a time seemingly proportional to the number of pieces.
I've noticed that the cargo frames seem to have a very detailed collider mesh - the curved orange diagonal pieces, for example, light up the part on mouseover while all the empty space around them doesn't. At least the main pieces on either side and the middle of the saddle seem to act as a unit (the gaps in those are still treated as pointing at the part). Maybe it would help to remove the long curved orange pieces from the collider, or treat the entire saddle as a continuous surface despite the open space?
On the bright side, procedural tanks work perfectly with these parts - they even come with a Copernicus texture:
Above are filleted cylinders, just under 6m long, 2.5m diameter and fillet (equal length, diameter, and fillet gives you a sphere, btw) and below is a 3m diameter cylinder.
-
After playing around with the parts in the VAB for a while, I realized the scalloping's indentation effect isn't nearly as extreme as I'd been picturing. The only parts I've tried that I could actually see into from outside were the KW Rocketry pancake tanks with the very thin, wider-than-usual outer walls. Even the stock 2.5m SAS module was thick enough to avoid that.
And I actually like how the special decouplers look when attached to the 2.5m cores full of wedges (those projecting pieces fit right into the triangular gaps - very well done). It's a PITA to get them to attach via the correct node sometimes. But it fits very well with the Mark 1-2 pod.
Speaking of SAS modules and wedges... You're already talking about adding monopropellant storage wedges and empty bays - how about a solid "blank" wedge model ("No user-serviceable parts inside", haha) that people with no modeling skills could use (perhaps with a default texture, or their own) to make custom parts that would fit into these cores? Things like an SAS module you could drop in pairwise if you have more bays than you really need, or don't like the flimsiness of thin stacked components like the stock 2.5m SAS...
-
this will allow people to add like an engine cluster without having to lug around that big fat adaptive fairing part.
What, like this?
-
Wow, people have actually used spaces in the names of parts? *ultrafacepalm*
-
If you're talking about parts that can surface-mount and having trouble getting them to attach to a node instead of a surface, like docking ports, I figured that trick out ages ago.
Doesn't hurt to restate it, of course. I was talking about parts like the hubs with three large nodes that overlap significantly though. It's still possible to get parts like the toroidal tanks to attach to the center node, but it's very, very tricky unless you attach parts to the top and bottom nodes first (or at least whichever of them is taking higher priority over the center node). -
Having the fairings on the cores and not the wedges! I foresee issues with per-part door animations though and being able to toggle them when full of wedges, but still, massive savings in RAM and polycount there! Will have to look into that.
Might not work so well - how do you open the door on a specific wedge then? And what about wedges with different fairing or door designs, like DMagic's science parts?
Might just pay to leave extra fairings out of it for now - did some tests with some really high poly (7.2million tri) fairings, and scaling them to 0% didn't remove them from the game (ie, the game kept lagging like hell). If we start including tons of variants in every wedge, it will really start effecting people's computers when each wedge's polycount silently increases by thousands of tris.Ouch. Yeah, that's no good. What about optionally-installed wedge part variants with fairings shaped for the 2.5m core? Still involves the work of creating those meshes, but if you find a good way to switch a part model on the fly without the rescaling hack, I doubt the work would be wasted.
I agree about getting the TAC and KAS packs finished first though. This would primarily be a "nice to have" cosmetic feature, not one that really adds any functionality like those would. My only potential concern is FAR aerodynamics and the collider meshes, which probably wouldn't be changing anyway unless you did offer 2.5m-fairing versions as separate parts. And I doubt that would really be a problem anyway.
-
Starfish, all you really need to do in that case is use a module manager .cfg file that adds the BurnTogether module to all command pods, and remove or don't install the special part - just have the plugin.
@PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[BurnTogether]]:FINAL
MODULE
{
name = BurnTogether
}That should do the job (Untested though).
-
Pretty sure KSP won't unload models but I don't think you'd really want that anyway, since you could have 1.25m and 2.5m cores full of modules in the same scene, if not on the same vessel, so you'd likely need both fairing shapes loaded.
I thought I'd read that the fairings were being hidden by rescaling them to 0% but maybe that was someone else's. If it was these, that approach could just be applied to two meshes instead of one, is what I was thinking. But i'm not familiar with the exact details of how your plugin works, so perhaps that wouldn't be as simple as it sounds.
Scalloped fairings or not, I'm looking forward to what I can make with these, and to the KAS containers and empty bay parts as well as whatever improvements you come up with next!
-
Just found this mod and immediately squealed and installed it.
Looks like you're already discussing something along the lines of what I was just thinking about, too. What about instead of toggling the wedges between just "fairings" and "no fairings", offer more than two options - for example, "1.25m-fitted fairings", "2.5m-fitted fairings" and "no fairings"? Would it be possible to have two separate meshes like that, with no more than one of them shown at a time, based on the VAB setting?
-
It would be nice if there was a way to 'squash' the nodes from spheres into... erm... flattened spheres? The shape of some pills, like advil. And not just visually, but to make them have a smaller grab range along that axis, so that closely spaced nodes wouldn't be as difficult to attach things to, without losing the visual representation of the node size. But if all else fails, making all nodes appear size 1 or even 0 would be far preferable to size 2 and 3 nodes overlapping so much that they're a pain to connect things to like they are currently. I wonder if that could be done with a VAB editor plugin with a toggle function, so you could enable or disable it at will...
-
Fairings go in the staging list like any other decoupler. Make sure you aren't using fuselage pieces instead, those have no decoupler.
-
Or a microwave thermal receiver for beamed power. A tiny fission plant would probably be plenty though.
-
Hah, I guess this whole crazy discussion had some unexpected benefits then!
Sleep well in your silly timezone where it's midnight instead of morning, and congrats on catching the problem. I look forward to seeing the revised stats.
-
The way I see it, choosing to use a mod part with such a poor mass ratio is about the same as shooting yourself in the foot. The same effect (having extra fuel mounted out around the center) could be achieved using purely stock parts without resulting in nearly that much dead weight - just radially attach three Rockomax X200-32 tanks and slap on fuel pipes as needed. You could even hook them up as drop tanks for a measly 0.05 ton decoupler apiece. Presto, similar fuel to an XL torus and no excess dead weight.
But that's ugly.
These tanks look much nicer, as well as being an interesting change of pace, but I don't want to be forced to severely nerf my craft performance-wise just for aesthetic purposes.
So, if you say it would require better materials than what the stock tanks are made of to construct them... then let there be titanium alloy. Honestly, if the "realistic" mass ratio wasn't *quite* so bad in comparison to stock tanks, like around 7:1, I wouldn't bother messing with it. In fact I might set mine somewhere around there instead. Just because "these particular tank models" (which are admittedly not an expert's work, even if I do like how they look) have extraneous stuff like bicycle rims doesn't mean a more realistic design would. It's just pixels. So if it's theoretically possible to design a toroidal tank with a better mass ratio, then why not fiddle with it to make it so?
-
Thanks. 4.128 eh? So, slightly under 1/4 dead weight compared to 1/9 stock. "Not as bad as 1/3 dead weight" is, unfortunately, not a stellar review (no offense). I'll just keep using the stock mass ratios for now, so that I can actually effectively employ these parts in functional ships and not just "concept craft" aka futuristic art projects.
And out of curiosity, RE: "Also, it turns out that the jumbo-64 is about right at 4t assuming a skin thickness of 9mm and being made of iron (and a few other not too unreasonable assumptions)." Does this hold true for the 1.25m tanks as well, or the smaller 2.5m tanks, since they all have the same mass ratio?
-
Alright, like I suspected, you definitely have a better handle on the math involved than I do. Interesting information, certainly.
the mass of a tank is not proportional to its surface area, but rather to its volume. As you increase the volume of the tank, you must also increase the thickness of its walls in order to contain the same internal pressure.That certainly makes more sense in relation to the stock tank volumes and masses - like the same-length tanks of different diameter having the same change to mass and volume, instead of what I had expected.
cylinder width (torus minor radius) certainly does, but a quick glance at the equations indicates that wall thickness being proportional to just the minor radius would keep the tank mass proportional to the tank volume.From Wikipedia (http://en.wikipedia.org/wiki/Pressure_vessel): "No matter what shape it takes, the minimum mass of a pressure vessel scales with the pressure and volume it contains and is inversely proportional to the strength to weight ratio of the construction material (minimum mass decreases as strength increases[5])." It sounds like the length doesn't matter, maybe? There's also a bunch of math I don't have the context to compare between for various shapes. But KSP certainly treats it like cylinder height doesn't affect the mass ratio, so it seems reasonable to follow that rule in this case even if it doesn't always hold fast in reality.
So, comparing the "large" torus (the one with a 1m minor diameter or 0.5m minor radius) with the stock 1.25m diameter tanks (radius of .625m), and assuming that they're built with similar materials and methods, wouldn't this actually imply that the toroidal tank's mass ratio would be similar to that of the stock tank? And that a toroidal tank with a minor radius of 0.625m would definitely have exactly the same mass ratio as the stock 1.25m diameter tanks?
As an aside, with the values I plugged into my config files giving them the stock mass ratios, I was able to make this beautiful (if undoubtedly a bit fuel-inefficient) 'lander' which turned out to be capable not only of landing but also of SSTO takeoff from Kerbin.
Yes, Talisar, Taniwha, this is one reason I want tori with larger minor diameters. A single XL variant with capacity similar to the two of these would cut out the KW pancake tank in the middle as well as looking better and wasting less space between the 3.75m engine and the inner edge of the toroidal tank.
-
Yeah, I've been watching the thread and refreshing any time my email beeped at me.
It only forces that if you constrain the total width of the torus. A torus with a bad ratio might as well have its hub replaced with a pancake fuel tank, resulting in a more efficient rocket. The way I see it, if you need more room in the middle, you need to expand the torus to a size where the ratio isn't bad, not shrink the minor diameter and make it worse. It's clearly possible to have a surface area to volume ratio that IS better than cylindrical tanks, even with the funny way of assigning masses they've used. But to do it you have to make a torus that takes up a lot more space, not less space. The one I described in my comparison to the J-64s would not fit around a 2.5m hub, for example. But if you didn't mind being equal instead of better, you could use a slightly more convenient minor:major ratio and have a better fit.
Additionally, if you look at the A/V of the 1.25m tanks instead of the 2.5m tanks, and/or keep in mind the "Kerbal Way" that I mentioned a couple posts back, it's not hard to see how even the current sizes and shapes of the toroidal tanks could have decent mass ratios. The 1 meter minor radius of the large tank isn't that far from 1.25m, and the XL is definitely more than 1.25m, and those stock 1.25m tanks are still 9:1... What's that tell us? Apparently, Kerbals can make thin-skinned tanks strong enough to stand up to high accelerations... So why not actually make use of that capability?
-
Ah, that makes sense. Thanks, I hadn't thought about that approach.
But even so, my first reaction to that is: They don't *have* to be long and skinny! Why would you want to maintain a constant volume while increasing the major diameter anyway? Let the volume increase. And instead of reducing the minor radius, increase it too. The closer to the major radius it can be, the better, right? Yeah, some sizes wont' fit around the larger hubs, but so be it. Instead of "what size must a certain volume tank be", consider "what's a good volume for a certain size tank to be".
-
Talinu: I used blender's mesh volume tool to calculate the volumes, but they matched closely with my rough hand calculations. Note that they're not all that bad: ~3:1 vs stock's 9:1.
If I'm reading that right, it's wet:dry mass... So 3:1 means having to carry around half a ton of dead weight for every ton of fuel? That's... absolutely abysmal, honestly.
I went back and examined a bunch of stock parts, and it's clear Squad was at the very least fudging the math, if not ignoring it entirely, probably for simplicity and gameplay reasons. Both wet and dry masses of successively smaller 2.5m tanks are exactly halved. A 1.25 tank of the same length as a certain 2.5m tank has exactly 1/4 the masses (which theoretically corresponds correctly to the reduction in diameter, but ignores all sorts of engineering issues like thickness of the tanks and the skin of the part). And halving the length of 1.25m tanks again exactly halves both the wet and dry mass.
The takeaway from this, in terms relevant to the discussion, appears to be that Kerbal engineers have a preferred volume to dry mass ratio and adjust things like the thickness of tanks of varying volumes as needed to give them that mass ratio, regardless of surface area. Which throws all discussion of surface area to volume ratios in regards to part mass right out the window in a flurry of scattering paperwork. Sigh.
I guess I'll just edit the configs on mine to set the dry mass proportional to the volume and call it a day...
-
Tallinu: those masses are based on stock (jumbo-64) tank masses. I even went to efforts to increase their mass ratios (high mass ratio = good). Long story short: toroids are one of the worst possible shapes for tank mass/volume efficiency (the sphere is the best, but has its own problems). What I don't get is why they're so much worse than a cylinder of the same volume.
Really? Maybe I'm missing something major. You probably know more about the subject than I do - I remember reading your discussions of it on these forums, but I'd have to go back and find them again for the details.
I suspected that the mass of a tank should be related mostly to its surface area (aside from issues like pressurization and other components), with the dry mass of the tank approximated by the surface area times the thickness of the tank's outer shell times the mass per cubic centimeter of the material used.
I looked up information on the volume and surface area of cylinders and tori, and right from the start, everything I read seemed to imply the torus was better. The formulas implied it, and explanations of proofs of the formulas seemed to support it as well. As a test, I used the same value for a cylinder's diameter and the minor diameter of a torus, and the correct cylinder height to make the volumes equal was then easy enough - just replace H with Pi*D. For tori and cylinders matched up by diameter in that way, the volumes were equal and the surface areas of the tori were always lower. So I decided to try values based on the J-64.
I don't know the exact height of the J-64 tank, but comparing it with three perpendicular tanks, it seems to be about 7.5 meters, for a volume of about 36.82 cubic meters. Making a 2.5m minor diameter torus with the same volume as a single J-64 would put the major diameter below 2.5m, which would turn it into a spindle torus (to which these formulas don't apply), so I've used two stacked J-64s instead for a volume of 73.63 m^3. The surface area of one is about 68.72, and doubling that gets 137.44 (I'm not simply increasing the height of a single cylinder because you can't actually do that while playing KSP, at least with stock tanks).
A height of 15m translates to a major diameter of 4.7746 (via division by Pi), so substituting 15 for Pi*D, the surface area of the torus would be A = Pi*D*Pi*d = 15*Pi*2.5 = Pi*37.5 = about 117.81 square meters. 117.81/137.44 = about 0.857 so the dry mass of the particular toroidal tank I've described should be about 14 to 15 percent lower than the dry mass of the pair of J-64s it was based on, while containing an equal volume of fuel.
I imagine it's possible to find some horribly high surface area to volume ratios for either a torus or a cylinder - for example, a very thin, wide pancake of a cylinder would be really bad, and a narrow diameter like a pencil would also be bad - both for a torus and a cylinder. By comparison with a sphere, which I believe has the lowest surface area to volume ratio possible in three dimensions, a larger minor diameter is always going to improve the area to volume ratio of a torus, while for a cylinder it will improve it as long as the diameter isn't so high that the squares in the end-cap terms don't grow too large... the height must keep pace with the diameter to avoid that. It's probably possible to write some kind of optimizing function, but that's a bit of a tangent.
http://en.wikipedia.org/wiki/Torus and http://www.engineeringtoolbox.com/surface-volume-solids-d_322.html were very helpful, as was Google with search strings like "right cylinder calc: find A" and "torus calc: find R, r=n/a, V=n/a".
Again, if I'm missing something important, please let me know. I spent quite a while working out errors in my math and I'm fairly certain everything agrees with everything else now, and I hope reading this doesn't seem like a waste of time in the end, but it seems to confirm the idea that tori are (or at least can be) better than cylinders, from a surface area to volume standpoint.
The 1.25x upscale is what caused the weirdness for me there. When I initially modeled them the tank end diameters were 1.25m/2.5m, and I basically made the centerline diameters one step up from the ends. Then there was a request for a bigger tank as well as more variety in endcap sizes, and for some reason I doubled the centerline diameter instead of stepping it up. The spherical tanks were actually my first attempt at modding, so you are seeing the end result of a very poorly planned out learning process. The only reason they ended up usable was due to a LOT of help from people like taniwha and Greys (among others).I see. You've done well despite the learning process, I think! If these weren't so useful and decent-looking even with the existing textures and models, I wouldn't be here bugging you for more, after all...
I had thought about the next iteration of the pack being procedural, but that's outside my current skillset (and now it looks as if swamp_ig is doing a great job of getting procedural versions out here). I feel that I have made significant progress toward improving both my modeling and texturing skills, so I think my next swipe at this pack will be aimed at making very good looking models and textures, as well as more firmly planned out workflow to make the tanks offered in sizes that make more sense.I haven't made too much progress on this lately, but here are some reposts of what I'm thinking of for the future of the pack:
He wrote that he's not doing anything toroidal, though! But I can totally understand not wanting to jump into coding something like that, especially given the aforementioned newness to modding.
Those new models look great, but I hope you'll provide endcap models with cover panels as well as the ones with just struts, for when aerodynamics (or at least the appearance thereof) is an issue. I've used your hemispheres as size adapters (particularly 3.75 to 2.5m) because they look a lot more interesting than the boring cones most parts packs offer. The smaller end-capped hemispheres also make great caps for 2.5m and 3.75m tanks mounted radially (or in similar fashions), like this: http://imgur.com/a/1wRdE#41 Especially when you want to stick docking ports on the ends. (In the left foreground, those are 2.5m KW Rocketry tanks with the 2.5m base & .625m cap hemispheres on top and bottom, Jr. ports on both. Same thing on the opposite side of the ship.)
Regarding the config options, I've tried removing all of the basemass = -1 lines I could find in the toroidal tank configs, but the game still wants to assign a dry mass of 56.2106 tons to the XL toroidal tank as soon as it has fuel tanks defined. The others have similar results. Pulling a fresh XL out of the parts window, it has 3910.3 LF and 4779.3 Oxidizer, and a wet mass of over 99 tons. Removing the LF tank reduces dry mass to 33.7264 tons, and removing both results in 6.2456, which doesn't even match the part mass listed in the config (mass = 16.0109). Looking in the configs for the spherical tanks (for example, the large), I see that the dry mass of the part does match (mass = 13.5) and doesn't change when the tanks are removed or re-added in the editor. These still have the basemass = -1 lines. I'm rather confused as to how this works and what's going on...
I do love the implied crew tunnel, but most parts just have texture art for the hatches...something to consider if you're ever in a must-lower-poly-count kind of mood. 
Cargo Transportation Solutions (WIP)
in KSP1 Mod Development
Posted · Edited by Tallinu
For anyone having difficulty attaching things to the cargo adapters, here's a quick pictorial guide. Make sure you don't have part clipping enabled or things will still try to attach to occupied nodes and these steps won't help at all.
Edit: Thanks, and you're welcome.