Oolite Bulletins

And here’s a version written with my brain engaged:

Will the error-fixes in the rotation-function also fix the (still!) broken spawnShip and legacy.spawnShip methods? Because in a lot of cases spawnShip still results in a random orientation instead of the one defined in the spawn-directory.

Kaks was working on that. So he should know if any underlying problem has been fixed.

Or is this completely unrelated?

No, this was purely a problem in the JavaScript function.

I’m pretty sure I’ve never heard anything about this spawn problem. Are you referring to facing_position? Do you have a test case?

@Ahruman: It is facing_position (well, the underlying oolite function - facing_position parsing works correctly & passes the right parameters to it), and it appears to have a 'blind spot' where the orientiation suddenly flips by 90 degrees of what it should.

One test case was at the beginning of 'quaternion strangeness' on the dev-list:

OXP used to highlight the bug: anarchies.oxp.

I launched from Lave, then entered the following on the console:

system.legacy_spawnShip('anarchies-hacker-outpost3');

The hacker outpost will be created with the dock at a right angle to the planet, as opposed to facing the planet.

If the outpost is set in a different quadrant, it will face the planet, as it's supposed to do.

That orientation bug was still there the last time I looked - 3 weeks ago, that is - and while 2 entities sharing the same orientation will face the same way, they don't seem to face the 'right' way, at least according to my limited knowledge of quaternion maths.

Commander McLane wrote:

Will the error-fixes in the rotation-function also fix the (still!) broken spawnShip and legacy.spawnShip methods? Because in a lot of cases spawnShip still results in a random orientation instead of the one defined in the spawn-directory.

After playing a day with the rotation function and adding the self-orienting code in the shipSpawned part of the ship-script, I suggest to do the orientating that way. The spawn directory only works for a fixed system. With the rotation code you can calculate the desired direction for each system separately, or copy the orientation from a nearby ship. (EDIT: Looking how the spawn directory worked I see it should work in any system for positioning and orientation. It even uses very similar code as I used in JS for the rotation. But instead using a calculated angle it uses or 0 or 180 degree because the ship has at that point not yet a random orientation. But probably the assumption of just two possible starting orientations is wrong.)

I just found a bug in the way I oriented things. The axis you rotate around must be a unit vector. I thought length of the vector shouldn't matter for rotating but my heading was always 5 to 10 degree off target. Until I realised that a non-unit vector also gives a non-normalised quaternion. And normalising of the vector is probably faster that normalising of the quaternion.

Eric Walch wrote:

And normalising of the vector is probably faster that normalising of the quaternion.

Yes, but only by one multiply, one add, and one extra variable to pack and unpack. In the context of an expensive operation like setting up an entity, worrying about that difference is just silly.

Kaks wrote:

@Ahruman: It is facing_position (well, the underlying oolite function - facing_position parsing works correctly & passes the right parameters to it), and it appears to have a 'blind spot' where the orientiation suddenly flips by 90 degrees of what it should.

Sounds like "Gimbal lock", something i read about when trying to figure out what quaternion is exactly... found some articles about it...

http://en.wikipedia.org/wiki/Gimbal_lock

Part of the point of using quaternions is that they’re not susceptible to gimbal lock. There are a variety of other possible causes, though.

I just added the wiki entry about equipment. That one was still missing:

http://wiki.alioth.net/index.php/Equipment.plist

There are a few special features about equipment that were never explained. Kaks recently named a few. By looking into the 1.65 code I saw they were already present by that time. Only the "conditions" I see for the first time appearing in 1.69.

I tested the conditions part. It works well. When added it is only offered for sale when the conditions are met. Much easier than constantly changing the tech level for that item on docking as I now do in UPS. In the source code there is still code that puts debugging ON/OFF when it tries to show a entry with conditions in it. Meaning it is not fully tested.

