If you log into the wrong game or even view the high scores of another game, it can corrupt your helper's database. It would be helpful if the game displayed a UUID when logging in or displaying scores.

What is a UUID?

Universally Unique ID. Basically a 128-bit random number, expressed as a hex string, like this: 067e6162-3b6f-4ae2-a171-2470b63dff00.

It's safe to count on them being unique even without any central coordination. If you generated a thousand of them every second, it would take several times the age of the universe to have a 50% chance of getting the same one twice. (Provided the random number generator is truly random... a whole other issue.)

My suggestion is for each game to have one assigned at bigbang.

In the program I am working on, I use the server domain, game letter, and BigBang date to determine the correct database to use. I agree that having a UUID (aka GUID) to identify the game would be more reliable.

They are not always random though. Some versions are based on the machine address and current time, and there are a variety of algorithms that can be used.

Delphi has a GUID generator that I've used in the past. I don't know about putting that on general displays, but maybe put it on the @ command?

I think it should be displayed when you press 'H', 'T', and maybe '*' from the "Enter your choice:" prompt outside the game.

Yeah, that's about the best we can do for now. But the game letter could be swapped, the domain could change...

Since it wouldn't be used by humans, I would just include it in the $ and * output.
Can you do the High Scores in XML?

I was thinking it would serve as a sentinel for data the helper is going to incorporate. In SWATH, for example, if you view the high scores of a different game (say you happen to be checking out the other games on a server to see if you want to join), it puts all those traders' names in the current database. And if you log into the wrong game by mistake, it adds everything you see to the database until it notices a sector number higher than the database is configured for. You could argue that these are helper bugs, and I would agree... but they'd be much easier to avoid if the game displayed a GUID during login and on the high scores screen.

The problem is your investigating game settings with a helper that stores that info for in game use (Swath)
The solution .. use twx and telnet or twx and putty .. or twx and zoc ..for instance.

None of these store that info , therefore no problems with corrupt data.
I have been thinking to make a twx script for the * gathering of each game on a server to help decide if that game is to my liking.

But Swath is not the thing to use when looking that stuff over.
No extra fix for TWGS is needed .. just a little lesson on what to use is all it took/takes.

my 2¢

Yes, we know, Vid... you think TWX is the best thing since sliced bread. But I've written scripts that make use of that '*' data SWATH stores for in-game use. I guess that means they'd be impossible to port to TWX, huh?

Actually , I have it imported to twx but in an ansi file ... text file.

But what your suggesting is J.P. put something into TWGS and Stein to also add to Swath to do something you already can do and accomplish.

Please don't fool yourself , TWX is the bomb.

It cannot be reliably accomplished, because game letters, IP addresses for servers without domain names, and even domain names themselves can and do change. There is currently nothing that can serve as a primary key to uniquely identify a game.

Servers that use IP #'s most likely also has "Registered to" in one or more of their screens.

Putting a time stamp in the file will also eliminate the issue of a game letter changing or signify it could be out dated info.

I know it is difficult to keep tabs on all or most of the servers out there.
Many players keep a text file of telnet addresses but not the game stats.

All of that might be done later in the JumpGate feature in the future when that part is explored.

That in itself will probably do what your looking for as a place to compare
edits and such.

I look forward to this myself.

I think the suggestions you're making are fine, Vid, but I do want to remind you that the feature request forum is a place where people can ask for features and we can discuss how such a feature might be implemented, but it's not meant to be a place to debate whether or not a feature should be considered. I don't want people to feel they have to defend their requests here. It's fine to open the discussion in another area if you want, but I don't want these threads breaking down into arguments about what's a good feature and what isn't in anyone's opinion. My concern is that people will be reluctant to offer their ideas for fear of being attacked. We get plenty of that in other areas.