Oolite Bulletins

Hi phkb,

After a long hiatus, I've returned to report another possible issue (I'm using version 0.5.9). I've several times tried to do mission type 33 (something was stolen but the thief took the shortest path, go there by shortest time to get there first, wait near witchspace beacon for thief in customised ship of ___ type, use comms to demand the stolen item). So far I have not been able to identify the thief ship. Maybe I am not waiting long enough, or maybe it is not spawning, or maybe I am in the middle of combat when it appears and it joins in and then becomes a derelict before I can hail it...

So I still have further testing to do before I can definitively say this isn't working, but when I took a brief look in the code, I noticed that the variable _type33Created in GalCopBB_ShipInteractions is compared === true in several places but never seems to be set to true. That doesn't look right, so I thought it was worth bringing to your attention.

Hope this helps!

Milo

Thanks Milo. I’ll dive into the code and have a look.

Yep, it looks like that variable is not being set, although it still should have created the ship (even if there is no way to know for sure now).

As a quick fix, if you're OK doing a little text-editing, you can try adding at line 307 of the galcopbb_shipinteractions.js file, immediately after the And see if that makes a difference. I won't get a chance to test this until probably tomorrow, so if you find another problem please let me know.

Thanks, I've made the changes but haven't had an opportunity to test that mission type again yet. On an unrelated note, I would like the Cargo Stopper to activate automatically whenever I target a cargo pod within range of the device (so I can remove it from my primeable equipment). I guess it could be triggered from a shipTargetAcquired callback?

Thanks, that's a good idea. I'll include it in the next release.

Removing the Range Finder MFD doesn't seem to work correctly, and I noticed that in the first of these entries, it's incompatible with the extender, not the core MFD equipment, and in the second entry, it doesn't have an incompatible_with_equipment line (for the extender).

Milo wrote: ↑Tue Jun 16, 2020 4:31 am

Removing the Range Finder MFD doesn't seem to work correctly

Hmm. In my tests everything works the way it should. The two "removal" items are designed to handle the two different conditions: one where only the standard range finder is installed, and the second for where both the range finder and extender are installed. I tried installing and uninstalling both versions, and everything seems to uninstall correctly. What went wrong when you tried to uninstall it?

What I thought I had seen was that when I removed the MFD, it still appeared in the cycle when I rotate through the MFDs. But, I can't seem to reproduce that now, so maybe this was another PEBKAC moment.

After testing some variations, I now understand that the incompatible_with_equipment line causes the equipment to be hidden from the F3 interface, so the incompatible line in the first entry has the desired effect (I think) of not showing you that entry when you have the extender, since you should be using the second entry in that case. And the second entry is fine too, because it requires both the MFD and the extender and will not appear otherwise. So I guess this was a complete red herring, sorry.

I'll just mention that I noticed in the script that the equipmentDamaged / equipmentRepaired callbacks include checks for the MFD extender removed placeholder, and I wasn't sure why it's not checking for the extender itself there.

In my current "Stealing cargo" mission, I've scooped 5 of the 14 units required, and when I scooped each of them, it displayed a message saying that they were being stored safely. When I then dock and go to the GalCop bulletin board and select the active mission, it gives me an option to "hand in current load and continue" ... and if I do that, it takes 5 units of the 7 units from my cargo hold (leaving two that weren't acquired by scooping). OK so far, except that I am in the "target" system still, not the system that gave me the mission. (To whom am I handing them?)

Without going to the bulletin board, is there a way to see how many units I've collected so far in the mission-required manner? It would be nice if the F5 mission status line gave a progress indication not only for how many units have already been handed in, but how many are ready to be handed in. (If I hand in the 5 as mentioned above, the F5 status changes from "steal 14" to "steal 9".)

Also, if I reload the saved game from before I handed them in, I can sell them all to the market, and then if I go back to the GalCop bulletin board, it shows that I have none so can't hand it in (even if I buy them back from the market). That all seems logical, but it leaves me confused about what the "safe" storage messages when I scooped them were trying to tell me.

Milo wrote: ↑Wed Jun 17, 2020 11:08 pm

it leaves me confused about what the "safe" storage messages when I scooped them were trying to tell me.

Normally, when precious metals or gem stones are scooped, they stay in the cargo pod they arrived in, allowing you to eject them again. I think I wanted to avoid trying to track the state of these items by having the scooped items transferred directly into the "safe" on your ship (where precious metals and gem stones are normally kept), from which items can't be ejected. But it looks like I was only half successful at this!

I've got some of the other improvements in the pipeline, so I'll add this to my tests and see if I can't iron things out a bit better. Thanks for all your tests and details analysis!

Version 0.6.0 is now available. In this version:

• Cargo stopper is now activated automatically when cargo is targeted, in front of the player ship and in range, negating the need for priming and activating the equipment.
• Fixed stealing cargo missions, where it was possible to hand in cargo at stations other than the originating station.
• Improved mission status messages for stealing cargo missions to show how much has been collected.
• Bug fixes.

There is a leftover(?) zip file in the Scripts folder.

For cargo stopper, the quoted condition below in the shipTargetAcquired could be optimized by just checking a "cargo stopper OK" boolean there and updating the boolean when equipment is added to the ship, removed, damaged or repaired. As this runs every time the target switches, which in combat can be frequent, and it has to scan through all ship equipment, this might impact performance a bit. (I haven't profiled it, so this is just speculation.)

if (p.hasEquipmentProviding("EQ_CARGO_SCOOPS") === false || p.equipmentStatus("EQ_GCM_CARGO_STOPPER") != "EQUIPMENT_OK") {
return;
}

That’s a good call. I’ll add it to the next release, and thanks again for your detailed reporting!

It seems that the stealing cargo missions can be satisfied by cargo “spawned” by Towbar OXP when mining derelict ships. But only when the player ship cargo hold is full. Towbar then spawns cargo pods in space near the ship. Towbar mostly loots cargo that the ship was carrying, but mining the ship also generates 1t of computers (representing dismantled ship systems) and some alloys. On my current GalCop mission, the target commodity is computers. I guess you could argue that it doesn’t matter if the computers were in the ship’s cargo hold or being used by the ship, but it does allow a different gameplay to complete the mission (salvage vs. piracy; you could even opportunistically wait for derelict ships from conflicts you didn’t participate in). So, just mentioning it for your consideration.

Unrelated, my Range Finder MFD was damaged, and upon repairing it, I got the following in my log:

ship got EQ_GCM_RANGE_FINDER_MFD
ship lost EQ_EQUIPSPACE_39
ship got EQ_EQUIPSPACE_39
EQ_GCM_RANGE_FINDER_MFD repaired
Exception: ReferenceError: rf is not defined
Active script: GalCopBB_RangeFinder_MFD 0.6.0
galcopbb_rangefinder.js, line 133:
player.ship.setMultiFunctionText("RangeFinderMFD", expandDescription("[gcm_rangefinder_mode_short_" + rf._mode + "]") + this._lastScan, false);
bought EQ_GCM_RANGE_FINDER_MFD

Milo wrote: ↑Sat Jun 27, 2020 1:39 pm

So, just mentioning it for your consideration.

Actually, I love this. I'm not sure if it counts as emergent gameplay, but it's certainly an "unintended consequence" and much better to leave as is, than to try to nerf it in some way.

Milo wrote: ↑Sat Jun 27, 2020 1:39 pm

Unrelated, my Range Finder MFD was damaged, and upon repairing it, I got the following in my log:

Will be fixed in the next release.