#34 Against the Bot

[Carl Spain]

Against the Bot rules - Neoancient

[Carl Spain]

I've never done any thread work beyond very basic stuff. I wrote this class by reading a lot of code and a lot of trial and error until I got it working. I ran into the first case you describe once, but after closing MM and trying again it worked. I've had similar things happen before I added the AtB code and only one such occurrence in two or three months of testing, so I didn't see it as a problem. If it needs more work I'll have to defer to those who are more proficient with thread synchronization than I am.

[saginatio]

The problem with concurrency bugs is that they are very non deterministic and can vary from machine to machine. Good news is that java is very friendly in that aspect (especially since java 1.5).

I'll look at it later (probably tomorrow) and try to make a proper patch.

I have a feature I want to ask for: can you display (somewhere) weight classes of player's lances?

[saginatio]

Ok, Ive tried to pinpoint the problem and I've failed ;(

I've removed concurrency when adding bot units since I see no point it having distributed among different threads. Yet the problem had persisted.

I guess the problem lies in the communication channel between client and server. I've added a delay after every packet sent and increased the delay from 125 to 500 which fixed the problem on my machine. When I tried using 125 or 250ms values MM hanged immediately adding the first bot or after adding 1-4 mechs to the first bot. This thing deserves a bug ticket in MM, imo.

I've attached a patch that fixes issues on my machine and removes unnecessary concurrency.

[Carl Spain]

Based on the feedback on the BT forums on the experimental build, this appears to be a widespread problem. My inability to replicate it hampers my ability to work on it. Since you had success by increasing the delay I thought I might be able to create the problem by decreasing it, but it works on my system even with the delay set to zero.

While I was toying around with that, though, I noticed that while I put in a delay after every entity add I didn't put in any delays after sending options, map info, or planetary info, and I wondered whether adding delays there might make it run more smoothly without having to increase the overall transfer time so much. If you wouldn't mind trying that, here's a patch for your convenience (though it might be just as quick to add the code yourself).

If this doesn't take care of it my next idea is to add a spinner to the connection dialog that lets the user set the delay, so each player can set it to whatever works on his or her machine.

[Carl Spain]

Nevermind. I managed to replicate the problem pretty consistently when running Windows (but never in Linux) and the patch doesn't help. Increasing the delay to 500 ms worked for me as it did for you. Thanks for your help on this.

[saginatio]

I've tried to setting low delay after adding mechs and very high (5sec) just after adding a bot but it didn't help either.

