Accounts, persistent storage and EVENT scripts

[Torr Samaho]

For those of you who are not following the details on the tracker I'd like to give an update on the things we have been doing recently.

The account and persistent storage systems are pretty much ready for testing by now. The ACS interface to make use of the new features is as follows:

Code: Select all

void SetDBEntryInt ( string Namespace, string EntryName, int EntryValue )
int GetDBEntryInt ( string Namespace, string EntryName ),
void SetDBEntryString ( string Namespace, string EntryName, string EntryValue )
string GetDBEntryString (string Namespace, string EntryName )
void IncrementDBEntryInt ( string Namespace, string EntryName, int Increment )
int PlayerIsLoggedIn( int Player )
string GetPlayerAccountName ( int Player )

There are three new cvars
- databasefile controls where the database is saved (defaults to ":memory:", i.e. volatile in-memory database)
- authhostname is the masterhostname analog (port can be specified with ":port")
- sv_forcelogintojoin prevents unauthenticated player from joining the game (can still connect as spectators)

The console command login allows the client to authenticate with the auth server the server has selected with its authhostname setting.

Furthermore, I added the new experimental script type EVENT. By calling EVENT scripts the engine can notify a mod that a noteworthy event happened and also provide some information about it. This is meant to cover events that are difficult or even impossible to be detected reliably with ACS. A mod can declare an event script (needs new ACC, source here) as follows:

Code: Select all

Script 11 (int type, int arg1, int arg2 ) EVENT

So far we have the following events (more details can be found in the tracker ticket)

Code: Select all

GAMEEVENT_PLAYERFRAGS (player frags another player)
GAMEEVENT_CAPTURES (player captures the flag/skull)
GAMEEVENT_MEDALS (player receives a medal)
GAMEEVENT_TOUCHES (player touches the flag/skull)
GAMEEVENT_RETURNS (the flag/skull is returned)
GAMEEVENT_ROUND_ENDS (the current round ends and the win sequence starts, e.g. when the fraglimit is hit)

'type' is the event type as integer, e.g. GAMEEVENT_PLAYERFRAGS=0. The activator, 'arg1' and 'arg2' encode additional information about the event. For instance, the activator of PLAYERFRAGS is the fragging player and arg1 is the number of the fragged player. For this event, arg2 is not needed and always zero. In the event script, the mod can react to the event in any way it sees fit. For instance, it can track stats with the new database interface.

At this point I'd be very happy about feedback from the community. While I'm pretty sure that the additions pave the way for new exciting mods, the interfaces are not fixed yet and can certainly benefit from your perspective. Also the list of events is still very short and has room for many more events.

[Tiger]

I strongly encourage that someone either mirror's or properly format's this into the Zandronum Wiki. Otherwise, this information will get lost eventually and - that is it.

[Combinebobnt]

Nice work as always; Some people will probably test this by starting new projects, too.

[Frits]

I strongly encourage that someone either mirror's or properly format's this into the Zandronum Wiki. Otherwise, this information will get lost eventually and - that is it.

Offtopic:
Imho wiki account should be linked to the forum one (like the bugtracker). Much easier.

On topic:
Digging all these new features and the development activity i've been seeing in the last couple of weeks.

[Catastrophe]

Question, with GAMEEVENT_MEDALS being added, will there be a way to check what medal the player received?

[Kara Kurt]

I strongly encourage that someone either mirror's or properly format's this into the Zandronum Wiki. Otherwise, this information will get lost eventually and - that is it.

^

---
I was wondering if "assists" can be added to the stats since these are medals.

Good job otherwise...

[Torr Samaho]

The type of medal is specified in arg1, so you can check which medal the player received. The capture event also species the assisting player as one of the args.

[Catastrophe]

I see, hopefully somebody can provide some example code using this in action. I'll try to document this, what should the page(s) be called?

[Slim]

Oh wow, Nice to see this making great progress. Guess some of us now know why Z& 2.0 is taking so long.

[Ænima]

Aaaaaand work on Mercenaries resumes! Awesome work, Torr and friends. :)

[Torr Samaho]

I see, hopefully somebody can provide some example code using this in action. I'll try to document this, what should the page(s) be called?

I think page for the new script type should be called "EVENT Scripts". The new functions should follow the same scheme the existing ACS functions use, see http://wiki.zandronum.com/ACS_Functions

Here is a testing binary that supports all features I mentioned above. The archive also includes an updated ACC version.

[Lollipop]

A thausand praises worthy, good job ;)

[Theshooter7]

Wow, color me impressed. I admit I don't monitor the tracker much and I wasn't expecting this in the slightest. I'll see about doing tests so hopefully this can make a speedy way into the official build. :)

[Theshooter7]

Hate to sound like a needy person, but are these by chance implemented/going to be implemented into the official beta? It'd make it easier to give this a test in my opinion (for instance I could implement this stuff into WDI, then it'll get a good testing run for sure!)

[Ninjamander]

already excited for all this XD

[Torr Samaho]

Hate to sound like a needy person, but are these by chance implemented/going to be implemented into the official beta?

I already ported the necessary code into our main development branch, so the next official beta will contain the new features.
There is only one thing left I'd like to resolve, before releasing the next beta build. This requires small but coordinated changes from AlexMax and me, so it may take a couple of days to get it done.

[Theshooter7]

Hate to sound like a needy person, but are these by chance implemented/going to be implemented into the official beta?

I already ported the necessary code into our main development branch, so the next official beta will contain the new features.
There is only one thing left I'd like to resolve, before releasing the next beta build. This requires small but coordinated changes from AlexMax and me, so it may take a couple of days to get it done.

Alright, glad to hear this. :) I await patiently.

[Kara Kurt]

It's cool.

[MrSetharoo]

Can't wait to see all the stuff people are going to make with 2.0

[Ijon Tichy]

GAMEEVENT_PLAYERFRAGS seems extremely redundant - a DEATH script that uses SetActivatorToTarget can not only achieve this, but work with monster frags as well.

Everything else is pretty neato, though I haven't fiddled with any of it yet.

edit: An event that fires whenever a player deals damage, running on the actor taking damage with the player number being passed as an argument, along with the damage done, would be much more useful, and would allow for much more accurate damage tracking - perfect for all the RPG mods that crop up.

It would probably be better if the events got batched up into one call (eg. an SSG blast only sends one damage event per monster hit, rather than one per pellet), rather than every single projectile, explosion, hitscan, etc getting its own event.