Spanksh

Members
  • Content Count

    31
  • Joined

  • Last visited

Community Reputation

21 Excellent

About Spanksh

  • Rank
    Rocketeer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  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.