Jump to content

[WIP][1.8.x] SSTULabs - Low Part Count Solutions (Orbiters, Landers, Lifters) - Dev Thread [11-18-18]


Shadowmage

Recommended Posts

The Series C pod has a pretty much finished IVA it does have two cfg's for it and one points to a custom RPM's but you can change it to use the one that has the stock RPM's which on that note has much as, I like custom RPM's if the modder don't keep up with the new changes in JSI then you don't get them in custom ones that is a down side so at less think about using stock RPM's or ASET one's.

Edited by Mecripp2
Link to comment
Share on other sites

General dev update:

Did not get much dev time in over the weekend as I was helping out a friend for a bit. As a result there is not much to show for an updated test release at the moment. I got the procedural model for the decouplers 'working', but it is lacking in features and balance - such as it currently does not update mass, cost, or ejection force based on its physical attributes, and it is still using the same texture that the procedural fairings use. Will hopefully have a good system figured out and coded in the next day or two, and issue an updated test release at that point.

Balancing parts will be the focus for the next week, in preparation for public beta testing. I'm pretty sure I have all of the modules in a usable and stable state (aside from the procedural decoupler), and do not think that will be doing any geometry/model additions or changes in the immediate future, so there should not be any more save-breaking changes after the upcoming private test release.

TLDR:

Updated private test release in a day or two for the last major code and config changes, and if all goes well, move on to public testing hopefully next weekend.

- - - Updated - - -

It's strange; I didn't encounter space-bar staging problems by making decoupling nodes top or bottom (last week I made 2 new parts for my mod that use top and bottom stack decoupling modules). I agree on dV calculations.

The problems only manifest because I purposefully disabled staging on the decouplers; as they were on the top node of an engine/fuel tank combo -- you would hit space to stage it and it would activate the engine and the decoupler simultaneously. I'm just trying to put too many functions on a single part :)

It's very interesting observation also when it comes to docking ports. So for example one could create a standard part with rigidbody/colliders (i.e. habitation module') that have i.e. 2 'holes' for physicless docking ports that you can attach in editor. Then when launched those 3 parts would count as 1 part with 2 docking ports (performancewise). That could be partial solution to the performance problem. It would come with some ceveats though (player would not be able to click on docking port parts - no collider, so generally no option to undock a part?, probably those parts wouldn't work well with KIS system etc).

This however could be solved by hybrid system, so one part is normal and has integrated docking module (i.e. habitation module with one side docking port) and other side you would just pluck physicless docking port. Then when docking other parts with integrated 1 docking port you could always undock :P.

You can still have colliders on physics-less parts. For example most of the small stock science-experiment parts are still physics-less, but you can mouse-over and right click on them. But yes, they often just explode if you drop them on the ground via KIS/KAS, and can exhibit other strange behavior when used as the root part on a craft. I believe I have even seen them collide with terrain on a vehicle / be torn off/ destroyed, so there might be some special handling of the colliders with the physics-less parts.

Will definitely be investigating this stuff more in the coming weeks. Will have to do some good testing regarding what kind of side-effects the physics-less parts can have, as that seems to be the easiest solution to alot of the station/docking port issues, and could be done with a simple MM patch.

Link to comment
Share on other sites

You can still have colliders on physics-less parts. For example most of the small stock science-experiment parts are still physics-less, but you can mouse-over and right click on them. But yes, they often just explode if you drop them on the ground via KIS/KAS, and can exhibit other strange behavior when used as the root part on a craft. I believe I have even seen them collide with terrain on a vehicle / be torn off/ destroyed, so there might be some special handling of the colliders with the physics-less parts..

Thanks for the information, I've tested 1 part with about 100 docking ports:

- PhysicsSignificance = 0 -> 24 fps

- PhysicsSignificance = 1 -> 34 fps

My installation and drivers might be faulty here, would be glad if someone could repeat this test.

What is important (and you've already mentioned) is that with physSig=1 they add mass to their parent part thus increasing joint strength (which is very good when there's no good way to modify joint strength of a docking port which usually has small mass compared to things it connects).

Results show that a multidocking part would still be useful to increase performance with multiple docking ports :)

edit: unfortunately docking ports without rigidbody don't work (you can't dock once undocked) so this creates even stronger case for multidocking port part ;)