My guess is that in some moment, I don't know when, server stops receiving packets. MekHQ is still sending new ones, filling up the socket's buffer. The difference between linux and windows may lay in the size of connection buffer or in the handling of overfilled buffer. But that is not my area of expertise:(

[luiges90]

Monitor resolution height is 768px. I tried dragging the window to the top and did not find any button at the bottom of the dialog

[luiges90]

On more thing, in AtB rules Special Missions are supposed to use a random unit among deployed lances instead of letting the player choose one. It would be less confusing if MHQ select one when the mission arrives.

In addition, in Officer Duel and Civilian Help only officers are rolled, while Ace Duel only roll non-officer.

---

More issues:

1. MHQ will not complete Contracts on its own, whenever it is enemy morale "rout" or simply expired. Not tested about BaseAttack victory though

2. Any chance will rules about Prisoners implemented (unfortunately AtB 2.29 does not mention about prisoners)

3. Refit rules are not implemented?

[Carl Spain]

saginatio: I remember intending to put the weight class in, but it must have slipped my mind before I got around to doing it. I was going to put it on the force view on the TOE tab, but in thinking through it again I think it would be helpful to have it on the lance assignment table as well. Space is at a premium, but I think it's worth squeezing in a letter code.

luiges90: I'll rework that dialog. I may not get to it until Monday. The only special mission that explicitly states that the deployed unit is random in 2.29 is prison break. You could argue that it's implied in the others, and I would agree with you. If I were to make MekHQ choose, I would have to make decisions about whether damaged units or injured pilots could be chosen, and if so how much damage or injury is acceptable. I decided in the end to leave it up to the player to determine how to select the unit, in keeping with my general philosophy of facilitating rather than enforcing the rules. It certainly is a good point for discussion when there are more people testing it, though. I'm going to start making a list. MekHQ does check for officer/non-officer for the duels, and I added an officer check for civilian help. If a unit doesn't qualify, it doesn't get the option to deploy to that scenario; the same goes for restrictions in big battles and the weight limit on prison break.

Other issues:
1. I took my cue from MekHQ's current behavior of not resolving the contract for you when the end date is reached. Rout or base attack are a bit different, though, and might warrant a different behavior. I'll add that to the list of discussion points.

1. I implemented prisoner capture from an earlier version (2.15, I think). It's not enabled by default. I think it's called "random prisoner capture" or something like that on the scenario section of the AtB tab in campaign options. I added the rule that any enemy explicitly picked up is automatically captured. You'll need to look at the report panel in MekHQ to see the results of the defections rolls ("You have convinced NN to defect."). I left it up to the player to decide what to do with prisoners and defectors. You will also be credited with the bounty for each prisoner.

2. I didn't implement any refit rules and didn't even notice that I left them out. I'll stick that on my to-do list as well.

[luiges90]

Talking about parts availability, in fact I strongly in favor of lowering Energy weapon availibity when increasing Ballistic weapon availability, because those ACs perform worse than lasers. If we were to compare BV between ballistics and energy designs, energy designs almost always win, needless to say that energy-weapons do not depend on ammo (Very important for mercs where supply line is unstable), and has no risk of ammo explosion.
(There is a 13 pages dicussion about this in BT forum: http://bg.battletech.com/forums/index.php/topic,29433.0.html)

Hence, I prefer making energy weapons harder to obtain, so to give players an incentive to use ballistic weapons instead.

Once this patch stables, we'b probably ask for responses in BT forum.

Though I might be biased because I play mostly in 3025 era for the moment.

[Dylan Myers]

@luiges90: Sorry, no. We don't do that. If you want to limit yourself, in your campaign, go for it. We don't include things like that in the software to force on others.

[Carl Spain]

@luiges90: I agree that we need to get input from the BT forums. As extensive as this patch is, I don't think of it as complete by any means. There are several features that are only minimally implemented (several of which you've already asked about), and I'm waiting for input from the user base at large before fleshing them out. At this point the main thing is to find and squash the bugs, though I've appreciated your suggestions for improvements as well.

[luiges90]

In the log, "Personnel market updated" always appear even though it is not updated in fact. Using AtB rules.

---

Sometimes when I advance day and the day in Monday, the date is not updated. And the log complains

Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
at mekhq.campaign.market.PersonnelMarket.adjustSkill(PersonnelMarket.java:1107)
at mekhq.campaign.market.PersonnelMarket.generatePersonnelForDay(PersonnelMarket.java:456)
at mekhq.campaign.Campaign.newDay(Campaign.java:1758)
at mekhq.gui.CampaignGUI.advanceDay(CampaignGUI.java:3495)
at mekhq.gui.CampaignGUI.access$5300(CampaignGUI.java:288)
at mekhq.gui.CampaignGUI$100.actionPerformed(CampaignGUI.java:2786)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$200(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue$4.run(Unknown Source)
at java.awt.EventQueue$4.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)

[luiges90]

1. In AtB rules,

   Attached Units count for the min/max limits (3/6) in unit numbers in a lance but do not count for tonnage purposes

I added and deployed 6 units in a lance, and the attached units still appear, resulting in 8 units in a lance. Not sure what to do here according to the rules.

1. Player reinforcements are never included. Is it unimplemented or anything?

2. Contract market still roll for contracts (other than subcontracts). Do I miss anything in AtB rules that allow taking another contract while in one?

[Carl Spain]

"Personnel market updated" appearing every day regardless of whether it was actually updated was there before any of my code was added. I think I'll sneak in a fix into my next patch.

The NPE comes from trying to apply an admin/HR modifier to the anti-mech skill of a soldier that doesn't have an anti-mech skill. Fixed.

The way I read the rules I understand the attached units to be obligatory, so having a contract with integrated command rights probably ought to set your maximum lance size at 4. As the code stands now, only lances that fit the size and weight limits and contain at least one ground unit appear in the lance assignment table, and I don't like the idea of lances disappearing without an explanation. I've got some ideas on how to include the relevant information in the available space, but it will take me a bit of time to work on it.

Player reinforcements are sort of implemented. You can deploy any unit to an AtB scenario the same way you would to a non-AtB one (with the exception of the filters for special missions and big battles). Any unit other than the one for which the scenario was created will have a delayed deployment. My to-do list includes adding a combo box to the scenario view to choose from available legal reinforcements, i.e. deployed in a scout (1/3 chance) or fight role (1/6 chance) without its own battle that week.

In this patch:
+added officer filter to civilian help special mission
+fixed NPE when generating infantry in personnel market
+rearranged edit mission dialog for AtB contracts

Added to my to-do list:
allow setting Princess behavior for attached units at the contract level, to be applied automatically to scenarios when created

[Deric Page]

"Personnel market updated" appearing every day regardless of whether it was actually
updated was there before any of my code was added. I think I'll sneak in a fix into
my next patch.

You should do this in a separate path or open up a new bug ticket for this. It's always better to keep code changes focused on specific things. That way it's easier to keep track of what changed where and when if further changes end up needed.

[Carl Spain]

Contract market still roll for contracts (other than subcontracts). Do I miss anything in AtB rules that allow taking another contract while in one?

I missed seeing this before. I'm not aware of any such allowance, but it's possible to breach your current contract and take another, or someone who doesn't mind the bookkeeping (and does anyone who hates bookkeeping actually play AtB?) could have homebrew rules for splitting the unit and playing multiple contracts at once. I'm sure other players can come up with more reasons to keep it going, and I see no benefit to stopping it.

For a similar reason I didn't add an option for whether to use infantry. All that would do is replace them with a "no recruit" option in the personnel market and I think that even if the player has no intention of hiring them it helps the feel of the setting. They become fluff.

[luiges90]

TC(Def) Victory conditions is not very clear. MHQ shows

Must prevent enemy from reaching the north edge with 50% of starting forces.

It didn't tell me how many units I need to prevent the enemy from escaping, as "50% of starting forces" sounds like I need to keep 50% of my forces alive.

[Carl Spain]

I can see how that might not be clear. I tried to be consistent and state what the player needs to do to win, but in this case it might work better to state the terms of defeat: "Player is defeated if at 50% or more of the enemy's starting forces escape from the north edge."

[Dylan Myers]

I think keeping it objective oriented is better. Here's a better wording:

Must prevent the enemy forces from exiting the north edge of the map with at least 50% of their forces

[Carl Spain]

A collection of small fixes:

+added missionId to newly generated special event battles
+added early success bonus to calculated contract score
+corrected chance of HS(Att) for defense lances
+fixed contract extensions due to war-time emergency clause
+adjusted RandomFactionGenerator and data/universe/factionhints.xml to improve results in post-Jihad era and expand potential rivals for Periphery factions
+only MWs have shares with an option for all personnel
+when using capture rules while playing a Clan unit, captured personnel are made bondsmen instead of prisoners
+Added copyright and license notice to AtB source files

[saginatio]

I still had problems in my vs clan contract, so I've turned on debugger, took a magnifying glass and started hunting. it turns out there was one bug in contract extension - return statement is in wrong place. There is also a second bug in generating base attack scenarios - they had uninitialised missionId field. I moved setting of this field to constructor - seems more natural.

I've attached patch file together with my small changes to contract extension duration, ignore those:)

Index: src/mekhq/campaign/Campaign.java
===================================================================
--- src/mekhq/campaign/Campaign.java    (revision 1925)
+++ src/mekhq/campaign/Campaign.java    (working copy)
@@ -1882,7 +1882,6 @@
                    }
                    AtBScenario scenario = l.checkForBattle(this);
                    if (null != scenario) {
-                       scenario.setMissionId(l.getContract(this).getId());
                        if (scenario.getBattleType() == AtBScenario.BASEATTACK && scenario.isAttacker()) {
                            baseAttack = scenario;
                            break;
Index: src/mekhq/campaign/mission/AtBContract.java
===================================================================
--- src/mekhq/campaign/mission/AtBContract.java (revision 1925)
+++ src/mekhq/campaign/mission/AtBContract.java (working copy)
@@ -962,22 +962,22 @@
                int extension = 0;
                int roll = Compute.d6();
                if (roll == 1) {
-                   extension = Math.max(1, getLength() / 2);
+                    extension = Math.max(4, getLength() * 4 / 2);
                }
                if (roll == 2) {
-                   extension = 1;
+                    extension = 4;
                }
                if (extension > 0) {
                    campaign.addReport("Due to the " + warName +
                            " crisis your employer has invoked the emergency clause and extended the contract " +
-                           extension + ((extension == 1)?" month":" months"));
+                            extension + ((extension == 1) ? " week" : " weeks"));
                    GregorianCalendar newEndDate = new GregorianCalendar();
                    newEndDate.setTime(getEndingDate());
-                   newEndDate.add(Calendar.MONTH, extension);
+                    newEndDate.add(Calendar.WEEK_OF_YEAR, extension);
                    getEndingDate().setTime(newEndDate.getTimeInMillis());
                    extensionLength += extension;
+                    return true;
                }
-               return true;
            }
        }
        return false;
