Oolite Bulletins

Ahruman wrote:

See the artefacts on the blue bits? That’s called Z-fighting. It happens when two polygons overlap without sufficient space between them. The workaround is to cut out the corresponding piece of the underlying model.

Yes, we know that there is a problem with the Z-fighting. I've already planned a new version for the next weeks and it will be solved. But I think I won't cut the related parts of the underlaying station and use the same way like the red ring on top of the main-part. That means to add some more faces (cutting also means to add more faces) to make the thing a little bit higher (extruded) instead of using single faces. This is done within minutes, but we will wait for some more reactions - maybe there are more weak points. It seems you have found one of them. :-)

EDIT: The other reason is that I'm a little bit worrying about the precision facor in different CAD-progs while exporting/importing and then converting it to .obj/.mtl. So it could happen that there is a gap.

BTW: I've had another problem with the station. Maybe you could enlighten me. pic1 pic2

There I'm always crashing. Eric hasn't got this problem on his machine, so maybe it is related to my processor (Intel Core2 Duo)?
On all other places I've got no problems.

Ahruman wrote:

It happens when two polygons overlap without sufficient space between them.

Is there a known value for this sufficient space between polygons? If not, no problem. I can test it on my own, but if it's known, please enlighten us.
EDIT: Just read some stuff about it and it seems that there is no easy anwer. It is related to the depth-buffer (z-buffer), NearCP and FarCP (clipping planes). I'll test it.

The general badness of Oolite’s collision handling is a known problem. I don’t think it’s processor-dependent.

Fixing it would be a rather big project, though, and the last thing we need is more big projects.

That's no problem. I just thought, that I've possibly made a mistake while modelling. And if a user has this question we can answer it. It doesn't affect the game-play (yes, I know that it is fun to fly through the bow), so I think we don't have to worry about it. Thanks for anwering that question.

But is there possibly a way to avoid it? I've modelled this thing on exact this position and with this angle. Is it maybe better to move/rotate the subents with the shipdata entry? I think the problem is the overlapping bounding boxes, right?

Sorry, I'll shut up now.

In principle, the bounding boxes shouldn’t happen (except that octree tests are only done for objects with overlapping bounding boxes). However, there are clearly cases where collisions happen when octrees aren’t intersecting.

Where is the new station located?

Can't seem to find one and I don't have an advanced compass yet.

There in all eight galaxies but only at systems that have certain tech-levels (not really high but not really low) and have faily stable governments and are either Rich or Average industrials. (Could post the exact requirments - but that'd be a bit of a spoiler). If there is one in the system it shows as B on the Advanced Space Compase.

It showed up as "M" on mine... I think...

"M" on the Advanced Compass for me too, no wonder, with:

Confused them with Black Monks. Yep it is M!

elite wrote:

Where is the new station located?

Can't seem to find one and I don't have an advanced compass yet.

The readMe gives some hints: Industrial systems (actually only in Rich- and Average Industrial) Intermediate technical level (not in the highest or lowest numbers). And one other value not mentioned in the readMe so I will leave it out here also.

They are in planetary orbit so look for it there. Even without space compass you can just see them on entering a system as a small dot in front of the planet. I could not randomise the location because it had to be hard-coded in several AI script to make the shuttles and Armadillos fly to that particular station.

The M showing on the Advanced space compass was because all logical characters were given and I didn't remember one with a M in it. (I missed Black Baron). BuoyRepair started so simple, but when we had a buoy factory it looked strange not having a buoy of his own. So the beacon shifted from the factory to the buoy.

And than you wonder what players would say when its own buoy didn't get repaired. Hmm. Probably lazy repairteam. Okay, that is an imago we didn't want so the repair team got also this buoy on his repair list.

I gave also replacing the buoys of commies a thought. Technically it was difficult because there are to many different ones. And besides that, the normal ones just fit in a standard docking port. A ship launching with such a big buoy, larger than the dock, would look unreal.

Perhaps it might be a good idea to put a list on the wiki all the alphas used in OXP's so far, I seem to recall that there are other clashes too, the biosphere for example but with what I cannot remember.

Hmm. As there happen to be only 26 letters in the alphabet, and two of them ('N' and 'W') already being used, clashes seem more or less unavoidable.

So I think the only thing we can do is to choose the letter we want to give to our beacon sensibly, and hope that the player also understands the context. E.g. the 'M' which is in the same direction as the planet must be the Repair Factory, wheras the 'M' somewhere else in the system must be something else.

In my OXPs (okay, currently only Anarchies is available, the rest is WIP) I try to always make the beacon-code part of the communication. E.g. the Hacker Henchman will tell you that you have to follow the 'H' in order to get to the Hacker Outpost. (In fact the Outpost only comes into being at this very moment.) I think in Ionics it is similar with the Link Base. IIRC you are told in a mission briefing that it has an 'L' beacon.

Ionics is also a good example for a temporary beacon code. I mean, the 'L' is unlikely to be confused with another 'L', as the Link Base only exists in one system, and only as long as you're doing the mission. So there is no real problem in assigning the 'L' to something else as well.

Commander McLane wrote:

Hmm. As there happen to be only 26 letters in the alphabet, and two of them ('N' and 'W') already being used, clashes seem more or less unavoidable.

So I think the only thing we can do is to choose the letter we want to give to our beacon sensibly, and hope that the player also understands the context. E.g. the 'M' which is in the same direction as the planet must be the Repair Factory, wheras the 'M' somewhere else in the system must be something else.

I think the problem lies somewhere else. Duplicate characters are unavoidable with only a limited choice of 26 sensible characters. There are also several characters used for special mission targets. Like the H of harkovs in Local_Hero.

For stations, duplicate numbers are normally no problem. From the direction alone you estimate what is mend. e.g. in version 1.4 of UPS I made a mistake. In that version I introduced buoys for my solar stations for easier lining up for the docking bay. I made them with like_ship from the system one. Just didn't think about the N in the original that now in also are in the solar stations. But any sensible pilot immediately knows witch is witch. (For the next update the character will be removed, or I use an other. Still in doubt).

Problems arise when codes of special mission targets already exist with stations. E.g. the Hackers outpost and the Harkovs. The Harkovs can be everywhere so it takes a while before a pilot realises he is after the wrong target. In this example there is no problem because they are always in different kinds of systems.

A list of characters could be useful. Not for stations, but codes that should stay reserved for mission targets and not to be used for the more permanent stations. e.g. the logical character T for target should never get assigned to a station. This list should be available at the technical page of the wiki were the beacon character is explained.

Okay. Done.

I guess I have missed some. So if anybody has any additions, feel free to put them in, or contact me.

As of 1.71, there are in fact about 220 possible codes. Some of them are quite hard to tell apart, though, and I doubt there’s much interest in using an apostrophe or parenthesis as a beacon code. The open star (☆), lowercase eth (ð) or pilcrow (¶) might be interesting, though. :-)

Edit: Oh, and maybe the cruzeiro symbol (₢) for shopping stations in a Corporate Systems flavour OXP.