edit2: maybe the plugin could contain code for the custom docking port that switches off rigidbody when it's docked (or switchable docking utility so player switches rigidbody on only when it's needed for docking)? ideally though dockingNode would work with physicsSignificance=1 :)

Edited by riocrokite
Link to comment
Share on other sites

another bit that might help on docking port front:

test of 2 vehicles with about 50 docking ports (deployable ones):

45-50 fps when both vehicles have closed docking ports,

22-25 fps when they deploy docking ports

fYuPMps.png

however:

22-25 fps when I load the scene with closed docking ports (have to manually open and close them for the fps to get back to 45-50 fps) - I guess this is another point where ksp code is not optimized, otherwise, could use stock deployable docking port module to increase performance easily.

This means that not only rigidbodies are slowing performance in docking ports but also probably their function (seeking other docking ports for magnet docking) as well. switchable docking ports (on/off) could help in that matter.

Edited by riocrokite
Link to comment
Share on other sites

Another test that might help:

Exposed docking ports vs stacked docking ports, both cases have about 110 docking ports, in the second case all docking ports are exposed, in 1st case only top (4) docking ports are exposed:

dCfBTGv.png

jWO3hf0.jpg

Addendum1: multiple exposed docking ports don't seem to slow down game when there's just one vessel, however anything else (debris, vehicle without docking ports etc) slows down game considerably; proof:

Z3Z6gKP.png

NBG75qY.png

Addendum2: when 2 vessels with multiple docking ports are docked (connected) and become 1 vessel, situation doesn't improve:

iDC0kVC.png

Edited by riocrokite
Link to comment
Share on other sites

Wow, nice work on the investigation and experimentation. Very interesting findings. Especially the fact that the shielded docking ports have less of a performance impact (when working properly) compared to a normal docking port. This tells me that docking ports have performance implications above and beyond the standard rigid-body/physics calculations that are present for every (physics-enabled) part.

The differences between the stack and surface-attached ports performance is likely related to the same bit as the shielded docking ports. I'm guessing that there is some not-insignificant overhead in the docking port 'magnetism' code, and this code only runs when the docking port has nothing attached to its attach-node. The shielded docking port likely uses the same code but has a bug during re-initialization on re-load where it does not update the shielded/searchable status properly.

I'll poke into the code on the docking ports a bit and see what I can find out about why they do not work when physics-less. It might be something collider/trigger related that could be worked around through a custom plugin/module. Would certainly be nice to just be able to use stock docking ports.

On the 'multi-port' docking port -- still working through the concept on this, but I think I have enough code implemented that I can try some experiments soon (just want to get the current WIP stuff to a releasable state before I start on any more experiments). Currently I believe you can have multiple docking port modules on a part as long as they reference different 'docking transforms'; the problems stem from there is no way to tell them apart on the right-click to tell which one you are undocking. What I have done is create a slightly customized docking port module that allows you to add a 'port name' to the right-click options; so instead of saying 'Undock', it would say 'Undock Port1' (or whatever you labeled them as in the config). This would have to line up with the model/textures to enable you to tell the ports apart, but so far the concept -seems- like it will work out.

Will also investigate what I can do to duplicate the good-performance aspect of the shielded docking ports (and fixing the inconsistency). Seems that a simple 'activatable' docking port could be a good solution for most single-port vessels; it could at least help with a tiny bit of performance while not performing docking maneuvers.

Link to comment
Share on other sites

On the 'multi-port' docking port -- still working through the concept on this, but I think I have enough code implemented that I can try some experiments soon (just want to get the current WIP stuff to a releasable state before I start on any more experiments). Currently I believe you can have multiple docking port modules on a part as long as they reference different 'docking transforms'; the problems stem from there is no way to tell them apart on the right-click to tell which one you are undocking. What I have done is create a slightly customized docking port module that allows you to add a 'port name' to the right-click options; so instead of saying 'Undock', it would say 'Undock Port1' (or whatever you labeled them as in the config). This would have to line up with the model/textures to enable you to tell the ports apart, but so far the concept -seems- like it will work out.

Cheers,

As for multi-port docking module the biggest problem I guess will be with with docking, not undocking (as this mechanic works currently as you described). Adding several empty 'dockingNode' gameObjects in Unity and then ModuleDockingNode modules in cfg lets you undock those ports. However docking is possible just to (I think) the first mentioned in cfg docking port. Similarly undocking works perfectly without rigidbodies, however docking again is not possible.

