Oolite Bulletins

I ran into a problem with the Energy Bomb in trunk...any OXP that gives an Energy Bomb as a reward will now have its script crash at the point of the reward.

Example code:
if(player.ship.equipmentStatus("EQ_ENERGY_BOMB") !== "EQUIPMENT_OK") player.ship.awardEquipment("EQ_ENERGY_BOMB");
...Will generate a script crash when it "hits" that line.

Time to rewrite a few OXPs?

Switeck wrote:

I ran into a problem with the Energy Bomb in trunk...any OXP that gives an Energy Bomb as a reward will now have its script crash at the point of the reward.

An unhandled exception in a script is not a crash, dagnabbit.

In any case, the example is simply wrong. The correct test is if (player.ship.canAwardEquipment("EQ_ENERGY_BOMB")). Don’t go second-guessing the game.

I’ve looked into the possibility of converting the award to a Q-mine, but it wouldn’t really work since the malformed test can’t reasonably be interpreted as a test of whether there’s a free missile slot.

Ahruman wrote:

Switeck wrote:

I ran into a problem with the Energy Bomb in trunk...any OXP that gives an Energy Bomb as a reward will now have its script crash at the point of the reward.

An unhandled exception in a script is not a crash, dagnabbit.

In any case, the example is simply wrong. The correct test is if (player.ship.canAwardEquipment("EQ_ENERGY_BOMB")). Don’t go second-guessing the game.

Sorry, I meant only that script quits running. (...and even then, only that part of the script quits running!)

Ok, so for guessing...is there any importance of the space between the if and (player?

Switeck wrote:

is there any importance of the space between the if and (player?

No. What Ahruman says is that there is an importance of the difference between and In other words: there is a method especially for the purpose of what you want to check (canAwardEquipment). So why do you not use it, but insist on using a homemade workaround (equipmentStatus) instead? Especially if the workaround throws an exception, but the proper method doesn't?

I get that canAwardEquipment is important NOW, but why I didn't before:

Because in the past that worked and I had missed reading everything necessary to avoid potential problems. Even though the commands are well-documented, finding the exact documentation I need to read to correct my misunderstandings (plural, as they are MANY!) is not quick for me...and WHY things are best done a certain way is not clearly documented in the wiki. Even if I fully understand how the parts (individual commands) work perfectly, how to assemble them into a complex OXP without making silly mistakes is beyond me.

Being self-taught as well as having taken numerous courses in more primitive languages (Basic, COBOL, FORTRAN, Pascal, etc...) and NO formal training in modern languages (besides a touch of Visual Basic v2-3), I've had multiple decades of acquiring bad programming habits. One of those bad habits is copying existing code without enough understanding and foresight to spot potential problems because the circumstances differ. And what better place to copy from than the game's own .js files?

Similar code in oolite-thargoid-plans-mission.js and oolite-cloaking-device-pod.js makes no use of player.ship.canAwardEquipment -- probably because there is no consideration that those pieces of equipment may not be allowed or exist.

player.ship.canAwardEquipment is likewise lacking from the overwhelming majority of OXPs that I have studied. I did a windows search for "canAwardEquipment" (sans quotes) to find a single OXP that used it in one script out of 100's of OXPs I have in my Oolite primary folder at the moment! (No doubt there's other OXPs that use it, but I oddly missed them when trying to learn how to properly reward equipment.) All the other OXPs probably lack that command primarily because the equipment they are awarding is overwhelmingly native equipment OR equipment created by the same OXPs and thus they do not consider that such equipment is not present.

Well, what I'm doing when I want to script something is browse through the documentation (I can only repeat that that's what the documentation is for) until I find the thing that does what I want do to.

So if I want to script a check for whether a ship can get some equipment or not, I turn to the JS-documentation for ship, and browse through the table of contents at the top of the document, especially through its methods-part. canAwardEquipment really catches the eye, then.

And I would regard this as a common-sense thing to do when writing OXPs. It's neither rocket science, nor does it require being a programmer (speaking as somebody who has much less experience with programming languages than your list reflects; the only "formal" training I ever had was some Pascal back in school).

Switeck wrote:

I ran into a problem with the Energy Bomb in trunk...any OXP that gives an Energy Bomb as a reward will now have its script crash at the point of the reward.......
Time to rewrite a few OXPs?

Probably, now the oxps need to do an explicit check for availability. Asteroid Storm was already updated to fix this problem about 6 weeks ago with version 4.03.

From AsteroidStorm.js version 4.03:sigh...

I was almost expecting it to be using player.ship.canAwardEquipment("EQ_ENERGY_BOMB").

Fatleaf wrote:

For me the Ebomb is a Test Pilot only weapon. But I agree with you on the sound it makes. For a laugh swap the file names around so that in the F8 Commodity Market screen, every time you buy something it goes 'BOOM' instead

That must be entertaining

I'm glad that there is a work around.

I have to confess canAwardEquipment passed me by as well. Mind you there is a huge wealth of information on those wiki js pages, and I don't claim to have an encyclopedic knowledge of all of it by any means.

Smivs wrote:

I have to confess canAwardEquipment passed me by as well. Mind you there is a huge wealth of information on those wiki js pages, and I don't claim to have an encyclopedic knowledge of all of it by any means.

There is, and it is of the form that if you already know it, it is a good reference. But if you don't then looking at other people's code is a much better and easier-to-understand one.

I think I know the AI Howto back-to-front after much reading of the wiki pages.

Point is... READ, READ and READ!!!

Tricky wrote:

Point is... READ, READ and READ!!!

Three most valid points indeed!