info about various getLog parameters

[DreadKnight]

Should have the AB.getLog(); various parameters figured out and briefly documented as they can come in very handy regarding development https://github.com/FreezingMoon/AncientBeast/blob/master/CONTRIBUTING.md#report-issues

[DreadKnight]

Found the related code for it over here: https://github.com/FreezingMoon/AncientBeast/blob/0305dda60a3523cf561b1fa9712cfa86bde9436f/src/utility/gamelog.js#L128

[HridoyHazard]

can u plz explain the issue a bit further so that i can understand and give it shot

[DreadKnight]

can u plz explain the issue a bit further so that i can understand and give it shot

Hey, this issue is assigned to me for a good purpose. Please poke at any of the hundreds or other issues that aren't assigned or labeled "brainstorm".

[andretchen0]

Converting to TS can help with this a bit, at least for writing code. The get(state) argument could be limited to:

'json' | 'save' | 'hash' | 'simple' | undefined

Here's what they currently do:

• json: prints a JSON version of the log to the console; returns the log
• save: saves the JSON version of the log; prints undefined to the console; returns undefined
• hash: prints a Base64-encoded ASCII string to the console; returns a Base64-encoded ASCII string
• simple | undefined and currently all other arguments: console logs and returns AB.restoreGame('${hash}');

All console logs are prefixed with "GameData: ".

env

We could maybe add get("env") or debug_game_log() for DEBUG_GAME_LOG in /env.

API suggestions

I don't mean to bikeshed, but I think I'd simplify the API and make it more explicit. I guess the fact that we're even talking about needing to explain the API suggests that that would be helpful. (The gameLog isn't called many places in the code, so it'd be relatively easy to change.)

Ideally, I'd wish for these getters:

• gameLog.base64 and gameLog.env - a DEBUG_GAME_LOG version of the log, Base64
• gameLog.json - a JSON string of the log
• gameLog.log - the unchanged log

... and maybe this method:

• gameLog.save(contents?, name?) - if no arguments are supplied, it can default to the current behavior of get("save")

With that, I think the API will be clearer. If you want to e.g., log JSON to the console from a JS file, you just:

console.log(gameLog.json)

or from the console:

> gameLog.json

And if you want to save:

gameLog.save(gameLog.json, "myfile.json")

I think that'd be clearer anyway.

[DreadKnight]

Converting to TS can help with this a bit, at least for writing code. The get(state) argument could be limited to:

'json' | 'save' | 'hash' | 'simple' | undefined

Here's what they currently do:

• json: prints a JSON version of the log to the console; returns the log
• save: saves the JSON version of the log; prints undefined to the console; returns undefined
• hash: prints a Base64-encoded ASCII string to the console; returns a Base64-encoded ASCII string
• simple and all other arguments: console logs and returns AB.restoreGame('${hash}');

All console logs are prefixed with "GameData: ".

Thanks for poking at this, I was lazy about it. Will see about adding those to the guide pretty soon.

env

We could maybe add get("env") or debug_game_log() for DEBUG_GAME_LOG in /env.

What would that do exactly? I'm almost falling asleep atm and I might be missing something.

API suggestions

I don't mean to bikeshed, but I think I'd simplify the API and make it more explicit. I guess the fact that we're even talking about needing to explain the API suggests that that would be helpful. (The gameLog isn't called many places in the code, so it'd be relatively easy to change.)

Ideally, I'd wish for these getters:

• gameLog.base64 and gameLog.env - a DEBUG_GAME_LOG version of the log, Base64
• gameLog.json - a JSON string of the log
• gameLog.log - the unchanged log

... and maybe this method:

• gameLog.save(contents?, name?) - if no arguments are supplied, it can default to the current behavior of get("save")

With that, I think the API will be clearer. If you want to e.g., log JSON to the console from a JS file, you just:

console.log(gameLog.json)

or from the console:

> gameLog.json

And if you want to save:

gameLog.save(gameLog.json, "myfile.json")

I think that'd be clearer anyway.

Great API suggestions 👏🏻 So the important thing is that we could even have gameLog.load(something), way easier.

[andretchen0]

env What would that do exactly?

If we don't implement the other API changes, I'd add that to the switch statement in get, in order to console.log the string that can be added to /env as DEBUG_GAME_LOG to autoplay a log.

[DreadKnight]

env What would that do exactly?

If we don't implement the other API changes, I'd add that to the switch statement in get, in order to console.log the string that can be added to /env as DEBUG_GAME_LOG to autoplay a log.

