Witchspace and docking sequence upgrade

[lave]

I think people are missing my point here.

I know you can fly 'into' a station, fuel station, rock hermit, ect...

but I was more thinking or an asteroid that had a hole in the side that you can fly into just to hide from persuing ships.

Thanks anyway.

[Kaks]

If I could find the software to make models for Oolite and knew how to get them in game then I'd have a go myself.

Ahem:

http://wiki.alioth.net/index.php/OXP_howto_model

[Smivs]

I think people are missing my point here.

I know you can fly 'into' a station, fuel station, rock hermit, ect...

but I was more thinking or an asteroid that had a hole in the side that you can fly into just to hide from persuing ships.

Thanks anyway.

Commander McLane explained this a few posts back. You can't 'just have a hole you can hide in' because of Oolite's in-built collision avoidance system. Basically you don't have to 'hit' something to crash into it...just getting too close will destroy you.
Dockables are different, because you don't actually physically fly into them...when you get to the dock the whole game changes so you are docked. If you don't understand, park close to a station and watch other ships docking. They don't actually enter the station or whatever, they just sort of disappear at the moment they reach the dock. This is what happens to you as well, you 'disappear' into a docked state.
Forgive the simplistic explanation...this as well as I understand it!

[lave]

OK thanks for that.

I got confused because of the fact that you can fly right through something like the fuel station which you don't actually dock with or some of the other dockable stations, like a hacker station, where you are inside the tunnel before you reach the point that 'docks' you.

That's why I assumed that a similar large object with a hole in it wouldn't have killed you if you didn't hit the sides.

[SiriusCG]

Ok, maybe some silly questions...

So, if you're in a Fuel Station, and you've come to a halt (before triggering the fueling process), are are you still on a pursuers radar? Does a missile target lock still work? If it does, won't the missile impact the fuel station first? (Although I suspect the fuel station ECM will deal with it.)

If one could "hide" in a fuel station ... I would surmise that one could "hollow out" an asteroid and configured it similar to a fuel station, and that "should" make it a fairly effective hiding place.

[Brain under construction. Please pardon the mess.]

Cheers.

[Smivs]

Perhaps a large toroidal asteroid might work, like a giant doughnut that you could fly through, but as has been suggested, it would have to be very big so that at no point do you get anywhere near the actual fabric of it.
But why hide? If you're going to attack something, GO FOR IT! If you're threatened, use Evasive Tactic Smivs Alpha (run away )

[Killer Wolf]

the hacker asteroids are hollowed out and way big enough to hide in, so modelling something like that is doable. as mentioned tho, it's the collision detection that might throw a spanner in the works if you find out you're able to fly out through a wall etc.

[lave]

The reason I asked is because in another game that I made models for you could hide in a hollow asteroid.
There was nothing special about the inside, just a hollow asteroid.

Depending on the type of asteroid, you were either hidden from other ships scanners (and thus you too could not scan outside the asteroid) or you were seen on scanners and the enemy ships would either wait outside for you to come out or they would even attack the asteroid itself.

Although depending on Oolite's pirateAI an enemy ship would probably just try to fly towards you and hit the asteriod and die anyway lol.

[Commander McLane]

The problem with Oolite's collision detection is that it is not very precise. Therefore there is the risk that two objects which are close to each other without actually touching each other will be detected as colliding. On the other hand two objects which already have moved into each other may not be detected as colliding. Both cases happen, and both are unpredictable.

The only circumstances where some extra precision is thrown in is when one of the objects is dockable, and the other closes in along the first object's z-axis, which means moving toward the dock from a straight frontal position. In this case Oolite is programmed to use extra precision.

Your hollow asteroids would not be dockable, therefore they would have to live with the lesser precision.

And even the greater precision for dockable objects isn't guaranteed. For instance it is possible at times to turn sideways within a Hacker or Salvager Tunnel, and fly through the tunnel walls and through the asteroid. A times. At other times you get killed immediatly when you try the same action. This is what I mean when I say that Oolite's collision detection sucks.

As far as "hiding from scanners" is concerned, the answer is very simple: scanners in Oolite don't work this way. They don't need visual contact. Therefore no object would be able to hide a ship's scanner signature. If scanners would only show objects which are visible in a straight line, you wouldn't for instance have ships on the scanner which are behind a station from your viewpoint. But you do. They are on your scanner, regardless of objects between you and them.

[CheeseRedux]

Your hollow asteroids would not be dockable, therefore they would have to live with the lesser precision.

[random idea mode]
1. Make hollow asteroid with dock
2. Make dock so tiny it becomes (almost) impossible to use it
3. Make a texture that camouflages the dock opening
[/random idea mode]

[Mauiby de Fug]

As far as "hiding from scanners" is concerned, the answer is very simple: scanners in Oolite don't work this way. They don't need visual contact. Therefore no object would be able to hide a ship's scanner signature. If scanners would only show objects which are visible in a straight line, you wouldn't for instance have ships on the scanner which are behind a station from your viewpoint. But you do. They are on your scanner, regardless of objects between you and them.