edit: another possible thing (however unlikely) that might also slow down shielded docking ports performance might be not disabling their animation when they are open and scene is loaded.

I recently had similar problem with BDanimationModule that animated container according to its 'fullness'. So possible solution here would be to set [objectAnimationStateName].enabled = false upon loading scene.

edit2: oh yeah, last thing that might help understanding ModuleDockingNode code would be to look at AdaptiveDockingNode by toadicus:

https://github.com/toadicus/AdaptiveDockingNode

forum thread and license:

http://forum.kerbalspaceprogram.com/threads/79128

I think he rewrote much of KSP ModuleDockingNode code adding functionality of docking different sizes ports.

Edited by riocrokite
Link to comment
Share on other sites

another thing: dunno if this is useful for your purposes, but decoupler module seems to get decoupling force vector from Center of Mass of base part, not actual part one wants to decouple. There's no effective difference when one wants to decouple top or bottom stuff, however decoupling sideways (jettisonable tanks out-of-the-truss style) is almost impossible.

Link to comment
Share on other sites

A bit of investigation on the docking port shows that for some reason the ModuleDocking port explicitly skips any part that has physicsSignificance set to 1 (physics-less). Its not a bug, rather it is explicitly written to skip those parts; I have no idea why. So they physics-less docking ports are a complete no-go because of stock code (and there is no clean way to override that section of code to fix it through custom plugin; and the docking port code explicitly references ModuleDockingNode by class/type so you cannot create a non-derivitive clean implementation and still maintain compatibility with stock docking ports; they would not know to look for your non-derived class and would never connect). At least they could have made it reference by an interface so that you could re-implement the stuff in a new class if desired; ohwell, nothing I can do about others' poor coding decisions.

But.. the good news.... I cannot see any reason in the code why a multi-docking port part would not work. The code iterates through every part on a vessel, and every module in each part looking for docking nodes to connect to; it does not early-out after finding the first port module, but continues iterating through the rest (as near as I can tell... granted I didn't look over it in any great detail). So... will def. be playing around with those a bit next week to see what I can come up with regarding a multi-docking-port part (or likely several parts in various arrangements of small/large ports).

Anyhow... I should have an updated private test release a bit later this afternoon. Mostly just adds the procedural decoupler, but there are also a few config tweaks in this update. After this, for the rest of the week/end, I will be working on configs and balancing in prep for the initial public beta test releases (hopefully this weekend/early next week).

Link to comment
Share on other sites

A bit of investigation on the docking port shows that for some reason the ModuleDocking port explicitly skips any part that has physicsSignificance set to 1 (physics-less). Its not a bug, rather it is explicitly written to skip those parts; I have no idea why. So they physics-less docking ports are a complete no-go because of stock code (and there is no clean way to override that section of code to fix it through custom plugin; and the docking port code explicitly references ModuleDockingNode by class/type so you cannot create a non-derivitive clean implementation and still maintain compatibility with stock docking ports; they would not know to look for your non-derived class and would never connect). At least they could have made it reference by an interface so that you could re-implement the stuff in a new class if desired; ohwell, nothing I can do about others' poor coding decisions.

But.. the good news.... I cannot see any reason in the code why a multi-docking port part would not work. The code iterates through every part on a vessel, and every module in each part looking for docking nodes to connect to; it does not early-out after finding the first port module, but continues iterating through the rest (as near as I can tell... granted I didn't look over it in any great detail). So... will def. be playing around with those a bit next week to see what I can come up with regarding a multi-docking-port part (or likely several parts in various arrangements of small/large ports).

Anyhow... I should have an updated private test release a bit later this afternoon. Mostly just adds the procedural decoupler, but there are also a few config tweaks in this update. After this, for the rest of the week/end, I will be working on configs and balancing in prep for the initial public beta test releases (hopefully this weekend/early next week).

Cool :) I won't interfere you further until the release.

However ;) - one last thing that one might ponder is that we might not need to care much about stock docking ports. In other words it could have been be easy to just create custom docking ports (models) with your plugin. Then I think there are many people who are struggling with performance and would be happy to use those (instead of stock ones) :)

Link to comment
Share on other sites

Cool :) I won't interfere you further until the release.

However ;) - one last thing that one might ponder is that we might not need to care much about stock docking ports. In other words it could have been be easy to just create custom docking ports (models) with your plugin. Then I think there are many people who are struggling with performance and would be happy to use those (instead of stock ones) :)

