Page 42 of 118
Re: Scripters cove
Posted: Thu Mar 22, 2012 4:41 pm
by Commander McLane
Gimbal Locke wrote: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.
Re: Scripters cove
Posted: Thu Mar 22, 2012 8:25 pm
by 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
Re: Scripters cove
Posted: Thu Mar 22, 2012 9:02 pm
by Smivs
Gimbal Locke wrote:
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.
Re: Scripters cove
Posted: Mon Mar 26, 2012 12:05 am
by Gimbal Locke
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.
Re: Scripters cove
Posted: Wed Apr 25, 2012 2:29 pm
by SandJ
Gimbal Locke wrote: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...
Re: Scripters cove
Posted: Wed Apr 25, 2012 7:21 pm
by PhantorGorth
Gimbal Locke wrote: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
Re: Scripters cove
Posted: Wed Apr 25, 2012 7:51 pm
by Thargoid
Collision detection gets in the way of this, even with a frame callback.
Re: Scripters cove
Posted: Wed Apr 25, 2012 7:53 pm
by PhantorGorth
Ho Hum...
@Gimbal: Does it need to be visible in flight? If not then why not use a mission screen?
Re: Scripters cove
Posted: Wed Apr 25, 2012 7:56 pm
by 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.
Re: Scripters cove
Posted: Wed Apr 25, 2012 8:05 pm
by 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.
Re: Scripters cove
Posted: Wed Apr 25, 2012 8:29 pm
by 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.
Re: Scripters cove
Posted: Thu Apr 26, 2012 10:55 am
by 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.
Re: Scripters cove
Posted: Sat Apr 28, 2012 5:14 am
by Capt. Murphy
Thargoid wrote: (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"]
Re: Scripters cove
Posted: Sat Apr 28, 2012 7:59 am
by 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.
Re: Scripters cove
Posted: Sat Apr 28, 2012 9:08 am
by Capt. Murphy
Thargoid wrote:I mean in-flight as in with one of the views visible.
Nope that works OK for me.