Jump to content

Spanksh

Members
  • Posts

    31
  • Joined

  • Last visited

Everything posted by Spanksh

  1. Very odd, I have already fixed that. Maybe an old version sneaked in somehow or it's a new bug. Either way, I'll take a look at it.
  2. Welcome back! It's awesome to see my most favorite mod back in active development
  3. I'm 99.99% sure you're not using the latest version (1.8.6) since that is all fixed
  4. Ok funny enough it's easily fixed by simply using the textures from 1.8 v4, HOWEVER these are 4k instead of 2k, meaning in dds they are 22mb large, which is quite massive. However obviously the quality is better as well. For the Juno Engine Mount this issue seems to be unfixable otherwise, since editing the texture will always create massive artifacts, even if only the vents are altered. @TheKurgan Ok so here are the temporary fixes for now OPT 1.8.6 HD - Texture Fixes. Mind you the textures are quite large now, but it'll have to do until we figure something out for the official fix.
  5. Ok so I was able to fix the intakes, I'm still fighting with the juno engine mount. Somehow I always end up affecting part that shouldn't even be touching that area of the texture.
  6. @TheKurgan yeah that's listed in the known bugs. I'm at this very second trying to work that out, but can't promise anything. We can't edit meshes without the source meshes, so unless it can actually be fixed on the texture itself (which turns out to be more difficult than expected) there's no solution.
  7. Would you please be so kind and stop accusing people of doing things they aren't. He was simply giving the necessary information. " OPT is not on CKAN " is pretty much an as neutral and straight forward answer as you can get. You asked/were confused. He answered/explained. He isn't acting in one way or another, so there is no need being rude to someone who is trying to help.
  8. Ok, so I realize the way I talked about the changes I made and how I argue some of my decisions have made a wrong impression of what I did/am doing. So first of all apologies and please let me clarify: First of all @stali79 is the one maintaining this mod and always has the last word about what he releases. I am not officially a member of the team, nor do I plan to create a full official release on my own. If he is going to use parts of my version, only makes adjustments, leave it as is or even decide not to use it at all, is always his decision. What I did (and am still doing while 1.2 prereleases are still going) was primarily a massive internal overhaul of the mod, meaning adding the new missing features, ironing out all the minor and major bugs, which sneaked in over the accumulation of all the different parts, all the in my opinion unjustified changes of features and most importantly tidy up all the incredibly messy configs, which were completely all over the place in regards to their entries. This is also the reason why I primarily did it on my own, since such a major rework is close to impossible to do with several people in conjunction, if not all have the exact same concept for the cfgs. I will argue for my decisions and explain them, however for whatever reason @stali79 decides to change whatever he wishes to, he can and should do so. My version will be provided to him as is and is simply supposed to be a major help for future development of this mod (Otherwise I would have kept it for me privately). I only did this in the first place because OPT is my most favorite mod and I literally can't play KSP without it. So I wanted to see the mod in its best possible shape for the new 1.2 update. I wholeheartedly hope @stali79 and maybe to some degree even @K.Yeon adopts my version and simply changes settings/assets in the way he prefers them, since imo the important part is upholding the general quality and layout of the new CFGs, which I hope he will continue using. If he decided to make major changes to the version I will provide him once 1.2 prereleases are done, with which I disagree, I might release a "Directors Cut" in a single post in here for the people sharing my views on certain features, but I will not publish it as a truly separate version or on a proper mod platform. @stali79's version is the only official continuation of OPT until @K.Yeon himself returns.
  9. Uh nice! Thanks for sharing! Well I definitely need to join the OPT fan club, considering I learnt KSP modding just to completely overhaul it, for the upcoming 1.2 release Seriously I can't play KSP without this mod Just going to post my most favorite creations for now. They might not look like much and seem fairly simple, but they are honed in every detail for best as possible performance (and looks, but nobody needs to know): Valkyr Mk II S Voyager (completely rebuilt in v1.8.6) The Valkyr class is a SSTO delivered in C (for cargo) or S (for science) configurations. The former boosts a double sized cargo compartment while the latter has a mobile lab and a single cargo compartment. The Mk II is a major overhaul of the previous line of designs, while it only has small visual changes, the performance changed fairly drastically. The Voyager configuration is completely self sufficient and contains everything you need to explore distant worlds including relay systems for control of drones. It is meant as permanent mobile base on alien planets. DAT *insert 3-letter profanity here* I really love the silhouette and sleek shape of it. Also handles like it looks. Like a very nimble and quick fighter. Strong independent plane. Complete with drill and ore converter, all the science and scanner you could ever need and multiple communications and relay solutions. Also able to dock to pretty much everything sporting a docking port. Pegasus Carrier II (built with v1.7) A drone SSTO carrying the (currently outdated) Valkyr III S. Able to transport any fully fueled Valkyr Class SSTO into orbit with enough fuel left to easily make it back to the KSC and then some. While attached, it functions as part of the Valkyr, being controlled form its pilot and supplying the engines of both planes for maximum efficiency. Once detached it is controlled from the KSC to ensure a safe return. While a total of 26 wheels are ensuring a stable takeoff, it's smooth sailing once the 250t combination reaches liftoff speed. It has 4 sets of wings with the two most rear ones being in a twin configuration to ensure proper control and lift while carrying the big amount of fuel and hardware. Once its cargo has been dropped off in orbit, it still handles perfectly and even glides with its weight dropped well below 50t.
  10. Since last weekend. When 1.2 hit I took it on me to completely rework the mod (no worries, no internally renamed parts). Meaning updating all modules, adding all the juicy new features of 1.2, ironing out all minor or major bugs, converting the textures for better visual quality, completely reformatting all configs, completely re-implementing all the fuelswitches etc. etc. etc. I'm basically done (just keeping on testing during the 1.2 pre release and looking out for bugs I missed and potential new features in future KSP releases) and waiting for 1.2 to hit the full release so we can make it properly public (also firespitter doesn't work until the full release hits, so 1.8.6 OPT doesn't properly work without some manual changes to work around this issue)
  11. But how? When you put it directly on a crew compartment there is far less space than on the part in question. Don't get me wrong, I fully understand your argument and even agree in general. However considering how this is handled in KSP in every other situation, it doesn't make sense to expect additional safety features no other part in the entire game provides. Just to clarify my basis of argumentation or justification in these kinds of cases in general: - Balancing the strength/severity of a feature: Actual game balance should follow, but might overrule game internal logic. This means changing the amount of fuel/seats/lift etc. should be done, if a reasonable balance is not achieved otherwise, even if e.g. the model would allow a higher/lower amount. The balance is hereby dictated by stock parts. So while you could argue, you could cram 14 Kerbals within a very small space, you should comply with the smallest amount of space stock parts provide, to stay within game balance. - Balancing the existence of a feature: The purpose of a part and actual look of the part should overrule balance, unless it would be of a game breaking severity. This means, if a part is built for carrying fuel/crew or provide certain features, there must be a reason like complete game breaking imbalance or impossibility/pointlessness within game internal logic to justify removing/adding it. Taking this case as example: The port is built for crew, fuel and a docking port. The existence of these features is reasonable within the game logic and does not completely break the balance of the game. Therefor these features need to stay. Within game logic it reasonably allows for ~800 fuel and at least 6 seats. Arguably this would break balance, since the seats would be very crammed in comparison to stock parts and it would make this single part very "powerful" within its features. More reasonable would be 4 seats to comply with stock balance (in regards to space) or 2 seats to slightly offset the amount of features the part has (its "power"). After this the part is balanced, both in existence and strength of features, unless a strong argument changing the tipping point of either of these comes up. Now I don't go through this entire thought process in detail only to set up a part for the first time. I rather follow the original balancing. However when it comes up that some aspect might be heavily off the charts (missing/having major features or having completely unreasonable values) then it's worth putting some more thought into it. ----------- - is already fixed in the upcoming 1.8.6 - is already fixed in the upcoming 1.8.6 - The only chimera parts are the cockpit and adapter (in 1.8.5.1, the latest version), which I suppose doesn't quite classify as a separate class, since it's part of Avatar. The naming of these parts also should be more clear in the upcoming 1.8.6 (hopefully) It'll be released once KSP 1.2 hits stable release, since it includes all the new features. Also would love to see your build!
  12. That is why I used the attachment point to demonstrate how much space is left below the docking port. And note that the tube actually doesn't even retract nearly as far as the attachment point imitates. Apart from that, even if the tube reached to the very bottom, the seats would easily fit next to the tube:
  13. Well KSP respectfully disagrees. In contrary to the Stail port, the June port tube is very short. It easily fits in the bulge at the top. It technically even leaves room for 4 seats, but I guess 2 are reasonable. Proof: The crew even has more space than in proper crew compartments and don't interfere with the fuel storage whatsoever. Also it seems like a reasonable trade off for only having a small port contrary to stail, which has a big and small one, but no crew. Speaking of which, I was finally able to fix the stail inline docking port. Works flawlessly now.
  14. Well but no crew module has an iva and it's literally called "crewdock", while the others are only called dock or dockingport.
  15. Good you mention that, I didn't even notice it was lacking the crew capacity. Added to the fixes for 1.8.6. Thanks!
  16. Well my version is already ready for 1.2 but we are waiting for the final release. Also neither Firespitter nor Module Manager works with 1.2 yet, so functionality would be very limited for now without some manual adjustments.
  17. Thanks! Well, while I'm embarrassed to admit that, I haven't really worked with guthub yet, so I'll send it to you once I'm completely done. Also I prefer you looking over it before making it publicly available anyways. Also in regards to the version check, what's the maximum version you usually set? eg. min is KSP 1.2.0 now, should max be 1.2.1?
  18. Well according to stock standards you have to add the liquid+oxi amounts for liquid only. See MK1 fuselage: 400 <-> 180+220, both weigh 2.25t, 2t fuel and 0.25t dry mass. So I massively upped all the liquid fuel amounts to fit this standard. On a side note: I'm effectively completely done now. I also completely redid the OPT_FS, since several parts were missing and it was containing parts that aren't in the mod (under that name). I did make a OPT_Resource_Defaults and OPT_FS, however after having done that I will move all entries into the parts themselves. While these cfgs are in fact convenient for mass-rebalance, I had to experience they are a massive pain, if you want to adjust single parts, since you have to either edit all 3 files or at the very least 2 files anyways. Also this enables FS to still work even when MM dies, which happens quite often (and serbian understandably refuses to release MM for prereleases, but in turn completely breaking OPT for these). That being said I overall dislike being dependent on it. I will keep the two files along the old ones in a packed archive so they aren't used by KSP, but it's possible to go back to them if needed for whatever reason. In the mean time here the current changelog for 1.8.6alpha (I went from .5 to .6 since it's a enormous overhaul, talking thousands of edits here, even if most might not be noticeable in game): STILL PRESENT BUGS: - Stail Inline Docking Port doesn't attach to docking ports (? needs testing with new FS and MM) - Stail Inline Docking&Utility Port - Docking port shaft doesn't apply texture properly and has odd inverted mesh around the top - OPT_k_10m_cockpit has wrong texture in intake - l_8m_cockpit has wrong texture in intake - j_engineMount_4 has wrong texture around engine mounts - since Build 1532 Fuel Switch is completely broken STILL TO DO: - Add EMM animation to b_cockpit_qs (I created a EMM texture) - Balance Monopropellant Amounts. They are all over the place from missing entirely to way too low to way too high. - Add working ModuleDockingBay to b_docking_port1 - Align interior in mk23_cockpit - Align interior in k_10m_cockpit 1.8.6 alpha * Updated for KSP 1.2 * Minor adjustments to folder- and texture-structure * Removed several superfluous and duplicate textures * Replaces several broken textures * Converted all Part textures to DDS for far better visuals ingame (no more pixelation from a distance) * Major reformatting and complete overhaul of all cfg files - Removed duplicate or superfluous entries - Added countless missing entries - Added tags to all parts - Sorted all entries in all parts - Fixed faulty entries - Updated outdated entries - Adjusted control names for consistency and fit with stock standards - Adjusted titles for consistency and fixed typos - Moved all parts to their appropriate categories - Added Transmitters to all Cockpits - Added KerbNet to Labs and Drone Cores - Added Hibernation to Drone Cores - Added/fixed ModlueScienceConverter and Experience Management on Labs - Disabled Staging on all retractable Docking Ports to fit with stock standards - Added Fuel to several parts missing it - Added FuelSwitch to most parts containing Fuel - Moved FuelSwitches and Default Resources to the parts away from separate cfgs. *Additional major fixes/Changes: - Stail: b_dropBay_mk2 - Fixed ModuleCargoBay object detection - Added Drag_Cube - Fixed Node orientation - Changed mesh filename for consistency (not part-name) b_dropbay_mk1 - Fixed ModuleCargoBay object detection - Added Drag_Cube - Added inner Nodes - Fixed lifting surface b_cockpit - Increased crew capacity to 5 - Switched interior to the finished one from 1.7 b_cockpit_qs - Added missing interior from 1.7 - Wings: stabilizer_1a - Newly Added from 1.7. Slightly different version of stabilizer_a. All Main Wings - Added Liquid Fuel. Balanced according to wing_a1 in relation to effective wing surface - Engines: Ari-73 - Newly added from 1.7 - Misc: mk2_ramIntake1 - Newly added from 1.7. Slightly different version of mk2_ramIntake. mk2_cockpit - Added missing interior from 1.7 ils_cockpit - Fixed texture switcher - Switched interior to the finished one from 1.7 phoenix_cockpit - Removed placeholder boxes-interior i_4m_cockpit_isp - Replaced entirely replaced by 1.7 version. Now with fixed texture, decals and lights - Removed placeholder boxes-interior i_4m_tail - Fixed texture mk23_cockpit - Added missing interior. (Still misaligned) - Avatar: ab_3m_adaptor - Newly added from 1.7 (formerly jk_3m_adaptor). Shorter version of ab_7m_adaptor. a_8m_cockpit - Newly added from 1.7 (formerly k_8m_cockpit). a_cockpit - Removed placeholder boxes-interior - Kraken: k_10m_cockpit - Exchanged misfitting Humpback interior with former b_cockpit interior (still misaligned, but fits slightly better) jk_3m_adaptor - Newly added from 1.7 k_10m_cockpit_legacy - Removed placeholder boxes-interior k_10m_cockpit_custom - Removed placeholder boxes-interior
  19. @stali79 Okay so the liquid fuel <-> liquid+oxygen conversion makes no sense. E.g. parts have 1440+1760, but only 2000 liquid instead of 3200, or 3375+4125 but again only 2000 liquid instead of 7500. Is this intentional?
  20. Well I mean fallback fuel as in part-internal. That works much more reliable since it doesn't require anything. (The number one rule I learned in my ~10 years of modding: Never ever depend on other mods unless absolutely necessary) The latest Module Manager does mostly work in 1.2 but it doesn't provide the default fuel, so that's why i think internal ones would be better. EDIT2: Well screw that. Turns out it doesn't quite work as I expected. Well but you still have the FSfuelSwitch module in each part, so even if you had to edit something you would end up editing hundreds of files+OPT_FS. And having the @PART segment in a separat file makes it more difficult to change settings for a single part, since you have to do it twice. Edit: Ok so I finally found the FS documentation and if I understood it correctly you only need one entry, which tbh is slightly counter intuitive from what OPT displays, since it has entries for FS all over the place. Some in OPT_FS, some in the parts, some in both, some with the actual values, some without. Also OPT_FS covers parts that never had fuel and shows options for all fuel types, while most parts only have Structural/Liquid/Liquid+Oxi. What's going on there, I honestly don't quite get it? @stali79
  21. Well damn, so have I Ah well. I use gimp to convert to dds, since I already used that for Bethesda games. Works like a charm aswell. And I'm almost done with the overhaul and fixes. I'm done with all parts except the majority of Juno. After that I'll have to rework the fuel. Most parts are missing fuel entirely and none of them have fallback fuel in case FS breaks (as it is now), so I'll have to add that as well. Btw I also saw that you apparently can directly put the FS info inside the parts cfg. Does this actually still work and does it make any difference if you put it in OPT_FS.cfg or directly in the part and which would you prefer? If it actually works, I personally would prefer putting it directly in, but I'll go with your choice.
  22. Okay so the latest prerelease just completely broke Firespitter, which makes it kinda difficult to update/add/modify all the fuel switches, but that can come later. In regards to dds textures: So by accident I just found out that (despite what I experienced when literally trying exactly this before, which is why I asked@stali79 to do it in the first place) meshes do actually detect dds textures even when they had png textures assigned. Afterwards I looked at the 1.7 meshes in blender and realized that most parts do in fact expect png, despite 1.7 exclusively using dds. So that's a thing apparently. The fun part: They get applied mirrored, so I have to flip all textures vertically before converting. Again please don't ask me why, I have no freaking clue. I'm used to somewhat more predictable behavior from game engines. So that's overall good news, since I can convert all the textures myself and simply complete the entire pack. So @stali79 in case you started converting, no need to do so and sorry for the trouble if you have. It's easier if I just finish it as is, instead of sending it back and forth, especially since I'm weeding out duplicate textures anyways and have to look at each part to make sure the cfg is working properly and all textures are there. So it's effectively no extra effort to do it all in one run.
  23. Alright, nice! Is it possible you used 1.6 instead of 1.7 for some of the older parts? It seems a couple things from 1.7 are missing including some entries in the cfg of several stail parts. Well either way, I'm currently in the process of adding them anyways, so no big deal Only half way through the Stail category and already an entire page of major fixes and additions including new 1.2 systems like communications and kerbnet. EDIT: It really seems like some of the 1.7 meshes and textures are newer, since they don't have certain bugs the 1.8.5.1 has. So I'll simply replace those parts with the meshes and textures from 1.7. EDIT2: Welp pretty much 10hours in and probably roughly halfway through @stali79 I seriously appreciate the work you put into this even more now. Working through all these parts takes freaking ages. But at least it's really satisfying. Slowly seeing the missing parts coming together and knowing that all the outdated parts are slowly back on track is really nice. I did make some changes which don't exactly pass as "fixes" but I will name them all in my long list of fixes/changes once I'm done, so you can decide if you like or dislike it. Also completely reformatting all cfg files might be slight overkill, but it makes it much much easier if someone decides to change something later on, so balancing will hopefully be much less dreadful.
×
×
  • Create New...