If I wrote a full-custom docking port, it would also be possible to just MM patch it to replace the stock module in the stock ports. Really don't want to go down that route (full custom docking port module), but it is always an option if I cannot find any other acceptable solutions.

Link to comment
Share on other sites

Working on a balancing pass of the lander part fuel/volume/mass data. Here are a couple of comparison landers, with before and after stats:

LC2-Basic Lander config (2-man, single-stage):

LC2-POD (with ascent tanks)

LC2-FL0

LC2-LEG

LC2-DESE

~2.4m at widest point (fits inside 2.5m fairing)

~3m tall with legs retracted

Original stats:

Mass: 6.15

dV: 1816

New stats:

Mass: 8.14

dV: 2523

LC3-Basic Lander config (3-man, single-stage):

LC3-POD

LC3-FL0

LC3-LEG

LC3-DESE

~3.6m at widest point (fits inside 3.75m fairing)

~3.5m tall with legs retracted

Original Stats:

Mass: 13.070

dV: 2290

New Stats:

Mass: 17.424

dV: 2971

LC5-Altair Lander config (3-man, 2-stage, Tylo lander):

Ascent Stage:

LC3-POD

LC3-ASCF

LC3-ASCE

LC2-FL0

Descent Stage:

LC5-FL2 (with mono/or RTG)

LC5-FL2 (with solar panels or RTG)

LC5-FL0 (with leg)

LC5-DESE

~4.9m at widest point (fits inside 5m fairing)

~5.5m tall with legs retracted

Original Stats:

Mass: 34.82

dV: 4747 (as=2335, ds=2411) (a bit short of a Tylo capable lander...)

New Stats:

Mass: 56.44218

dV: 6108 (as=2881, ds=3227) (Tylo capable, from proper insertion orbit; might need plane change from external propulsion for some landing sites)

Basically I'm going for more Kerbalized; slightly overweight (as is everything kerbal), but still with adequate performance. Compared to the current balance, the new numbers should increase weight substantially (~35%), but also increase the dV budget for a design by %20. Tankage mass fraction has stayed consistent (and is inline with stock values), but the tanks now hold more fuel. The new fuel/volume/mass numbers are based off of an idealized fuel-tank for each size (rather than the previous balance pass that was based on the actual volume of the individual tanks in any particular part). This brings the fuel tanks to be more in line (volume wise) with the cargo parts (and allows me to add a resource-switch to the cargo parts to allow them to carry fuel as well, without being overly OP compared to the other fuel tanks).

I've also aimed for single-stage capable landers for -most- situations. I've found it is barely (if any) more efficient to build a 2-stage Mun lander than a single stage (using stock parts at least); so I've saved the multi-stage setups for planets/moons that really need them -- Duna, Laythe, Tylo, Kerbin. Most other moons and planets have low enough gravity /dV requirements that a single stage lander is small and light enough that designing a two-stage lander for the purpose really only increases part count and cost (you -might- save a slight bit of mass on the two-stage design).

Any thoughts on this information? Does it seem like these parts would be overpowered, underpowered, or just about right? I have tried to maintain stock balance values for tank dry mass ratios, and am staying within the volume constraints of each part (e.g. it does not magically contain more fuel than it could by exterior volume). There is still a bit of wiggle room in the numbers though, so please let me know what you think.

Edited by Shadowmage
Link to comment
Share on other sites

Just out of curiosity, will they have IVA's upon release?

Finished IVAs - no. They will have basic geometry-only placeholder IVAs (no textures, no props), some with more finished geometry than others (LC2 IVA is completed geometry wise, but still needs props and textures).

IVAs take several weeks each to do (at least for me), so I will be working on the IVAs during the 'public beta' period, so as to not delay the release by the several months that would be needed for me to do them all.

Link to comment
Share on other sites

...balancing stuff..

1) are you building new integrated engines or the lander will have place for stock ones? if your own, what isp/thrust would they have?

2) would it be possible to attach additional jettisonable tank rings under the lander (inline) to extend its dV (so for example player would drop empty bottom tank(s) before touching down so the legs could then be extended). this is an approach that i'm using when preparing new 7.5m delivery boxes that is stork landers (I'm also working on side jettisonable tanks atm, you can check stork SDS thread in my sig).

Personally I'm a fan of balancing everything against stock - mass and volume wise - not to overpower anything too much. Then modularity allows player to attach additional fuel rings on the bottom (that have space for upper engine exhausts) that extend dV when needed.

