Progress

[JensAyton]

The obvious use case is for tagging subentities of interest to a script, instead of relying on indices.

Viz:

Code: Select all

/*
    findSubEntityGroups(ship)
    Find subentities identified by tags in shipdata.plist.
    In shipdata.plist, tags take the form:
        script_info =
        {
            tags = ( "tag1", "tag2" );
        };
    
    findSubEntityGroups() returns an object with one array of subentities
    for each used tag. Each subentity may have any number of tags. 
*/
function findSubEntityGroups(ship)
{
    let groups = {};
    ship.subEntities.forEach(function (sub)
    {
        let tags = sub.scriptInfo.tags;
        if (tags && tags.length)  tags.forEach(function (tag)
        {
            let groupForTag = groups[tag];
            if (groupForTag)  groupForTag.push(sub);
            else  groups[tag] = [sub];
        });
    });
    return groups;
}

[maik]

… and congratulations to your promotion, cim!

Indeed, well deserved! CoOngrats

[Svengali]

Subentity dictionaries can now have script_info entries. These are merged with any script_info in the subentity’s shipdata entry’s script_info, with the subentity dictionary taking precedence. The obvious use case is for tagging subentities of interest to a script, instead of relying on indices.

Thanks a lot, Ahruman. It will make things so much easier.

[cim]

A few more changes:

Hopefully the last case where OXPers needed to use the legacy script engine is now gone, with the introduction of condition scripts. Condition scripts can be added to equipment.plist, shipdata.plist and shipyard.plist as "condition_script" = "myoxp_conditions.js". A function in the condition script is then tested in the same cases the old "conditions" would be tested. (Additionally, the equipment.plist test is evaluated when trying to award equipment to NPCs)
Initial documentation

"allow_player_docking" has become "disallowed_docking_collides" (with opposite sense!) in the new multi-dock code (still read-only for the moment, but I'll make it read/write at some point to give the "docking bay doors" requestors an easy answer). This simplifies the underlying code and fixes a couple of bugs. The Javascript acceptDockingRequestFrom method can be used to implement the old behaviour of "allow_player_docking" in a more flexible way.

The F5 F5 screen now becomes pageable if it has too many items on it to fit on a single screen.

[Commander McLane]

The F5 F5 screen now becomes pageable if it has too many items on it to fit on a single screen.

That's a huge step forward, given how messy the whole GUI code used to be (at least that's what we were always told)!

[cim]

That's a huge step forward, given how messy the whole GUI code used to be (at least that's what we were always told)!

The GUI code itself is relatively tidy within its limits. Unfortunately one of those limits is no support for pagination / scrollable regions / etc. (which were never needed in the original Elite or even until relatively recently in Oolite)

So to implement those you have to put custom pagination code in your function which passes data to the GUI, and custom page-switching code in the controls handler, and that is messy. (It's a well understood mess, so I just copied the approach which already worked for the status screen equipment list, but it involves a lot of almost-but-not-quite identical code every time you want to do something similar)

That screen is particularly tricky because it has four independent regions each of which (except cargo) can independently take up anything from no space at all to more than a page on their own. The solution I've implemented is not ideal for that situation (obvious problem: the heading for a section can be the last line on a page, with the content all on the next page) but will probably work well enough for now.

[Fatleaf]

That's a huge step forward, given how messy the whole GUI code used to be (at least that's what we were always told)!

May I too express my gratitude to your hard work on this. Thank you very much

[Switeck]

I ran across this line:
key_mode_equipment = "b";
...when editing/updating my keyconfig.plist
What is it for?
(OXP equipment or standard equipment or both?)

[another_commander]

I ran across this line:
key_mode_equipment = "b";
...when editing/updating my keyconfig.plist
What is it for?
(OXP equipment or standard equipment or both?)

This is a contribution from timer (that is the username). It is dormant code corresponding to Berlios request 5496. Basically, it enables primeable equipment to go into different modes of operation. We have not activated it yet because some more testing would be required and also because we are still contemplating whether the control system starts becoming a bit too complex by assigning a key to equipment supported only by OXPs, but I think it pretty much works as per specs, at least in the test case timer has sent us. If anyone would like to enable the code in private builds, the macro FEATURE_REQUEST_5496 must be defined to 1 inside config.make. Until it becomes official feature, do not expect official support.

[Switeck]

Thanks for the info...and no wonder I didn't recognize it.

I can see it being useful for redefining how the Galactic Hyperdrive might work -- regular GH jump or jump to a particular location in the next Galaxy Chart.

...Or making Military Lasers fire only a single shot instead of a burst if their firing button is held down. (This would probably require more code changes to be possible though.)