Index: src/mekhq/campaign/mission/AtBScenario.java
===================================================================
--- src/mekhq/campaign/mission/AtBScenario.java (revision 1925)
+++ src/mekhq/campaign/mission/AtBScenario.java (working copy)
@@ -274,6 +274,7 @@
        setDate(date);
        lanceCount = 0;
        rerollsRemaining = 0;
+        setMissionId(lance.getContract(c).getId());
        initBattle(c);
    }

[Carl Spain]

Yes, the return statement was in the wrong place. I tested to make sure it worked when extending contracts, but didn't test closing a contract without an extension.

Setting the missionId in the constructor will result in a NPE for special mission and big battle scenarios, when lance == null. Passing the missionId as a parameter to the constructor might work and seems pretty obvious, so I'll have to go through the code and see if there's some reason I didn't do that.

Edit: Extending the contract by weeks instead of months will run into difficulty with the payment system, which is based on whole months.

[saginatio]

Thx for the warning with extending by weeks.

I found two more bugs: 1)The bot camo is assigned to the player 2) In windows OS game may hang in the lobby during base assault (or any mission where there are at least two bots). I've attached my patch ( with a change that sets camo for bot before adding its units to lobby)

Index: src/mekhq/AtBGameThread.java
===================================================================
--- src/mekhq/AtBGameThread.java    (revision 1925)
+++ src/mekhq/AtBGameThread.java    (working copy)
@@ -191,8 +191,8 @@
                     /* Start another thread that waits for the server to add the
                      * bot then send entities and set team and starting position
                      */
