Progress

[Commander McLane]

At least we is consistently inconsistent..

Indeed!

[Svengali]

To better support strict mode, and to avoid buggy scripts carrying information across games, I intend t reload scripts whenever the game resets in 1.74 and forward. This means:

• The reset() handler will no longer be called. Instead, a new instance of each script will be run, and startUp() called.
• There will be no persistent timers.

Good to know (aargh), but the missionVariables are not accessible at this point. Will this change?

[JensAyton]

I can’t guarantee that offhand.

[JensAyton]

Since someone didn’t see fit to include it in the release notes, I thought I’d bring this back from the archives:

*spins the wheel of unexpected new features*

And this week’s grand prize is… data-driven crosshairs. This means that crosshair shapes are now loaded from a config file. But that’s not all! They can also be overridden by any HUD plist by adding a crosshairs dictionary. But that’s not all! The size, thickness and colour of crosshairs can also be overridden by any HUD plist with the keys crosshair_scale (default: 32), crosshair_width (default: 1.5) and crosshair_color (default: greenColor) respectively. But that’s not all! Oh wait, yes it is. Except for the minor detail that crosshair width is now proportional to window size, just like everything else.

The format of the crosshairs.plist entry is simple: each entry is an array, whose elements are arrays of six numbers, each such array representing a line segment. The first three numbers are alpha, x and y for one end of the line segment, the other three numbers are alpha, x and y for (surprise!) the other end.

[Eric Walch]

Good to know (aargh), but the missionVariables are not accessible at this point. Will this change?

What do you mean with not accessible. In the past they were just nil for a Jameson, but could already be set by code. ups-courier initialises its variables on starUp() and they always changed and still do with the new way. And on reset() the variables from a saved game were already available. For ups it works both the old as the new way, without need to change the code.

My target reticle.oxp did not work anymore as in only read in the variable on reset() because it was stupid to read it on startUp() as you already knew it was nil than. Now I changed the code so startUp() calls reset() on startup and it works again. But that this fix works, also implies it already reads in missionVariables on the new startUp().

[Thargoid]

Currently this.reset() is called when a save-game is loaded (or the game restarts due to a space-bar moment), but if you just start a game with the default new Jameson all you get is this.startUp(), and never this.reset().

So I think the question will be if this.reset() is removed, when the script first begins (and fires this.startUp) the saved game is not yet loaded (along with its stored missionVariable settings) so whether that will cause a problem or not to scripting and their setting/reading of missionVariables. We may need a this.saveGameLoaded or somesuch event, which is a little nonsensical as that is partially what this.reset is anyway.

[Eric Walch]

....So I think the question will be ...the saved game is not yet loaded (along with its stored missionVariable settings).

What was unclear with the last sentence of my previous message? I thought I pretty explicit wrote the variables were read in at that point, just as before.

[Thargoid]

So essentially this.startUp is actually going to become this.reset, with the addition that it is triggered at first game start as well (to cover new Jamesons where currently this.reset is not triggered)?

Seems a sensible economy to me as in most cases the workload is duplicated anyway (or one calls the other), just to get around this.reset not being called without a save-game load or a spacebar moment.

[JensAyton]

So essentially this.startUp is actually going to become this.reset, with the addition that it is triggered at first game start as well (to cover new Jamesons where currently this.reset is not triggered)?

No, they are fundamentally different. startUp() is called for newly loaded scripts, while reset() is called for existing script objects. In the old model, scripts were loaded once at startup and were responsible for completely resetting their state when reset() was called. In the new model, old script objects are thrown away and new ones are created.

From a scripting perspective this happens to occur at the same time reset() was called, but the script does not have to worry about resetting any of its properties that it might have altered before, for instance. (If your scripts for 1.73 and earlier aren’t doing this in reset(), they’re broken.)

[Commander McLane]

Then mine are certainly broken.

Praise the Ahruman for making them whole again with 1.74!

[Svengali]

Thanks Ahruman for clarifying this.

@Eric+Thargoid: Yes, I know about the behaviour (as you've already said, Eric) in v1.72+v1.73. The only question was if this behaviour changes for v1.74 and how this works now - but meanwhile I've tried Dizzies installer, so no question anymore .-) I've to tweak a few things now, but that's the risk of scripting with/for testversions. So wherever we are ending - it will be good (plus sensible economy, Thargoid).

[Eric Walch]

The only question was if this behaviour changes for v1.74 and how this works now - but meanwhile I've tried Dizzies installer, so no question anymore .-) I've to tweak a few things now, ....

As far as I looked through mine scripts and several others, I think none is affected by this change (with the exception of the reticle.oxp)
All scripts that were set up as:

Code: Select all

this.startUp = this.reset= function()

or

Code: Select all

this.startup = function()
{
  // one time stuff
  this.reset()
}

this.reset = function()

will work correct for both versions. And that are far the most of the scripts.
And Ahruman is right that there is a real risk not every scripter resets its own variables correct on reset. I already had an oxp that after reloading a new commander, used variables from the old commander.

[JensAyton]

Flasher memory consumption in 1.73.3: 324528 bytes.
Flasher memory consumption in trunk: 336 bytes.

Exhaust plume memory consumption in 1.73.3: 324528 bytes.
Exhaust plume memory consumption in trunk: 2028 bytes.

Every other entity type is also 12300 bytes smaller.

[Lestradae]

That's a good one, Ahruman!

The flasher memory eater has been exterminated!



L

[DaddyHoggy]

Flasher memory consumption in 1.73.3: 324528 bytes.
Flasher memory consumption in trunk: 336 bytes.

Exhaust plume memory consumption in 1.73.3: 324528 bytes.
Exhaust plume memory consumption in trunk: 2028 bytes.

Every other entity type is also 12300 bytes smaller.

Wow! That's a better trick than Derren Brown! How did ya do it?