[cim]

While I'm poking the GUI...

...an extra feature that should make mission OXPs a bit easier to write.

You can now use the current short range chart and current long range chart as backgrounds for mission screens. (background: "SHORT_RANGE_CHART" or background: "LONG_RANGE_CHART")

[JensAyton]

OXPs can now contain logcontrol.plist files for their own log entries. They cannot override settings defined in the built-in logcontrol.plist (but you can still do that with loose files in AddOns folders). In fact, they cannot touch hierarchies from the built-in file; for example, they can’t set script.myScript because the built-in one has entries beginning with script. This is a way of ensuring that OXP authors don’t inadvertently change users’ settings for core game log messages.

Additionally, log settings now affect the printing of log() messages in the debug console, if they use an explicit log message class. If they don’t, the message is still logged with the class script.debug.message, which is off by default, but shown in the console anyway.

The suggested way of using this is to use log message classes beginning with <yourName>.<oxpName>, put a logcontrol.plist in the OXP turning this message class off, and put another one in your AddOns folder turning it on. This way, you will see your log messages and users, by default, will not, without having to delete them from your scripts.

For example, I might call log("ahruman.shadyBillboard.didSomething", "Something happened to " + this.ship); in a script, and put { ahruman.shadyBillboard = off; } in the OXP’s logcontrol.plist. The message could then be enabled on my computers with a loose file, or with the console command :logOn ahruman.shadyBillboard.

Log settings are loaded from the following locations, from lowest to highest priority:

• logcontrol.plist inside OXPs, but only in hierarchies not defined by the built-in plist.
• Built-in logcontrol.plist.
• Loose logcontrol.plist files in AddOns folders.
• Preferences (settable through the debug console).

Because the settings are loaded very early, before the state of strict mode has been set, OXP settings are always loaded. Since they shouldn't have any effect in strict mode, that's fine.

[Lestradae]

The F5 F5 screen now becomes pageable if it has too many items on it to fit on a single screen.

Thank you, thank you, thank you and thank you!

I have really been waiting for this ... is it only trunk or will it make it's way into an eventual 1.76.2?

Cheers & keep up the good work

L

[cim]

I have really been waiting for this ... is it only trunk or will it make it's way into an eventual 1.76.2?

Trunk only, I think. It's a little too large to put in under "fix bug" which is all that should be in 1.76.2

Since there are currently no changes in the maintenance branch since 1.76.1 was released, there may well not be a 1.76.2 anyway

[cim]

A small adjustment to witchspace exit: the radius of the witch buoy is now taken into account when determining minimum safe distance. YAH buoys should now be safe to use.

A few modifications to the AI:
Full pirates
Eric had already made some changes way back in r4770 to make offenders and fugitives less likely to dock at the main station compared with 1.76. I've slightly tweaked this to make the chance of going for the main station depend on how big the price on their head is.

To make this work properly, there needs to be a non-main station for pirates without a witchspace engine to go to. The pirates without witchspace engines tend also to be the ones with small holds, so they fill up most often and then look for a station. Experimentally, I've changed the system populator so that all systems have at least one rock hermit. If there wasn't one generated on the normal spacelanes, there will be one added to a semi-random point in space quite some distance from the spacelanes.

While this has the potential to increase trading profit, my testing so far is that the added rock hermits are almost impossible to find without either cheating or spending a lot of time searching for them. I've had this change installed on my local version for a while and in 40-odd jumps, with the benefit of knowing how to find them, I've only found one. There are quicker ways to make money, even without OXPs.

New event
A new AI event "ATTACKER_MISSED". This fires whenever a ship fires at another ship and misses. What I often saw on the spacelanes was a trader wandering along with a couple of escorts, and a lone pirate coming in towards it firing wildly and missing every shot. The trader would then completely ignore it until a stray shot finally hit it.

This event has been added to a lot of the core AIs so that in that situation, the trader will start returning fire after the first missed shot. It works for the player too, so the text in [wiki]Laser tactics[/wiki]

If you are making a pre-emptive strike on another ship, make absolutely sure the ship is properly in the target reticule before firing. Nothing gives away the element of surprise like a shot across the bows when you really meant to hit.

is now accurate for at least some ships.

It's only been added to "non-fighting" AI states (and not all of those, either), so a ship already in combat isn't going to be distracted by some near misses.

Cleanup
I've been doing some cleanup on the targeting code, which I think is working normally now, but there were some odd side effects while I was testing it (scooped cargo canisters remaining targeted in the hold, flying through the starfield backdrop, etc.) so if trunk users could keep an eye open for other oddities...