Link to comment
Share on other sites

1) are you building new integrated engines or the lander will have place for stock ones? if your own, what isp/thrust would they have?

2) would it be possible to attach additional jettisonable tank rings under the lander (inline) to extend its dV (so for example player would drop empty bottom tank(s) before touching down so the legs could then be extended). this is an approach that i'm using when preparing new 7.5m delivery boxes that is stork landers (I'm also working on side jettisonable tanks atm, you can check stork SDS thread in my sig).

Personally I'm a fan of balancing everything against stock - mass and volume wise - not to overpower anything too much. Then modularity allows player to attach additional fuel rings on the bottom (that have space for upper engine exhausts) that extend dV when needed.

My actual design for a range extender would be an 'upper' drop tank, using the existing docking port on the pod; skycrane style (perhaps even with the upcoming skycrane parts that have integrated engines). Perhaps even a re-usable de-orbiting module (drops peri to just above/at surface, decouples, and re-orbits itself for refueling). This allows for the plane change and de-orbit burn to be done by the extra fuel-module.

I do have custom designed engine clusters, and while there is a space in the center of the descent engine clusters where one could potentially mount a lower 'range-extender' stage, lack of attach nodes at that position make it difficult (due to stock bugs with too many attach nodes in similar locations). There -is- an (optional) attach node on the very bottom of the engines, so you can always use traditional staging. The engines are designed as very low-profile (<1/2m tall), and the descent engines are built in ring-style clusters (with a hollow center section). All of the lander-designed engines have an ISP of 355 (intended to represent advanced hypergolic fueled engines which would be in use for these types of designs with potentially long loiter times/long surface stay times). Thrust is as-yet undecided; though there are 6 engines (3 ascent, 3 descent), so there will be a variety of thrust levels available. As they are engine clusters, they will all be multiples of the thrust of the single engine which is used for the smallest ascent-engine (LC2-ASCE). Currently the thrust progresses such as: Ascent: 60 (x1 engine), 180 (x3 engines), 240 (x4); Descent: 240(x4), 480(x8), 720(x12)

So, to answer your question - yes; in multiple different varieties and capabilities, including the normal stock stack-staging (with fuel lines). The openings in the tanks have also been designed to be large enough to accommodate stock engines (1.25m, 2.5m, 3.75m), though most might look a bit strange and not fit exactly (as the lander parts are slightly smaller than stock diameters, at ~2.4, ~3.65, and ~4.9m).

Edited by Shadowmage
Link to comment
Share on other sites

My actual design for a range extender would be an 'upper' drop tank, using the existing docking port on the pod; skycrane style (perhaps even with the upcoming skycrane parts that have integrated engines). Perhaps even a re-usable de-orbiting module (drops peri to just above/at surface, decouples, and re-orbits itself for refueling). This allows for the plane change and de-orbit burn to be done by the extra fuel-module.

I do have custom designed engine clusters, and while there is a space in the center of the descent engine clusters where one could potentially mount a lower 'range-extender' stage, lack of attach nodes at that position make it difficult (due to stock bugs with too many attach nodes in similar locations). There -is- an (optional) attach node on the very bottom of the engines, so you can always use traditional staging. The engines are designed as very low-profile (<1/2m tall), and the descent engines are built in ring-style clusters (with a hollow center section). All of the lander-designed engines have an ISP of 355 (intended to represent advanced hypergolic fueled engines which would be in use for these types of designs with potentially long loiter times/long surface stay times).

So, to answer your question - yes; in multiple different varieties and capabilities, including the normal stock stack-staging (with fuel lines).

cool, cannot wait to test the concept :)

yah, I've noticed stock bug with too many attach nodes in similar location. Need to test it a bit more (will try JSIpartutilities with toggling nodes)

Link to comment
Share on other sites

1. after quick comparison between stock and sstu tanks I support proposed increase in their capacity; ATM they feel seems to be holding much less fuel than similar shape stock variants

2. Personal suggestion however might be too late for that. I feel that lander bottom view (so how close to the ground are you) is not adequate (LC3). Maybe moving windows lower (or swapping their orientation 180 degrees) could help. Personally I would move some of the prospective instrumentation to the top (or left / right depending on a seat) as well to unblock bottom view so one can land in IVA mode and watching shadow lander's shadow :P

Link to comment
Share on other sites

