For information and discussion about Oolite.
https://bb.oolite.space/
Maybe I should put your Habitat into "Station for Extra Planets" oxp? To get it into play? Unless you want to reserve it for other use of course, as a Hotel Station for example. Shame if it goes unused.Zieman wrote:And while we're at it, feel free to use (and improve) the Habitat Stations ( https://app.box.com/s/p52h0w4wj3hxq5h3i4mi ) as part of the Hotel Station pool.
The last version already has the flashers.. look very pretty, too..pagroove wrote:can anyone grab the last version of Ring.oxp and make a script so that it only spawns at Tertiri (G5)?
And then the one with the flashers?
I really like this idea.. but I doubt it would be feasible, as you'd have overlapping bounding-boxes, yes? (trying to remember what little I've learned here about the way such things work)ClymAngus wrote:By using plate units that bevel up at one end and down at the other, might it be possible to give the appearance of connectivity?
If it's made of a single entity (even with subentities), its bounding box will touch the planet, and it will instantly collide with it. It'll also be so large that I doubt it would workDiziet Sma wrote:Does anyone have any other ideas, apart from flashers to connect the sections? A sub-entity at one end (or smaller sub-ents at each end) of each section, perhaps? Or is that subject to the same limitations?
Well no.. I was referring to Thargoid's already working proof-of-concept demo.. which is made of many individual entities.cim wrote:If it's made of a single entity (even with subentities), its bounding box will touch the planet, and it will instantly collide with it. It'll also be so large that I doubt it would work
So are you saying that bevelled ends could be made to overlap, thus, from a distance appearing to be contiguous, so long as they don't actually touch? If so, how close together is it safe for them to be?cim wrote:If you make it out of sections, so long as they don't actually touch, they'll be fine ... until the player gets away and the collision detection algorithm moves from "exact" to "approximate". That particular optimisation might be possible to remove - I'll have a look at how much time it actually saves. If not, you'll need to use bigger "joints" in the next step.
Could you elaborate on what you mean by "make the polygons for the joints into a visual effect" for us not-up-to-speed types, please? I have a project of my own in mind where this idea might be helpful.cim wrote:To cover the joints: provided that the size of the gap is too small to fly a ship through, make the polygons for the joints into a visual effect, not a ship. It'll look just the same - provided everything stays positioned correctly - but it won't cause internal collisions.
Thargoid's demo currently uses over 300 sections with no problem. Each is about 1km long, I believe, with a 200m gap between sections, currently filled with a pair of flashers. A less "cheaty" way of filling the gaps would be great.cim wrote:So long as the collision radius of each real section does not intersect the planet, it should then be fine. You probably shouldn't have any individual section being significantly bigger than a Coriolis - maybe 5km long at most. Tetiri is a big planet, so you're probably looking at around 150 such sections, plus 150 visual effects to join them together. That's manageable.
If the player is at long distance, the centres of the objects must be separated by at least the sum of the collision radii of the objects.Diziet Sma wrote:So are you saying that bevelled ends could be made to overlap, thus, from a distance appearing to be contiguous, so long as they don't actually touch? If so, how close together is it safe for them to be?
Let's simplify it to two boxes you want to put together. They're both "ships" through shipdata.plistDiziet Sma wrote:Could you elaborate on what you mean by "make the polygons for the joints into a visual effect" for us not-up-to-speed types, please? I have a project of my own in mind where this idea might be helpful.
Code: Select all
+-------+ +-------+
| | | |
+-------+ +-------+
Code: Select all
+-------++-------+
| || |
+-------++-------+
Code: Select all
+------ =*
|1 2|
+------ =*
Code: Select all
+------=*+------=*
|1 2||1 2|
+------=*+------=*
But isn't this exactly what would happen if the ends of the segments were bevelled so as to overlap without touching? As I understand things, the collision radii would extend from the "o" in the centre of each object, to the "+" at the furthest corners.. thus, the centres would be separated by less than the sum of the collision radii if the bevels overlapped to even a tiny degree. Or am I not understanding something correctly?cim wrote:If the player is at long distance, the centres of the objects must be separated by at least the sum of the collision radii of the objects.Diziet Sma wrote:So are you saying that bevelled ends could be made to overlap, thus, from a distance appearing to be contiguous, so long as they don't actually touch? If so, how close together is it safe for them to be?
Code: Select all
+---------------------------------- +-----------------------------------
\ \ \ \
\ \ \ \
\ o \ \ o \
\ \ \ \
\ \ \ \
------------------------------------+ ------------------------------------+Very cool.. thanks for the explanation!cim wrote:Let's simplify it to two boxes you want to put together. They're both "ships" through shipdata.plist
Correct. Potentially even if they didn't. As I mentioned above, that optimisation on the collision detector may need to go - it's player-centric, which I don't like, but it may be that in typical systems on old computers it's also necessary.Diziet Sma wrote:thus, the centres would be separated by less than the sum of the collision radii if the bevels overlapped to even a tiny degree.
