Kingdom Generator needs major overhaul

[aiannacc]

There are several problems with the current implementation:

• The dialog is generated by assignment to innerHTML, which Mozilla rejects as a security violation
• The dialog's button is an input submit element, so the code it triggers has to explicitly prevent the submission or else the page reloads; errors in the code or even in the entry can cause that code to fail to execute, resulting in the page reloading
• There is no hinting or error correction for card/expansion name spelling
• The dialog doesn't pop up until after Goko has run its own random deck generation algorithm
• The set parser (which is unreadable machine generated code) is in the same file as the generator logic (I did this, actually).
• There are several long sections of data that could be generated programmatically or stored separate from the code logic
• The help file is hosted on retrobox. That server should be considered unreliable at this point because nutki is no longer an active developer or forum member

[serakfalcon]

I'm going to separate the set parser and data stuff into a "mini-library" to be called kinggen_utils, before the 'work code' in kingdomgenerator.js (to be separated out once I'm sure there's no side-effects and I have a better handle of how everything comes together).

I'll also separate out the displayed HTML into its own section, it could also potentially be stored separately since the 'visible' part only takes up 1 line of code right now.

[serakfalcon]

OK my latest commit should fix

• security violation issues (assigning to innerHTML is not a violation per se, its only a violation if the div has not been attached to a page yet (so the code runs in about:blank)), so append child before we assign innerHTML.
• Dialog button: no longer runs as a submit. No longer exits on error. In the event something is really messed up, added a cancel button that runs with default settings (equivalent of typing 'All' into selval). Goko assumes the generator call can't be cancelled, maybe that could be overwritten?
• set parser, and sections of data placed in its own 'namespace' at the top of the script. Could be separated out.
• User prompt visual elements placed in a 'subnamespace' of the above namespace, user prompt code elements placed in a separate subnamespace
• Hooked into Goko's css to make UI emulate Goko's.

To Do:

• Continue overhaul allowing users to change more settings. Proposed Features: Selection of kingdom generator (the site generally uses HuaWei's 'fun' generator for casual games) including Pro Veto Mode, more user friendly controls and checks (input boxes for each set so users can input numbers, autocomplete and error-checking/prevention), save generator settings.
• When the above is complete we'll definitely need new help documentation.
• Run before Goko generates a random set instead of after.
• Figure out why StoreVerifier.prototype.VerifyCardIds takes so long to run (overwrite?) (appears as p.VerifyCardIds in FS.DeckBuilder.js),

[aiannacc]

Great fixes and proposals!

A few thoughts and some possibly-useful advice:

It would be nice to have an error message when you try to create an illegal kingdom. Right now the UI just doesn't respond.

I suggest getting rid of the innerHTML anyway, since we don't want to count on the Mozilla folks looking into our code to realize that it's not actually dangerous. Then again, releasing to the Firefox store isn't going to be an option anytime soon anyway, since the Mozilla add-on review process seems to have ground to a complete halt.

Running VerifyCardIds on every new game (and worse, every time the create game dialog is opened) is totally unnecessary. Some variant of it should run once on login, and maybe again after visiting the Goko store, and the information should be cached. The method itself should be overridden with a dummy that just checks the cache.

Implementing Pro Veto Mode in the kingdom generator sounds tricky. You have to interact with your opponent somehow, probably through a third party server. You're welcome to use mine, but you'll have to install and set up the environment for goko-dominion-tools in order to make changes. If you do, you may find it helpful to look to the automatch code to see how the WebSocket communication works. Some parts of the code are pretty ugly, particularly the disconnect detection, but it'll show you how it works. I suggest creating a second WS connection rather than abusing the existing automatch connection to add the veto-mode communication.

There's also a sneaky bit of Goko code for pro games to watch out for. An initial kingdom gets generated when you create the game. It uses the same method that generates a casual/unrated kingdom regardless of whether you're creating a pro/casual/unrated game. But for pro games, a second kingdom gets generated right before the game starts using a different method, and this is the kingdom that the actual game uses. The kingdom generator overrides the casual/unrated kingdom creation but not the pro.

Kingdom generation and game creation is a particularly nasty section of the Goko code. You can delve into it and try to make the exact changes you want, as the kingdom generator does now, but I think the easier solution might simply be to ignore it entirely, altering the create/edit game and start game UI elements to call our own code and communicate with the server directly instead. There's code elsewhere in Salvager that shows how to specify the kingdom and create a game table directly, so you just have to mock a Goko client's request to the server start a game and (possibly) intercept the server's responses.

There used to be a separate file called set_parser.js that contains just the machine-generated Jison set parser. I rather idiotically merged it into the kingdom generator script. You might save yourself some time by retrieving it from one of the old tags.