Shadowmage Posted March 9, 2016 Author Share Posted March 9, 2016 10 hours ago, Sudragon said: Thanks for the upgrade to the petal adaptor. NP Was in there cleaning up some other things for the plugin code, so it only took another few minutes to add the needed functionality and create the second part.cfg file. Please let me know if you spot any major problems with it, as it did not receive much testing last night. Quote Link to comment Share on other sites More sharing options...
Jimbodiah Posted March 9, 2016 Share Posted March 9, 2016 The that nuke came faster than we thought Would be nice to be able to cluster them as regular SSTU engines. The single interstage node would be most welcome. Quote Link to comment Share on other sites More sharing options...
Shadowmage Posted March 9, 2016 Author Share Posted March 9, 2016 47 minutes ago, Jimbodiah said: The that nuke came faster than we thought Would be nice to be able to cluster them as regular SSTU engines. The single interstage node would be most welcome. Well, I originally set it up as a test-case to help debug the problem of stock fairing removal that JoseEduardo was running into while doing some custom engine stuff; but then I figured...what the heck... I need some NRVs for clustering anyway, and the stock geometry is...close enough for those engines. What is there currently is just the initial 'get it to show up in-game' pass of config work. The effects are likely badly broken; the mount options are non-existent, and even the thrust/mass/heat for them is...probably not right. Quote Link to comment Share on other sites More sharing options...
Jimbodiah Posted March 9, 2016 Share Posted March 9, 2016 You have to start somewhere. Quote Link to comment Share on other sites More sharing options...
Sudragon Posted March 9, 2016 Share Posted March 9, 2016 Most of us start in the VAB with 'What happens if I do this?' Quote Link to comment Share on other sites More sharing options...
thunder175 Posted March 10, 2016 Share Posted March 10, 2016 I just wanted to take a moment to thank the author. I've been using your mod recently and it's pretty much replacing all other part packs given its utility, breadth, and completeness. I recently discovered the ability to make 1.875m tanks and fairings using your mod, as well as other various diameters. This is such a welcome addition to the design arsenal. Thanks so much and please keep up the excellent work. I'm greatly looking forward to your additional work. Quote Link to comment Share on other sites More sharing options...
blowfish Posted March 10, 2016 Share Posted March 10, 2016 Hmm ... is it intentional that the minimum size of the radial booster decoupler is 1.25m and not 0.625m? Quote Link to comment Share on other sites More sharing options...
Shadowmage Posted March 10, 2016 Author Share Posted March 10, 2016 14 hours ago, thunder175 said: I just wanted to take a moment to thank the author. I've been using your mod recently and it's pretty much replacing all other part packs given its utility, breadth, and completeness. I recently discovered the ability to make 1.875m tanks and fairings using your mod, as well as other various diameters. This is such a welcome addition to the design arsenal. Thanks so much and please keep up the excellent work. I'm greatly looking forward to your additional work. Thanks, I'm glad to hear you are enjoying the mod in its current state Only going to get better (or that is the plan), and I generally update at least once a week, so make sure to check back in once in awhile to catch all the new updates and features. 9 hours ago, blowfish said: Hmm ... is it intentional that the minimum size of the radial booster decoupler is 1.25m and not 0.625m? Nope, must have just missed it while updating the default radii (radius'?) for the parts. Will get that one cleaned up shortly. Aiming for a consistent 0.625m minimum with 0.625 increment for all modular/procedural parts -- so if you spot any others that are off, please let me know Quote Link to comment Share on other sites More sharing options...
Jimbodiah Posted March 10, 2016 Share Posted March 10, 2016 Aparantly MM 2.6.20 is out https://janbrohl.pythonanywhere.com/ckan/ModuleManager/2.6.20 Quote Link to comment Share on other sites More sharing options...
Shadowmage Posted March 10, 2016 Author Share Posted March 10, 2016 Aye, but it appears that the newer ones are dev versions, as they are not available for download from the main MM thread or repository. Quote Link to comment Share on other sites More sharing options...
Jimbodiah Posted March 10, 2016 Share Posted March 10, 2016 Weird thing is that 6.19 is listed but not for download. 6.20 isn't even listed Quote Link to comment Share on other sites More sharing options...
Shadowmage Posted March 10, 2016 Author Share Posted March 10, 2016 H-1 geometry nearly finished (only some minor cleanup to do, possible poly reduction; 7.5k tris as it sits now) Quote Link to comment Share on other sites More sharing options...
Shadowmage Posted March 10, 2016 Author Share Posted March 10, 2016 I figure now is probably a good time to start talking about (and figuring out the method for) the upcoming packaging split. This will (hopefully) see the mod broken up into (currently) four different downloads / packs (more packs would be added for station/base/rover/probe parts in the future): 1.) Ship-Core -- spacecraft and general parts (SC-A/B/C/E and SC-GEN parts... decouplers, fairings, rcs, science bits, etc) 2.) Tanks -- MFT tanks, upcoming MCB cargo bays, any/all future fuel-tanks and containers 3.) Engines -- All of the engines and SRBs 4.) Lander-Core -- all the lander-specialized parts (currently the lander pods, lander fuel tanks, and specialized lander decouplers; in the future will just be the pods as the tanks are going to be redone and moved into the TANKS category/package). Now, the biggest problems that I'm facing are the general assets layout that I have in place and the massive amount of texture/model sharing that is done between many of these parts. 1.) Service modules use at least the textures from the engine that they are based on. Would need to duplicate these assets across multiple distributions, or find some 'common' folder for them. 2.) Mounts and nosecones get used -everywhere-. These would have to be distributed with both the tanks and engines packs. 3.) RCS models and textures -- not too much of a problem as these would be in the Ship-Core pack with the parts that use them. 4.) How to allow for a clean installation process -and- a clean uninstallation process for individual pack? Currently I'm thinking the directory setup would be such as: GameData |--SSTU |--Plugin |--Data (model data files, resources, etc; pretty much just as it is currently, would be distributed in its entirely with most packs; text files don't take up too much space) |--Flags (common folder, distributed with all packs) |--FX (common folder, distributed with any packages that need it) |--Props (common folder, distributed with lander and ship core packages) |--Resources |--Mounts (models/textures; asset folder only, no part configs, would be installed by either/both of tanks and engines packs) |--Assets |--Data (mount model data? might just leave it in the above data folder) |--Engines |--Assets (but how to allow the ship-core parts to use these without duplication?) |--Parts (config files) |--Patches |--Ship-Core |--Assets |--Parts (config files) |--Patches |--Spaces |--Lander-Core |--Assets |--Parts (config files) |--Patches |--Spaces |--Tanks |--Assets (including all texture-switch textures; no more separate download pack) |--Parts (config files) |--Patches Sadly, this would require re-exporting every single part model that I've made (to update their internal texture url reference), which... is in the hundreds, and more work than I really think it is worth. Would also be a pretty major disruption to the current work-flow, and would require at least 5x the amount of time to do the packaging / updating threads / posting every time there was an update (which is already one of the most time-demanding parts of modding). Still in the concept validation point on all of this stuff. If I can't find a -clean- way to do it that doesn't require completely reworking and re-exporting every-single-model, then I'll likely just stay with one giant monolithic distribution and let users trim it as they see fit (possibly including some instructions/notes on what goes with what though to make it a bit easier). Seeming like this is probably the way it will end up -- I cannot think of any way to solve the texture-sharing problems without a common assets folder. (Yes, sometimes I make these posts just to think through the problem; easier to spot problems when it is all laid out in text). Quote Link to comment Share on other sites More sharing options...
Jimbodiah Posted March 10, 2016 Share Posted March 10, 2016 (edited) Lot's of dillemas in that kind of split. Why split the shipcore into 3 seperate mods though? There are only a hanful of tanks, plus where would the HUS/ICPS go? Keeping tanks and engines together would be most logical as the mounts are shared between all of them. The only way to do it otherwise is to bundle the textures with each of the seperate mods. If someone installs them all, then the same folder is just overwritten. Directory makeup example: (just for the textures, you can do they same for plugins etc). SSTU/ShipCore/.. ../ShipCore/PodTextures/.. ../ShipCore/EngineTextures/.. SSTU/Tanks/.. (+Boosters?) ../Tanks/TankTextures/.. ../Tanks/EngineTextures/.. ../Tanks/NoseTextures/.. ../Tanks/MountTextures/.. ../Tanks/BoosterTextures/.. SSTU/Engines/.. ../Engines/EngineTextures/.. ../Engines/MountTextures/.. SSTU/LanderCore/.. ../LanderCore/LCPodTextures/.. ../LanderCore/LCTanksTextures/.. ../LanderCore/LCEnginesTextures/.. So some texture folders will be in multiple .zip files for download, but once unzipped into the GameData/SSTU folder they will overwrite each other. Each mod will be self-contained though. Edited March 10, 2016 by Jimbodiah Quote Link to comment Share on other sites More sharing options...
Shadowmage Posted March 10, 2016 Author Share Posted March 10, 2016 Honestly it is looking highly likely that I will -not- be splitting the mod up. As any change in directory structure would require re-exporting every single model (some of which I may not even have Unity files for any more and would have to completely re-rig from the blend files), as well as updating the configs for those parts. The only way that would not require re-exporting things would be an unmanageable mess as far as packaging goes (keep current directory structure, but only pack up those bits needed for each pack), as well as making it impossible to un-install a single pack easily. Still going to give it a bit more thought, but I cannot see any way around the re-exporting (which I am not going to do). It doesn't bug me with everything in one download though; and the only real reason that I can think of to do it would be for memory use concerns, which I'm going to stop worrying about with 1.1 anyway (srsly, just buy more RAM; its cheap) Quote Link to comment Share on other sites More sharing options...
blowfish Posted March 10, 2016 Share Posted March 10, 2016 @Shadowmage I don't think .mu files store the exact path of the texture - it just looks for them in the same directory as the model. Quote Link to comment Share on other sites More sharing options...
Shadowmage Posted March 10, 2016 Author Share Posted March 10, 2016 10 minutes ago, blowfish said: @Shadowmage I don't think .mu files store the exact path of the texture - it just looks for them in the same directory as the model. Hmm.. that would certainly ease the pain of the conversion considerably. Will see about doing some tests on this soon to see how well it works out. Quote Link to comment Share on other sites More sharing options...
blowfish Posted March 10, 2016 Share Posted March 10, 2016 1 minute ago, Shadowmage said: Hmm.. that would certainly ease the pain of the conversion considerably. Will see about doing some tests on this soon to see how well it works out. I've definitely moved models and textures around in GameData and had them work just fine. I've also opened smaller .mu files with a text editor - you can find the texture references pretty easily, but it doesn't store a GameData relative path anywhere. Interesting side note, it does store the texture names with extensions, but it doesn't care about them ... if you replace blah.png with blah.dds it works fine. Quote Link to comment Share on other sites More sharing options...
Shadowmage Posted March 10, 2016 Author Share Posted March 10, 2016 Aye, I've noticed the texture-extension doesn't matter (or else all of the .dds conversions would fail, as PartTools cannot export .dds ). Been awhile since I've opened one of the models in a text editor; last time it was to look for some proper tag names (Icon_Hidden ). Sadly, even with that bit of ...help.... will still be quite an undertaking to split things up (sooo many part.cfg files would need editing). Still debating if it is going to be worth the effort and complications in the long run (and still need to figure out how to deal with the texture sharing). Quote Link to comment Share on other sites More sharing options...
ComatoseJedi Posted March 10, 2016 Share Posted March 10, 2016 Wouldn't splitting up the mod into separate entities make more work on you, @Shadowmage ? Quote Link to comment Share on other sites More sharing options...
JoseEduardo Posted March 10, 2016 Share Posted March 10, 2016 (edited) what about spliting between only Ship Core and Landers, as Jim said, for now, and have all the new ones as separate stuff? because I don't see why anyone would want to, say, keep the tanks, but not the engines, or keep the engines but not the tanks or capsules... I think ShipCore could be kept as a KW or FASA type of release, with tanks, engines and spacecrafts in one pack, with Landers, then Stations, Satellites, Rovers etc separate Edited March 10, 2016 by JoseEduardo Quote Link to comment Share on other sites More sharing options...
Shadowmage Posted March 10, 2016 Author Share Posted March 10, 2016 3 minutes ago, ComatoseJedi said: Wouldn't splitting up the mod into separate entities make more work on you, @Shadowmage ? Considerably, even after I get it figured out, it will increase the work-load for -every- release, and just the amount of work in general keeping them all split up; which is why I really don't want to. Have had a few requests for an engine-only pack though, which is why I'm considering it. -I- personally don't need (or want) them to be split up at all. The mod is intended to taken as a package. 3 minutes ago, JoseEduardo said: what about spliting between only Ship Core and Landers, as Jim said, for now, and have all the new ones as separate stuff? because I don't see why anyone would want to, say, keep the tanks, but not the engines, or keep the engines but not the tanks or capsules... I think ShipCore could be kept as a KW or FASA type of release, with tanks, engines and spacecrafts in one pack, with Landers, then Stations, Satellites, Rovers etc separate Mostly it is the engines that I see requests for (and mostly from RO users...). Hmmm... will probably be easiest to do just that -- the 'full' pack, with everything, and then a trimmed down pack for those few people who want just the engines (which would allow me to keep the same directory structure, and would likely just need some slight alterations to my packaging script). I really don't understand the whole thing though.... why would someone want just the engines without the mounts, tanks, etc? I could understand people not being interested in the spacecraft end of things... but the engines without the mounts and tanks really makes no sense. So... perhaps I will do... nothing . I don't want to split it up, it doesn't make sense to me, I'm not doing this mod to support RO, and it would add considerable amounts of overhead to managing all the various distributions. If, in the future, someone -else- wants to take the time to make up an engines/etc only pack...well... nothing is stopping them as long as they follow the license stipulations. Quote Link to comment Share on other sites More sharing options...
Jimbodiah Posted March 10, 2016 Share Posted March 10, 2016 Just keep it in the same folder and make it possible for people to delete the directory of parts they don't need. Keep unique textures with the part, all the shared on in one folder (=take it or leave it). Don't make more work unless it;s really necessary. I can see landers being a seperate package, unless it will share engines etc with Shipcore. Quote Link to comment Share on other sites More sharing options...
JoseEduardo Posted March 10, 2016 Share Posted March 10, 2016 well... you know my opinion on that regard also, for me I will always download the full pack as I consider SSTU a must (hence why I often annoy you asking for something ), if 1.1 has a stable x64 I have even less reasons to get separate packs... Quote Link to comment Share on other sites More sharing options...
MrMeeb Posted March 10, 2016 Share Posted March 10, 2016 While I'm not in favour of splitting, simply because it'll up the workload for you unnecessarily, I believe that the mod should be made more user friendly when it comes to removing individual parts, if that is possible. I would understand it not being so simple due to the seemingly large interlocking fashion of the mod, but some people may only be looking for the tanks, or the SRBs, or certain engines. Now that I write this, I'm not sure if making it easier for us to trim the pack is any less work than splitting it up entirely...hmm...whatever. It's your mod, and I love it to bits! Do you what you wanna do I'm so great at useless posts Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.