1. after quick comparison between stock and sstu tanks I support proposed increase in their capacity; ATM they feel seems to be holding much less fuel than similar shape stock variants

2. Personal suggestion however might be too late for that. I feel that lander bottom view (so how close to the ground are you) is not adequate (LC3). Maybe moving windows lower (or swapping their orientation 180 degrees) could help. Personally I would move some of the prospective instrumentation to the top (or left / right depending on a seat) as well to unblock bottom view so one can land in IVA mode and watching shadow lander's shadow :P

Good to know regarding the balance; I think that bringing them closer in line to stock values is probably the right way to go. Will continue tweaking the balance on those a bit.

On the LC3-Pod geometry - hmm... I -might- be able to change it up a bit. Alternative to lowering the windows would be raising up the kerbal seats a bit; much easier to do and would not require reworking any 'finished' geometry. Might still be able to rework the model a bit; will depend on how much a PITA it would be to redo the AO bake and update the UV mapping. Will keep this on my 'todo/investigate' list and look into it again/more when I am working on finishing up the texures.

I am aiming to make them usable from IVA, so will definitely give this some thought as I am finishing things up.

Also, note that there is/should be/will be a double-click view-switch option on the front windows, which -should- allow for a better landing view (though you cannot see very many instruments with your nose pressed into the window like that) (you can see the LC2-POD for example -- go into IVA and click/double click on the front windows or upper docking window, it should switch you to a much closer-to-the-window view).

Link to comment
Share on other sites

yah, I'd move chairs up in LC2 and LC3. Personally I'd stuff most instruments in the top bar above windows (monitors?) and then some small instruments in a thick line between windows. In effect one could have clear view downwards which IMHO is the most important thing for landers. LC2 closer-to-the-window view is cool, however ideally one is able to see the bottom view and instrumentation at the same time to control orientation descent rate and see the distance to the ground.

LC5 view is magnificent, it's also perfect for space stations. Personally I would move or add one more seat to central position or behind first two folks (commander position with more monitors and stuff:)) so one could have a great view being further from the windows (star-trek like :P). This would probably require to move 2 front seats further to the left and the right so the commander has better view :P

Another thing would be to add two more windows to the front bottom side so they are symmetrical to the top. If 2 first guys are seating more to the left and right they could have instrumentation on the left and right respectively.

Just my 2 cents.

Ii6EIx7.png

jma0W3P.png

- - - Updated - - -

edit1: - Engines -

Since everything is more or less balanced against a single LC2-ASCE engine, just couple of my observations:

It has the size of 0.625m 48-7S engine, however it has slightly more power and ISP than larger 1.25m lv-909 with only 60% mass of a lv-909. So it seems to be a bit too op. I'm assuming it's a late game tech engine(?).

Considering its size I would decrease its thrust by 1/3 to about 40-45 so it would be more in-line with lv-909 and this would explain it's better ISP efficiency as well as smaller size and weight.

edit2: After short testing I think that using JSIPartUtilities switchable nodes solves KSP bug with attachment nodes being too close.

Edited by riocrokite
Link to comment
Share on other sites

yah, I'd move chairs up in LC2 and LC3. Personally I'd stuff most instruments in the top bar above windows (monitors?) and then some small instruments in a thick line between windows. In effect one could have clear view downwards which IMHO is the most important thing for landers. LC2 closer-to-the-window view is cool, however ideally one is able to see the bottom view and instrumentation at the same time to control orientation descent rate and see the distance to the ground.

LC5 view is magnificent, it's also perfect for space stations. Personally I would move or add one more seat to central position or behind first two folks (commander position with more monitors and stuff:)) so one could have a great view being further from the windows (star-trek like :P). This would probably require to move 2 front seats further to the left and the right so the commander has better view :P

Another thing would be to add two more windows to the front bottom side so they are symmetrical to the top. If 2 first guys are seating more to the left and right they could have instrumentation on the left and right respectively.

Just my 2 cents.

Thanks for the feedback. Will keep this in mind when I am moving on to tackling the IVA stuff.

However, I'm not sure there is any way to get a true 'downwards view' while still having isntruments in view; at least not with the current pod geometry. About the best I can do is the view-switching. Or I guess I could move the kerbal seats -way- upwards. The overall geometry though is flawed in regards to Kerbals; It works/would work for humans IRL, as we can move our head around to look out the window, and move it back to look at instruments if needed; not so easy to do with a Kerbal in-game. IIRC, that was how the Apollo crew flew the LEM - standing up with their noses pressed into the window, moving back and looking around at instruments as needed (or relying on the co-pilot to relay vital information). Unfortunately, it is a bit hard to do that with a Kerbal.

