Jump to content

Araym

Members
  • Posts

    609
  • Joined

  • Last visited

Everything posted by Araym

  1. 21.8GB is my "final" installation. I have generally more than one, trimmed HEAVILY down, just for the "testing" that I need each time: generally I have secondary installation, for example, for "graphic visual testing"... one for pre-viewing any mods that add new parts (to check if I like them, before switch them in my "final" one)... and then one or more for troubleshooting/balancing between different mods/any needs could possibly arise, just to have some sane loading time. Up to now, I just found 2 solid boosters referencing textures from KSP up only to 1.8. I made a post about them in the SXT releas thread
  2. I'm not an actual "super fan" of too many MM patches, to the point that, probably, I will do an extensive rework of any file I'm using in an "hardcore" mode alike yours, in the future. I'm back to KSP after a long absence (I was basically bored to have, mostly, the need to contiously change/update mods to the latest version, as I was doing more "coding and patching" than actually playing, to the point that I'm relived that 1.12 will be the "final version": aside minimal, future, patches, the game is finally finished and mods will settle) and I'm just making a list/check of all the thing that I want in my own version. ... but on my end, the MM-patches are the last of my problems: yes... they take "some time" to load, but done it once, MM is generally going to loads the parts from its own cache... ... the problem is after then: I have so many mods installed that (even if my pc is not a super-latest pc gaming, it is not a bad one for sure: I made it for be sure to be above any KSP mod needs I will ever have) is the UNITY needs to keep EVERYTHING pre-loaded that keep my startup time infinite... and that is not so much different if the game has to read the filse from dozen of single cfg, or from the bigger, single, MM-cached list. Just for your reference (counting not only part mods, but also visuals, planetary systems, and all the"extras" that I like) up to now, my GameData folder is 21.8 GB... that is A LOT of bytes to pre-load... ... hardcoding most of the MM patches in actual, final, cfg versions could eventually save me one minute or two, of the dozen that my KSP version need, anyway, to pre-load.
  3. Hi, @linuxgurugamer Thanks (as always) for all you efforts to keep one of the thousand mods, that you adopted, alive for modern KSP. Coming by from the discussions of another couple of mods fighting with all the textures hidden in the "zDeprecated" folder, and during a general check of any, similar issues (that you resolved by the creation of the genuinely simple-but-amazing scripts that go fishing them automatically) I noticed, sadly that, a couple of parts are referring to textures not even in the game anymore. It's not a complete list, but only about those that I found up to now: "SXTCastor30" solid rocket booster (in the needs of textures from Squad's "solidBoosterBACC") "SXTSize2SRB" solid rocket booster (in the needs of texture from the "MassiveSRB") are both refering to those present in KSP only up to v.1.8.xx For later KSP version, even if technically the parts are loaded, they obviously show up with messed visuals, as the textures present in game are mapped totally differently. Your scripts, sadly, are not helping, as the file naming reference is actually the same, but the actual texture is not. There is not really a "simple solution" for it, rather than having the original texture files from a version prior or equal to KSP v.1.8 and, manually, copy-paste them in game. On a personal level, I already sorted out the problem (I have all the KSP version needed... actually I have them up to v.0.17 archived ), but I understand that could be more of a problem for a future STX "public release" to plunge in Squad owned assets, even if outdated (... even if, technically, there are plenty of "vintage part collections" that are simply redistribuiting old Squad files)
  4. Sadly, even if more than capable to "fiddle with KSP" in its own "cfg - sort of software" language, I'm not capable to write a single, real, line of coding for script alike the one made for STX. Even if it could be simple to check the STX source, make some changes to the original coding and recompile it for M2X - and M3Expansion too, as parent mod, I do not even know how to, then, recompile it to an actual, working, script.... I'm more the kind of guy just capable of "brute-force" the solution by manual copy/paste... By the way: even SXT is not totally perfect... I found a couple of STX parts that are referring to textures not even in the game anymore (one of the mods that I needed to fix, on my end, by searching Squad assets in old KSP versions) - namely (up to now) at least 2 solid boosters that are in needs of textures present in pre-1.8 KSP versions
  5. For "myself" I do often even "worse" than simply copy some texture (... I basically "rewrote" my entire game... ahahahahah in search of an "impossible balance" between stock and mods, nothing is safe). But even doing that, I generally make my changes thru MM just because, eventually, I can revert/change (keeping them organized) my own, not caring if in the meanwhile I eventually copy/paste/install new versions (And in this case, I needed just "one copy" for each texture, that could then be addressed for multiple parts by my MM patch... also by themself, the patch could be just temporary: once the original mod is eventually updated to "its own way" to deal with the texture problem, I just need to fiddle with MY files, not its own folders) Put in case that I re-install a mod over my modifications, if them are done as MM patch, they are indipendent... The problem here is that, "for myself", I actually moved the files needed, made my patches (... I have a "Squad_MM" folder where I put my personal changes to stock parts, that I'm using to store the missing textures), then thought to offer them to "everybody", just changing the paths to those available in a "stock install" (... so pointing to the "zDeprecated" folder), not knowing that the game itself DO NOT load these folders (until I tested the "to the public version" of the patches) ... I just thought to "be helpful" for other peoples, but failed. I cannot "re-distribuite" squad owned textures, technically - even if in a lot of mods they are minimally changed and reused - so... well... I basically commented out the part related to "use my patches" (as they are actually not working as they are wrote) but basically added the comments about "what is needed to do" to make them work, they are still useful at least to actually find them with their folder addres... then is it just matter to "copy them" outside and do a little adjustment to my patches and/or place them, with minimal name changes, in the mod folder itself. I prefer the "external folder" route + MM patch, rather than put them directly in the mod folder, because: 1. I do not need to make multiple copy of the same texture; 2. sometime they need to be renamed, accordingly to the part needs, as the blank placeholder texture, that could be eventually overwrtten by an accidental copy/paste of the mod itself in a latter moment (I'm not new to have lost my changes when, by chance, I had to reinstall/move things, as clumsy as I am ); 3. if I find a more "elegant" way to repair things, I can eventually "share" to other people that are suffering similar problems like mine, avoiding them the time spent by myself in resolving issues (also pointing out the problem and eventually an actual solution to the mod author itself, that could then grab my patches and modify it officially) Example unrelated: ... I found some similar "errors" in other older mods that I keep alive for myself... Being "old", they are eventually even referring to textures not even present anymore in the game. I have no problem to take the needed textures/assets from older KSP releases (I basically have ALL the KSP versions since 0.17 in my own pc... probably I could find, not well archived, even more older ones, having bought mine since v.0.13/0.14) and add them to the latest version for myself... but I (technically) cannot redistribuite those "solutions" because they are plunging in "Squad owned textures/assets" (even if they are old... even if it's tollerated, as a lot of mods keep alive "old parts", basically copying/pasting the original Squad ones).
  6. I guessed it... ... the only alternative is manual move the needed files outside (I did it) or make a little script that, automatically, move the needed files (something alike was done for STX, that has a small bak file that fishes for the zDeprecated textures).
  7. BAD NEWS! Even if my MM patch, to change the model textures, are pointing to the right ones, somehow KSP is not really react to the part in "zDeprecated" folder. Dunno if its ReStock acting weird on my install, some typos made by me or the base game behaviour that avoid to load textures in those folder. As VERY ROUGH workaround, for myself, I simply took the needed textures, copied out of Squad folder in one of my own creation, and adjusted my above patches accordingly (with the new custom folder address, rather than the "Squad/zDeprecated/..." one). Obviously, that way, no need for any restockwhitelist.
  8. BAD NEWS! Even if my MM patch, to change the model textures, are pointing to the right ones, somehow KSP is not really react to the part in "zDeprecated" folder. Dunno if its ReStock acting weird on my install, some typos made by me or the base game behaviour that avoid to load textures in those folder. As VERY ROUGH workaround, for myself, I simply took the needed textures, copied out of Squad folder in one of my own creation, and adjusted my above patches accordingly (with the new custom folder address, rather than the "Squad/zDeprecated/..." one). Obviously, that way, no need for any restockwhitelist.
  9. You can add the list I did above to the original whitelist, eventually: I prefer to keep my edit in a separate file/directory, just in case (... a new install, in which I install from the release zip... a new release only partially resolving issues... me, being dumb, forgetting of some of my adjustment and overwriting original files...)
  10. Are you using ResStock? (the first thing that could mess with Squad texture loading) EDIT: Yeah: a file is missing in the "whitelist" needed, if using ReStock. Added in the above message by me, so it still easier to find
  11. Some textures are missing after some model swapt by Squad (namely: new docking ports from 1.12.2, but also a lack of update to past engine rework, as Mk3Expansion still uses the old deprecated textures)... For the part "M3X_size1adapter" (folder: "GameData/Mk3Expansion/Parts/FuelTank/mk3size1adapter") it lacks the placeholder "Mk3Adapters.dds" file: copy/paste it from any other Mk3Expansion tank nearby... it's just a placeolder texture needed then to kick the swap to the Squad texture itself by the part cfg file... All the other issues (waiting an update) are resolved by a nameless volunteer (a.k.a. "me") that has prepared some fast MM patches for 1.12.2 A "basic" ModuleManager patch file is needed to be created, plus a second whitelist file in case of ReStock users, complementary to the one already in the mod, to avoid eventually Restock itself will mess with texture loading (my list are ADDING the missing texture in a new whitelist: the old one is still needed!!!). Place them anywhere inside "GameData" folder (I made a "Mk3Expansion_MM" folder, to have them separated by the mod itself, but easy to find and be erased when it will be updated): Create a M3X_texture_fix.cfg file (mandatory for everyone) and copy/paste this code, to have the updated texture folder paths: @PART[M3X_Heavyprop] { !MODEL{} MODEL { model = Mk3Expansion/Parts/Engines/HeavyProp/Model texture = model002, Squad/zDeprecated/Parts/Engine/liquidEngineMainsail_v1/model002 texture = Jet Engines, Squad/Parts/Engine/jetEngines/Jet Engines texture = model000, Squad/zDeprecated/Parts/Engine/solidBoosterRT-10_v1/model000 texture = rotordisc, Mk3Expansion/Parts/Engines/HeavyProp/rotordisc } } @PART[M3X_Linearaerospike] { !MODEL{} MODEL { model = Mk3Expansion/Parts/Engines/LinearAerospike/Model texture = Mk3Adapters, Squad/Parts/FuelTank/adapterTanks/Mk3Adapters texture = Mk3CargoBay, Squad/Parts/Utility/mk3CargoBay/Mk3CargoBay texture = model002, Squad/zDeprecated/Parts/Engine/liquidEngineMainsail_v1/model002 texture = model004, Squad/zDeprecated/Parts/Engine/liquidEngineMainsail_v1/model004 } } @PART[M3X_ConcentricAerospike] { !MODEL{} MODEL { model = Mk3Expansion/Parts/Engines/ConcentricAerospike/Model texture = Mk3Fuselage, Squad/Parts/FuelTank/mk3Fuselage/Mk3Fuselage texture = Mk3CargoBay, Squad/Parts/Utility/mk3CargoBay/Mk3CargoBay texture = Mainsail2, Squad/zDeprecated/Parts/Engine/liquidEngineMainsail_v1/model002 texture = Mailsail_E, Squad/zDeprecated/Parts/Engine/liquidEngineMainsail_v1/model004 } } @PART[M3X_CLEAVER] { !MODEL{} MODEL { model = Mk3Expansion/Parts/Engines/CLEAVER/Model texture = Mk3Adapters, Squad/Parts/FuelTank/adapterTanks/Mk3Adapters texture = Mk1Structural, Squad/Parts/Structural/mk1Parts/Mk1Structural texture = Mk3CargoBay, Squad/Parts/Utility/mk3CargoBay/Mk3CargoBay texture = Turbojet_Emissive, Mk3Expansion/Parts/Engines/CLEAVER/Turbojet_Emissive texture = model002, Squad/zDeprecated/Parts/Engine/liquidEngineMainsail_v1/model002 texture = model004, Squad/zDeprecated/Parts/Engine/liquidEngineMainsail_v1/model004 } } @PART[M3X_serviceBay] { !MODEL{} MODEL { model = Mk3Expansion/Parts/FuelTank/ServiceBay/ServiceBay texture = Mk3Fuselage, Squad/Parts/FuelTank/mk3Fuselage/Mk3Fuselage texture = Mk3CargoBay, Squad/Parts/Utility/mk3CargoBay/Mk3CargoBay texture = ServiceBay, Squad/zDeprecated/Parts/Utility/ServiceBay_v1/ServiceBay texture = z-400BAttery000, Squad/Parts/Electrical/z-400Battery/model000 texture = model001, Squad/Parts/FuelTank/RCSTankRadial/model000 texture = RadialTanks, Squad/zDeprecated/Parts/FuelTank/FoilTanks_v1/RadialTanks texture = RadialTanks_N_NRM, Squad/zDeprecated/Parts/FuelTank/FoilTanks_v1/RadialTanks_N texture = ksp_r_xenonTank_diff, Squad/Parts/FuelTank/xenonTankRadial/ksp_r_xenonTank_diff } } @PART[M3X_StackDockingPort] { !MODEL{} MODEL { model = Mk3Expansion/Parts/Utility/DockingPorts/Stack texture = Mk3CargoBay, Squad/Parts/utility/mk3CargoBay/Mk3CargoBay texture = model000, Squad/zDeprecated/Parts/Utility/dockingPortSr_v1/model000 texture = Mk3Adapters, Squad/Parts/FuelTank/adapterTanks/Mk3Adapters } } @PART[M3X_InlineDockingPort] { !MODEL{} MODEL { model = Mk3Expansion/Parts/Utility/DockingPorts/Inline texture = Mk3CargoBay, Squad/Parts/utility/mk3CargoBay/Mk3CargoBay texture = model000, Squad/zDeprecated/Parts/Utility/dockingPortSr_v1/model000 texture = model001, Squad/Parts/FuelTank/RCSTankRadial/model000 } } @PART[M3X_AligningDockingPort] { !MODEL{} MODEL { model = Mk3Expansion/Parts/Utility/AlignedDockingPort/Model texture = model000, Squad/zDeprecated/Parts/Utility/dockingPortSr_v1/model000 } } ... then, create also a new M3X_revised.restockwhitelist (safe net for ReStock users... not needed for anyone not using it) to have added the missing texture in a new whitelist (I prefer to have it in a separate file/folder, to find/remove it easily when the mod will be updated: DO NOT ERASE the one provided by the mod!!! This is a complementary file to it) Squad/zDeprecated/Parts/Engine/liquidEngineMainsail_v1/model002.dds Squad/zDeprecated/Parts/Engine/liquidEngineMainsail_v1/model004.dds Squad/zDeprecated/Parts/Engine/solidBoosterRT-10_v1/model000.dds Squad/zDeprecated/Parts/Utility/dockingPortSr_v1/model000.dds Squad/zDeprecated/Parts/FuelTank/FoilTanks_v1/RadialTanks.dds Squad/zDeprecated/Parts/FuelTank/FoilTanks_v1/RadialTanks_N.dds Squad/zDeprecated/Parts/Utility/ServiceBay_v1/ServiceBay.dds Let me know if anything else is missing (I could have, eventually, overlooked something). Enjoy and Space Safely! EDIT: At least for me, those patch are not totally working: the textures in the various parts present in "Squad/zDeprecated" folder are the needed one for make the patch work, but (at least for me) probably a combination of ReStock and some basegame rules, does not allow them to be loaded: I moved them out in a folder of my creation, adjusted the above patches accordingly, and the problem seem resolved, but, obviously, it's a workaround that has to be done on per player basis,, each instalment of the game, manually. Sorry if you are in the same situation, with missing textures, even after my advised patches...
  12. Some textures are missing after some model swapt by Squad (namely: new docking ports from 1.12.2, but also a lack of update to past engine rework, as Mk2Expansion still uses the old deprecated textures)... ... but tankfully, (waiting an update) a nameless volunteer (a.k.a. "me") has prepared some fast MM patches for 1.12.2 A "basic" ModuleManager patch file is needed to be created, plus a second file in case of ReStock users, to avoid eventually Restock itself will mess with texture loading. Place them anywhere inside "GameData" folder (I made a "Mk2Expansion_MM" folder, to have them separated by the mod itself, but easy to find and be erased when it will be updated): Create M2X_texture_fix.cfg (mandatory for everyone) for the updated models/textures @PART[M2X_LinearAerospike] { !MODEL{} MODEL { model = Mk2Expansion/Parts/Engines/Aerospike/Model texture = mk2FuselageShort, Squad/Parts/FuelTank/mk2FuselageShort/mk2FuselageShort texture = Mainsail2, Squad/zDeprecated/Parts/Engine/liquidEngineMainsail_v1/model002 texture = Mailsail_E, Squad/zDeprecated/Parts/Engine/liquidEngineMainsail_v1/model004 texture = Mk3CargoBay, Squad/Parts/Utility/mk3CargoBay/Mk3CargoBay texture = mk2adapters1m, Squad/Parts/FuelTank/mk2Adapters/mk2adapters1m } } @PART[M2X_MATTOCKv2] { !MODEL{} MODEL { model = Mk2Expansion/Parts/Engines/MATTOCK/Model texture = mk2adapters1m, Squad/Parts/FuelTank/mk2Adapters/mk2adapters1m texture = Mk3CargoBay, Squad/Parts/Utility/mk3CargoBay/Mk3CargoBay texture = Jet Engines, Squad/Parts/Engine/jetEngines/Jet Engines texture = Mainsail2, Squad/zDeprecated/Parts/Engine/liquidEngineMainsail_v1/model002 texture = Mailsail_E, Squad/zDeprecated/Parts/Engine/liquidEngineMainsail_v1/model004 } } @PART[M2X_Turboprop] { !MODEL{} MODEL { model = Mk2Expansion/Parts/Engines/Turboprop/Model texture = mk2FuselageShort, Squad/Parts/FuelTank/mk2FuselageShort/mk2FuselageShort texture = Hammer000, Squad/zDeprecated/Parts/Engine/solidBoosterRT-10_v1/model000 texture = rotordisc, Mk2Expansion/Parts/Engines/Turboprop/rotordisc } } @PART[M2X_Servicebay] { !MODEL{} MODEL { model = Mk2Expansion/Parts/Utility/ServiceBay/ServiceBay texture = z-400BAttery000, Squad/Parts/Electrical/z-400Battery/model000 texture = mk2CargoBay, Squad/Parts/Utility/mk2CargoBay/mk2CargoBay texture = mk2FuselageShort, Squad/Parts/FuelTank/mk2FuselageShort/mk2FuselageShort texture = ServiceBay, Squad/zDeprecated/Parts/Utility/ServiceBay_v1/ServiceBay } } @PART[M2X_AligningDockingPort] { !MODEL{} MODEL { model = Mk2Expansion/Parts/Engines/Turboprop/Model texture = mk2FuselageShort, Squad/Parts/FuelTank/mk2FuselageShort/mk2FuselageShort texture = Hammer000, Squad/zDeprecated/Parts/Engine/solidBoosterRT-10_v1/model000 texture = rotordisc, Mk2Expansion/Parts/Engines/Turboprop/rotordisc } } @PART[M2X_ShieldedDockingPort] { !MODEL{} MODEL { model = Mk2Expansion/Parts/Utility/DockingPort/Model texture = mk2FuselageShort, Squad/Parts/FuelTank/mk2FuselageShort/mk2FuselageShort texture = dockpitportstd, Squad/zDeprecated/Parts/Utility/dockingPort_v1/model000 texture = light1, Squad/Parts/Utility/spotLightMk1/light1 texture = light1_em, Squad/Parts/Utility/spotLightMk1/light1_em } } Create M2X_revised.restockwhitelist (safe net for ReStock users... not needed for anyone not using it: ADD IT MANUALLY to the existing restockwhitelist or, for safety, create a new file only with these files, to complete the ones missing by M2X itself) (UPDATED for some other missing: copy it again if you have not the latest one) Squad/Parts/Utility/landingLegLT-2/landingLeg.dds Squad/zDeprecated/Parts/Engine/liquidEngineMainsail_v1/model002.dds Squad/zDeprecated/Parts/Engine/liquidEngineMainsail_v1/model004.dds Squad/zDeprecated/Parts/Engine/solidBoosterRT-10_v1/model000.dds Squad/zDeprecated/Parts/Utility/dockingPort_v1/model000.dds Squad/zDeprecated/Parts/Utility/ServiceBay_v1/ServiceBay.dds Let me know if anything else is missing (I could have, eventually, overlooked something). Enjoy and Space Safely! EDIT: At least for me, those patch are not totally working: the textures in the various parts present in "Squad/zDeprecated" folder are the needed one for make the patch work, but (at least for me) probably a combination of ReStock and some basegame rules, does not allow them to be loaded: I moved them out in a folder of my creation, adjusted the above patches accordingly, and the problem seem resolved, but, obviously, it's a workaround that has to be done on per player basis,, each instalment of the game, manually. Sorry if you are in the same situation, with missing textures, even after my advised patches...
  13. If any it's needed any "help", do not worry: call me also in PM to try to figure "what happened" to me. Some "facts" about the problem I noticed, and "how/where/why" in my install: I play win an heavy, modded, enviroment: having both Pathfinder, Snacks and B9PartSwitch, i personally "preferred" to have the tanks set following B9PartSwitch than Patfinder, so initially I removed the patch for Pathfinder itself and "deleted" the checks for it in the B9Partswitch tanks patch (because with it, even without the patch for Pathfinder, the B9 one was not loading): it started to throw the above mentioned error once, finally, it started to be seen by ModuleManager I moved to a clean install (without pathfinder at all), only with Snacks and B9Partswitch, but it also didn't work... I noticed the ":NEEDS[Snacks]" error (... it should be ":NEEDS[SnacksUtils]", so I corrected that too: the error didn't disappear... ... ... In the end, I basically "rewrote" all the patches, removing A LOT of various ":NEEDS" to a bare minimum (basically just a check between having or not B9Partswitch and/or the various Snacks/SncacksFreshAir/SnacksStress) knowing that I'm not going to play with a lot of the mods placed in the various checks (TacLS/USILS/etc etc) and, somehow, it started to work on my end In the end, I think that the problem is somewhere in the B9Tank patch, but I didn't figured "where", as basically, aside removing the (too many) :NEEDS, I basically copied it... so it should be some weird interaction at that level
  14. Hello again, @Angel-125, and sorry to bother you so much... ... as an hard fan of the old Kerbfleet by Kuzzter (and to recreate, eventually) a situation where my kerbals could eventually make Hydrazine on orbit, I was wondering if there are any template (somewhere) for that kind of "converter", and which part could eventually be (someway) balanced to became a "distillery" (crew cabins??? labs??? I would like a converter that could be used only by engineers, like a legacy about Bill being the one actually making it in Kuzzter's comic, obviously in a kind of conversion only from monopropellant )
  15. Question/Curiosity: browsing folders and files in Vanguard Technologies, I found a MM patch that adds "ModuleKrKerbalParachute" to some of the "kerbalEVA" definitions, namely the Default and Vintage ones (both for the male and female versions)....... ... should it been update also for the Slim and Future ones???
  16. Yeah... done it and working. ... I perfectly immagined was a non standard option somewhere to turn on... ... multiple time I even checked the Life Support Folder... ... but dumb as I am, I never noticed that little difference between cfg and txt (on my end, both opens in Notepad++) so I was wondering "... damn: the file are there! WHY are they not working???" <ME: dumb as always> Thanks for the answer
  17. Call me "dumb" (because.... I definitely am it, sometime-if-not-always), but, even if I enabled the "basic" SNACKS behaviour (related to Snacks usage and Soil production), I somehow fail to find how to enable "FreshAir" and "Stress" advanced one. It's done in the "Setting" Menu??? Is it functional only when starting a new save??? (because I cannot find it in the "setting" menu, in already started saves) Is it working only for career??? (because I'm not finding it, but for the moment I'm just settling my mods in a sandbox one) KSP 1.12.2 and latest SNACKS 1.27.3 here
  18. Update: In the end, with the original patches provided, I could not resolve the issue. Knowing that I'm playing with SNACKS and B9PartSwitch, I simply moved the "Extra_B9TankTypes.cfg" in an external directory (to find it easily, in case) simplyfing it only to the mod I know I'm using (so no Kerbalism, USILifeSupport or TACLifeSupport), and making a "nuked version", removing the various ":NEEDS[....]" in it (to have them loaded always, to avoid any issue), then also simplyfing the ":NEEDS" in the "Extra_B9Tank.cfg" file (also moved in the same external directory). That resolved it (for the moment)
  19. Hi here... I'm appearing again to advice, probably, about a B9PartSwitch problem: when using SNACKS and B9PartSwitch MM patches (both "Extra_B9TankTypes.cfg" and "Extra_B9Tanks.cfg"), I found my game throwing a fatal error by B9PartSwitch itself, prompting me to close the game once in KSP main starting menu. It took a while to, in the end, narrow it to a specific part of coding, inside "Extra_B9Tanks.cfg": in the definitions related to the Commodity tanks, every SUBTYPE related to Snacks itself has "SUBTYPE:NEEDS[Snacks]", but it should be "SUBTYPE:NEEDS[SnacksUtils]" EDIT: NOPE! That could be an issue, eventually, but the game is still throwing the same errors, even trying my modification. (I have errors related to all the parts trying to interact with "Extra_B9TankTypes" searching for the "tundraSupplySnacks" subtype) [LOG 20:40:04.659] DragCubeSystem: Creating drag cubes for part 'TE2.19.SH.Interstage' [LOG 20:40:04.733] PartLoader: Compiling Part 'TundraExploration/Parts/GOJIRAIII/TE2_19_SH_Tank/TE2_19_SH_Tank' [LOG 20:40:04.806] PartLoader: Part 'TundraExploration/Parts/GOJIRAIII/TE2_19_SH_Tank/TE2_19_SH_Tank' has no database record. Creating. [LOG 20:40:04.807] [DragCubeSystem]: Drag cubes not found or cannot be read for part Part. Generating New drag cubes. [LOG 20:40:04.810] DragCubeSystem: Creating drag cubes for part 'TE2.19.SH.Tank' [LOG 20:40:04.873] PartLoader: Compiling Part 'TundraExploration/Parts/GOJIRAIII/TE2_19_SS_AFT/TE2_19_SS_AFT' [WRN 20:40:04.918] [Part]: Cannot have ModuleCargoPart and ModuleInventoryPart on same Part [TE2.19.SS.AFT'. Removed ModuleCargoPart [LOG 20:40:04.947] PartLoader: Part 'TundraExploration/Parts/GOJIRAIII/TE2_19_SS_AFT/TE2_19_SS_AFT' has no database record. Creating. [LOG 20:40:04.947] [DragCubeSystem]: Drag cubes not found or cannot be read for part Part. Generating New drag cubes. [LOG 20:40:04.950] DragCubeSystem: Creating drag cubes for part 'TE2.19.SS.AFT' [LOG 20:40:05.019] PartLoader: Compiling Part 'TundraExploration/Parts/GOJIRAIII/TE2_19_SS_CARGO/TE2_19_SS_CARGO' [LOG 20:40:05.418] PartLoader: Part 'TundraExploration/Parts/GOJIRAIII/TE2_19_SS_CARGO/TE2_19_SS_CARGO' has no database record. Creating. [LOG 20:40:05.418] [DragCubeSystem]: Drag cubes not found or cannot be read for part Part. Generating New drag cubes. [LOG 20:40:05.425] DragCubeSystem: Creating drag cubes for part 'TE2.19.SS.CARGO' [LOG 20:40:05.523] PartLoader: Compiling Part 'TundraExploration/Parts/GOJIRAIII/TE2_19_SS_Crew_Pod/TE2_19_SS_Crew_Pod' [WRN 20:40:05.893] [Part]: Cannot have ModuleCargoPart and ModuleInventoryPart on same Part [TE2.19.SS.Crew.Pod'. Removed ModuleCargoPart [ERR 20:40:05.895] Module ModuleB9PartSwitch threw during OnLoad: System.Exception: Fatal exception while loading fields on module ModuleB9PartSwitch on part ---> System.Exception: Exception while loading field subtypes on type B9PartSwitch.ModuleB9PartSwitch ---> System.Exception: Exception while loading fields on subtype PartSubtype tundraSupplySnacks ---> System.Exception: Exception while loading field tankType on type B9PartSwitch.PartSubtype ---> System.Collections.Generic.KeyNotFoundException: No tank type named 'tundraSupplySnacks' exists ... and I HAVE the B9 tank definitions in GameData.
  20. ... and after all the "simulation", today was "The Day"! Today the Might(ly kitbashed) Saturn C-8 Nova is going for landing on the Mun! Direct Ascent style! It's said the even the seats of the gods were shaken, when the 8 F-1 engines on the S-IC-8 first stage roared at lift off... First Stage cut-off and second stage separation/ignition: Low Kerbin Orbit final burn/insertion, completed by the third stage S-IV-B: The satisfaction was palpable in the crew module, with Jebediah, Bill and Bob complimented each other, after having ride "The Beast" safely in space. But it was only the begin of their journey... After a check-out of every system, it was time for the Munar Insertion Burn, again performed by the S-IV-B's single J-2 engine: Everything went smoothly: after ditching the S-IV-B, it was time just to enjoy the ride until the Munar SOI... ... to perform the Munar Orbital Insertion... ... and then, be ready for the start of Munar Landing... ... that will be in a very "hystorical" place... "Kouston... Tranq... ehm... Armstrong Base here: the Eagle has landed." At this point, was just matter of performing the IVA on the Mun surface: The first was Jeb, eager to pay his homage to the place... ... then Bill turn... ... rapidly followed by Bob... ... to riunite the crew on Munar soil. Bill- "It's time to set the flag, lads..." Bob- "Flag??? What "flag"??? Nobody told me to take "a flag" with me!!!" Jeb- "Don't worry, Bob..." "... I have you covered!" "... a small step for three Kerbal..." "A giant leap for Kerbalkind!" It was time, then, to leave the Mun: our heroic trio climbed back to the Command Module... ... and set sail for the second leg of their journey: returning back to Kerbin. -- This conclude our coverage of the "Direct Ascent, Apollo II" Munar Mission. -- To the next time, fellow kerbonauts. Space Safely!
  21. Since yesterday, aside some heavy cfg patching to some old parts that I'm trying to keep alive in modern KSP, I'm messing with a monster rocket... Behold! The Might(ly kitbashed) Saturn C8 NOVA! Some "flight test simulations" (a.k.a.: put it in the pad to check if I stacked everything correctly and deal with a lot of "Revert to VAB" moments, to iron out issues) showing some "simulated" moment of the prospected final vehicle: And then the final, actual, product that will be shipped to the Araym's Kerbal Administration of Space Adventures, refined by changing the layout of the first stage engine positions (... in these pre-flight tests, they were arranged alike the Saturn I: 4x central, 4x external) and the addition of the 8th engine in the second stage: Gloriously rocket of BDB lineage (at probably 80% derived from Bluedog's Sarnus V) made of: a mandatory entire (hystorical) Apollo CSM as Munar Ascent Stage; a reworked/shortened Saturn I S-IV (the early upper stage, with 6 small engines mount) with modernized 6x AJ-100 engines (derivative of the upper stage engine used in the Thor-Able/Delta rocket, or the General Electric's proposal for another, discarded, Direct Ascent Apollo) as Munar Lander Stage/Munar Orbit Insertion, as my kitbashed invention; the entire (actually flown) S-IV-B (from the Saturn V) in the classic single 1x J-2 propelled version as third stage; a S-II-8 second stage of new concept, exagerately powered (but needed) by 8x J-2 engines (7x in anular configuration + 1x central) as the Nova required also, following the proposed rocket; a S-IC-8 first stage, powered by 8x roaring F-1 engines (in the same S-II new design as 7x anular/1x central). Further "press release" will inform the public about the sorts of the intrepids Jeb, Bill and Bob, scheduled to be launch live for the actual Mun shot mission.
  22. I guessed it was just a nice "estimation", but nothing more, almost right. Interested in the topic I did a bit of backtracking in almost the whole thread, just to understand the "process" that brought some values as they are actually, and the struggle to have bot RO playstyle and stock playstyle to live together in one single library of resources: not playing in RO, I can someway imagine that they have some differencies, once all their modding is implemented, that maybe put LqdHydrogen to the value that it is... The only "weirdness", mostly probably by the fact that, probaly, at the time, not so much of other fuels were used in a stock-modded enviroment (You were the first trying, probably, launching CryoEngines/Tanks, but looking at those dates it was A LONG AGO: it was probably just a niche addition)... ... but now I see A LOT more mods, in a stock enviroment, using different resources in a realistic fashion, and a lot of people, for example, are starting to code, for example, SpaceX rockets (a novelty only, back then, when today is a leading firm in space launch) and I noticed a very large gap in in-game credits between a standard LiquidFuel "stock rocket", a far too cheap LqdHydrogen, and a far too expensive LqdMethane (if assumed the same tank and similar performance engines). I do not want to push, here, my own "preference" (pushing for a change here could lead to the necessity of an entire "rework" of thons of mods that probably were balanced against the actual figures): politely, as last request, to not further clog here with tons of post, I would eventually ask if I can bother you, in PM, for a couple of simple requests: by myself, for my own usage, I tried to "change" eventually something, but the major problem I found is that, even if succesful for the cost/unit, then I encountered some "little bugs" once the actuall version of CryoTanks apply its patches (probably just because are mass/cost tailored to the actual values) with some "negative cost". If it is not an inconvenience, @Nertea, I would just ask about those patches a bit (mostly because I'm a bit of a disaster when MM patches start to make "math" and implement "variables", and probably I would just needed an indication or two about where I should look to then take all the matters about "personal modificatios" on my own)
  23. Indeed it will not: it just happened that you mentioned a thing that I was not aware of...Taken notice of it, we can go on on the main topic of my appearance: the underlying cost balance between LiquidFuel, LqdHydrogen and LqdMethane. Hydrogen, for sure, is "the common material in the universe", but in my own grasp of rocketry, also one of the hardest fuels to manage, given the boiloff problems. I totally get the more "scientific data" under each resource (density, heat capacity etc etc): those are easy to find around and, with a bit of knowledge, even to understand. In fact I'm not arguing that: I still do not grasp "the money" involved, then, to quantify the usage of those value. I'm not asking a complex dissertation: a simple "we found this cost in this piece of paper/this reference: it show this cost/units. In game, that real life units equal to xxx units in game. It looked plausible" followed by a "Oh... I didn't know it...." by me, and I will disappear in peace. I didn't find (up to now, internet hunting) a clear "real life" value to just debunk myself or any misconception of mine (eventually dumbely exposed in my previous posts), prior to rush here and ask: it just seemed odd the disparity in game. (I'm a very curious guy, even more when related to science, and in scientific fashion I find myself in the urge to "ask/inquiry" things that I do not know: not to debate anyone else knowledge, but to wider mine)
  24. @RoverDudeI understand that me, as "a single nobody", has "no power" to "force" a change: I'm here just as an user/player (looking at the related LqdHydrogen/Lqdmethane, as you adviced, it seems that both falls under Nertea maintenace, so it was not a totally mistake to ping him in the previous message...) trying to figure "why some things are set in a way that, in MY own game, they seems odd". I do not like to make too much of a comparison to "real life", but basically, even taken in account the "boil-off" problem, in a modded game like mine, in any career, ANYTHING is superseeded once LqdHidrogen is reach: better ISP better costs no need of any different chemicals even (or probably even more) for lifters from Kerbin, as boil-off is painful for interplanetary stages (unless used in conjunction with a lot of mods that upgrade nuclear engines to LqdHydrogen usage, more likely in real life, rather than the kerbal Kerosene counterpart of LiquidFuel... at that point leaving the "more common" LiquidFuel just for atmospheric planes jet engines) It's a lot of time from my lastest days in KSP, so I'm only recently returning to play it (the "final release" will lower the need to constant update mods for each release), and, restarting from the ground with my careers, I found extremely odd the discrepancy found on LqdHydrogen tanks (... probably is because I'm still bound to an "early gameplay", just to re-discover all the new things added since my last time in KSP). Being CRP the "common resource", I found just more easy to talk about it here: not seeking to "impose my will", but rather "understand"... ... and without any further annoyance, once that, return to my own game, where I'm kind of capable, eventually, to customize things, once I grasped the PRO and CONS of some, actually implemented, choices, by the most influencial modders: I do not want to be unpolite... just having "A LOT" of mods, often developed with different mindsets, I'm not new to "smooth angles" when they are put together, to then develop a personalized version of the game that plays "more intuitively" in MY own mindset. KSP is the first game that offer to me that, in some way, probably because I'm following it since 0.13 and I saw its own development. I actively mod it myself. Not "releasing mods to the public", but for the possibility offered, knowing its own "coding", between cfg files and a bit of MM, to tailor the end result to my preferences. For me is not a "game", but a "software language" that allow to develop "my own game of little green men". ---- Aside that: So, now, each mod that involves some kind of harvesting is it going have its own "Resource Configs"??? I will have to check each of those, one by one??? Having still installed the "old" configs, will the new one be compatible/MM patches/have the same syntax alike them??? Have I to remove them and add/wait each mod to develep their own??? Sorry, again, for all of these questions (maybe made thousand of times) but, as said, I'm back from a LONG hiatus from KSP and I'm trying to get a grasp of all the changes occurred during the time (I'm behind, probaly, 5 or 6 major release, from my latest time here) I'm at lost here too, now: seeking for some answer brought me more questions...
  25. Preface: I use A LOT of mods. Probably "too many". Among them, CryoTanks and related patches for A LOT of mods. Issue: I'm in the process, using CryoTanks as inspiration, to adapt some old mods that I find useful for myself. During the balancing process, I noticed something that is puzzling me: basically, I noticed how VERY different is the cost of the same tank, if it run as LOX (stock 9:11 ratio between LiquidFuel/Oxidizer), LH2/OX (15:1 CryoTank ratio between LqdHydrogen and Oxidizer) and LCH4/OX (3:1 CryoTanks ratio between LqdMethane/Oxidizer. This is a simple example (a tank with, stock, 450 fuel + 550 Oxidizer, for a 1000 units total): Oxidizer LiquidFuel LqdHydrogen LqdMethane density = 0.005 density = 0.005 density = 0.01097000000 density = 0.00042561 unitCost = 0.8 unitCost = 0.8 unitCost = 0.0367500 unitCost = 0.45 LqdFuel LH2 LCH4 Fuel quantity 450 3750 1875 Oxidizer quantity 550 250 625 Total Fuel 1000 4000 2500 Ratio 9:11 15:1 3:1 Fuel Cost 360 137.8125 843.75 Oxidizer Cost 440 200 500 Total Fuel Cost 800 337.8125 1343.75 I do not want to go too deep in any technicality (I'm an average person, and probably Engineers and Technician in the field by profession could debunk my assumption easily), but I'm trying to figure out some werid thing I noticed, as player, following these assumption: Ratios used/densities are considered only as final value needed to balance the overall cost Liquid Fuel: it should be the "easier" fuel to obtain; it's easy to storage, it has average performances (as ISP, assuming it is basically Kerosene... yeah... mileage could vary, based on engine technology, but overall that is...); it has no issue in long term usage in space (no boil-off) LqdHydrogen: it is hard to storage (a LOT of boil-off), so in game (as CryoTanks introduced) it needs insulation and/or active cooling; it's, generally speaking, costly to obtain (there are a lot of way to do so, not only pyrolisis, but I assume that, even if available in high quantities, in modern day, the net energy spent is high, and it is useful just because, the costly production offer some benefits, as ISP); it has the best performances (best ISP overall) LqdMethane: it is not so hard to storage (little to none boil-off, being a big molecular compoound); it is fairly cheap to obtain (a lot of gas extraction sites); it has a better ISP than LiquidFuel but slightly worse than LqdHydrogen I kind of figure that the cost of LqdMethane is, probably, someway, based of the real life, cost/availability of liquid methane for automotive usage (based probably on US$ prices???) so I assume that could be left as it is (better overall ISP could be paid in game)... ... BUT the thing that is puzzling me is, actually, the SO LOW overall cost of LqdHydrogen tanks: in the example above, taking for granted that 800 credit is the base cost of that tank, that the methane version could have been balanced equally with real life consideration, so 1343.75 total could be good, I personally should expect to see the hydrogen tank being the MOST expensive, not the cheaper (a consideration, gameplay wisely, that you can get better ISP, but at the cost of tank complexity/usage of EC to avoid boil-off/high production costs). By some fast math, I see that, probably, the cost of both was based on actual usage of Methane and Hydrogen for cars (the easiest way to get some prices, and some of those I run too), but: both hydrogen and methane used for cars are not CRYOGENIC contained , but only mantained in a "liquid" state by pressure (again: i'm not a scientist, I espect some technician in the field to debunk my assumptions, but I suspect that for rockets that has an HUGE impact: that "more fuel x volume" squized using cryogenic chilled fuels make the "more cost/complexity x volume" ramp up probaly exponential, rather than the hi-pressure only methane used in household common usage) methane for cars is way more expensive, for example, than the same methane used for home appliances, but they are THE SAME product (and in this I have some knowledge: I worked for some methane retailers and, even if based on my country, I know the HUGE difference, up to 1\3 for home applications) Overall, I have not a final value to propose (I have my own concern about it): In a game perspective, I would balance the tank cost as LiquidFuel<LqdMethane<LqdHydrogen, based on their performances in game only, rather than various comparison to real life. It's not so much difficoult for the methane: a reduction, to place the above example tank in the 900 credits range as fuel cost, leave a value of (900 total minus 500 Oxidizer = 400 credits for LqdMethane... 400/1875 units = 0.21~ x units.. as it was a job of mine, I know that, in my country, it's not so far from the cubic meter cost in € for house usage, removed the cost of taxes and the provider profit... so also doubles as a real life parallel), but then the LqdHydrogen should be the most expensive (let's say that the above tank should be the one in the 1300 credits overall, more likely the actual LqdMethane) then going for an HUGE higher price: 1300 total costs, minus 250 Oxidizer cost, leave a 1050 credits. Divided by the 3750 volume units, it gives a 0.28 credits/units in in game price for LqdHydrogen... it's almost a 30x value respect the actual one, but I feeling it as more balanced value than the, actual, "cheaper fuel/best performance fuel" we have in a CRP modded game. Knowing that I do not have a real life comparison/figures for the LqdHydrogen, I made these absumptions only looking on a game-balancing perspective. I would like to know, @RoverDude, what figures were used to extract the actual CRP's LqdH prices, just to see if there is a way to, actually, place a more balanced value. As the developer of reference for CryoTanks, I would also like to invite @Nerteato this discussion, to eventually share some thoughts. Thanks in advance for any answer
×
×
  • Create New...