Jump to content

helldiver

Members
  • Posts

    677
  • Joined

  • Last visited

Posts posted by helldiver

  1. Just out of curiosity why are you using customised rpm instead of say a hyomoto or wari screen is it a personal choice, not a dig at you just curious wouldnt that save you heaps of work and when stuff like hyomoto gets upgraded its seemless

    ttQWi3b.jpg

    RcXVv7V.jpg

    Do either of their RPM screens do the above? Let me know. The only thing Wari's edit does is clear up the RPM screens so that they are more visible as well as add more information, right?

    Neither of them show the proper altitude and speed tapes the way an ADI does. Neither of them work for when you have to have a custom screen that doesn't use stock displays. Example; the laptops can't use stock RPM displays since it uses a pseudo "Mac book" like display which deletes the hash marks as well as different buttons labels. In other words, you have to edit the text files, PNG/TGA artwork, and various components of an RPM screen in order to get it to do what you want it to do.

    The EWBCL uses touchscreens which requires that the hash marks and labels on a stock RPM screen be deleted. Going to do a stream specifically dedicated to this soon.

  2. The KSO seems to use an old version of the Hyomoto MFD. It also looks like the MFD stuff is in the KSO folder directly. Is there a way to update the KSO MFD version, or is it customized somehow?

    All that will be updated once the EWBCL is up. It's going to use customized RPM screens hence it uses its own folders. I'm trying to fix the ADI to have proper numbers and tapes but it's been a hassle.

  3. Unless its changed, the nose cone is fixed in place and the area where the nose cone is is too small for a mini docking port.

    Exactly.

    There is no mounting anything in the nose. If you don't put the nosecone you'll have RCS problems.

    KSO EWBCL RCS Module

    Murika Superstellar Inc.

    Installed just behind the radome, the KSO EWBCL features a forward RCS module to help balance the craft during translation. Integrated into the nose is the EWBCL's flight computer, reaction wheel, and SAS.

  4. AHHHHH its so beautiful I think I am gonna cry! Are the seats a little close too the control panels? Other then that its beautiful, magnificent, bravo!

    Yeah they were. They've been moved back since those shots were taken. :D

    There's still a lot more involved. Once I get it I have to inspect it all and almost always more changes occur (such as adjusting seats further).

  5. Update

    -I know I said I wouldn't put up any more previews until my testing streams. But I decided to post some progress shots since I know a few folks appreciate them.

    Notes

    -KSO S25 had the crew reduced to 6. This was because the 6 chairs in the crew deck looked too crowded/busy. So I reduced it to 4. Gives me space to fit more space junk in there.

    -KSO S25 flight deck fashioned after 787. Uses touch screens.

    -Has a simulated EICAS display

    -Does not have analog gauges, but relies on RPM displays

    -FMCs are the actual RPM screens. Additional screens are hardset/cardcoded to specific displays. S25 uses 4 "real" RPM screens as opposed to 6 like the standard KSO uses.

    -Touchscreens

    -Panel hood is really low, for improved visibility.

    c9XWfNG.jpg

    mfVGDcI.jpg

  6. How long has it been showing up? Since before version ~2.x.x of Module Manager? Or after?

    I'm not sure. Once I get the KSO 25 done and we're testing, I'll run some tests to see.

    Nope I haven't messed with anything. Any sure-fire way of fixing it?

    The way I do it, is I just re-save my craft files after fixing the engines in the VAB. Seems you only have to do this once. Discard the stock craft files in the ships folders, and replace with the ones you saved (which should be in your saved games ships folder).

  7. The Block 7 craft file doesn't seem to retain the action keys pertaining to engine trim/pitch. Is this a known issue and is there a fixed version of the craft file out there?

    This is a mysterious issue that sometimes shows up. It has to do with editing engine values in the config files. Did you change the TWR of the OMS engines? The other cause seems to be updating or replacing the km_Gimbal.dll file.

  8. Knowing Helldiver he's probably just getting into the boring details that aren't really "update" worthy at this point. I seem to recall the same thing happening a few times with the other phases.

    You hit the nail on the head and broke the hammer and the nail.

    The other problem which goes along what you said, is that most folks on here don't know what they are looking at. So it confuses people further or they start making suggestions which slows me down. Suffice to say, I've been working all week on the interior.

  9. Sure, I'll separate it myself if needed. Having options from the start, though, would be really nice.

    Alright, let me expand on that.

    Like Freeman said, it would take you just a few minutes to delete or not move parts you don't want.

    So what happens if I split the mod into three+ sub mods to make it more convenient for you?

    -We don't have an installer. If someone where to program a Mod installer for us (or for the KSP modding community in general), then we could probably have a system that allows you to cherry pick what parts of a mod you'd like. One reason why I support moving all of KSP Modding to the Nexus. Nexus manager allows mod authors to create an installer script enabling the end users to cherry pick parts of the mod they wish to install.

    -We're just gamers like you with limited time and only so much of that to devote to modding

    -Because the mod uses resources from one part to the other, and because the mod relies on RPM resources I made that are shared, it becomes a troubleshooting nightmare when I update one part of the mod (for example the KSO) and then have to make sure those updates get to all the other mods (Satellite Parts, KSO 25).

    -There are way too many files and it is too easy to forget one, or screw up the download. Forget to update a DLL in one and then we can't figure out why someone is having an issue in the Station IVAs but they work fine in the KSO. Crap like that starts to happen and has happened already in our project, hence the migration and consolidation of the RPM folders.

    -Then we have the issue of having to upload 3 separate Zip files, plus another 3 Separate zip files to Mediafire, plus all the various alternate files after the first 3 got changes. And if I discover an issue in one, odds are it affects the other two so they all have to be tracked down and updated.

    -Making changes to one file make it easier for Nazari and I to drag and drop those changes to any other similar file within the same installation environment.

    So in the end, what would you guys rather me spend my time? Hounding down and verifying three separate mods and dealing with all the issues and potential bugs that would cause? Or spending that time on new mods and content for the KSOS project?

  10. Just out of curiosity, why did you decide to go with LFO boosters instead of true SRBs? I personally always swap out the LFO boosters for the ARM SRBs.

    KSOS project will always use LRBs as opposed to SRBs. This is do to Center of Lift, and launch profile issues. LRBs allow Nazari to keep things simple for both himself in a configuration standpoint, keeps download footprint small do to the lack of needing special fuel plugins, and keeps things simple for end-users/players. Basically LRBs allow us to "plug and play" the shuttles included in the mod. :D

    -Easier to balance TWR's

    -Easier to adjust amounts and fuel efficiencies.

    -Scalability with other mods (MechJeb)

    -Easier to fix Center of Lift/Center of Mass issues.

    -Are more precise in terms of maintaining the weight location during ascent.

    SRBs work differently in terms of how their weight works. Nazari can chime in. I believe they tend to be nose heavy during the ascent instead of tail heavy?

    SRBs also have an issue regarding thrust to weight, being significantly heavier for the amount of thrust they produce.

    SRBs nozzle for a while couldn't be managed properly by thrust vectoring plugins. Although I believe Nazari said those are no longer issues since the latest plugins allow gimbaling of SRBs. Either way, I'd rather keep things simple. Aside from aesthetics or "just because" I haven't seen a need to make them true SRBs.

  11. Shiny!

    So question: are the lifters interchangeable on the KSO and Super? I.e. shared mounting bracket - can I put the Super external tank onto the KSO and vice versa?

    Yes, technically.

    However, the super 25 might clip into the lower mounting bracket of the standard KSO's EFT. Also, I'm not certain at this time, but the way the LRB's attach to the EFT on the S25 may be different than the surface attach method used in the original KSO.

  12. Now it would only be Energia style because the S25 had main engines so it would only look like the Energia.

    Thank you.

    I believe there was a misunderstanding. I'm not making Energia from Buran. To make the Energia boosters and design, would take too long for the amount of time I have available for this project. This project is already taking way too long as it is. Energia type boosters are also 4x more complicated to balance than the KSO Lifter 2 LRB+EFT design.

    The design of the Super 25 lifter's boosters are inspired by Energia in looks only, but not in function.

    I prefer not to split the lifter up into sub-components for the following reasons:

    -If you want a lifter that comes in parts (cones, bottom end, mid section), download any number of awesome mods that provide that. Adding yet another EFT, SRB, LRB parts kit is a waste of my time.

    -It makes it difficult for Nazari to balance properly since you end up with fuel in various sections all being used up in different ways complicating things significantly.

    -We have enough complaints in this thread from people not even able to fly the stock KSO that comes in the download... the thread would fill with complaints about a multi-part LRB/EFT solution that doesn't function well for them.

    -This project isn't designed to cater to advanced KSP users. I'm trying to target folks that want a shuttle that's easy to use and is an addition to gameplay content that doesn't become a chore on its own.

    Hope that clarifies things.

  13. Update

    Q1d7W8E.jpg

    isXLjCG.jpg

    To Do

    -Nosecone Flight control systems texture details.

    -Any additional art support that may come up.

    -All Unity/KSP integration (Nazari's end). First flights have already begun which returned some issues that have been solved but required some art assets.

    -Interior

    -Lift vehicle (possibly Energia inspired)

    Optional

    -If time permits, I will include the Airstair truck so your Kerbals can disembark from the KSO EWBCL

    -KSO EWBCL does not have an airstair

  14. What will be the crew capacity for the super 25?

    Eight (8)

    I'll be streaming tonight.

    Hmm, one piece body. No more LES I guess :(

    I want to eventually revisit the KSO and it will get the same treatment as the Super 25, including welding the rear, cargo bay, and cockpit all into one. Part of that update I also want to improve the front window fascia as well as improve IVA visibility. But that won't be for a while.

×
×
  • Create New...