Still, I'll see what I can do. Can't promise perfection, but I'll try to at least make it more usable than it is currently. Thinking about saving the pods to work on last for texturing, in case I need to make any model changes to accommodate an improved IVA experience.

edit1: - Engines -

Since everything is more or less balanced against a single LC2-ASCE engine, just couple of my observations:

It has the size of 0.625m 48-7S engine, however it has slightly more power and ISP than larger 1.25m lv-909 with only 60% mass of a lv-909. So it seems to be a bit too op. I'm assuming it's a late game tech engine(?).

Considering its size I would decrease its thrust by 1/3 to about 40-45 so it would be more in-line with lv-909 and this would explain it's better ISP efficiency as well as smaller size and weight.

Aye, their thrust is quite OP at the moment, at least compared to their size. I was waiting to finalize the masses on the pods before working over the engine thrust and mass values. 40 or so will probably be about right for the single engine; It just needs to be powerful enough to be used as an ascent engine for the LC2-POD+ascent tank (updated full/wet mass value of 2.82; 40 thrust would give a vacuum TWR of ~1.41). Might even bring it down a bit further; the single engine is at most intended for low-gravity worlds, so it likely doesn't even need a 1:1 TWR on kerbin. Will investigate something like 28-30 thrust, should allow it to still be quite usable for the low-gravity worlds, and possibly allow for a slight mass reduction as well.

I've based the ISP on real world examples for upper end/higher tech hypergolic fueled engines; specifically a scaled-down https://en.wikipedia.org/wiki/RD-0124 (~ 0.5t, 300kN thrust, 359 ISP). Yes, it is one of the highest ISP RP1/LOX engines available; why would you use anything but the most efficient engine available for a real lander design? However, the ISP might come down slightly (350?), as I believe the performance #s of the parts with their new fuel/mass values might be a tiny bit -too- good. Might make this during a second balance pass; will probably keep the ISP as-is for now, and look into adjusting in the future if needed.

The engines will start to be available about 1/3 the way through the tech-tree (45 or 90 science nodes); one or two nodes deeper in than the most similar stock counterpart, but still early enough to make the landers useful in a (still developing) career game. They should be all set into the tech tree currently, but some of the current positions will likely be adjusted during this balance pass.

On the note of tech-tree nodes; If you have any suggestions as to where to place the higher-end parts (LC3, and mostly LC5), I'm all ears :). It seems the current standard is to stuff any/all high-end parts into the far-upper-right tech-node (don't remember what it is called; very-heavy rocketry or something), but I would much prefer to have some variation as to the placement of the parts.

edit2: After short testing I think that using JSIPartUtilities switchable nodes solves KSP bug with attachment nodes being too close.

I'm not familliar with JSIPartUtilities (will take a look!), however I do have a custom part-module (SSTUSelectableNode) that allows for adding/removing/inverting attach nodes while in the editor that I will be adding (back) onto a couple of these parts. Most parts originally had it present, but was removed earlier in the dev cycle as it was not needed at the time; I thought I had found solutions to all of the attach node stuff. Might also add back in the rest of the 'optional' nodes to the parts that had them (using the node switch module)... such as the upper-middle node on the engine clusters.

Anyhow, thanks for the feedback and info. Should be able to get most of the stuff sorted out without too much difficulty.

Will likely have one final test private release in a day or two for a quick testing of the updated balance on the parts. I expect it should be ready Fri. night or early Saturday.

Link to comment
Share on other sites

I'm not familliar with JSIPartUtilities (will take a look!), however I do have a custom part-module (SSTUSelectableNode) that allows for adding/removing/inverting attach nodes while in the editor that I will be adding (back) onto a couple of these parts. Most parts originally had it present, but was removed earlier in the dev cycle as it was not needed at the time; I thought I had found solutions to all of the attach node stuff. Might also add back in the rest of the 'optional' nodes to the parts that had them (using the node switch module)... such as the upper-middle node on the engine clusters.

check my MFS mod (link in signature) for JSIPartUtilities.dll, you can see usage in some of my parts' configs. Relevant code:

