Scripting requests

[Svengali]

Can we get a modification to system.info so that when we assign a texture, alter a description, change the sun's corona, etc. - we can pass a parameter that'll tell Oolite NOT to add the change to the save-game file? The default could be to still do so, so it maintains backwards compatibility, but I'd like to be able to tell it NOT to do this.

I've just tried it with current trunk and it looks superb. cims patch has been incorporated (r4822), so cleaning the used keys will delete the empty dicts as well. This is available as nightly already.

Means that FamousPlanets and SystemRedux can enable the "Texture target" switch as default now without leaving relicts in the savedgame. Muchas gracias!

[Phasted]

An event-handler (well, two actually) that triggers when the player buys or sells cargo (passing commoditiy name, quantity, and price).

[Commander McLane]

An event-handler (well, two actually) that triggers when the player buys or sells cargo (passing commoditiy name, quantity, and price).

Seconded, as it seems quite useful.

[Capt. Murphy]

An event-handler (well, two actually) that triggers when the player buys or sells cargo (passing commoditiy name, quantity, and price).

Seconded, as it seems quite useful.

In the meantime you could do something clever with the this.guiScreenChanged handler triggering a framecallback including code to keep an eye on the players manifest and credit level whilst on the market screen and react appropriately. In effect using framecallbacks to make your own event handlers.

[Thargoid]

Depending on what you want to do, the guiScreenChanged event could even suffice as-is.

Take a snapshot of the credits and manifest when entering the market screen, do same on exit and then take the difference. That will give you an overview of things when you leave the screen, which may be sufficient for some needs.

May get screwed up if you leave the screen by launching perhaps though, which would need to be captured.

[Capt. Murphy]

An event-handler (well, two actually) that triggers when the player buys or sells cargo (passing commoditiy name, quantity, and price).

Seconded, as it seems quite useful.

In the meantime you could do something clever with the this.guiScreenChanged handler triggering a framecallback including code to keep an eye on the players manifest and credit level whilst on the market screen and react appropriately. In effect using framecallbacks to make your own event handlers.

https://bb.oolite.space/viewtopic.php?f=4&t=11805 for a code snippet...

[timer]

Please, add ID property to OOJSEntity as getter for universalID, it's not hard

And please, tell me something about this proposal https://developer.berlios.de/feature/?f ... up_id=3577

[another_commander]

And please, tell me something about this proposal https://developer.berlios.de/feature/?f ... up_id=3577

Hi and welcome timer. Your proposal is basically what we had a long time ago as option for enabling OXP equipment, before the N/Shift-N priming-activation method was implemented. Our proposal back then was to have four instead of two keys that would be bound to functions very similar to what you propose and using these functions to activate equipment and also recognize particular keypresses. However, this option had to be abandoned. Although it would work great for just a couple of OXPs making use of the functionality (I still have somewhere on my hard disk a test script that was responding to keypresses), it very soon became evident that the four functions would be devoured very quickly by OXPs trying to book themselves for using them. Ahruman back then described the situation as resembling IRQ conflicts on the old PCs (those of you who experienced the IRQ hell will recognize the horror in the statement ). The more OXPs we get trying to use the scripted "function keys", the worst it will become. So, although I do see where you're coming from with this proposal, and I do see that it is implementable, I don't think that it will be possible for it to be put to practical use.

[timer]

Hi and welcome timer

Thanks a lot, I'am glad to join BB

Well... So, I ask to add only one key - only one: "device mode", without it we will come to that for each option of operation of the device => the separate device will be created

And what about ID getter?

add:

it very soon became evident that the four functions would be devoured very quickly by OXPs trying to book themselves for using them

wait... may be my english is so bad and you don't understand me OXPs can't conflict - func keys available ONLY for current active prime equipment - NO hook keys by script(OXPs), only callback from engine for ONLY two keys, that user configure himself in keyconfig.plist

[Kaks]

Using IDs has been deprecated: ID numbers stop referring to valid entities the moment the player jumps from one system to another, and are recycled as needed by the entities inside the new system. Trying to keep track of ships using IDs would quickly cause way too many headaches. If you need to keep track of a ship, or any entity exposed to js, you can assign the entity directly to a holder variable (which will work as using a pointer in c, if you know what I mean: no extra memory usage, and immediate access to all its properties).

We did have a universalID getter in js, but - following its deprecation for scripting purposes - it was removed in rev3520 (almost 2 years ago). If you want to assign IDs to ships for your own reasons, you can always add dynamic properties to an entity, as with all js objects:

Code: Select all

