B-STRK

Members
  • Content Count

    332
  • Joined

  • Last visited

Community Reputation

218 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. Workaround: Click Setup; set the fairing pressure to a negative number. If yo want to only deploy fairings as stacked but not past a certain point: set your stage limit to any stage BEFORE the fairing you DON'T want deployed. Set the fairing deploy pressure to a negative number. ENSURE that your launch profile will use up the stages tight up to before the limit, including the fairing stages you want deployed. BE WARNED: setting a stage limit that is arrived before your apoapsis height has been established as desired will mean You Will Not Go Into Space TodayTM, please redo your Setup. EDIT: What I have not established yet is if GT will deploy fairings that are set to Not Staged in the editor (meaning only a PAW action can deploy them), but it is something to try.
  2. Okay, I'm not the mod author, but in the spirit of assistance especially to Igor when he reads your post, more detail please. You mentioned KAS connectors. We're talking about the same KAS, right? The new implementation by Igor whose KAS connectors no longer do the pipes, and not the old KAS where they did do the pipes? Because the KAS connectors of nuKAS don't stack. Neither do the joint bars of nuKAS. Not at all. I cannot recall anymore if the old KAS connectors stacked, and if that memory dates back to when KAS also handled storage functions before it was spun off to KIS and KAS. Continuing on, I'd like to ask: when you say items used to be stackable, are we talking about an earlier version of KIS (you upgraded and they are no longer stackable), or in the same version of KIS? If in the same version of KIS, can you recall anything new you did between when they were stackable and they aren't? Finally, I do recall that the definition of stackability can be writ into the config of each part, using the KIS modules. I think, IIRC, that stackability is not the default for parts. (For this, I suggest visiting IgorZ's github KIS wiki for help on the modules involved.) But again, you're not providing enough detail to see if this is a mod issue, or an upgrade-between-versions issue, or even a restart-KSP-to-see-if-the-problem-goes-away issue. In the words of Jerry McGuire, "Help (Igor) help you. Help (him) help you."
  3. Hey again, allista! Couple of queries. First, are the docking ports of the dockable kit containers (particularly the construction ports) compatible with the USI Konstruction mod's weldable docking ports? (let's just say I've been having trouble with getting a craft's nodes to expose in the build scene for GC to identify, so I was thinking if I used weldable docks to somehow get around it). It doesn't seem like they're compatible, but this brings up another query. And second, as pictured below, I was testing if the kit can dock to a weldable dock. But when I set the control-from-here to the construction port, it was aiming backwards (the DPAI gives the better indicator of it, but even the navball shows that the construction port in this case is oriented antitarget). Was I doing something wrong here? EDIT 24 June 2020: The reason why I wanted to investigate if a dockable kit can dock to the weldable dock is because, like I said, one station module I'm making wasn't registering its bottom node as exposed by Global Construction. Some convoluted thinking on my part thought that maybe using a docking port would allow GC to recognize something, and I wanted to use the weldable ports to make a permanent connection if I was forced to use it. But I discovered what was causing GC to drop recognition of the bottom node, and I wanted to run it past you. The two pictures below represent the space station module I am constructing. The node meant to attach to the mother station is a Stockalike Station Parts Expansion/SSPx 3.75m crew tube structural, though that's not critical right now. What I found was that if I added one of the three large solar panels from the Near Future Electrical mod, the three being (a) the superlarge circular panel generating 125EC/sec, (b) the superlarge blanket array generating 250EC/sec, and (c) the hyperlarge blanket array generating 500EC/sec, all three being surface attachable only, Global Construction can no longer recognize the exposed node. (Picture below is the 125EC one) If I take the solar panel concerned away, however, GC will now recognize the exposed bottom node. As I'm not a coder, I can only run some hypotheses from intuition. (a) These are superlarge solar panels (you could see it in the first picture of this setup). Somehow their size causes GC to lose recognition of the bottom node. (Please note that this happens whether or not the panels are retracted; I extended them in the pic to give you the idea of the total size). But I note that there are other solar panels in NFE that approach the size of these, but do not cause GC to lose the bottom node. Is there a size limit to GC in the orbital-dockable construction mode? (b) Something in the code of these specific parts is messing with GC. But that means having to coordinate with Nertea on what's conflicting, if there is any conflict in the first place. But the other NFE solar panels do not cause this to happen. (c) Maybe there is another mod interfering with both NFE and GC. Haven't gotten to test that yet, admittedly. Again, running this past you in case I might have run into a GC limitation (this time, size, maybe).
  4. Thanks for the compile/rerelease! Questions: I can replace the previous/pre-this-release KipEng folder with the one here without any issues? (as in there are no substantive changes between your rerelease and the original release that will break crafts built with the last version UDPs, for example?) And would you have plans or interests to make a 5m and/or 7.5m version of the megachonk UDPs?
  5. I vote for keeping it, I bury my reactors in parts or in bayload bays (as though shielding it) and sometimes having to play with the camera to access buried parts is just a hassle. Also the control sliders are a little finer-tuned in the US than they are in the PAW.
  6. Hiya maja, one proposal would be to add a settable offset (say x number of meters from target), maybe a cardinal direction or bearing from target as well. Or randomly within that circumference, but it does create the complication of arriving in a zone with multiple vessels, usually like MKS or Pathfinder bases which allows for discrete base/vessels in a given flight scene and range to interact; the rover could be targeted to arrive at an offset from the targeted but it just so happens that another vessel is on that same spot. Maybe add a conflicting traffic check as well prior to spawning, and then offset the rover to spawn clear of the vessel? Other than that, Paaaad, if you've got Waypoint Manager, you can set up a marshalling waypoint clear of your base for rovers to target, and have BV target that. Just make sure as well if you're sending multiple vessels simultaneously to that one spot to stagger their launches (and thus arrivals), or you'll have the same issue as targeting the base--this time with all the arriving rovers.
  7. I know what you mean. I don't use Restock myself, but what I can show you is what I hope can help you as a workaround: What you're aiming to do is to make a subassembly of your docking ports with some sort of removable "guide" to indicate which way is up. In the picture above, that would be the 1.25m battery with a Communotron 88-88 surface attached to where the "up" point would be (A). For the basic docking port, it's stacked to the "working"/front end so the back is free to be connected to your craft, like in (C). When you're done attaching, you take out the battery and you're done. (Remember: this works because when you first pick a part from the menu to place, it is (I hope this is the case for all parts stock and mod) always oriented Z+-up and facing forwards as it is programmed to in its configuration. In making the thing above there, the only thing I ever maneuvered/rotated was the flat silver platform thing out of the Buffalo mod so I could make some sort of multicoupler to show everything simultaneously (in reality, you'd just be using a simple tank as your root part in creating the subassemblies). In mounting the docking ports above, no part rotation was applied before placement--hit spacebar multiple times if you have to to ensure it is in the default position.) For the shielded docking port, where there is no "front" node to attach to (B), the guide is attached to the back and saved as a complete subassembly (port, battery, and antenna). The battery is what attaches to the craft, but after doing so, pull off the docking port--and hope to God it does not reorient itself when you do so; this usually happens I think when you mount a part to a parent, rotate the parent with the gizmo, then pull the first part off, so avoid using the gizmo to position the subassembly until after completing the following steps--pull out the battery, and reattach the docking port (which we hope has retained its pre-pull-off orientation) back to its mount. In placing the ports on station and spaceplane, orient the antenna (rotate the port in case of (A), the battery in case of (B))in the favored direction, so that when the ports are docked, the antennas are facing the same direction. For example, you want the antenna on the station docking port facing away from other structures and out into open space; you want the antenna on the spaceplane pointed downwards (if mounted on the nose, for example) or the direction away from the empennage (if mounted as a dorsal docking port). In the case of the shielded port where using the rotation gizmo on a parent part will cause the child part to reset its orientation when pulled off, you may have to use WASD to rotate the part before placement so as to prevent the dock from resetting its orientation when pulled off. This does not help in surface-mounting the docking port, I know. I am not sure if surface-mounted parts may be saved as a subassembly. If they can be, try to set up your root part so that things can be surface attached while pointing "forwards", but I am not sure if parts rotate themselves as you surface-mount them. This one will be more experimentation than anything, sorry. One tip however I can repeat from my last post is that the gizmo tool in Local mode orients itself to the part's XYZ axis locations. See picture below; your Z axis passes through the intersection of the red and green rings. It doesn't help you identify which of the two is "up", but it does reduce your DPAI (and Mechjeb docking autopilot) alignment solutions in flight to 0o and 180o. Finally, and I really do mean this, we can ask the Restock designers to add some sort of indicator or guide in the design of the docking ports to ID which direction is Z+/up. I really do mean it. I know Nertea contributes to Restock--his design for the docking port there is the remesh of the standard docking port made when one installs Stockalike Station Parts Extended to a stock KSP install, and yes it has that symmetrical "problem". But the extendible docking port provided by SSPx has a design asymmetry I could use, and Nertea designed that one as well (albeit the asymmetry was a consequence of the design of the extension animation). ADDENDUM: whoops, my original instructions for how to point the antennas on the station and plane are mixed up, this would cause collisions. Actual instruction is to imagine the final placement of the ports relative to each craft so that when they are docked and aligned, the plane empennage/tail is pointed towards open space from the station's perspective.
  8. For the stock docking ports, their graphical design is actually not symmetrical in the vertical/z axis. For example, when looking at the "front (SPH)/top (VAB)" or the "working end" of the docking ports in question, the Docking Port Jr. has the '__' look on its face (the classic "Docking Port Jr. Is Not Amused" face ) with the "eyes" being Z+. For the other two docking ports, there is this black bar on the center that is above the (imaginary) horizontal/lateral/X-axis bisecting diameter of the disc face, and the side this bar is on is generally treated as the Z+. All these are based on how these parts are deployed into the SPH as a root part, or how its pre-placement "ghost" graphic is oriented when you bring it into the build scene without rotating the part using WASD, meaning that the working end is pointing "forwards" towards the SPH doors. If you want your two craft to be docked in a specific orientation, you have to get these "up" directions pointing the same way on both the docking and dockee craft when you build them both. How you can test it is to build the craft separately, load one into the VAB or SPH (SPH is better because of the camera freedom), MERGE the other craft into the scene--but don't worry if there is no exposed node to snap the new craft into place because the root part is buried between parts, this is where the next step comes in), place it into the scene as a "ghost" (no attaching to the main build craft), REROOT (keyboard #4) THE GHOST CRAFT TO ITS DOCKING PORT, which will expose the port's node on the working end, then snap it into place on the docking port of the main build where you plan it to dock, in the orientation you want it to be docked (WASD, or use the rotation gizmo (#3) after placing). You'll know it's zero-zero aligned when the faces of the two docking ports "reflect" each other; e.g., the faces of the Jr. ports are "kissing each other" literally --> <-- . If they're not, you will need to adjust the placement of either docking port in its parent craft to the right orientation. Alternatively, when you build the crafts involved, build them as one craft, making sure that where they dock they are properly oriented and the ports are mirroring each other, then break the build craft apart and save the parts separately by using the reroot function. (Reroot to Craft 1's planned Root, delete Craft 2 from its docking port down, Save; reload the main build, reroot to Craft 2's planned Root, delete Craft 1 from its docking port down, Save). Alternatively alternatively, if you're okay with it you can download DockRotate which allows post-dock rotation of docked ports (and their attached crafts) and do it by eye post-docking. For non-stock ports, you'll have to inspect the part to see if they're non-symmetrical. One nice tip is to use the rotation gizmo in relative (I think) mode: the ring's orientation is fixed to the XYZ axis definitions of the part and you can use this as a guide for aligning the axis of the port relative to their parent craft. End of the day though, zero-zero port alignment really is just that the ports "mirror" each other graphics or design-wise when docked.
  9. Hiya Nils, I would agree with technik here in that a mobile GC part would be dandy. I'd probably suggest though, in keeping with allista's concept for GC that available space per kerbal in the workshop dictates their efficiency/productivity, I'd probably disagree with using the lab module as a workspace (else it'd have to be limited to two engineers only), but maybe make the module expandable like the KPBS Mk2 Habitat/Greenhouse/Lab, and/or similar to camper vans and trailers that unpack/expand for use, so that at least it contains the same total volume as the KPBS GC workshop. I'd however state, technik, that, while the GC workshop is quite mismatched to the FUR profile, with some creativity in offsetting, a few additional mods, and by rethinking about the architecture of your Mobile Construction Vehicle (we're going to have to act, if we want to live in a different world [Frank Klepacki intensifies]) it can even look somewhat decent. If I may suggest? The idea here is that the MCV is the workshop and batteries only (as well as living quarters modeled in using the crew cabin, especially for life support purposes), while Matkits are brought down in disposable USI containers to the construction site by skycranes, and hooked up using KAS. So you wouldn't have to worry about Matkit tankage onboard the MCV, especially if you're constructing something a very wide ground base that is past the 300m limit of GC (wait, there's a limit? Or are we talking about distance of workshop from kit-efficiency of construction here?), if you can bring the Matkits in separately and dispose of the tanks afterwards when there's no further need of them. For a FUR-profile resource tank to hold the Matkits needed while still being reasonably within the size profile (e.g., a FUR fuel tank), and have enough kits to construct a megabase (like a hundred thousand Matkits) you'd be towing a lot of trailers, that it'd be more parts and space-efficient to just use the largest tanks you can get out of USI/NearFuture/Configurable Containers (instead of the rover tanks from FUR/Buffalo or Bison, for example) and bring them in separately. Not even the basic GC Mobile Workshop can hold that much Matkits for what I think you're trying to suggest, even if all the internal tanks were converted to Matkits. Trust me: back in 1.4, a Minmus megabase I built required THREE of the 3.5m USI Matkit Kontainers (the one that look like shipping containers, not the circular one like up above there), and I picked the 3.5m profile only because making a skycrane for the 5m profile Kontainer was a nightmare. And I think I had required two KPBS GC workshops so I could get it done fast (as in a week's work). Not that I'm disagreeing with your petition to Nils to include a FUR GC workshop, Nils, he does have a point there. But in order to keep to allista's space-use philosophy while giving the FUR GC workshop the same efficiency as its KPBS counterpart, we'd have to either reduce the number of kerbals inside, or make it an expandable campervan to match the KPBS GC's internal volume. And admittedly, I haven't even thought of the possibility that GC isn't programmed to take into account expandable parts, unless it is possible to establish the efficiency of a part independently of any formula? EDIT: also a good idea to include Matkit production in FUR's ISRU (I can't recall right now if FUR has a drill and ISRU, but if it does, then yes, KPBS already has a setup made for OSE after all I think?). Alternatively, technik, you can ModuleManager patch it into the appropriate FUR part with the appropriate module provided in GC's config files that plug the functionality into the Squad ISRU, you'll just have to get the ratios between the Squad ISRU and FUR ISRU right to make sure it isn't too OP. I know I did one for the Mining Expansion's S3 ISRU, but I cannot locate that patch anymore (and I think the functionality was already patched in by suicidalinsanity in the MEx mod, so I didn't have to anymore nowadays).
  10. Hiya Stone, thanks for getting Wyvern up to speed again! One issue I found after testing the part, the IVA seems inverted vis-a-vis the pod's control point orientation: (The navball being "upside down" when the pod is maneuvered IVA is rotated heads up). I'm not sure if this is a mod conflict or not? (RPM is the adopted version as you suggested.) Edit: One thing I notice however is that the door on the IVA matches up to the door on the exterior model. Only thing is that when the part is loaded in the SPH build scene, it appears "door side up" which usually gives me the impression the door is on the "upper"/dorsal side of the craft in a horizontal flight/SPS orientation, similar to how a cockpit canopy is the "up" of that part. And that is reflected by the door side oriented towards the sky blue in the navball above.
  11. I can also confirm this for 1.9.1. I don't recall that development or curation was ever passed from CaptainKipard or anyone else, and the one I'm using is from a user's unofficial hosting (I don't know if he made any changes) from my last post a couple years back. We could try asking one of the present "professional" mod curators (linuxgurugamer or zer0kerbal) if either is interested in trying to get in contact with CaptainKipard about this. (And also if he or at leat the present license will allow a 5m and 7m UDP to be added to the set--I've been missing those lately.)
  12. No worries on the question, if there's anything anyone can answer, we do try. I think this one though can be asked as well to allista over at the Global Construction thread, to find out how far the Ground Construction (which he built up) and MKS modules interact. But my suspicion is that GC just isn't equipped to handle MKS's distributed logistics logic. It'll only read resources (and crew) in the vessel housing the Workshop for purposes of construction, although maybe (and I haven't tried it yet admittedly, plus I run GC independently without MKS so I'm speaking from this experience) you could team up other workshops in nearby vessels on a single kit project once it gets going (I had gotten it going with workshops in the same vessel, so that is a go).
  13. Don't we all appreciate a good function when we see it? https://github.com/UmbraSpaceIndustries/MKS/wiki/Modules#weight-distribution The link should take you to the list of modules the MKS system uses. I think you're looking for USI_IntertialDampener. I think? Further context: the module should be transplantable to a part by patching, maybe. I recall seeing ground tether in the Offworld Rocket Pad of Kerbal Hacks (the one with asphalt tiles).
  14. Admittedly I'm running a mod heavy run, also KIS/KAS (but IIRC Rover never intended any integration between them and Konstruction), but this is what it looks like on my end. I also confirm it was this way back in 1.4, and in fact trying this out on Minmus led my insurer to jack up my insurance premiums on all Minmus operations faster than a Falcon Heavy can yeet a Ferrari into Pluto (translation: hilarity with momentum). As noted, there is the Magnet Strength slider in the PAW, and again I really don't think it would be the case that KIS/KAS is adding it, I believe it should be inherent in Konstruction. Can anyone else confirm if they've got the same PAW as here, just in case?
  15. Just to rule out some preliminary stuff, sorry, are you also seeing a Magnet Strength slider in the PAW, and is there juice in the batteries?