Page 2 of 2

Re: Truncating/Archiving the Notification log

Posted: 30 November 2020, 10:16
by RicardoRix
can you some how automatically start a new game for each mission. (So there would need to be a mission number option possibly).

Re: Truncating/Archiving the Notification log

Posted: 30 November 2020, 23:17
by BaronFraser
tchobello wrote: 30 November 2020, 10:09 isn't it possible to limit the notifications read back (50 ? 100 ? ) while a real or turn by turn game has not ended ?
This would be the perfect solution, but I'm not aware of any such (built-in) functionality. Does anyone know anything I don't know?

Re: Truncating/Archiving the Notification log

Posted: 30 November 2020, 23:20
by BaronFraser
Tisaac wrote: 30 November 2020, 09:07
Een wrote: 30 November 2020, 09:03
Tisaac wrote: 29 November 2020, 13:09 Have you tried a brute force approach by clearing old logs of the database yourself and see how the framework react ?
:shock:
Is it really a bad idea ? :D
I mean, if you resynch your whole game current status at some points, you don't need the full previous logs/notifications, right ?
I would say it's worth a try :)
There's always a risk when directly manipulating the BGA data (rather than going through an API) that if they change their underlying database structure in future then the game will break.

Re: Truncating/Archiving the Notification log

Posted: 08 December 2020, 09:13
by Scribal
Prefacing this by saying that I only recently signed up for the Studio site and haven't had time to do anything with even the tutorials, so maybe this wouldn't actually be an easy fix.

It would seem to me that any kind of campaign game should generate a save state at the end of each race/mission that simply points to the primary key for the last log entry for that race/mission. With that save state, when continuing a turn based campaign game would then call a slightly different SELECT statement.

Currently, I'm guessing that the SELECT statement looks something like "SELECT * FROM LOGS WHERE GAME_ID = XXXXXXX;" and the results are passed to PHP to be parsed. If there is a LOG table, I expect it's set up with roughly these columns: primary key, game_ID, event_type, and action. If that is the case, create a new event_type, something like save state. At the end of a race/mission "INSERT LOGS(GAME_ID, EVENT_TYPE, ACTION) VALUES (GAME_ID, 'save state', (SELECT PK FROM LOGS WHERE GAME_ID = XXXXXXX ORDER BY PK DESC LIMIT 1));" Campaign games would then have an altered SELECT statement when loading the log for the turn based game "SELECT * FROM LOGS WHERE GAME_ID = XXXXXXX AND PK > (SELECT ACTION FROM LOGS WHERE GAME_ID = XXXXXXX AND EVENT_TYPE = 'save state' ORDER BY PK DESC LIMIT 1);.

Not knowing exactly how the log subsystem works, it seems to me like that would only be a couple of extra lines of code to the log subsystem and probably only a couple of extra lines of code for each game. These changes wouldn't change how a replay is reviewed because that would ignore the save state and you should be able to avoid breaking any current games that don't have a save state flag.