Also, you can actually get the hash with this line:
%hash = sha1(%obj.getPosition() @ %obj.angleId);
You're saying that like it negates what he said, but in order to do that you have to show code which gets the position and angle of the object back from the hash, which is impossible due to the
Pigeonhole Principle (in this case, reducing the virtually infinite position space for a brick* into an admittedly quite large, but still finite, 20-byte value space of the SHA1 hash.)
Now, the largest
usable brick position space is likely much smaller than the value space of SHA1, but that still leaves you having to go through several years of cryptography courses to understand exactly what SHA1 is doing and how to correctly reverse it. Normally you could just adapt a library someone else had written to your language of choice instead, but TorqueScript doesn't really lend itself well to that sort of importation.
Plus hashes shouldn't be used in the manner that you're using them. Like I said, the
theoretical value space of a hash is larger than the position space, but it's likely that there's some possible combination of gate positions and rotations that someone could actually place that would end up having the same hash for both gates. With your code, it's impossible to have those two gates both exist in the same map. Jump forward twenty years, where a
VERY pissed off user** will want to know why he cannot place two gates in those two places.
*Nothing other than the fxDtsBrick class has an .angleID variable by default. (That I know of.)
**Free software designers who have contact with their users have the worst of both worlds. They don't get paid for their hard work but they still get bitched at by starfishs who expect everything to work perfectly if anything breaks for even half a nanosecond.
Hashes shouldn't be used for guaranteed unique identification for objects. The objects themselves should be used for that. Hash functions are used in cryptography, such as storing passwords in irretrievable forms that can still be compared against, or for signing a document in a way that proves it was you that read and signed it.
They're not something that you use to simplify comparisons. Regardless of whether you hash your data or not, you're still going to have to make the same number of comparison checks. SHA1 adds an additional function call, and takes up more space on disk on average (at least in TS, which has no bit/bytewise IO, and thus represents them as hexadecimal, doubling the number of bytes on disk).
The long and short of it is, there's no reason to use hashing for your purposes, and plenty of reasons not to. They are useful, but not for what you're doing. You may eventually realize that you need to get the position and angleID back out of the hash for some reason, and then you'll have to rewrite ALL of your code in order to be able to do so.
Anyway, about your actual question, you can't add a variable to a .bls file. However, you can add an event to change those variables, then have an autoeventer to add them to the warpgate bricks. Just make sure that you idiot-proof them to the greatest degree possible - Blocklanders love destroying your lovingly crafted mods at the earliest opportunity.
