allista
-
Posts
2,208 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by allista
-
Sorry, I didn't quite understand the situation you've described. What structure was left on runaway? Anyway. If you recover a hangar with some stored vessels (i.e. they are invisible and appear in the list in the GUI), their cost is just added to the cost of the hangar, so they themselves are not, technically speaking, recovered, just their costs. On the other hand, if some vessel is just positioned inside the hangar (e.g. you drove your rover into the inactive ground hangar and left it there) and then you recover the hangar, positioned vessel is not recovered; the hangar just disappears from beneath. Maybe the vessel that was left was not stored, just located inside the hangar?
-
Unfortunately, you can't add meshes and transforms to a model with MM. And while I can add the option to define hangar space in .cfg file with two vectors, defining a transform is much less intuitive. But that's doable too.
-
I'll think about it all. It does sound interesting. But there are other things to consider: smaller mode with less functionality is easier to maintain and thus it'll live longer; not all people like ExLP functionality, considering it a little cheating, so it's good to have it in a separate mode; etc.
-
Thanks ='= Maybe I'll swap texture sets in the end, making the gray one the default.
-
No, the door is not really required. But the hangar space and launch position are. Without them there will be a (big) chance that launched ships will intersect with the walls of a hangar and explode.
-
Hmm... the last time I've checked the thrusters they were shaded normally, just like the Spaceport on your picture. Unfortunately I will be able to check this only after September 11 when I return home. Am I guessing correctly: a flag decal should use the translucent shader to render such a flag? I haven't found any documentation on flag decals, so it was (as it often is with KSP) a reverse engineering... EDIT: added an issue about the flag
-
I don't see the need for this, as it is just the functionality ExLP provides. The Hangar is about storing ships, not building them. If you want an enclosed wharf instead of a launchpad you should probably write to taniwa instead. But understand that such wharf will have to check ship's geometry before the build, and that's not an easy task.
-
That won't solve the problem in general, because it's not marginal but geometric. Your probe stuck not because it was a little bigger, but because it intersected with some of the colliders. With four out of six, to be exact. So the only solution (without rewriting the check itself) is to make the bounding box to fit the real space. But that would decrease the space available for vessels by 2-3 times (square inscribed into a polygon). Good one! I'll definitely use it.
-
Well, if you make a model for it, I'll plug it in, no problem. I'm not a great modeller as clearly may be seen by the models of hangars. In fact they are my first models ever. For a hangar module to work a model should have: an animation of opening door(s) a hangar space -- hollow mesh without a renderer which is enclosed by colliders. But see the previous post for caveats. a launch transform -- an empty which local transform is used to orient and position a launched vessel. Note, that I use position of geometric center of a vessel, not CoM. So the launch transform is better be just in the middle of the hangar space.
-
The "good" news: I think I know the reason for this behavior. When a hangar looks at vessel's dimensions it uses bounds of internal space and checks if every part of the vessel is strictly inside these bounds. This effectively means that whatever the shape of the internal space is, for the hangar it's just a box. Then it's pure geometry: if you inscribe a circle (heatshield in your case) into a square (bounding XZ plane) it would be larger than any finite inscribed polygon (hexagonal internal space of inline hangars). So the hangar lets you store the heatshield that fits inside the bounds, but not inside the walls of internal colliders. The bad news: I don't know what to do with this, except to make all internal spaces to be boxes, like in ground hangars. In Unity colliders do not have means to check if some point is inside or outside of them, they just detect collisions with other colliders. And to perform an actual collision detection for every collider of every part of the vessel just to check if it fits... it seems too much of a price computationally. But maybe that's what has to be done after all. Need to think about this.
-
Added the link to your texture pack to the main post.
-
Thanks a lot! Maybe you could list the mods you used in construction, so I could install them to see? - - - Updated - - - Perfect! Thank you so much!
-
0. It would help greatly if you provide the .craft file of the probe with the shield, and of the carrier as well maybe. 1. I was thinking about it myself. Made an issue and will implement it. 2. Well... inline hangars were meant to be snapped to the end of rocked part of the smaller size than they are. Small Inline -- size1; Habitable Inline -- size2. Not size2 and size3.
-
Announcement I'm going on a vacation and then on a conference, so I wont be able to work on the Hangar till 10th of September or so. I will however monitor (albeit less frequently) the forum and GitHub issues. Thank you all for your support and testing! With your help the mod will become STABLE in a couple of months. I hope ==
-
Oh, that's fantastic! I do want them! Anyway I was going to do just the same thing with the textures, but after 10th of September, when I will again have time to work on the project. So it'll be nice to release an alternative texture pack before the vacation. As for the issues, I've answered and will think about your proposition.
-
If it comes to that, using a hash function on a file would be more robust.
-
What you're suggesting have much sense, but in addition to the apparent need of rewriting the CraftBrowser (I'll burrow into the disassembled code of the CraftBrowser to know for sure) there's another problem: it's not enough to remember which crafts you already measured, you need to know somehow if the files have changed since, because you can't guarantee that the user, say, didn't changed them by hand, or some other plugin like MM didn't changed them on the fly. But again, these are two separate problems, and if I could add this additional check into the CraftBrowser, well even loading and measuring 20-30 craft files would take no more than a second of freezed Editor. That's bearable.
-
Indeed, couple of digits should decrease the probability of such confusing moments considerably! But there still will be confusion with rotated frames of reference... Unfortunately, the only way to measure vessel's dimensions is to actually load it into the Editor. The hangar does just that: loads the vessel, rotates it, measures, and then immediately destroys so the vessel remains unseen. And load ALL of them in one frame... Besides, the window with the list of ships is a stok GUI over which there's little control on the API side. I doubt it's possible to add an additional check there. But I'll investigate.
-
I think I understand now what's happened. The Sedan's frame of reference IS correct in that its Y axis is in its forward direction. Which was correctly indicated in Vessel Info window all along: X (width): 1m, Y (forward, longest side): 2.3m, Z (height or depth): 0.9m. The same is true for the Lander in its natural orientation (bottom down in VAB, bottom back in SPH): X (width): 1.8m, Y (height in VAB, forward in SPH): 1.5m, Z (depth in VAB height in SPH) 2.3m. But this particular hangar launches vessels rotated, so that their Y axis looked in its Z direction (and rover wheels were down when it's standing on its bottom). So indeed, dimensions that are compared become swapped here. But that was not the problem, it's just confusing and I need to think about how to better display things. The problem, as you may already guessed, was simple: displayed dimensions are rounded up to the one decimal digit. So your Sedan is really, say, 2.33m long, while the hangar at the scale of 1.3 was 2.32m long (in its Z direction). That's why the Sedan didn't fit at first and fitted when you increased the size a little. That is again a problem with representation and confusing messages. I'll think how to improve things for such a case. Many thanks for your investigation and reports! *about reference frames and VAB/SPH: KSP works on Unity engine, so in the world space as well as in the local space of correctly modelled part the XYZ are always the same: width, height, depth. The only difference between VAB and SPH is that SPH editor rotates any part cloned from the parts panel by default. That means that in SPH world space is still the same: width, height, depth; and the local space of a part is the same. But the transform from the local to the world space has an additional rotation of 90 degrees around X axis. Sorry if I my explanation is unclear. This whole thing with different reference frames and transforms often confuses me myself.
-
The X,Y,Z dimensions of context menu and Vessel Info are always in the same order: X, Y, Z. And that's what "causing" the problem, I reckon: Enable "Show Directions" option and see where are Y and Z (forward and bottom) of the Sedan are. Each hangar has its own launch frame of reference, and when a hangar tries to fit a vessel inside, it first rotates the vessel so that vessel's axis are cooriented with hangar's launch frame of reference (as indicated by the arrows inside that hangar). Your Sedan's local frame of reference is probably rotated so its Y axis looking up, through the roof, not forward. So rotated it does not fit the hangar. It's not a bug, it's just a safety mechanism ensuring that when a vessel is launched inside a hangar it does not collide with the hangar's walls.
-
If you hover over a hatch (any hatch on any part that has it, that's stock functionality) a label "Crew Hatch" appears. When it does, click on the hatch to summon the window with the list of the crew. In the list there is a button "EVA" alongside each crew member listed. Push that button and your kerberonaut will climb out of the hatch. Note: 1) the label appears only from a small distance; if you're looking at your station from too far, move your camera closer until you see the label. 2) the label appears only when the ship is at rest, not accelerating or throttled; the check is the same as for saving the game. But sometimes this check doesn't work every frame and you see the label flickering. Then you just have to click repeatedly on the hatch until you hit it at the right moment. That's Squad's bug.
-
You're right, those numbers are for the cargo bay, so it really should have been fit. If by any chance you have the .craft file of the vessel that was not fitting, I would be glad to test it, because it does smell like a bug for me. Try to check saves_backup folder if it was overwritten in your save folder.
-
The hotfix for the rover-on-mun problem is out. Here's proofpic:
-
I have a confirmation from Joshwoo69 and already working on the issue Expect a patch today. And sorry for that stupid bug '
-
Wow... That's incredibly strange! I'll test it ASAP!