thatShip= system.addShips('thatship',1)
thatShip.specialID=223244;

<snip>

if (thatShip.specialID && thatShip.specialID === 223244){
   // do something here...
}

I've got to admit I've never even thought of 2 buttons per oxp script, but I think I know what you mean - I've seen games with a primary mode button & a secondary mode one. It's a bit of a slippery slope too, because then it'll be just a matter of time before someone needs a tertiary mode button...

However, you can record when the equipment was activated and enable different actions for 'single click' and 'double click'. This might help:

Code: Select all

this.lastClick = 0;
this.firstModeDelay = .01; // 10 milliseconds

this.activated = function () {
   var useFirstMode = clock.absoluteSeconds-this.lastClick > this.firstModeDelay;
   this.lastClick = clock.absoluteSeconds;
   if (useFirstMode) {
      this.modeTimer = new timer(this, this.firstMode, .25);
   } else {
      if (this.modeTimer && this.modeTimer.isRunning) this.modeTimer.stop();
      this.secondMode();
   }
}

this.firstMode = function () {
   // do something
}

this.secondMode = function () {
   // do something else
}

Assuming I've coded it right, if you press the activate equipment key once it will 'fire' after .25 seconds ( a limitation of timers) or, if you press it twice within 10 milliseconds it'll do whatever is inside .secondMode immediately.

This bit of code has got 'a few' problems, but it's just meant as a starting point...
For example, the .25 seconds thing is a limitation of timers: if you use frame callbacks you can get around this 250 milliseconds limitation, but the code does become a bit more complex...

[Svengali]

No need for a timer - a simple example is used in Hyperradio (pretty similiar to Kaks example, but without timer):

Code: Select all

this.activated = function(){
  if(!this.lastPress) this.firstMode();
  else {
    if((clock.absoluteSeconds-this.lastPress)<2) this.firstMode();
    else this.secondMode();
  }
  this.lastPress = clock.absoluteSeconds;
}
this.firstMode = function(){
  return;
}
this.secondMode = function(){
  return;
}

More precision is possible by using (new Date).getTime(). A example can be found in cabal_common_comm_eq.js which differentiates between three modes (0-1200, 1200-5000 and >5000 ms).

[timer]

you can always add dynamic properties to an entity, as with all js objects:

hm... I thought this is impossible... but if JS objects is ordinary JS objects (I try do so but... may be something wrong)
ok, question obout ID is closed - THANKS.

I've got to admit I've never even thought of 2 buttons per oxp script

We talk not about common OXP... we talk about OXP that presents equipment for SPACE SHIP...
and pilot have to push push push push push just ONE button to select mode and activate some functions... hmmm... excellent! let send this proposal to NASA's engineers
sorry...

Pleeeaaaseeeeeeeee add just one key for mode change for selected prime equipment

For example, I write OXP that cycle target ships on the scanner, and I want set different modes 1) select only "red" hostile ships 2) select outlaw ships 3) select cargo pods

or Upgrade for Aux Fuel Tank - set mode 1) transfer from aux tank to main 2) from main to aux (after sunskim)

many devices can work in different modes - look at simple electronic watches - one button for select mode and the second for action it's hard - to do it with one button

Kaks - thanks anyway, for help.

[Wildeblood]

many devices can work in different modes - look at simple electronic watches - one button for select mode and the second for action it's hard - to do it with one button

But there are two buttons - N to select mode, and n to activate - maybe you just want to edit your key configuration to change the N to a different - lower case - button, so you don't need to hold the shift key?

Or perhaps you're overlooking the possibility of adding equipment items that only exist to change the configuration of your main equipment? Have a look at my Sniper Sight OXP, which is mostly just an exercise to see how many different configuration options I can fit into one script.

Consider using other options like dummy mines - I think Ramirez does that in Resistance Commander OXP, or the compass mode - you could activate an equipment item using the n key and have it do completely different things depending on which mode the compass is in.

[Switeck]

"Your proposal is basically what we had a long time ago as option for enabling OXP equipment, before the N/Shift-N priming-activation method was implemented."

CTRL + Shift + N goes backwards through the equipment list. I use it a lot now that I have typically >5 activated equipment on my ship.

[Kaks]

No need for a timer - a simple example is used in Hyperradio...

Doh! RL taking its toll again, brain too slow today! Thanks Svengali for a much simple version.

For timer's purposes, I'd change it slightly though:

if((clock.absoluteSeconds-this.lastPress)<0.3) this.firstMode();

It should allow for a fairly natural 'double click' effect...