I see, yeah, handy; thought there was already something like that, guess just plans for it in my mind. Feel free to poke at this and even the API changes, don't forget the load/save hotkeys, so that they don't get their functionality broken again :P

[andretchen0]

don't forget the load/save hotkeys

Is there a keyboard shortcut for loading? If so, can you point me to it? I don't know where it is.

save hotkeys

The current keys are kind of hard to access: shift + ctrl + meta + x. That's 4 buttons, so kind of tricky.

But it's also impossible to trigger on Windows/Firefox, afaik. event.metaKey on Windows/Firefox is false even if the Windows key is held.

We could remove meta as shift + ctrl + x is unused.

But maybe better - ctrl + s is the usual "save" shortcut. It's also currently unused.

[andretchen0]

So the important thing is that we could even have gameLog.load(something), way easier.

Currently gameLog has a play method that accepts a few different formats: a string, an array of "actions", and a "log object" that contains an array of "actions". Did you want something besides that? Just change the name to load?

Or is load distinct? If so, let me know what you're thinking.

---

There is currently a possibly confusing asymmetry between play and get.

get produces a few different kinds of strings:

• JSON
• 'AB-' + version + '@' + today + ':' + window.btoa(json): i.e., base64-encoded JSON with a prefix.
• AB.restoreGame('AB-' + version + '@' + today + ':' + window.btoa(json)): i.e., same as above, but wrapped in a function call.

play only knows how to deal with the 2nd option above. The other types of strings will fail silently.

I don't know if get needs to be dumber or play needs to be smarter, but it seems logical to me anyway that any log output format that gameLog produces - by get or otherwise - should be able to be read back in by play (or load). The only human-readable string format get produces is JSON, and that's not readable by play.

---

It'd probably also be a good idea to throw an error here if the passed string can't be handled in play (or load). Failing silently is graceful in some circumstances, but here I think it tends to leave the user wondering whether anything happened at all.

Any thoughts?

[DreadKnight]

don't forget the load/save hotkeys

Is there a keyboard shortcut for loading? If so, can you point me to it? I don't know where it is.

I can't locate it quite yet, but hotkey is ctrl + shift + meta + L and works in the pre-match screen.

save hotkeys

The current keys are kind of hard to access: shift + ctrl + meta + x. That's 4 buttons, so kind of tricky.

But it's also impossible to trigger on Windows/Firefox, afaik. event.metaKey on Windows/Firefox is false even if the Windows key is held.

We could remove meta as shift + ctrl + x is unused.

But maybe better - ctrl + s is the usual "save" shortcut. It's also currently unused.

Usually avoided simple hotkeys like that because browsers are kinda problematic at times if you use stuff that's already in use. We could give that another go and try ctrl + s provided that ctrl + L and ctrl + P will be nicely usable as well.

[DreadKnight]

So the important thing is that we could even have gameLog.load(something), way easier.

Currently gameLog has a play method that accepts a few different formats: a string, an array of "actions", and a "log object" that contains an array of "actions". Did you want something besides that? Just change the name to load?

If if has that already, good. It's what I was worrying about. Was planning a rename, but...

Or is load distinct? If so, let me know what you're thinking.

Now that you've mention it, reminded me of something, so it should be different. There's this issue #2161, so if we'll implement those new hotkeys in menu, ctrl + P would be for play, meaning you would get to see all moves animated, while ctrl + L would be for load which would skip all animations, allowing you to continue the match right away.

There is currently a possibly confusing asymmetry between play and get.

get produces a few different kinds of strings:

• JSON
• 'AB-' + version + '@' + today + ':' + window.btoa(json): i.e., base64-encoded JSON with a prefix.
• AB.restoreGame('AB-' + version + '@' + today + ':' + window.btoa(json)): i.e., same as above, but wrapped in a function call.

play only knows how to deal with the 2nd option above. The other types of strings will fail silently.

I don't know if get needs to be dumber or play needs to be smarter, but it seems logical to me anyway that any log output format that gameLog produces - by get or otherwise - should be able to be read back in by play (or load). The only human-readable string format get produces is JSON, and that's not readable by play.

True, play and load should deal with any of the stuff that's being output by get. Feel free to open new issues.

It'd probably also be a good idea to throw an error here if the passed string can't be handled in play (or load). Failing silently is graceful in some circumstances, but here I think it tends to leave the user wondering whether anything happened at all.

Any thoughts?

I agree, we could even display warning that version numbers don't match between log and current version for example.