Yeah, dockpoints are quite wonky since you can't edit orientation (or position offsets, though that'd be a bit much).
Progress so far:
7/10 models UV'ed, still have the turret section and the cores to do.
At the moment, the bottom four models share a single texture, as do the two on top of them (sensor and residential sections), and the two on top of that (dockpoint and core-connector sections). The cores will obviously share a texture since they share so much geometry. I could make the turret section with its own texture, or share it with a new section- possibly a vertical connector like BW suggested, as a ring section instead of a core section. Otherwise, I could make the turret section with its own UV, which may be necessary since the two types of turrets will require a good amount of detail.
About the core section connecting on more than one side: I'll probably do that. I have yet to UV the cores, and it'd be trivial to copy the existing geometry to make ones with 2, 3 and 4 connectors at 90 degree angles. This would mean 8 models instead of 2; models for 1, 2, 3 and 4 connectors for both cores.
Technical issue (so many :words:)Consider the ring section here:
Section 1 connects to S2, S2 to S3, and so on, until S15 connects to S16. This means we have a 16-section ring, all docked in one piece, and all the sections have well-defined positions relative to S1. This includes S16.
So what if we add a connection between S1 and S16?
In this case, S16 has two well-defined positions: the one defined by the S1-S2-...-S16 docks, and one defined by the S1-S16 dock. Because it's a 16-piece ring, these two positions are the same. Approximately.
I really doubt that the exact floating-point representation of S16's dock is equivalent to S1's dock, after being transposed 15 times, including all the error inherent in that process. This means that FSO cannot be expected to resolve the position of S16, and since our selection of "S1" is arbitrary, FSO cannot be expected to resolve the position of any section in the ring. I've done some testing in FRED, and it doesn't crash, but I'm still treading in the murky waters of undefined behavior.
In case you're still thinking of S16 being in the exact position that's needed: Imagine if I tried to connect S15 to S1. Would the ring just "bend" inwards to accommodate the 15-section ring? No? Didn't think so. Two possible positions for S15, and no good solution as to where to put it.
There is one obvious solution: simply not to dock a section to another. Leave S16 unconnected to S1. This is an acceptable solution, assuming the entire station remains intact. But most ships, and this station is no exception, exist to be PWND by BEAMZ. What happens if, say section 9 is destroyed? The rest of the station is pushed away by the explosion- and, because of the S1-S16 gap, "the rest of the station" is now two distinct pieces. S1-S8 and S10-S16 float away from each other, and S1 drifts away from S16 without any warning of their separation.
Quick fix: When any section of the ring is destroyed, use an explosion-effect in FRED placed between S1 and S16, and explain it away as structural failure caused by the same impact that destroyed S9.
The other solution-- and I am entirely unsure if this would work-- is to dock the entire ring and pray like crazy that the behavior isn't TOO undefined. FSO will be able to resolve positions exactly as soon as one section is destroyed. As to what happens before that... I'd need to do further testing.
