Mission offering

[Eric Walch]

I have programed a mission OXP. I'll upload it soon if I find out how.

In writing I noticed that missionoffering is handled badly by most programmers. Nobody takes the trouble if it is allowed at that time.
Result: Two missions are offered simultaniously but the player sees only one of them. This can easy be overcome by always checking if "gui_screen_string" is equal GUI_SCREEN_MISSION before a mission is offered. In oolite this check leads to somewhat complicated programming. So easier is it to test for the most important other pages as in next demo script:

<key>conditions</key>
<array>
<string>"Put your condition equasions here"</string>
<string>gui_screen_string oneof GUI_SCREEN_STATUS, GUI_SCREEN_EQUIP_SHIP, GUI_SCREEN_MARKET, GUI_SCREEN_SHORT_RANGE_CHART</string>
</array>
<key>do</key>
<array>
<string>setGuiToMissionScreen</string>
<string>addMissionText: test1</string>
</array>

Existing missionscripts are easy modified by searching for the text "addMissionText:" and add above "gui_screen_string" test in the condition.

For Assassins this adding took one minute, for targoidwars it took even less. I wrote a special OXP that offers a mission on every dokking and I had my own OXP. With this change all four OXP worked perfectly together and waited for each other in presenting their missions.

This works in 95% of the cases. To get a 100% compatibility betwee OXP one must introduce a extra variable that everybody checks. I wrote a proposal and will upload it together with my OXP.

Eric Walch

[LittleBear]

Hi Eric. Welcome to the Boards.

The main problem with the mission clash briefing is Thargoid Wars and Military (as these are set to run in any Galaxy). Its not that Murgh and Wombat were being lazy, its just that these guys wrote these OXPs a long time ago <mode>gray_haired_commander</mode> <string>I remember when all this was star-fields!</string> and neither of them are active in modding ATM. When they wrote their OXPs there weren't any other missions to clash with!

I knew about the mission clash problem, so set Assassins in G7 (no other native or OXP missions run there - except TW and M which can run anywhere) but I know it could clash with Thargoid Wars / Military. (Hence the readme warning). I'm redoing it at the moment to make it work on 1.69. I've posted the code for the first briefing below. Could you posted an edited version which includes the "wait if another OXP is giveing a breifing and don't give this briefing until then" condition? Just so I get the syntext right before C&Ping the whole script!

Code: Select all

