0

Im writing in c# for XNA MonoGame, and have written up an enemy state enumeration to allow me to determine what logic to use for my enemy at each update function.

Here is the enumeration:

    public enum EnemyState {
                            /// <summary>Non-active state, ideally should not process logic.</summary>
                            WaitOrder,
                            /// <summary>Enemy is moving towards a directed position.</summary>
                            MoveOrder,
                            /// <summary>Enemy is chasing a directed target.</summary>
                            ChaseOrder,
                            /// <summary>Enemy is launching an attack towards directed target.</summary>
                            AttackOrder,
                            /// <summary>Enemy is dieing, and should be moving towards being deleted.</summary>
                            Dieing
                        }

And I simply use EnemyState state as a deceleration in my enemy class, with the constructor adding state = EnemyState.MoveOrder.

The problem is, XNA is appearing very clingy to the MoveOrder state. Even though I check that state == EnemyState.MoveOrder before entering the movement update function, and this clearly returns false, it still enters.

With a break-point inside the movement function, marking the line where I change the value of state, I proceed to step through the code, line by line.

Visual Studio is telling me that state == EnemyState.WaitOrder before and after the if statement, and that state == EnemyState.MoveOrder returns false.

What could otherwise cause it to ignore the requirement, and jump into the statement, even when the requirements are not met?

As you can see, at the first line of the if statement, the if clause returns false.


update

If I place the check into a boolean, first, the boolean shows the check to be true. That said, If I change state == EnemyState.WaitOrder to state == 0, I do not have a problem.

Community
  • 1
  • 1
Gnemlock
  • 325
  • 6
  • 22
  • are you using async methods for changing this value? – Sebastian L Sep 11 '15 at 05:59
  • Is your game multi-threaded / async? – Rohan Büchner Sep 11 '15 at 06:04
  • 3
    Store the complete condition in a local variable to see its exact value (at the time of checking). `var condition = state == EnemyState.MoveOrder; if (condition) { \\ ... }`. – Corak Sep 11 '15 at 06:14
  • I'm not multi threading at all. @Rahul, the image shows that breaking at that particular interval, Visual Studio is directly identifying the statement to be false. As such, I have provided all the code that is going into this, which is entirely why I have come here to see what else I could have missed. Condescending comments of poor grammar are of no value. – Gnemlock Sep 11 '15 at 06:15
  • @Corak, that helps slightly. The actual bool is set as true, but the statement is set as false :/ – Gnemlock Sep 11 '15 at 06:17
  • So Ive fixed the problem.. but still cant figure out why it happens. Simply changed "EnemyState.MoveOrder" to its respective int. Makes absolutely no sense to me :/ – Gnemlock Sep 11 '15 at 06:21
  • So at the exact time the checking occurs, it seems like `state` actually *is* equal to `EnemyState.MoveOrder` and only by the time you are looking at `state == EnemyState.MoveOrder` VS tells you, it's false. That does sound very much like a multithread problem. Or maybe (much less likely) some weird `enum` behaviour. – Corak Sep 11 '15 at 06:21
  • Wait, how is `EnemyState` defined? – Corak Sep 11 '15 at 06:22
  • @Corak, updated info – Gnemlock Sep 11 '15 at 06:26
  • how do you set `state`. is it changed inside MoveOrder method or setter/getter of some properties? – M.kazem Akhgary Sep 11 '15 at 06:30
  • Huh, sorry, then I'm at a loss. I thought maybe some weird `[Flags]` combination would occur or maybe multiple enum items having the same value or some such stuff, but this seems straight forward. – Corak Sep 11 '15 at 06:31
  • @M.kazemAkhgary, it is set within MoveOrder method, once the move order pushes the unit within proximity of the current destination. As I stated previously, changing to int fixed the issue, but i still want to know why it happened, so that I can learn from it. Is it at all possible that its just VS playing sillies? I have had teachers use this as a reason, before, and had a similar issue with sound. – Gnemlock Sep 11 '15 at 06:32
  • Are you sure you haven't just returned from the `MoveOrder` method? Otherwise I would turn the declaration of `state` into a property (e.g. `private EnemyState state { get; set; }`) and put a breakpoint on the setter. – jaket Sep 11 '15 at 06:50
  • To make sure, I went through a few iterations, starting at the first break-point seen in my screenshot. So it's not just returning from `MoveOrder` – Gnemlock Sep 11 '15 at 06:51
  • Do you have any code optimizations enabled in Visual Studio? We even managed to cut down such an error to an assignment of `int x = 2 + 2;` and after that, `x` was `17`. The VS-integrated optimizations sometimes result in old code base, so you get different results in the compiled assembly than VS displays. – LInsoDeTeh Sep 14 '15 at 14:41
  • @LinsoDeTeh, none that are not default. – Gnemlock Sep 14 '15 at 19:33

0 Answers0