B-STRK

Members
  • Content Count

    302
  • Joined

  • Last visited

Community Reputation

204 Excellent

1 Follower

About B-STRK

  • Rank
    Lowlife Three Striker

Profile Information

  • Location Array

Recent Profile Visitors

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

  1. Banned because upgrading is stalled at 87%.
  2. Ace Combat 7. In fact, I'm so soaked in it at home, the only time I can play KSP is if I can sneak time at work, and lately that's been impossible, so I'm kinda missing my space hotels and munar construction sites already. Still, Ace Combat. The one series guaranteed to put muh space program on pause.
  3. Banned for confusing non-chemists with your basis for banning GRS. (Yes, I checked the wiki link. Still confused.)
  4. Hi, and okay, even if the authoritative answer would come from @allista, if anyone else would have an idea, I would be much appreciative. So both the Ground Hangar and the Habitable GH have attach nodes on top and behind (seen in SPH), right? I'l like to attach them to a baseplate, more particularly the Large Landing Pads from @Enceos (I think) to form part of a base complex. Thing is, I attach them using either node, and then offset, launch to test, and on return to the SPH the offset is gone, like if I attached it from the baseplate's bottom/Hangar's top, then offset up, on return to SPH, and loading from the saved craft file, the offset is gone. Similar with the back node, except it loses only vertical offset, rotation is still preserved. So, is it particular to the Ground Hangars that they lose their vertical offset if I try to attach them as a child part? And if it can't be avoided, how can I add, either by manually editing the part cfg or an MM patch, a bottom attach node opposite the top attach? (Interested in doing this in order to integrate the ground hangars as part of a base vessel, to reduce total vessel and vessel loaded in scene count. So far only the Inflatable and Rover Lander can do so as they have bottom attach nodes, but the Inflate only stores one vehicle and the Rover Lander is kinda unwieldy with its lander legs/ramps.) Thanks for any answers that may arise! EDIT: Looking at the config in the github for the "Small Hangar"--I guess the Ground Hangar, for example, I see: node_stack_bottom = 0.0, -2.18543, -0.4944, 0, -1, 0, 1 node_stack_back = 0.0, 0.4, -1.6194, 0, 0, -1, 1 which I guess defines what I called the back ("node_stack_bottom"), and top ("node_stack_back") nodes as seen in the SPH, the definitions in the config based on their orientation in the VAB (the ground hangars load into the VAB doors pointing upwards). I guess what I am looking for is the opposite of node_stack_back, to pop a stack node where on the "floor" of the hangar where it meets the ground. But the CGF documentation in the wiki isn't helping as it doesn't even mention "node_stack_back", and even if I knew, I'd have to know the position and vector coordinates to plug in. Really hoping someone can help me here, particularly with the coordinates. EDIT 2: Playing in KSP a little more, I can observe that the behavior only happens if the part size is changed; despite any translative offset saved, on reloading in the SPH, the Hangar defaults to the position of the node it is attached to (though keeping its rotation offset). Which means that it seems the editor can't save the offset of a part tweakscaled up or down from its default. I guess even adding the stack node I was hoping for won't help if even with that, it won't save offset positions. Unless I'm missing something?
  5. Hi @Gaarst, I tested @CaptainKipard's Universal Docking Ports (based on this available download as posted by forum user Chonner--who by the way if what I read and interpret is correct has not modified these files in any way from as originally released, just rehosted them in a more accessible location) in 1.4.5, and confirmed working as advertised. Thing is (a) the link to the download is a mirror of the existing latest available update (from what I can read), which is not the original download link (being mediafire links, but one of the latest posts states that typing up the links still works), and (b) the modder hasn't popped in since 2016 or thereabouts, so I'm not sure about the licensing issues that could crop up (even if it is NC-SA 4.0), but in terms of updates, this be working in 1.4.5. I guess it might still work in 1.5 and 1.6, depending on if there are any major changes to docking across the versions?
  6. Yep, confirming that the latest DockRotate works with UDPs (under a KSP 1.4.5, MM 3.0.7, KJR linuxgurugamer fork setup)
  7. Good news, DockRotate .21 now works for UDPs in both UDP-stock port and UDP-UDP instances, both connected ports tested, and with mis-matched sizes as well, right up to continuous rotation. And this is with KSP 1.4.5, and MM 3.0.7. Admittedly though I am still using the linuxgurugamer KJR fork, so for any updates involving the KJR/L fork someone with that install would have to try it out as well. (Pics of testing rig below, behind the pull-down) Much thanks for the update @peteletroll!
  8. Hi @peteletroll, kinda bringing up something from the past here (although word of warning, I am playing with a 1.4.5 install, so I'm not sure how this would be in 1.5/1.6). I went ahead and installed the Universal Docking Ports from back in the day, using this mirror-file Dropbox link provided by another forum user (while CaptainKipard hasn't returned to the forums for quite some time already). The ports work, they just don't have a DockRotate function despite the PAW in-flight having the toggle to activate it, and neither will any regular/stock port docked to it. I've yet to test if installing Universal Docking Port will interfere with two stock ports or Konstruction ports docked together, but based on what I've read here so far my bet is that it wouldn't interfere (like DockRotate just needs to recognize the existence of a specific port part to bring up the functionality, if I guessed right). But I'm dropping a note here in case it might be useful or desirable want to have dock rotation functions with UDPs, for those who want to use UDPs. (Myself being one of them, of course, but that does bring up an interesting question: can DockRotate work with two different port parts docked together as would between UDPs and stock ports?)
  9. Okay, so I know it's not about 1.5 or 1.6, but if anyone's curious again, the Universal Docking Ports you get from Chonner's dropbox (which is still around) still seem to work in 1.4.5. And unless something major changed with docking nodes jumping to 1.5 or 1.6, there's a good chance it means it'll work for current KSP as well. A note for those who use DockRotate though: while the Enable Rotation toggle appears in the PAW, it will not bring anything up. Neither will any stock port docked with a UDP be able to bring up its Rotate functions. Likely because DockRotate hasn't been programmed to consider UDPs (yet). And now that I realize it, I should have tested whether DockRotate will work with the stock and Konstruction docks as usual while UDP is installed... I'll be back when I find out. (Also cross-posting this up in DockRotate.)
  10. Hope to see it soon as well! Danke! (And by that I mean released for all, changes merged etc.)
  11. I just realized... what's the formula for EC requirement for any given construction? Can we estimate how much EC capacity to bring on-dite before starting construction, so we can safely leave and return when all is ready without the game deciding we ran out of juice midway?
  12. Well, given how large those salad bars (the decoration rows) get, maybe compressing things some might make things easier to scroll about when looking at the roster? And to be fair, to see someone march with a master's hood on grad day generally presumes thay he marched in the past with a bachelor's cap too, so he doesn't have to march with his bachelor's regalia either. I say generally because I never marched with my bachelor's or master's degrees... long story, having to do with late submission of final requirements. I did march for my law degree though, so you can make the presumption very safely. Looking at things, it's probably because with the default ribbons each achievement is treated as a unique decoration, as such it gets its own ribbon. A different implementation for custom ribbons for example might be to include devices (those pins on some ribbons that indicate repeat or meritorious achievements) that would justify replacing ribbons to reflect the updated awards.
  13. Banned for critical fail rolls.
  14. Speaking of which, going off from IgorZ's post above, how would I be able to expose the mini-greenhouse (it's not been deprecated, right?) without installing an LS mod... for roleplaying purposes only? I'd be willing to edit a cfg, although I guess would it be safer instead to write an MM patch to force the exposure? Thanks! What? I take good nutrition seriously. How else are my kerbals going to stay a healthy shade of pink green, chew on rocks?
  15. Hi @IgorZ, no worries, this isn't a bug (and certainly not) complaint this is just a blue-sky spitballing post about coming up with ideas that may or may not work. So I do agree that this shouldn't be anything of a priority, but hopefully something to think about for the next major update? I wonder... is it possible to implement a kerbal's grab-and-position functionality as a module for a part, say a robotic arm, whether IR or some other implementation like Konstruction? I already know that the KIS module on a part like that makes the vessel act like multiples of kerbals within its affect range, but the actual grabbing still has to be done by a kerbal on EVA, dismounted from the vessel, when I'm thinking maybe the kerbal on/in the vessel with the robotic arm with the KIS module (or in other words, the vessel itself) be able to simply grab the part and position it (probably even screw it in, but yeah I get the picture why in terms of realism this might not be a popular idea to implement). I do ask because even if a vessel would be able to provide the lift power and range to reach a 3.5m diameter or larger part, because it's still the kerbal who has to do the grab-and/or-bolt, he or she might be too far out of range of the CoM of the part concerned to manipulate it ("Too far" tooltip). Someone else somewhere else in this forum (or maybe the subreddit?) made a similar observation about how tricky it would be under those conditions, and there are times I wish a robotic crane or mecha or such would just be able to bolt in a 5m diameter part on a node for a ground base KIS-style (... long story, but short version is, saving MaterialKit costs in Ground Construction by shipping prefab parts to bolt in), rather than have to manipulate robotic controls, and a magnet or a Klaw, to get the parts concerned to dock or fasten together. Alternatively, could we have the existing KIS module actually also extend the grab and bolt range of nearby kerbals in its own affect range as well, so that even if we have no choice but to use an EVA kerbal due to coding mechanics, at least it'll be as if the robot or crane was doing the heavy lifting and reaching over beyond a kerbal's reach, or in actually be providing the heavy lifting and reaching that a kerbal alone could not do, and all the kerbal had to do was crawl under and screw in the bolts? Like I said, it's not a major concern or anything, nothing urgent, but hopefully an idea for a future update, if it is possible to implement in the first place? and can it be 1.4.x friendly in a future update? I feel like I can't even move to 1.6 yet, so much yet to transition over, so much instability in the mods to fear...