I have before now been attacked by a pirate which was almost "hidden" by a cloud of either asteroids or cargo canisters (I'm not sure which, was too busy trying to shoot him, but I would guess it might have been the remains of his last victim), by which I mean that there were numerous white blobs that almost covered up the yellow (then red!) blob. Perhaps an asteroid cluster, or an asteroid made up of multiple asteroids joined together, might do the trick?

[Switeck]

I've been killed by pirates shooting through an entire Pirate Cove (or Rock Hermit) asteroid with their lasers. Major collision failures there!

[Eric Walch]

The problem with Oolite's collision detection is that it is not very precise. Therefore there is the risk that two objects which are close to each other without actually touching each other will be detected as colliding. On the other hand two objects which already have moved into each other may not be detected as colliding. Both cases happen, and both are unpredictable.

The only circumstances where some extra precision is thrown in is when one of the objects is dockable, and the other closes in along the first object's z-axis, which means moving toward the dock from a straight frontal position. In this case Oolite is programmed to use extra precision.

Its not the extra precision that happens with stations, but it is more that collision detection is disabled for stations. Or more precise: When the ship is in a narrow lane in front of the dock, collision is disabled. When you move a little outside that lane, scratch damage is inflicted on the ship and the ship is bounced a bit to the centre of the lane. This scratch damage is no part of the regular scratch damage generated by the collision detection. (Thats why the shipCollided() event-handler does not fire when touching docking walls) When you are to far outside the docking corridor, normal collision starts and that probably means: "press space commander". At long as you stay inside that lane, you can even fly through solid walls. (like in the buoyRepair station.) Its up to the ship designer to not add such walls in the path.
And because the docking-lane is only in front of the dock, any bends in the approach will be impossible.

[Eric Walch]

I'm actually surprised that no one has ever made a hollow asteriod or other structure that you could fly into.

What? The Hacker Outpost and the Salvage Gang are hollow asteroids, and they are a part of Oolite for ages.

However, hollow structures only work if they are dockable. It is impossible to make a non-dockable entity you could fly into.

I was a bit curious at the code. It seems that the size of a ship not really matters at all for docking. When the dock is not at least 10% larger than the ship, Oolite will increase the virtually opening a ship can use in steps of 25% until it does fit. (That also explains why some largely oversizes ships could dock.). The only important thing for big ships is keeping the centre of the corridor.

When you switch "docking" debugging on (Very easy with the mac console were its a menu item) you'll see which dock size the station is using. I was surprised to find for my boa II:

Code: Select all

[docking.debug]: Normalised port dimensions are 192 x 80 x 250.  

That explains the ease of docking. My boa II is 60 meter high and a dock is 65 meter high. That should give a margin of 5 meter. But its actually calculating with a port hight of 80 meter. That gives me 20 meter margin.

[Big Bene]

OK, this is the way I would try to do it (if I had any experience in Oolite scripting):

I. The effect we want to achieve:
Scene 1:
For whatever reasonn, the player wants to hide.
He sees a huge asteroid with a cave in it. Probably this asteroide is a) part of an asteroid field, b) moving itself.
The player now flies "into" the cave. This is a difficult task, because he has to line up the course of his ship with the cave entrance and the possible movement of the asteroid. It's very similar to docking on a station without computer (maybe somewhat more difficult, but the same principle).
If the player manages to do so, he will fly inside the cave. If not, he will explode.

Scene 2:
He did it. The player is now iside the cave. His speed must be null of course, or he will still colide and explode. I vote for setting his speed to zero automatically (just as wehn docking on a station), but who ever will write the script may choice to leave the responsibilty to make a full break to the player.
The player is now staring at the dull rear wall of the cave. Naturally, he will want to see more, so he slowly and carefully turns his ship around. Of course he can start the engine if he wants, but this will still result in collision and certain death.
After making a full turn, he can now see out of the cave. The movement of the asteroid has mystically came to a halt. It's not "realistic", but it adds to the game dramatics, as the player can now watch the battle (or whatever situation he is hiding from) from his hiding place. He won't notice, anyway.

Scene 3:
The danger is over, the player starst his engine and flys out of the cavern. He still must align his ship carefully with the entrance.

Scene 4:
The player is in space again, looking back at the asteroid from the outside.


II: How to do it:Scene 1:
Make the asteroid a "station" resp. a dockable entitiy. You may give it some stone-shaped "escort ships" to make it part of an "asteroid field". If the player has a landing computer, take it away, and give it back to him later.
So the player has still to line up with the cave entrance (the difficulty of which depends on the movement you give the aseroid), but if he do so, the collision dedection will be turned off.
We don't want to trigger the docking sequence, so we will not let the player actually dock to the asteroid. Instead, we start a script.
I don't know if there is an event handler that triggers when the player is "about to dock". If yes, this would be the best way to do it. If not, we will have to let the asteroid "reject" the player's docking attempt, as a hostile station would do, and then start the script.

Scene 2:
destroy the asteroid and replace it with another entity. I will name this "Asteroid2".
Asteroid2 is made out of several subentitys to form a hollow structure around the player ship.
The crucial point about Asteroid2 is size. It has to be so big (the subentitys so far apart), that the collision detection is not triggered when the player ship is inside. To achieve this, it probably has to be much bigger than Asteroid1 at the outside.
Perspective here comes to our help: The player (not the player's ship, but the real player at his computer at home) has only a 2-dimensional vision of the ooverse. As long as he only sees the inside walls of Asteroid2 and these have textures sized appropreately, he will just see himself being "in a cave" and assume it has the size he saw from the outside. Of course, too much movement will still trigger the collison, which is a desired effect.

Scene 3:
Likewise, given the size of the entrance, he can now fly out, triggering the collision detection possibly, but not necessarily.

Scene 4:
We need to detect when the player leaves Asteroid2, so we can replace it with Asteroid1 again. To do so, we place an addtional entity in the entrance of Asteroid2, which has a shader with full alpha, therefore beeinng invisilbe, but of course still "collidable". Make it very weak, so flying "through" it won't hurt the ship but destroy this entity. Make a script that triggers on it's death.