Jump to content

FusTek Station Parts Dev Thread (continuation of fusty's original work)


sumghai

Recommended Posts

Should I remove MechJeb from most modules, keep the reaction wheels, and redefine the crewed compartments as basically glorified versions of Hitchhikers (so that they don't auto-populate with crew at launch)?

I'd throw my vote in favor of this.

Link to comment
Share on other sites

I'm also tempted to strip the modules of MechJeb functionality (with the exception of the Utilities Modules, which are considered the "command centre" for space stations), but keep the reaction wheels already built into the modules.

What does everyone else reckon? Should I remove MechJeb from most modules, keep the reaction wheels, and redefine the crewed compartments as basically glorified versions of Hitchhikers (so that they don't auto-populate with crew at launch)?

.

Yes and yes.

Link to comment
Share on other sites

If you're going for a realistic tug based construction then the modules simply don't need it. and adding control units to anything other than a command module would triple a modules production cost. (for when career mode becomes available)

Moving MechJeb to a radial mounted module would be beneficial to everyone. for those who don't have MJ, there game would not be trying to load modules that don't exist (unecisary processor drain). for those that do, it would mean a lower component count. (component count affects game speed as well as part count)

Edited by abrr2000
Link to comment
Share on other sites

It's slightly annoying (even for myself) to be launching modules with crew already assigned to them, when in fact they should be launched uncrewed first and then visited by ferrying vessels.

I've noticed that Jeb has a habit of stowing away on unmanned missions if there's a place for him to hide.

I'm also tempted to strip the modules of MechJeb functionality (with the exception of the Utilities Modules, which are considered the "command centre" for space stations), but keep the reaction wheels already built into the modules.

I agree with this idea - especially if there's a good way to attach a removable MJ that can be used while launching other modules. Once joined to the Utilities module, there's no need for every component to have MJ functionality anyhow. But keeping the reaction wheels in all parts is a good idea, provided that it doesn't cause a station to torque itself apart.

Should I redefine the crewed compartments as basically glorified versions of Hitchhikers (so that they don't auto-populate with crew at launch)?

Works for me. I look forward to it!

Edited by HeadHunter67
Link to comment
Share on other sites

after you mentioned about mechjeb I wondered if this was the cause of the Lag on my ship, so I decided not to wait and strip it from the .cf files. and while I was there I noticed something odd. your not using the SAS system or standard RCS. instead your using permanent torque which uses no resources at all. neither of these were the cause of my lag, though removing them did help a little. however I did find it odd and not just a little bit cheaty. especially as I prefer to know where my magic torque is coming from. is it supposed to be a temporary thing?

Link to comment
Share on other sites

So I've finalized my decision and updated the Karmony module CFGs to the new control scheme:

- All crewed Karmony modules have been moved into the Utility tab, where the stock Hitchhiker crew container is located

- Nearly all of said modules have been stripped of ModuleCommand

- Simiarly, MechJeb has been removed from most modules; a space station doesn't need that many points of control

- Only the Karmony Utilities modules still retain MechJeb and ModuleCommand, as they are intended as the "core" of any space station - essentially, they become probes with crew-carrying capability

With this arrangement, users will (for the most part) no longer have to worry about stowaways at launch. The exceptions are the Utilities modules, where the crew will still have to be manually evicted with Crew Manifest or via the pre-launch vessel selection - a small price to pay in order for the station to remain controllable while unmanned.

I won't be making a FusTek'd radial MechJeb control box, though, for the following reasons:

- The idea sounds horrendous

- The Utilities module must have them built-in for station-keeping

- Lifter rockets carrying other modules into space can already have their own (stock) probe units; once in orbit, the lifter probe can be jettisoned, leaving the (uncontrollable) modules to be fetched by orbital tugs or robotic arms.

I'll see if I can release a patch this weekend, but no promises. Been busy working on real life and SDHI stuff.

Link to comment
Share on other sites

I believe reaction wheels are supposed to use electricity when you maneuver. I know my drain increases when I try to maneuver my small probes.

OK, that's what I thought he might have meant. I just wanted to be sure, because some people use the words "magic torque" when referring to reaction wheels because they think that the concept of a reaction wheel somehow violates Newton's Third Law. Such people should be used for rocket-sled testing, but that's just an opinion. :)

Link to comment
Share on other sites

Lifter rockets carrying other modules into space can already have their own (stock) probe units; once in orbit, the lifter probe can be jettisoned, leaving the (uncontrollable) modules to be fetched by orbital tugs or robotic arms.

I use the "lifter delivers a module and orbital delivery/maneuvering system to LKO, after it delivers the module to the station the orbital delivery/maneuvering system is deorbited" method myself.

Link to comment
Share on other sites

When there is no crew inside one of the fustek modules, does the IVA still render or is it "turned off" so that it no longer uses computer resources? I noticed having a lot of parts with IVA really slows down the game significantly. I really only need one IVA scene active at any one time. Hopefully this reassignment to the Utilities tab may address this?

Link to comment
Share on other sites

Although it is not rendered into separate portraits to be displayed bottom-right, probably the slowdown is due to all those IVA spaces actually existing (even if empty) inside the various crew-able modules. Even though half of the interior would get likely backface-culled, the rest would get rendered then occluded by the exterior of the module.

Link to comment
Share on other sites

shame there's no way to turn the cameras on or off in game (for non command modules). after all, you can EVA by right clicking a hatch. this also works with the new docking ports if you set them right. however you cant get in via the new docking ports because there's nothing for the kerbal to grab on to.

Link to comment
Share on other sites

this also works with the new docking ports if you set them right. however you cant get in via the new docking ports because there's nothing for the kerbal to grab on to.

The IACBM's hatch mode is mainly designed for emergency egress. If you want regular in-and-out EVA, you will need to add an airlock module to your space station.

I thought I made this clear in the documentation...

Link to comment
Share on other sites

Its too bad all of the IVA's are still rendered. I may go in and disable all of them except for maybe one particular type of fustek part. I dont really care or need to see all of them being rendered, especially when they are all the same interior and have a bunch empty seats.

Link to comment
Share on other sites

Its too bad all of the IVA's are still rendered. I may go in and disable all of them except for maybe one particular type of fustek part. I dont really care or need to see all of them being rendered, especially when they are all the same interior and have a bunch empty seats.

That may be a good idea for now.

I think the reason for the strange yellow lights and the associated performance drop is due to the part origin offset required to fix the R0.02a exploding hatch issue, which means the positions of the externals and internals no longer match up. As soon as I finish the SDHI stuff, I'll start working on properly-positioned IVAs.

Will the Next update be a bit better optimized? I have a strong computer, and this pack will crash me after about 20 minutes.

Try removing the internals for now, since I think that's what causing the performance issues (as above).

Link to comment
Share on other sites

Try removing the internals for now, since I think that's what causing the performance issues (as above).

There are a few opportunities for optimization, although it would require some effort, and some could be potentially save-breaking: If the "adapter" variants were reorganized so the endcap normal / diffuse textures were model002 and model003, and the chassis maps were -000 and -001, then the "adapter" and non-"adapter" models could share textures, and the models and cfg for both variants could be in the same directory (both would use -000 and -001, and the adapter would also use -002 and -003; the hab and science modules could also share the emissive maps). The adapter texture maps can be rescaled to 1/2 size in both axes and still have a good level of detail - right now, each endcap is budgeted as much texture space as the entire rest of the part. One could also convert the PNG to TGA format - this isn't a memory optimization, unless the PNG memory bug is still present, but it is a video performance and image quality optimization, since the game does not create mipmap chains for PNG images. Any part using textures created from a PNG source will show sparklies and other artifacts of a non-mipmapped image, and it is a less efficient use of the GPU (granted, this game is CPU limited for most users). There are some other options to reduce the memory footprint, but it entails some more radical efforts that increase the maintenance cost for sumghai to implement them - like replacing some textures with dummy textures and using texture substitution that KSP 20.x or 21.x introduced.

FWIW, I've resized the endcap textures and converted all of the textures to TGA in my local copy. I'd love to have the adapter models reorganized so they could share textures with the non-adapter variants, so I could keep both versions around without duplicating texture and normal maps.

Link to comment
Share on other sites

I'd like to suggest simplifying the power systems, as I know from experience that a complicated power system is a frame rate killer in KSP.

1) everything does not need a battery.

when generating or draining power KSP must move it from or to any available batteries. the more batteries it has, the more complex the maths becomes.

and lets face it. space stations simply don't need 20 tons worth of batteries. all they need is enough to get them through the short night time cycle.

as such I would suggest limiting the components with batteries to the key modules only. AKA utility, observation and possibly node.

2) simplify the power draw.

for example the utilities module is both generating and using electrify.

adding and subtracting power from modules that are permanently on within a single unit is a waste of KSP's processor power. instead combine these number inside the cfg file, rather than making KSP do it hundreds of thousands of times in game.

other than the utility and observation, the only real power draws worth simulating constantly are the habitation module and the science module.

Habitation, because you want to recycle that air. science because science takes power. however I added all the power drain on the science module to the lights, because you only do science when the lights are on ^^

3) remote tech control with no kerbals (not power I know, but still something that needs adressing)

the utilities module has remote tech command built into it. this is great. however with a min crew requirement of zero this essentially breaks the whole point of remote tech. It should have at least a min crew of 1. or if your going to stay true to the mod, that number should be raised to 2

Link to comment
Share on other sites

  • 3 weeks later...
...Try removing the internals for now, since I think that's what causing the performance issues (as above).

How is this accomplished? Do I just need to remove the INTERNAL{...} sections from the .CFG of the parts I want to disable IVA on?

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...