Page 2 of 4

Re: (WIP) GalCop's Most wanted

Posted: Mon Nov 27, 2017 11:20 pm
by phkb
Small update to v0.5, to allow for some easier integration with other OXP's. (Go rustem!)
Link in the first post.

[Edit] Oh, and created a wiki page

Re: (WIP) GalCop's Most wanted

Posted: Mon Dec 04, 2017 12:00 am
by phkb
I'm working on a bug fix for a particular scenario, and I'm not sure of the right answer. So here it is: should ships be spawned at the witchpoint location if the beacon itself has been destroyed? I don't think there's any technical impediment, but I'm thinking conceptually or logically, as part of the game world.

Re: (WIP) GalCop's Most wanted

Posted: Mon Dec 04, 2017 12:50 am
by montana05
I don't think there's any technical impediment, but I'm thinking conceptually or logically, as part of the game world.
Interesting, is the witchpoint buoy merely a navigation help or is it essential to travel to the system ? If the 2nd applies after the destruction it would be impossible to go there until a new buoy is in place. What happens with ships already on the way ? Do they finish their journey as the wormhole already was opened or do they strand in interstellar space ?

Re: (WIP) GalCop's Most wanted

Posted: Mon Dec 04, 2017 1:16 am
by Cody
Strictly in-game: if you destroy the witchpoint beacon, then loiter, ships will still hyperspace in.

Re: (WIP) GalCop's Most wanted

Posted: Mon Dec 04, 2017 10:57 am
by Rustem
Theoretically: they should be accepted a shifting of spawn position to random position before recovery a buoy in position[0,0,0]. But this should be apply to all ships.

Practically: in oolite-core game the other ships will continuated arrival in system?

Re: (WIP) GalCop's Most wanted

Posted: Mon Dec 04, 2017 4:06 pm
by Disembodied
phkb wrote:should ships be spawned at the witchpoint location if the beacon itself has been destroyed?
I can see the merit in making the WP buoy an integral part of interstellar navigation: otherwise, why is it there? Ships already en route might be OK, but if the buoy is destroyed, it might be difficult/impossible to open a new wormhole to the system. Or ships might just start appearing randomly all over the system.

Then again, if the WP buoy is a vital part of interstellar navigation, shouldn't it be a lot harder to destroy?

Re: (WIP) GalCop's Most wanted

Posted: Mon Dec 04, 2017 4:14 pm
by Cody
Disembodied wrote:
Mon Dec 04, 2017 4:06 pm
Then again, if the WP buoy is a vital part of interstellar navigation, shouldn't it be a lot harder to destroy?
<grins> This why I sidestepped the conceptual/logical angle.

Re: (WIP) GalCop's Most wanted

Posted: Mon Dec 04, 2017 4:32 pm
by Disembodied
Cody wrote:
Mon Dec 04, 2017 4:14 pm
Disembodied wrote:
Mon Dec 04, 2017 4:06 pm
Then again, if the WP buoy is a vital part of interstellar navigation, shouldn't it be a lot harder to destroy?
<grins> This why I sidestepped the conceptual/logical angle.
We could just make them very, very tough … *waves hands* because they're anchored in subspace, any energy that hits them - lasers, collisions, etc. - gets channeled into the fabric of local spacetime, allowing them to absorb weapons fire and impacts without being damaged. Or something.

Which would require tweaking Thargoid behaviour, so they don't try shooting the buoys. Unless Thargoid weapons can damage them …

Re: (WIP) GalCop's Most wanted

Posted: Mon Dec 04, 2017 4:36 pm
by Rustem
Disembodied wrote:
Mon Dec 04, 2017 4:06 pm
Then again, if the WP buoy is a vital part of interstellar navigation, shouldn't it be a lot harder to destroy?
The GRS from the Buoy Repair OXP can recover the WP buoy.

Re: (WIP) GalCop's Most wanted

Posted: Mon Dec 04, 2017 4:54 pm
by Disembodied
Rustem wrote:
Mon Dec 04, 2017 4:36 pm
The GRS from the Buoy Repair OXP can recover the WP buoy.
I'm a fan of the Buoy Repair OXP but - if we assume that the buoys are there for any sort of urgent purpose - then they are, currently, very very very fragile. It's a bit like having inflatable lighthouses: they'd be relatively cheap to make, and easy to replace when they inevitably burst, but after a while you'd have to ask if it wasn't better, safer and in the long run cheaper to build them out of granite!

Re: (WIP) GalCop's Most wanted

Posted: Mon Dec 04, 2017 5:56 pm
by Norby
montana05 wrote:
Mon Dec 04, 2017 12:50 am
is the witchpoint buoy merely a navigation help or is it essential to travel to the system ?
In the second case how arrived the first buoy? So the first case is better to me.

Re: (WIP) GalCop's Most wanted

Posted: Mon Dec 04, 2017 6:14 pm
by Astrobe
The main function of WP buoys is of course to mark a dangerous zone where ships could pop anywhere and anytime. They also have a built-in transmitter that broadcasts its coordinates which the ASC automatically picks up.

Re: (WIP) GalCop's Most wanted

Posted: Mon Dec 04, 2017 8:21 pm
by phkb
Thanks for the discussion - I'm going with "spawn ships regardless of the WP state" for the moment at least. WIP products are subject to change without notice, though!

Version 0.6 is now available. In this version:
  • Fixed route time calculations that were not taking changing destinations into account when doing multiple calculations.
  • Fixed issue where bounties flagged as pending were not coming out of pending if a large time-skip occurs (eg when the player ejects).
  • Fixed issue where bounties flagged as due to arrive at the witchpoint were not spawning if the witchpoint beacon has been destroyed or replaced via GRS Buoy repair.
If this release proves to be reasonably stable, I'll add this to the manager.

Re: (WIP) GalCop's Most wanted

Posted: Sun Dec 17, 2017 11:06 am
by Damocles Edge
I will have to give this oxp a try - I can't believe I haven't seen it before :D
Sets me in mind of my fave western ever - "For A Few Dollars More" 8)

Re: (WIP) GalCop's Most wanted

Posted: Mon Feb 26, 2018 11:11 pm
by phkb
Version 0.9 is now available, which is mainly a bug fix release.
  • Moved first possible access of PhraseGen to startUpComplete to prevent startup sequencing issues.
  • Fixed incorrect text for defining route mode calculation (has "OPTIMIZED_FOR_" instead of "OPTIMIZED_BY_").
  • Added protection against condition where no route can be calculated between a character's current and destination systems.
  • Bug fixes.