Scripting requests

[JensAyton]

Stuff about adding galaxies split to a new thread.

[Cmdr James]

Request:
Either
a) Modification to the position of the call to guiScreenChange when entering the Equipment Screen to before the calculation of the available equipment.
or
b) New event of guiBeforeScreenChange that occurs before any calculations for the target screen.

I added this verbatim. If it breaks anything the next commit includes

Code: Select all

if (player.equals(Phantor_Gort)) 
{
  player.ship.add(trumble);
}

[PhantorGorth]

I added this verbatim. If it breaks anything the next commit includes

Code: Select all

if (player.equals(Phantor_Gort)) 
{
  player.ship.add(trumble);
}

ROFL that's easy to get round

[Lestradae]

Request:
Either
a) Modification to the position of the call to guiScreenChange when entering the Equipment Screen to before the calculation of the available equipment.
or
b) New event of guiBeforeScreenChange that occurs before any calculations for the target screen.

I added this verbatim. If it breaks anything the next commit includes

Code: Select all

if (player.equals(Phantor_Gort)) 
{
  player.ship.add(trumble);
}

I am getting the impression you devs are a bit touchy about not-absolutely-nescessary scripting requests atm, no?

[PhantorGorth]

I am getting the impression you devs are a bit touchy about not-absolutely-nescessary scripting requests atm, no?

That was humour between me and Cmdr James referring to the code changes I had requested having been tested by me but not exhaustively.

The devs can correct me if I am wrong but from what I can gather the devs are reducing the number of code changes in advance of releasing 1.74. Otherwise they won't be releasing it before hell freezes over.

The difference with my change, other than me ambushing Cmdr James , is that I didn't just make a request, I gave actual code changes which I had tested myself. Cmdr James didn't need to spend time figuring out how to do it for me. He only had to check if it caused a problem.

With devs' limited time and 1.74 approaching, you can expect that anything complex, requires significant investigation on how to do it, makes major changes to the game's "philosophy" or doesn't personally interest them is going to be dropped or very low on their priority scale.

[Lestradae]

With devs' limited time and 1.74 approaching, you can expect that anything complex, requires significant investigation on how to do it, makes major changes to the game's "philosophy" or doesn't personally interest them is going to be dropped or very low on their priority scale.

I know that and am even quite happy about it because it means that 1.74 and even the "no-longer-M" NSR 1.75 are going to become a reality in mid-term future.

But don't tell anyone, or they will ignore my suggestions to 100% instead of 95%

[Eric Walch]

That was humour between me and Cmdr James referring to the code changes I had requested having been tested by me but not exhaustively.

I think Cmd James can already start writing the additional trumble code as the new change at least breaks the current constrictor mission. (at a very mildly invisible way)

When the guiScreenChanged fires it transfers a TO and FROM parameter. But because an other script could already have changed the page in the meantime (e.g. snoopers that adds a missionscreen when going to the F7 page), the constrictor mission checks for the actual page on display before adding the hints below the system description. Now it also adds the text when leaving the F7 screen to the F3 screen. Probably not a visible bug as the double added text below the F7 screen will immediately disappear when the F3 page is generated.

I could also imagine anyone trying to set up a missionscreen when going to the F3 screen (Like snoopers for the F7 screen and Bloomberg market for the F8 screen) has a problem as that screen will be overwritten by the F3 screen that is added afterwards.

I think it can be made more foolproof by adding some extra checks to the code. But why not add an extra handler instead: guiScreenWillChangeTo. That way you have no exception for the time of firing for the current guiScreenChanged handler on the equip page?

[PhantorGorth]

I could also imagine anyone trying to set up a missionscreen when going to the F3 screen (Like snoopers for the F7 screen and Bloomberg market for the F8 screen) has a problem as that screen will be overwritten by the F3 screen that is added afterwards.

I think it can be made more foolproof by adding some extra checks to the code. But why not add an extra handler instead: guiScreenWillChangeTo. That way you have no exception for the time of firing for the current guiScreenChanged handler on the equip page?

That is definately not something I had considered nor tested for (I never said I had fully tested it) but in my original request post I did mention the idea of doing a "guiScreenWillChangeTo" event instead (though I called it "guiBeforeScreenChange").

I suggest someone reverses that change Cmdr James did for me and I will look into where to put the "guiScreenWillChangeTo" event and the code needed for the event function itself. The call to it would be needed in a fair few number of places.

[Eric Walch]

but in my original request post I did mention the idea of doing a "guiScreenWillChangeTo" event instead (though I called it "guiBeforeScreenChange")..

I now implemented it as guiScreenWillChange. Yet another name but it matches better with the current "guiScreenChanged". Leaving the old handler on its place leaves the possibility to start a missionscreen on entering those pages with the "guiScreenChanged". e.g. for doing a very special equipment offer on entering the equip screen.
And because the only use for the "guiScreenWillChange" will be to do some modifications to change the screen that will be displayed, it only triggers for a few screens were it could be used in that way.

[PhantorGorth]

I now implemented it as guiScreenWillChange. Yet another name but it matches better with the current "guiScreenChanged". Leaving the old handler on its place leaves the possibility to start a missionscreen on entering those pages with the "guiScreenChanged". e.g. for doing a very special equipment offer on entering the equip screen.
And because the only use for the "guiScreenWillChange" will be to do some modifications to change the screen that will be displayed, it only triggers for a few screens were it could be used in that way.

Thanks Eric. Much appreciated.

[Svengali]

It would be pretty nice if performAttack could be influenced by scripts.

The current way - I think - works pretty well for escorts in groups of ships and prevents the player from being roasted too fast, but single ships with odd IDs are still problematic in mission contexts, specially if wormholing or heavy injector usage would break the story.

So maybe it would be an option if the decision (check odd/even) would consider some other factors too. Bounty, accuracy and a scriptable (read/write) property - e.g. Ship.maxAggression (JS) and max_aggression (shipdata) - maybe?

[Thargoid]

We have a world script event for shipLostTarget, but we seem to be lacking in it's mirror image - shipAcquiredTarget(target).

Would such a trigger be possible, firing when the ships target goes from null to something, or something to something else?

[another_commander]

We have a world script event for shipLostTarget, but we seem to be lacking in it's mirror image - shipAcquiredTarget(target).

Would such a trigger be possible, firing when the ships target goes from null to something, or something to something else?

We actually do have it already in trunk: ship.shipTargetAcquired(target).

[Thargoid]

Now that's what I call service!

[JensAyton]

The naming is inconsistent. Since shipLostTarget() is already deployed and subject-verb-object is the most common word pattern in both English and Oolite message handler names, I suggest we switch to shipAcquiredTarget().