Kaks also mentioned a bug with "requires_equipment" and "incompatible_with_equipment". In the code there is a copy and past error. I think Kaks already corrected this. It results in that when incompatible_with_equipment is not defined it uses the contents of "requires_equipment" as incompatible. This bug can be easy bypassed by just defining a dummy equipment as incompatible. I already saw that missiles & bombs does this. But I think Ramirez can also use some of the other things.
e.g an ending on MISSILES or MINES sets the "requires_empty_pylon". But I think this allows also for missiles on the list that don't have this ending. It could be that this will give "player only" missiles.

Thank you very much, Eric! You have just granted one of my longest-standing requests.

(One less to go...)

Commander McLane wrote:

Thank you very much, Eric! You have just granted one of my longest-standing requests.

The code was there al the time, at least since version 1.65 but probably even longer. (not in 1.55) It was just never documented. Even the bug has always been there. Only the conditions were later added. In 1.69 or at least after 1.65 (I have no source references in between). In my short test with a test for government number it worked well. However it was never finished for release: if there are conditions it sets debugging on and after reading the conditions it puts debugging of resulting in debug messages in the log file every time a player visits the equipment screen.

All the tests are cumulative: if one fails, the others are not evaluated. Thus, when the tech level is not met, conditions don't matter.

Not all items is useful for scripting. e.g test for a certain free cargo space works well, but the script itself can not occupy the cargo space after the equipment is bought. This makes it silly to test for free cargo in the first place.

At he moment I think Kaks already looked into it as he mentioned part of this in an other thread, including the bug. I just tried to document the stuff for later reference.

You probably misunderstood. What I requested for a long time was indeed a documentation, not any features themselves.

<rant>It is so hard - from a scripters perspective - to work with undocumented stuff; because it means you have to scan through virtually all existing equipment.plists in any possible OXP, in order to find out what is possible and what not, and how the syntax is. And this kind of search tends to come up with very few results, because the other scripters also didn't know the undocumented features, so they didn't use them either. Believe me, it's a very frustrating and time-consuming way to learn scripting - I've been there, a couple of times; not only with equipment.plist, but also with a number of other undocumented things. Therefore I know what I'm saying when I thank you for documenting it. </rant>

So, thanks again!

Commander McLane wrote:

You probably misunderstood. What I requested for a long time was indeed a documentation, not any features themselves.

<rant>It is so hard - from a scripters perspective - to work with undocumented stuff; because it means you have to scan through virtually all existing equipment.plists in any possible OXP, in order to find out what is possible and what not, and how the syntax is. And this kind of search tends to come up with very few results, because the other scripters also didn't know the undocumented features, so they didn't use them either. Believe me, it's a very frustrating and time-consuming way to learn scripting - I've been there, a couple of times; not only with equipment.plist, but also with a number of other undocumented things. Therefore I know what I'm saying when I thank you for documenting it. </rant>

So, thanks again!

i downloaded the source(before this), i even searched for requires as in "requires_empty_pylon", but not "required", and ended up not finding what i was looking for, now had i typed "required" i prolly would have found it. So even with source in hand, you are not sure to find what you are looking for. as english is not my primary langauge, i didnt strike me that the author might have used "required_equipment" instead of "requires_equipment"...

I would if i had the time, go through the code, and document all none documented "features"... and i think that is the real problem... no one has the time to document it all...

Frame: Sometimes, it is convenient to not search for entire words when looking in the source code. This is precisely because a word can have different forms depending on context. A trick, if you want to call it like that, that I use quite often is search for the parts of the word that don't change. In your case, I would probably go and look for occurences of the string "requir" in the code.

another_commander wrote:

Frame: Sometimes, it is convenient to not search for entire words when looking in the source code. This is precisely because a word can have different forms depending on context. A trick, if you want to call it like that, that I use quite often is search for the parts of the word that don't change. In your case, I would probably go and look for occurences of the string "requir" in the code.

Yeah, but the reason i did´nt do it was because

ultra_edit 8.10a wrote:

Search complete, found 'required' 630 time(s).

had i gone any less specific in searching, i figured the hits would go up, and time the damn time, i dont have enough of it to spend on what i thougt would be a futile search..

but thanks for the tip