More on OpenID
Just to clear things up about why I mention this when there are a few other similar things out there. This one truly is decentralised. Somewhere on the page you use as an ID is the address to your OpenID server. This site has a diagram explaining it all.
OpenID in GR
Well I have OpenID working at a basic level in Galaxia for signing up and logging in. For signups though a user still needs to provide a username eventually to replace the url which will generally be too long…
OpenID
LiveJournal I hadn’t noticed before… OpenID. It’s a clever idea – a truly distributed identity management system. The idea is to allow you to login to websites using just a URL (in my case http://www.oliverbrown.me.uk/) and have everything done automatically.
In detail:
You login into a website that supports OpenID (like LiveJournal). The browser then checks that URL you gave for a bit of HTML that specifies your home server. The website then redirects your browser to that server and logs you in (and because of the joy of cookies etc. this should be automatic). The server then asks if you really want to share your identity with the site you specified and if so redirects back to the original site which now knows you are who you say you are (i.e. the owner of the url and actually registered with the server you specified).
It’s confusing but clever 
]]>
Scripting in Galaxia Reborn
Introduction to XGS
This won’t sound that impressive since noone has seen any of GR working but I have scripting working at a minimal level in Galaxia Reborn.
I gave a ship the following script:
<xgs>
<script event="entersector">
<savetomemory name="w" value="($w+1)%4" />
<setcourse target="$waypoints.$w" />
</script>
</xgs>
$waypoints is simply an array of four coordinates. The function savetomemory just saves data to the ship which is read back in when the script next executes.
Bombs in London?
http://uk.news.yahoo.com/050707/140/fmtu4.html
Guess I picked the right time to leave London…]]>
Working user scripting
The whole thing is actually simpler than I expected it to be and as such it can do stuff I didn't plan. The first is maths expressions. This is something that may cause a problem however since it just just evals the code (after substituting variables and stripping possible harmful stuff).
The coolest feature I think though is handling aggregate data types. When you call a script you also pass it an array of variables. These variables can be of any type from integers or strings to arrays or objects (or even resources); it's upto the functions you define to actually handle them. Now different elements of arrays and properties of objects can be accessed using a slghtly suspect-looking dot notation. So (from a working example I wrote) you could use something like $fleets.1.name which would access the name of the second element of the fleets array.
It's worth pointing out that I decided to stick with numbering arrays from 0 since as a programmer that's what I'm used to.
Anyway when I say that is accesses the name of the second element, it checks the type of the element and accessed it as an array ($fleets[1]['name']) or a property ($fleets[1]->name) as appropriate.
You can also do $fleets.$n.name to access the name of the nth element (although be warned that if n doesn't reference a key of the fleets array then it won't work obviously). Which brings me to biggest problem with it at the moment... everything fails silently if something isn't right.
The way the scripting is called is also more flexible than I originally planned. The first way is:
$xgs->parseXGS('event', 'fleetentersector', $script, $vars);
$script is the a well formed XML script and $vars is an associative array of variables. Any script tags with an attributes of event equal to fleetentersector (<script event="fleetentersector">). This is was done mainly with Galaxia in mind so players could create different types of scripts other than ones designed to respond to events (i.e. use it just to create a batch command system).
The second far more flexible way to use it is:
$xgs->parseXPath($xpath, $script, $vars);
Where $xpath is an XPath expression selecting the root node of the script. Just to point out the first example actually just calls that with XPath expression "script[@$type='$att']" ($type is the attribute name and $att its value).]]>
I’m not dead
But I'm back now. :)]]>