node_stack_mediumeng1 = 0.0, 1.6, 1.0, 0, -1, 0, 2

node_stack_mediumeng2 = 0.0, 1.6,-1.0, 0, -1, 0, 2

node_stack_mediumeng3 = 0.0, 1.6, 0.0, 0, -1, 0, 3

//----------------- BIG ENGINE NODES SWITCH -----------------------------------

MODULE

{

name = JSIPartComponentGroup

groupID = MediumEngineNode

areComponentsEnabled = true

persistAfterEditor = true

activeInEditor = true

activeInFlight = false

activeWhenUnfocused = false

enableMenuString = - Medium Engine Nodes

disableMenuString = + Medium Engine Nodes

showToggleOption = false

managedNodes = mediumeng1|mediumeng2|mediumeng3

}

The bold text did the trick (when I switched nodes off again before launching). However I didn't have much time for testing so there is a chance I might be wrong. This might have side effects for example for KIS/KAS (nodes not visible for node attachment after launching when using KIS) however for my modding needs I'm fine with it.

Edited by riocrokite
Link to comment
Share on other sites

Balancing has been... going. I think I have things to a more usable state though.

Parts are still balanced using stock balance mechanics - actual measured volume, 85% fuel mass fraction for tanks. Raw engine TWR is identical to the LVT-45 (13.3)(which is quite terrible, compared to skipper/mainsail(21,25), but very slightly better than lv-909(12)). Pod masses have increased fairly significantly for the LC2 and LC3 pods; though still lighter than the stock 3-crew command module, they are heavier than using multiple stock 1-man lander cans; so I feel they are probably in the right ball-park for mass balancing (additional mass could be explained by the inclusion of RCS and solar panels).

Had a heck of a time trying to enable an Altair-styled Tylo-capable lander. But I think I have the parts capable of doing one now, without mucking with stuff too much.

12-part, 2-stage, 3-crew Lander.

Uses LC3-POD, with LC5 fuel sections, so should look fairly Altair-like, at least the earlier concepts with the horizontal crew compartment.

59.9405t total mass (quite overweight compared to real/scaled down Altair; mostly due to hypergolic fuels, resultant low ISP, and terrible mass-fraction of stock balance on the tanks)

Total delta-V: 6280 (-should- be Tylo capable, with a small margin for inclusion of

Ascent stage:

5 parts

9.4623t (5.25t fuel, 4.20 dry)

350 ISP engine (lc3-asce)

2788 dV

1.29 Kerbin TWR

Descent Stage:

-- Has spare dV, so could easily be used as a cargo-lander variant with increased payload.

7 parts

50.48t (38.23 fuel, 12.25 dry)

350 ISP engine (lc5-dese)

3491 dV

0.80 Kerbin TWR (Tylo TWR of 1 on start of de-orbit burn on Tylo, will increase substantially as the burn goes on, ending in a Tylo TWR of ~3.5 with empty descent tanks upon touchdown)

Anyhow...

Will be issuing an updated test release this evening with the new balance on the parts. Hoping to get a few moments to re-create the example ships for this release, as I think I'm nearing the stage where the parts should be stable enough that the examples should not be breaking constantly.

If no large problems are found with this test release I will probably open it up as the first public beta release, likely Monday or so.

Edit:

While doing balancing, I found the need (desire?) for oversized ascent fuel tanks for the LC2 and LC3 pods, so they can act as dedicated ascent modules in multiple configurations. For example in the previously mentioned Altair-styled lander, I had to use an additional fuel section below the pod to enable proper ascent dV; with a larger ascent tank this extra fuel section is eliminated, reducing overall mass of the lander and resulting in a much cleaner looking 2-stage setup (and proper RCS balancing without the extra mass hanging below).

So, I -will- be doing up a second mesh-switch option/variant for the LC2 and LC3 pods. However, these will likely come with a future update; expect to see them along side the skycrane and service modules in a 1.1 update (after all current stuff is -finished-).

More Edit:

Adding some updated images (if it ever updates...):

Javascript is disabled. View full album
Edited by Shadowmage
Link to comment
Share on other sites

I'd like to issue some kind of apology (to those who care, mostly Shadow), as my contributions may be a little late. I've been pretty busy.

And a personal note to Shadow; I won't be able to get on later as I promised; My girlfriend was emitted to the ER this morning and I need to be there with her.

More apologies for being useless.

Cheers,

-Alli

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...