This means:
1. Adding the new CA to AI configs
2. Removing it whenever the combat CA is removed
3. Preventing conflicts for AIs that previously used overlapping scores
It depends on timing whether or not the guest shows the wait dialog between
scenarios. If the second scenario has already started when the guest tries
to show the dialog, the dialog is skipped: otherwise it's shown and it
changes the plugin context.
The join.lua plugin assumed the change of plugin context to mean that the
test is over and that the plugin should quit the game. As a result, it
ended up quitting in the middle of the test if the second scenario hadn't
started yet.
Commit 6016bdf2 tried to fix the problem by allowing the plugin context to
change once during the test. It resulted in the opposite problem: if the
second scenario *had* started, the plugin context didn't change. When the
test ended and the guest was thrown into the lobby, then the plugin
assumed that it was just the scenario change and kept waiting for the next
scenario that wasn't coming.
This commit finally fixes the problem by explicitly polling the name of the
scenario being played. Now join.lua ignores plugin context changes as long
as the last scenario hasn't started, but starts waiting for the game to end
when the scenario starts.
I verified locally that, with these changes applied, the tests pass both
with an unmodified build and with a build that has an artificial delay to
simulate the timing in Travis.
When the type was changed, only the filtered games were printed to the list, meaning there was nothing
to make visible when the filter changed. This makes it so all games are printed, and the invalid ones
then hidden.
This fixes an issue where any random map settings would immediately be lost upon clicking
Regenerate since set_current_level resets the generator, for some reason.
The cause was the data_ class member being modified every time the map was regenerated using itself
for the calculations, causing an eventually-fatal cumulative effect. This solves that by keeping a
temp copy of the data which is then modified and passed to the generator job.
grep'd and didn't find any other places this massively stupid mistake appeared.
rather than change behavior, after correcting the definition, changed the calls.
This CA performs attacks on enemy units so close to leveling that the
default AI's combat CA would not attack them (with some exceptions).
This is meant to keep players from being able to exploit this known
weakness of the default AI.
In fact, the entire garrison may be dead. The bandits need to get real lucky, but it could happen.
Appoint a new commander from the survivors. Skip the conversation if it was a masacre.
Sir Gerrick is not the leader, and Urza Afalas is just a loyal follower, neither are heros any longer. Update their overlays and ellipses to reflect their new status.
I never understood the purpose of mermen. All they do is change what the Naga Queen has to say. Let's let Sir Gerrick recruit them here. It's really just about the only place in the entire campaign where they actually can do some good! Why limit him to just those Deoran had?
When we next see Sir Gerrick and the units he has on the map will be in S09a. While Sir Gerrick will be fine, the units will appear to be in poor shape in the recall list. Let's heal everyone, first, so we're sure everyone is in fighting shape when they return.
When Urza Afalas and his band join Deoran they should be able to move. But, since they're changing sides their movement won't have been reset, yet, so we have to do it by hand.
There is no reason to stop his moving about. Separating his sighted event and finding the bandit encampment eliminated any problems with his movement. This was a todo comment for when this was fixed. Actually, I think the real problem was the inapproriate sighting of the bandits when we found the lich.
