Ok. These sector parms... are they a fixed set of parms or can we define new ones? They're global in scope across the entire db (but not across games)? Sounds exciting... I can think of a dozen things that could make use of this. No more reading ck figs for everything... laff. Ah well, so many great ideas, so little time to make them happen.

The entire point of the SectorParamaters is that we can make up new ones.
quote:from the TWX Proxy Script Reference:
setSectorParameter

Purpose: Sets a permanent variable in the TWX Database, assigning it to a sector.

Syntax: setSectorParameter {sectorIndex} {parameterName} {value}

{sectorIndex}: The index of the sector to hold the value.

{parameterName}: A name identifying the value to allow it to be retrieved later. This can be anything up to 10 characters long.

{value}: The value to store. This can be anything up to 40 characters long.

Notes: Use this command if you need to store an extra sector-specific value in the database (for example, a notation indicating which sectors belong to an enemy player).
The value assigned to the sector can be any length up to 40 characters. A sector can in theory have any number of values assigned to it. These values can be stored and retrieved from any script that works using the selected database.

Be extremely careful how many values you store against sectors. The method used to store and retrieve these values is not very efficient and will cause performance problems if the search list of total values is too large. A large number of these values can also cause the database to bloat and make it less efficient.

Values can be retrieved using the GetSectorParameter command.

Xide was very concerned about the DB getting bloated, but in the tests EP and I've done, it hasn't been a problem if you use a realistic number of them. (don't have 100 per sector!)The biggest problem I face is when I create some kind of loop during script development that hoses the DB somehow. (Which happens to me quite often. heh)

The biggest reason nobody used them in 2.03 was because if you visited a sector that had sector params set, it would blow them away. There were some work arounds for that, but for the most part they were unusable. In 2.04, they are fixed, and it's gotten me scripting again.

The sector parameters are stored in a data dump, in a simple linked list. As more sector parameters are added to a sector, traversing to the end will take longer and longer. With that in mind, you'll want to add the speed sensitive parameters first, and other low-priority parameters later.

Keep in mind that you have a 10 character limit on the parameter's name, and a 40 character limit on it's value. In addition to the other bug Traitor mentioned already, 2.03 also has a bug which limits the value length to 10.

A good test would be to see the speed difference between retrieving the 1st, 10th, and 100th parameter's value to discern lag. And using the new setTimer command, you could actually measure such tiny differences.

+EP+