{ 
					conditions = ("status_string equal STATUS_DOCKED", "galaxy_number equal 6"); 
					do = ( 
						{ 
							conditions = ("dockedAtMainStation_bool equal YES", "mission_assassins undefined", "score_number greaterthan 199"); 
							do = ( 
								"setMissionImage: victim1.png",
								setGuiToMissionScreen, 
								"addMissionText: hitbrief_1", 
								"addMissionDestination: 73",
								"set: mission_assassins_gotscan 0",
								"set: mission_assassins_jumpcount 0",					 
								"set: mission_assassins_bugattack 0",
								"set: mission_assassins_robotescape 0",
								"set: mission_assassins_robottimer 0",
								"set: mission_assassins_killcount 0",
								"set: mission_assassins_navybots 0",
								"set: mission_assassins_war 0",
								"set: mission_assassins_unlocked 0",
								"set: mission_assassins_basedeath 0",
								"set: mission_assassins_trumble 0",
								"set: mission_assassins_card 0",
								"set: mission_assassins assassins_STAGE1",
								"setMissionDescription: assassins_header1",
								"setSpecificPlanetInfo: 6=73=description=Orramaor is noted for its companion world Apollodorus and is reasonably well known as the corporate headquarters of Soin Classic Shipyards Ltd. In recent years, Soin Classic Shipyards have specialised in the development of greatly improved versions of Serpent Class ships.",
								"setSpecificPlanetInfo: 6=73=techlevel=14",
								"setSpecificPlanetInfo: 6=73=government=6",
								"setSpecificPlanetInfo: 6=73=economy=0",
								"setSpecificPlanetInfo: 6=73=inhabitants=Fierce Rodent Scientists",
								"setSpecificPlanetInfo: 6=73=productivity=53489",
								"setSpecificPlanetInfo: 6=107=description=Esrire is famous for its large gas giant, Cerberus. The system is however plagued by high levels of criminal activity, even by the standards of an anarchy system. GalCop Special Branch suspects that many criminal organizations make their home in this system, but have thus far found no living witnesses to corroborate their theories.",
								"setSpecificPlanetInfo: 6=107=productivity=97252",
								"setSpecificPlanetInfo: 6=107=inhabitants=Sinister yellow frogs",
								"setSpecificPlanetInfo: 6=194=description=Tiared is well known for its large volcanic companion, Diomedes. The inhabitants have a passion for the sport of Zero-G Hockey, hosting the last five Galactic Cup competitions. The Galactic Zero-G Hockey Association have their headquarters on the northern continent of the planet.",
								"setSpecificPlanetInfo: 6=194=inhabitants=Hockey-obsessed lizards",
								"setSpecificPlanetInfo: 6=203=description=Beatle is well known for its moon, Augeas. The Augeaian Orbital Repair Facility is famous for the affordable servicing facilities provided by its industrious work crews. The Augeaian Security Force maintains a strong presence of both Mega and Interceptor Kraits in the vicinity. Customers can rest assured that their powered down craft will remain secure whilst undergoing servicing.",
								"setSpecificPlanetInfo: 6=203=inhabitants=Feline Engineers",
								"setSpecificPlanetInfo: 6=203=techlevel=14",
								"setSpecificPlanetInfo: 6=203=economy=0",
								"setSpecificPlanetInfo: 6=203=productivity=39902",
								"setSpecificPlanetInfo: 6=203=government=7",
								"setSpecificPlanetInfo: 6=39=description=The Ateslete System is reasonably noted for the ice-world, Stymphal. The well known robotics company, Griff Research Ltd, operates factories over most of the planet and maintains an orbital research station near Stymphal.",
								"setSpecificPlanetInfo: 6=39=techlevel=14",
								"setSpecificPlanetInfo: 6=39=government=7",
								"setSpecificPlanetInfo: 6=39=productivity=78824",
								"setSpecificPlanetInfo: 6=39=economy=0",
								"setSpecificPlanetInfo: 6=39=inhabitants=Humans and Robots",
								"setSpecificPlanetInfo: 6=53=description=Quandixe is well known for its tropical moon Hesperides, the climate of which is perfectly suited to the cultivation of Megaweed. Dark rumors circulate that the Quandixeian Corporation is in reality a front for a Mafia narcotics syndicate.",
								"setSpecificPlanetInfo: 6=53=inhabitants=Legitimate businessmen",
								"setSpecificPlanetInfo: 6=53=economy=5",
								"setSpecificPlanetInfo: 6=18=description=Geteve is reasonably well known for its large moon, Hercules. GalCop Special Branch maintains a well armed base in orbit around Hercules. The main offices of the Galactic Prosecution Service are based on the moon's surface.",
								"setSpecificPlanetInfo: 6=18=economy=0",
								"setSpecificPlanetInfo: 6=18=government=6",
								"setSpecificPlanetInfo: 6=18=inhabitants=Law abiding humans",
								"setSpecificPlanetInfo: 6=184=description=This planet is notable for its great tropical forests, but is famous for its inhabitants passion for the sport of Zero-G Hockey.",
								"setSpecificPlanetInfo: 6=184=inhabitants=Hockey-obsessed humans",
								"setSpecificPlanetInfo: 6=81=description=Ataneris is famous for its forest covered companion, Hippolyte, but has a sinister reputation as traditional place of bloodshed. In dark corners of disreputable space bars it is whispered that, from time to time, duels between pilots of great skill take place by the Witchspace Beacon. Two ships enter the circle. One ship leaves.",
								"setSpecificPlanetInfo: 6=100=description=Formally a GalCop penal colony, a successful rebellion by the prisoners placed the system in the hands of felons. At present the system is run by the Yankisona Triad gang. In criminal circles, it is well known that relations with the Quandixeian Mafia are less than cordial. Many fear that all out gang warfare is imminent.",
								"setSpecificPlanetInfo: 6=100=inhabitants=Criminals of many species",
								"setSpecificPlanetInfo: 6=100=productivity=29127",
								"setSpecificPlanetInfo: 6=118=description=The planet Orreedon is famous for its strange mountains, but cursed by deadly goats. In criminal circles, it is said that an illegal trade in the export of Orreedonian deadly goats flourishes on the northern continent. Once domesticated, the deadly goat can be trained as a vicious attack beast.",
								"setSpecificPlanetInfo: 6=82=description=Estiri is noted for its large ocean covered moon, Nemean, and famous as the location of the Galactic Supreme Court. The Galactic Navy operates from a well armed base orbiting the moon.",
								"setSpecificPlanetInfo: 6=82=productivity=27654",
								"setSpecificPlanetInfo: 6=82=govenment=6",
								"setSpecificPlanetInfo: 6=19=description=Sobeer is famous for the delicious nature of its native marine life, particularly the exquisite Sobeerian spotted cod. Beings of a more sensitive nature decline however to partake in this delicacy, knowing its use in certain sinister Mafia rituals.",
								"setSpecificPlanetInfo: 6=13=description=Eszausve is famous for its rocky moon and the twin gas giants Hades and Lernean, but cursed by one of the most oppressive governments in the Galaxy. Although the People's Popular Front bravely resists the oppressive regime of Governor Tarkin, thus far they have made little progress in restoring freedom to the planet.",
								"setSpecificPlanetInfo: 6=13=productivity=98764",
								"setSpecificPlanetInfo: 6=13=techlevel=14",
								"setSpecificPlanetInfo: 6=13=inhabitants=Oppressed harmless fat birds",
								"setSpecificPlanetInfo: 6=13=station=abcstat"
							); 
						}, 

[/code]

[TGHC]

Man oh man what a stunning first post!

A huge welcome to the Board Eric, and very well done.

Mission briefing "clashes" have been an ongoing problem, a "fix" for this has been long overdue, and seemingly insurmountable. No one has really addressed this issue head on before.

If this is a permanent solution, all the existing OXP's could be amended, all new OXP's should include it.

Hooray! give that man a coconut!

[Captain Hesperus]

Man oh man what a stunning first post!

A huge welcome to the Board Eric, and very well done.

Mission briefing "clashes" have been an ongoing problem, a "fix" for this has been long overdue, and seemingly insurmountable. No one has really addressed this issue head on before.

If this is a permanent solution, all the existing OXP's could be amended, all new OXP's should include it.

Hooray! give that man a coconut!

If it works as well as my (very) limited code reading skills appear to say, then, it could even be uploaded to the Making an OXP section of the Wiki.

Captain Hesperus

[dajt]

I looked into this at the beginning of the year and it sounds like we may have hit upon a similar solution. See my post.

[TGHC]

@dajt, sorry about that, you should get a coconut too!

I'm surprised that nobody really picked up your idea and ran with it, because it's such a major issue for OXP's.

I guess the resident wizards will sort out which of these is the better solution, and easiest to be implemented.

[LittleBear]

Hmm I'm puzzeled!

I testing this with Military and Assassins. I haven't changed anything in Militray, but I've added this to Assassins (as a global condition for giving any assassins briefing).

Code: Select all

conditions = ("gui_screen_string oneof GUI_SCREEN_STATUS, GUI_SCREEN_EQUIP_SHIP, GUI_SCREEN_MARKET, GUI_SCREEN_SHORT_RANGE_CHART", "dockedAtMainStation_bool equal YES", "mission_assassins undefined", "score_number greaterthan 199"); 
							do = ( 
								"setMissionImage: victim1.png",
								setGuiToMissionScreen, 
								"addMissionText: hitbrief_1", 
[rest of script...]

Now Millitary is triggering whilst as soon as the Commander is loaded (as it should as I have more than 1000 kills). I read the Military briefing and look at the F5 Screen. The Assassins "Ensure Be Soin enjoys a happy retirement in the Orramaor System." is now on the F5 screen. I have not seen the assassins briefing but all the do commands have been executed.

How come!

I was looking at the Military briefing so the GUI was the Mission Screen. Therefore the condition in the oneof was not true. None the less Oolite has gone on to do all the things it was told not to do unless the condition was met.

Grr!

Any ideas?[/code]

[Commander McLane]

First of all: Welcome to the board, Eric, and: WOW! This is a very charming and stunning idea you are proposing here. The especially charming aspect of it is that it could work without the extra variable dajt was proposing in his idea.

Earlier this year, but after dajt's post, I posted an idea of mine that somehow went in the same direction as yours: Displaying the mission screen only when the player has left a possible other mission screen and arrives on another screen.

There is a little flaw to this method, as for reasons I don't know some of the other screens don't return any value to gui_screen_string, so we can't query them correctly.

But--and here comes your idea, as far as I understand it: We don't need to do that! The only thing we need to know is that gui_screen_string is not GUI_SCREEN_MISSION.

Now, how can we do that? In my humble opinion the most effective (perhaps not the most aesthetic and elegant) way is the right way of dealing with conditions. And here we should remember that conditions have a do-part and an else-part. (In the JS-model we don't need that, because we will have a "is not" in a condition (will we, Ahruman? please!). But in the old scripting model we don't.)

So, what to do? (specifically @ LittleBear):

You leave youre existing condition as it is:

Code: Select all

      conditions = ("dockedAtMainStation_bool equal YES", "mission_assassins undefined", "score_number greaterthan 199");

Now in the do-part you start a new condition:

Code: Select all

                conditions = ("gui_screen_string equal GUI_SCREEN_MISSION");
                do = ();
                else = (
                    "setMissionImage: victim1.png",
                    .
                    .
                    .
                    "setSpecificPlanetInfo: 6=13=station=abcstat" 
                );

What should happen? As long as any other mission has already brought up a screen: nothing. (The do-part is empty.) As soon as another screen is brought up: everything in the else-part, vulgo your mission screen and all that follows.

That should be the solution.

Thinking again, there is however a problem. If the text of the other mission runs over more than one screen, than you get a PRESS SPACE COMMANDER at the end of the first screen. As soon as you press space, gui_screen_string changes to GUI_SCREEN_STATUS for some milliseconds. If the engine runs your condition "gui_screen_string equal GUI_SCREEN_MISSION" at that very moment, the condition will be false, the else-part will be entered and your first mission screen will be shown instead of the second screen of the other mission. And that's why we are going to need the variable on top of this method. So Eric is right.

Anyway, LB, I'll be interested to know how far you come if you try this.

[JensAyton]

And here we should remember that conditions have a do-part and an else-part. (In the JS-model we don't need that, because we will have a "is not" in a condition (will we, Ahruman? please!) …

Yes. This should work (in 1.68 or 1.69):

Code: Select all

if (guiScreen != "GUI_SCREEN_MISSION")
{
    mission.imageFileName = "victim1.png"; // equivalent to setMissionImage:
    // stuff
    mission.missionScreenTextKey = "hitbrief_1"; // equivalent to addMissionText:
    mission.showMissionScreen(); // equivalent to setGuiToMissionScreen
    player.call("setSpecificPlanetInfo:", "6=13=station=abcstat"); // No JS-native equivalent yet
    
}

[LittleBear]

Cheers Guys. This is an excelent method, so really want to try to get it working. First go, no good though! The problem CM has raised happened. I got the military briefing (multi paged). Accepted the transmision. The Militray brief continued, but with the assassins victim1.png now replacing the military.png (guess in the the screen switch some of the assassins script ran). But once the Military briefing finished I did see the assassins briefing in full. I'll keep fiddling with the order I'm setting conditions..

I suspect that the code orginally proposed by Eric & CM would work to stop a clash with another OXP that put up a single page briefing, but won't work for any OXP that every offers choices in a breifing or uses more than one page (which every mission OXP does at some point).

EDIT : Tried taking out the GUI_SCREEN_STATUS, out. My theory being that it was this screen that was "flick to" for a faction of a second during the page change in military. Didn't work either, same problem. I think there is a solution, but perhaps I need to go at it the other way. Thinking of having a condition in assassins that just checks for an equal mission screen and sets an internal assassins variable to "mission_assassins_missonscren INUSE". I'll have a think about this..

LATER:-

Come up with an idea that should work. But its not!

My plan is to set a variable if the mission screen is in use by another OXP. This test is done right at the start of the assassins script like this:-

Code: Select all

conditions = ("gui_screen_string equal GUI_SCREEN_MISSION");
                			do = ("set: mission_assassins_give_brief NO");
                			else = ( 
						{ 
							conditions = ("mission_assassins_give_brief undefined", "dockedAtMainStation_bool equal YES", "mission_assassins undefined", "score_number greaterthan 199"); 
                					do =   ("setMissionImage: victim1.png",
								setGuiToMissionScreen, 
								"addMissionText: hitbrief_1", 
[rest of script]

I then reset the variable back to undefined, when the player launches, or looks at the shipyard, market screen etc. This should mean that if the mission screen is being used by another OXP Assassins then waits the until the player docks again or he buys some cargo, checks the shipyard etc.

However, although Military is using the Mission Screen the variable is not being set. Is the syntax right? "gui_screen_string equal GUI_SCREEN_MISSION"? Is that the right name for the string the gui_screen is using?

Stuck!

[/code]

[Commander McLane]

However, although Military is using the Mission Screen the variable is not being set.

Are you sure? Have you tested the value of the variable? Do this: Reduce your condition to its first part:

Code: Select all

{
     conditions = ("gui_screen_string equal GUI_SCREEN_MISSION");
                			do = ("set: mission_assassins_give_brief NO");
},

This does nothing more than setting mission_assassins_give_brief.

Now have another condition like this:

Code: Select all

{
     conditions = ("status_string equal STATUS_DOCKED");
                			do = ("commsMessage: [mission_assassins_give_brief]");
},

This should display the state of mission_assassins_give_brief on your screen. If '[mission_assassins_give_brief]' is displayed, then the variable is still undefinded. If 'NO' is displayed, then it's correctly set to NO.

[Commander McLane]

I then reset the variable back to undefined, when the player launches, or looks at the shipyard, market screen etc.

A main issue will be to find an elegant way to reset the variable. A reset when launching works, but it has the problem that your mission can continue only when the player launches and relands. If he doesn't know he has to do that (and how should he know, if he hasn't read this thread?), this is highly unlikely. And therefore frustrating for the player.

Resetting on other screens unfortunately works only on some of the screens, as some other screens do not return a correct value to gui_screen_string. (I mentioned that earlier. It is annoying. Must be a bug in the code. Perhaps our codemonkeys could search for it if they get some spare time from their other projects?)

There is another drawback in resetting the variable when the player looks at another screen: As scripts are run only every ten seconds or so, the player has to stay a another screen for up to ten seconds in order to make sure that the script is run while he is there. In the scripting model there is no way to overcome this 10-second-rule. In Javascript this seems to be different, if I understand Ahruman correctly.

As a result your variable mission_assassins_give_brief probably is never reset during your stay at the station. Therefore your mission briefing never turns up. Have you tried launching and relanding (given your resetting condition on launching is syntactically correct)?

[LittleBear]

Saved the game after testing so I know that the variable is not set (but all the other variables in the script - which would not run anyway unless the give_brief variable was undefined - have been set and are now in the save file). I'm using a brand new Jameson to test this, so no variables are present unless they were set by the test. For the test I'm NOT resetting the variable. So if it had been set it would be in the save file.

I'm only reseting the one give_brief variable by launching. True this does mean that the Assassins giving of its brief is delayed until the next docking, but that is what I want really. In play it would work like this:-

The player dockes and suddenly the alarms go off and he his launched by Thargoid Wars to defend the station. He shoots down the Thargoids and docks to sell his cargo. Now he gets a message from the Assassins Guild asking him if he wants to retaire Be Soin. The player won't know that had it not been for Thargoid Wars deciding to scramble him he would have seen the briefing earlier. The real problem ATM is that Assassins is running (and the mission desription is set of the F5 screen), but the player has missed the message and only seen the Thargoid Wars brief.

If pretty sure though the problem is that Oolite is not detecting that the screen went to the mission screen.

The best way would be to be able to reset the variable using the oneof : all the non-mission screens. But this works too well! As soon as I answer to Thargoid Wars "Yes - I'll defend the Station", for a fraction of a second the screen is one of these, so the Assassins script runs, but I miss the briefing and am launched to defend the station!

[Commander McLane]

Code: Select all

conditions = ("gui_screen_string equal GUI_SCREEN_MISSION");
                			do = ("set: mission_assassins_give_brief NO");
                			else = ( 
						{ 
							conditions = ("mission_assassins_give_brief undefined", "dockedAtMainStation_bool equal YES", "mission_assassins undefined", "score_number greaterthan 199"); 
                					do =   ("setMissionImage: victim1.png",
								setGuiToMissionScreen, 
								"addMissionText: hitbrief_1", 
[rest of script]

Third idea: The functioning of condition - do - else with a lot of conditions and sub-conditions is somewhat tricky. So it could be a good idea to split it into two independent conditions:

Code: Select all

{
	conditions = ("gui_screen_string equal GUI_SCREEN_MISSION");
	do = ("set: mission_assassins_give_brief NO");
},
{
	conditions = ("mission_assassins_give_brief undefined", "dockedAtMainStation_bool equal YES", "mission_assassins undefined", "score_number greaterthan 199"); 
	do = ("setMissionImage: victim1.png",
			setGuiToMissionScreen, 
			"addMissionText: hitbrief_1", 
[rest of script]

},

The idea is that if there is another mission screen, the first conditions will work and set mission_assassins_give_brief to NO. The now independent second condition won't be run, because of its first condition. As soon as mission_assassins_give_brief is reset this part of the script will start.

[Commander McLane]

By the way: You can test whether a screen sets gui_screen_string or not with this small script:

Code: Select all

{
	conditions = ("status_string equal STATUS_DOCKED");
	do = ("commsMessage: [gui_screen_string]");
},

At the bottom of your screen something like 'GUI_SCREEN_EQUIP_SHIP' will be displayed, if the variable is set correctly. IIRC there a some screens where a wrong name turns up. And if you see '[gui_screen_string]' as a message, then the variable is not set at all.