Oolite Bulletins

Is this any good?

kanthoney wrote:

Is this any good?

Not sure.

$ python pltojs.py /usr/local/src/oolite/Resources/Config/shipdata.plist shipdata.json
Traceback (most recent call last):
File "pltojs.py", line 22, in <module>
if __name__ == "__main__": main()
File "pltojs.py", line 11, in main
plistObject = plistlib.readPlist(sys.argv[1])
File "/usr/lib/python2.7/plistlib.py", line 78, in readPlist
rootObject = p.parse(pathOrFile)
File "/usr/lib/python2.7/plistlib.py", line 406, in parse
parser.ParseFile(fileobj)
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 1, column 0

From what I can guess from the help file, the python library plistlib only reads the XML version.

There's a large number of nodejs modules to parse plists, most of which would probably work with in-browser JS with minimal modifications
https://www.npmjs.com/search?q=plist

(Probably quite a few of them only work with XML or Binary rather than OpenStep format plists, but you might get lucky)

There are now only two models but that's because I rewrote quite a few things (in preparation for multi-textures models notably) and now the data conversion process is a bit more involved.

Until I find out how to convert the plist into JSON automatically, I do it manually (it's not too hard, fortunately). I also need to insert the mesh into the "model" entry. I will focus on doing things on a very few number of ships.

I can now read data such as a the "custom view" quaternions. I created a drop-down menu to select them. Interestingly enough I don't quite get the expected view, which means there is a coordinate system mismatch somewhere.



EDIT: Ok apparemment les quaternions dans les fichiers plist sont au format W X Y Z et non X Y Z W comme dans glMatrix.

Ok I now understand how to put several ships in the scene their own attitude/position parameters.



I should soon be able to tackle displacements.

I made this part in a different html page:

http://grondilu.github.io/oolite/

I got a first prototype of the compass working.



http://grondilu.github.io/oolite/test-compass.html

OK, first try at controlling speed:

http://grondilu.github.io/oolite/test-coriolis.html



Setting the matrices in the correct order and stuff was quite a headache. As a matter of fact I proceeded a bit by trial-and-error at some point so to be honest I'm not entirely sure everything is fine, but it seems OK.

Docking is obviously quite difficult without the scanner, not to mention the lack of fine tuning in the controls. But even with just the compass it seems doable.

grondilu wrote:

the lack of fine tuning in the controls

Nice minigame, I can "dock" without problems from any angles, just I feel myself in an Anaconda and missing the return to zero of pitch/roll when I release the keys.

Very basic scanner prototype:



http://grondilu.github.io/oolite/test-coriolis.html

First attempt at drawing stars:



http://grondilu.github.io/oolite/test-coriolis.html

I used the Hipparcos catalog and drew the stars as points on a large (1Mm but I could use any value) sphere around the observer.

Looking good.

grondilu wrote:

I used the Hipparcos catalog and drew the stars as points on a large (1Mm but I could use any value) sphere around the observer.

"Sphere of fixed stars" is about how Oolite does it. Ours is only at 75km - but is drawn first in the scene with depth-buffering disabled, so appears to be behind everything.

grondilu wrote:

First attempt at drawing stars:



http://grondilu.github.io/oolite/test-coriolis.html

I used the Hipparcos catalog and drew the stars as points on a large (1Mm but I could use any value) sphere around the observer.

Can I have a laser so I can pew-pew the station?

Jokes aside, I like a lot where this is going. And the flight model as it is right now is interesting, too. It kind of feels Newtonian, but I find it very challenging.

Looking forward to the full game.

cim wrote:

Looking good.

grondilu wrote:

I used the Hipparcos catalog and drew the stars as points on a large (1Mm but I could use any value) sphere around the observer.

"Sphere of fixed stars" is about how Oolite does it. Ours is only at 75km - but is drawn first in the scene with depth-buffering disabled, so appears to be behind everything.

Interestingly enough, I wrote a projection matrix especially for stars, with the far plane at the infinite (that's actually possible, because mat4.perspective has a limit for f -> infinity), so I could put the actual stellar distances in real units, and it'd still work. That'd be unnecessary since no parallax would be visible, but still.


PS. Just checked by setting the radius at 1e15m. Still works. Oops, sorry, I was not looking at the local branch. 1e15m is too big for some reason. Not sure why yet.

another_commander wrote:

Jokes aside, I like a lot where this is going. And the flight model as it is right now is interesting, too. It kind of feels Newtonian, but I find it very challenging.

I suspect it's because you were looking at the compass too much, and it may still have bugs. (I've just made a few fixes but it's not tested much).

If I try very hard to put the stars on an astronomical distance (say 1e15m), first I get nothing if I try with Float32Array. If instead I try with a Float64Array, I get an interesting artifact :



The stars seem to align on particular directions in the sky. I suspect it's because of the lack of precision in the trigonometric functions.