-                    ConfigureBot thread = new ConfigureBot(botClient, fd);
-                   thread.start();
+                    ConfigureBot configureBot = new ConfigureBot(botClient, fd);
+                    configureBot.run();
                 }

             }
@@ -210,12 +210,11 @@
         }
     }

-    public class ConfigureBot extends Thread {
+    public class ConfigureBot {
        private BotClient botClient;
        private AtBScenario.BotForce botForce;

        public ConfigureBot(BotClient bc, AtBScenario.BotForce fd) {
-           super("Configure bot " + bc.getName());
            botClient = bc;
            botForce = fd;
        }
@@ -228,6 +227,19 @@
                if (null == botClient.getLocalPlayer()) {
                    MekHQ.logError("Could not configure bot " + botClient.getName());
                } else {
+                    botClient.getLocalPlayer().setTeam(botForce.getTeam());
+                    botClient.getLocalPlayer().setStartingPos(botForce.getStart());
+
+                    if (botForce.getCamoCategory() == Player.NO_CAMO) {
+                        if (botForce.getColorIndex() >= 0) {
+                            botClient.getLocalPlayer().setColorIndex(botForce.getColorIndex());
+                        }
+                    } else {
+                        botClient.getLocalPlayer().setCamoCategory(botForce.getCamoCategory());
+                        botClient.getLocalPlayer().setCamoFileName(botForce.getCamoFileName());
+                    }
+
+                    botClient.sendPlayerInfo();
                    for (Entity entity : botForce.getEntityList()) {
                        if (null == entity) {
                            continue;
@@ -236,19 +248,6 @@
                        botClient.sendAddEntity(entity);
                        Thread.sleep(campaign.getCampaignOptions().getStartGameDelay());
                    }
-                   botClient.getLocalPlayer().setTeam(botForce.getTeam());
-                   botClient.getLocalPlayer().setStartingPos(botForce.getStart());
-
-                   if (botForce.getCamoCategory() == Player.NO_CAMO) {
-                       if (botForce.getColorIndex() >= 0) {
-                           botClient.getLocalPlayer().setColorIndex(botForce.getColorIndex());
-                       }
-                   } else {
-                       client.getLocalPlayer().setCamoCategory(botForce.getCamoCategory());
-                       client.getLocalPlayer().setCamoFileName(botForce.getCamoFileName());
-                   }
-
-                   botClient.sendPlayerInfo();
                }
            } catch (Exception e) {
                MekHQ.logError(e);

[Carl Spain]

It stands to reason that deploying the forces for multiple bots in parallel threads would cause the same problems as deploying one bot too quickly. Changing it from parallel to sequential as your patch does should take care of that, and the timeout that's already in the thread class would prevent it from blocking completely, but if it's not going to involve threads there's no reason to create a new class and this method can be moved into the main class.

This week has been a bit crazy, but I should be able to get to it in the next couple days.