With the turn processing finished, Notoriously Databased was ready for limited testing. Unfortunately some conflicts with the online database made the LAN tests a bit of a flop, even though I'd been able to test a couple of turns myself locally. Debug phase ...
The first issue was that the cascade on delete that I'd set up locally hadn't been merged over very well. I tried fixing it with a diagram system, but it kept complaining about multiple cascade loops when it was only cascading downward from multiple parents. Wierd. It allowed it on manual update of the foreign key though.
Next issue was that partially filled submissions were causing null errors, so I zero'd out all the null fields at the start of processing. Later on I found out that Characters not submitting a turn was throwing errors too, so created a default blank submission for those. Some other small errors were isolated & fixed in a couple of hours.
Testing the turn processing was getting a little tedious when triggering the proces from the admin panel, so I moved it to the player's screen to keep it all together for now. It raised another problem I've been having with MVC and the modelessness of web design: there doesn't seem to be a built in way of returning back to the previous caller, rather it lets the currently active action determine where to go next. I can see why this might be the case, but it's such a radical shift from traditional functional design, I'm surprised that they haven't tackled it in some way. There are far more complex issues (like entity framework) that have been solved. Hopefully I'm just missing something simple, which is quite likely.
Another thing I wanted was a quick way to see the character's story. Earlier changes to the controller and views made it quite simple to make a method receiveing the character's ID and only outputting those stories. Since it was only called from the player's screen, at least I didn't have to worry about the redirection on completion. Limiting the stories to those involving the character was one step, but I also needed to include all public stories as well. In SQL this would be a simple ID=x OR isPublic=1, but it took a while to figure out how an OR could be imoplemented. Many methods to do an AND, but only one looked like it could also be manipulated into being useful for an OR by simply using C# binary logic in the where() clause. It looks like Entity Framework does a nice job of processing the logic and converting it into an SQL statement. I haven't had to reduce entity framework to SQL queries just yet, although there have been a couple of wierd interfaces to do more or less the same job.
After the turn processing I thought it would be a good time so show the whole story of the turn to whoever processed it (as another debugging tool). Setting up another list was pretty easy, but unfortunately I couldn't trigger it easily with a RedirectToAction() passing a parameter to another controller, but it feels like returning to the Player's screen was a more concise alternative anyway, leaving individual turn debugging relegated to the admin panel.
It's feeling nice and solid. Now for some serious strategy testing ...
With turn processing triggered of fthe admin panel, and
