Page 22 of 56
Posted: Tue Mar 23, 2010 2:19 pm
by JensAyton
Stuff about adding galaxies split to
a new thread.
Posted: Tue Mar 23, 2010 8:54 pm
by Cmdr James
PhantorGorth wrote: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);
}
Posted: Tue Mar 23, 2010 11:16 pm
by PhantorGorth
Cmdr James wrote:
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
..
Posted: Wed Mar 24, 2010 6:58 am
by Lestradae
Cmdr James wrote:PhantorGorth wrote: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?
Re: ..
Posted: Wed Mar 24, 2010 8:50 am
by PhantorGorth
Lestradae wrote:
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.
Re: ..
Posted: Wed Mar 24, 2010 11:24 am
by Lestradae
PhantorGorth wrote: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%
Posted: Wed Mar 24, 2010 12:00 pm
by Eric Walch
PhantorGorth wrote: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?
Posted: Wed Mar 24, 2010 1:13 pm
by PhantorGorth
Eric Walch wrote: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.
Posted: Sat Mar 27, 2010 9:44 am
by Eric Walch
PhantorGorth wrote: 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.
Posted: Tue Mar 30, 2010 10:27 pm
by PhantorGorth
Eric Walch wrote: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.
Posted: Fri Apr 02, 2010 9:16 pm
by 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?
Posted: Tue Apr 13, 2010 7:52 pm
by 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?
Posted: Tue Apr 13, 2010 7:58 pm
by another_commander
Thargoid wrote: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).
Posted: Tue Apr 13, 2010 7:59 pm
by Thargoid
Now that's what I call service! 
Posted: Tue Apr 13, 2010 8:03 pm
by 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().