Scripters cove

[Commander McLane]

The confusing thing for new OXP scripters (well, for me anyway) is to know what to do in plist and what to do in Javascript (both formats are new to me), but the above discussion has been clarifying a lot.

There's no hard rule. As a general guideline it is advisable to do as much as possible in JS, because that's the most flexible approach.

For instance, a plist (= property list) is all about declaring fixed properties which are not subject to change after they've been declared. Shipdata and equipment items are the most prominent examples. Whenever two different OXPs want to declare the same property there's potential for a clash between them. The most prominent example for that would be the universal section of planetinfo.plist. With JS-scripts, the two struggling OXPs can deal with each other in a meaningful way. With the static property lists there's only eat-or-be-eaten. One OXP wins, the other(s) lose. And which one wins is essentially random. Not a good solution.

[Gimbal Locke]

Thanks again, I have the equipment being for sale at specific planets working.

I do however have another problem which stumbles me: I can use the "legends" key in the hud.plist to display images on screen (code from DeepSpace HUD):

Code: Select all

<key>legends</key>
		<array>
			<dict><!-- crosshair -->
				<key>height</key>
				<integer>128</integer>
				<key>width</key>
				<integer>128</integer>
				<key>image</key>
				<string>crosshair.png</string>
				<key>x</key>
				<integer>0</integer>
				<key>y</key>
				<integer>0</integer>
				<key>alpha</key>
				<real>0.3</real>
			</dict>

			<dict><!-- dashboard -->
				<key>image</key>
				<string>base.png</string>
				<key>height</key>
				<integer>137</integer>
				<key>width</key>
				<real>640</real>
				<key>x</key>
				<integer>0</integer>
				<key>y</key>
				<integer>-185</integer>
				<key>alpha</key>
				<real>1.00</real>
			</dict>

		</array>

I can also replace the complete hud from a script (code from Generic HUD):

Code: Select all

   switch(newCondition)
      {
      case 0: // we're docked
         {
         player.ship.hud = "kwtradinghud.plist"; // set the docked HUD
         break;
         }
      case 1: // we're at green alert
      case 2: // or we're at yellow alert
         {
         if(player.ship.energy > 108) // if we're not using the damaged HUD
            {
            player.ship.hud = "kwnormalhud.plist"; // set the standard HUD
            }
         break;
         }
      case 3: // we're at red alert
         {
         if(player.alertHostiles && player.ship.energy > 108) // and under attack and not using the damaged HUD
            {
            player.ship.hud = "kwcombathud.plist"; // set the combat HUD
            }
         break;
         }
      }

I'm trying to have different images being displayed at different times but in several combinations. So, let's say I have 3 images A, B and C. At time 1, I want images A & B being displayed. At time 2, I want images B & C being displayed. At time 3 I want to see all images and at time 4 I do not want to see any of them. Each image has a fixed position on screen. Is this possible?

One way I see is to define as many HUDs as there are permutations of the images I want to display (meaning that if I have 5 images which can be displayed independently, I need 5 factorial = 120 plist definitions to switch between from the script) 2^n HUDS for n images (so 5 images need 2^5=32 plists), but this approach is very impractical. Another problem with this is that the player loses any OXP altered HUD in the proces, I would prefer a solution where the previous HUD is preserved.

I also looked at the jellybaby dispenser (my apologies for even mentioning this most dangerous subject) for inspiration, but there the trumbles mechanism is used to display the images, so that is not a solution for me.

Anybody has any better ideas on how to do this?

EDIT: corrected my math

[Smivs]

I also looked at the jellybaby dispenser (my apologies for even mentioning this most dangerous subject) for inspiration, but there the trumbles mechanism is used to display the images...

Oi! That's a trade secret.

[Gimbal Locke]

Oi! That's a trade secret.

Well, I'm a spy.

I even intend to add insult to injury by building my OXP on top of your Combat HUD (using the 2^n plists method mentioned in my previous post).

Fortunately this forum does not have intergalactic spy assassins.

[SandJ]

Well, I'm a spy.

Fortunately this forum does not have intergalactic spy assassins.

Upon first seeing your name, my sub-conscious automatically filled in some details of your back-story. Despite trying to forget them, some significant parts are still rattling around in my head, so I'm putting them down here to get rid of them.

Gimbal Locke. Flies a ship purely as a cover and to make pocket money, often with his family on board. The family are:
- son Stearing
- daughter Camden
- baby Kensington
- and his wife, "Compass" Rose, as navigator.

I'll leave the rest to the talented Oolite fan-fic writers...

[PhantorGorth]

Anybody has any better ideas on how to do this?

You could put up to 3 special "ships" programmatically in front of your ship and use a frame callback to keep repositioning them. The "ships" are basically billboards. The texture for them would then be based on the images you want to display.

Not tried it myself but this is purely extrapolating from what I know can be done.

Regards,

Phantor

[Thargoid]

Collision detection gets in the way of this, even with a frame callback.

[PhantorGorth]

Ho Hum...

@Gimbal: Does it need to be visible in flight? If not then why not use a mission screen?

[Thargoid]

I have an OXP on my machine which does something similar (keeps an entity in front of the ship via a callback) and it has to be quite a distance away or else collisions occur. And even then when using injectors it still sometimes collides.

[PhantorGorth]

I am wondering if it might be sensible to request the option for a mission screen to have a transparent background. I think in mission screens nothing, not HUD or Mission screen related, gets drawn. So to have the "transparent" mission screen would mean not doing that and making sure that the mission screen stuff doesn't trigger any collision detection.

[Thargoid]

Works for me, although an in-flight overlay screen would be needed (you can't display a mission screen in-flight). But the concept sounds like a good one.

[Gimbal Locke]

Phantor & Thargoid, thanks for your replies and ideas. A mission screen will not work, it's during flight and not while docked that I need this.

What I will do is create a script to generate 2^n property lists defining as many HUDs.

[Capt. Murphy]

(you can't display a mission screen in-flight).

You sure about that? I've always thought you could, and have just tested it with mission.runScreen from the debug console, and they display fine. The only potential problem is that leaving it will fire missionScreenOpportunity and any other OXPs which don't check for an isDocked condition (they should be) could display their missionScreens after.

Just came across this as a potentially useful little technique - if your script ever needs a list of all current missionVariables...

Object.keys(missionVariables)

output is an array...

["BattleDamage_status", "ig_missionreward", "ig_rescuetime", "trumbles", "cloakcounter", "ig_rescuelocation", "ig_currentmission", "ig_missionlaunchtime", "ig_missionsystem", "ig_rescuelocationcurrent", "ig_rescuedwhen", "ig_missionsystemname", "ig_rescuee", "ig_contactname", "murphy_thargoid_drive_driveCounter"]

[Thargoid]

I mean in-flight as in with one of the views visible. If you go into the manifest screen (F5) or something similar whilst not docked, from there you can display mission screens by capturing the GUI changes. But in this case it was to overlay one of the views, and that isn't possible.

[Capt. Murphy]

I mean in-flight as in with one of the views visible.

Nope that works OK for me.