Xna Pr 0.1.x Bugs

[[dteviot]]

Yes, I know we have a bug tracker, but I thought I'd set up this thread to record bugs initially.

 

I get an error in XNet when I click on an certain entries..

For instance Alien Navigation Systems, Plasma Principles -

 

edit wrong pic

Ditto (that is, exactly the same problem here).

Fixed.

 

 

There are some other "bugs" that I've found (you probably know them, but I don't know if you do ):

1) The buttons can be pressed even in the xeno-window is out of focus and behind another active window

A few more details please, exactly which windows & buttons are you referring to?

I think this isn't a bug, it's because XNA uses direct input, so it's always aware of the mouse, even when Xenocide doesn't have the focus.

2) Time runs while you're reading the X-Net (I forgot to check if this also happens in baseview, although my guess is that it does)

OK, I'll look into that. (Not sure how that happened.)

Fixed.

 

3) Your fighters can attacked a crashed UFO! A new firing circle begins until the first hit, where the ufo either crashes (an already crashed ship crashes, kewl xD) or gets destroyed. You can redo this procedure until you completely destroy it

That's not a bug. That's an additional feature I added.

More specifically, fighters being able to attack a crashed UFO is not a bug, that's a feature I added.

The fact that a crashed UFO crashes again (before it takes off) probably does count as a bug. If you attack a crashed UFO, combat should continue until UFO or aircraft is destroyed or runs out of ammo.

Note, if you don't attack a crashed UFO, it will eventually fly off. But I'd assumed that it repairs would be jury rigged, so if you attacked it again, it wouldn't take much to make it crash.

 

4) Fighters can attack terror sites and salvage artefacts :S

Lockout needs to be implemented. However, it's contingent on some refactoring I also want to do

fixed.

 

Btw, something strange happened 2 mins ago while I was taking screenshots: I moved around the globe, and all of a sudden the whole globe render (all the left part of the xeno window) turned blue!!! I couldn't do anything else, I entered the X-Net and returned but it was still the same. I abandoned the game and started a new one, same render. I tried to put a new base, and an error poped up (3rd image) and of course crashed. Restarted the game and everything worked well. It MAY be due to running it from within a .rar archive, but it happened as I was happily moving the globe around, don't know...

 

Fixed.

 

edit: Updated some of the bugs.

Edited September 17, 2007 by dteviot

[kafros]

May I add another "irritating" bug?

 

At the save dialog, if you try to save a game but you haven't written a name, the game crashes!

 

I call it "irritating", because I tried to save a game after spending ~10 mins in order to research everything (I was checking something) and the aforementioned situation occured <_ src="%7B___base_url___%7D/uploads/emoticons/default_happy.png" alt="^_^">

 

 

In addition, could you make the enter key close any "OK-Dialog" just like you did with the "Add your first base" one? That would be useful!!

Edited September 6, 2007 by kafros

[[dteviot]]

May I add another "irritating" bug?

 

At the save dialog, if you try to save a game but you haven't written a name, the game crashes!

 

I call it "irritating", because I tried to save a game after spending ~10 mins in order to research everything (I was checking something) and the aforementioned situation occured <_ src="%7B___base_url___%7D/uploads/emoticons/default_happy.png" alt="^_^">

Fixed.

 

In addition, could you make the enter key close any "OK-Dialog" just like you did with the "Add your first base" one? That would be useful!!

SaintD is (was?) looking into this.

Edited September 10, 2007 by dteviot
Update bug status

[SaintD]

In addition, could you make the enter key close any "OK-Dialog" just like you did with the "Add your first base" one? That would be useful!!

SaintD is (was?) looking into this.

 

I spent a few days on this actually. The Add First base is easy because the text dialog has focus, so I can trap the keystrokes and scan for enter. The other dialogs don't have focus when they pop up. The main windows still has the focus. I tried various ways of changing focus and/or capturing the input, but unless I clicked the dialog with the mouse first, I was unsucessful.

 

I am sure it's possible, but it doesn't work at all like windows.forms does and that's what I am used to. I may look into again in the future. It might be possible to hook deeper in the object graph and capture those inputs.

 

Also, work got really busy so I haven't had as much time to spend on Xenocide.

 

-D

[Darkhomb]

I wouldn't call this a bug but my laptop didn't have the driver for audio installed and I wanted to try xenocide on it. It crashes because it can't init the audio driver. Don't know if we want it to ignore this so game is still usable with out a soundcard.

[kafros]

I wouldn't call this a bug but my laptop didn't have the driver for audio installed and I wanted to try xenocide on it. It crashes because it can't init the audio driver. Don't know if we want it to ignore this so game is still usable with out a soundcard.

I guess they use a "NullAudio" device for that purpose, tricking the software into thinking that it communicates with a real sound card

[taz0k]

I've found the source of blue screen bug, but I haven't tried to find a solution yet as I don't exactly understand the code in the particular function (GeoPosition.GetAzimuth) in which the source of the bug resides. Someone with more knowledge please check it out.

 

 

The problem is that Math.Sin(d) inside the outer else statement in GeoPosition.GetAzimuth(GeoPosition position) can become ZERO,

which causes "maker" some lines later to become NaN in the statement:

 

float maker = (float)((Math.Sin(position.latitude) - Math.Sin(latitude) * Math.Cos(d)) / (Math.Sin(d) * Math.Cos(latitude)));

 

 

d is calculated as:

 

float d = (float)(2.0f*Math.Asin(Math.Sqrt(

(Math.Sin((latitude-position.latitude)/2.0f))*(Math.Sin((latitude-position.latitude)/2.0f)) +

Math.Cos(latitude)*Math.Cos(position.latitude)

*(Math.Sin((longitude-position.longitude)/2))*(Math.Sin((longitude-position.longitude)/2))

)));

 

Yes, this assignment is the part that I don't understand, so I am not the best candidate to actually solve the bug.

[taz0k]

Problem solved. Darkhomb tipped me to set the divisor to a low number, so I set it to 0.0000001f.

 

After that modification I managed to trigger the same "situation" again (the situation that triggered blue screen before) and I didn't notice any oddities, so it seems to be working.

 

Patch posted under patch topic.

[[dteviot]]

I've found the source of blue screen bug, but I haven't tried to find a solution yet as I don't exactly understand the code in the particular function (GeoPosition.GetAzimuth) in which the source of the bug resides. Someone with more knowledge please check it out.

 

 

The problem is that Math.Sin(d) inside the outer else statement in GeoPosition.GetAzimuth(GeoPosition position) can become ZERO,

which causes "maker" some lines later to become NaN in the statement:

 

float maker = (float)((Math.Sin(position.latitude) - Math.Sin(latitude) * Math.Cos(d)) / (Math.Sin(d) * Math.Cos(latitude)));

 

 

d is calculated as:

 

float d = (float)(2.0f*Math.Asin(Math.Sqrt(

(Math.Sin((latitude-position.latitude)/2.0f))*(Math.Sin((latitude-position.latitude)/2.0f)) +

Math.Cos(latitude)*Math.Cos(position.latitude)

*(Math.Sin((longitude-position.longitude)/2))*(Math.Sin((longitude-position.longitude)/2))

)));

 

Yes, this assignment is the part that I don't understand, so I am not the best candidate to actually solve the bug.

Well, d is the distance between the two positions.

And the purpose of GetAzimuth() is to give the heading between to points.

That is, what compass direction do you need take to get from this to the position that was provided.

Now, thinking a bit more, sin(d) = 0 under two conditions.

d = 0, and d = 180 degrees

Obviously, when d = 0, there is no unique solution, because your start and end position are the same. So any direction will do.

And when d = 180, then the two points are at opposite ends of the earth, e.g. North and South poles. So again, any direction will do.

 

So, correct solution is: if sin(d) is very close to 0, return 0. (Any bearing will do.)

Should be possible to confirm this is the error, by setting up a unit test with a GeoPosition calling GetAzimuth on itself. When point is NOT at the north or south poles, as they're already special cases, with their own handling.

[[dteviot]]

3) Your fighters can attacked a crashed UFO! A new firing circle begins until the first hit, where the ufo either crashes (an already crashed ship crashes, kewl xD) or gets destroyed. You can redo this procedure until you completely destroy it

That's not a bug. That's an additional feature I added.

More specifically, fighters being able to attack a crashed UFO is not a bug, that's a feature I added.

The fact that a crashed UFO crashes again (before it takes off) probably does count as a bug. If you attack a crashed UFO, combat should continue until UFO or aircraft is destroyed or runs out of ammo.

Note, if you don't attack a crashed UFO, it will eventually fly off. But I'd assumed that it repairs would be jury rigged, so if you attacked it again, it wouldn't take much to make it crash.

 

I wouldn't call this a bug but my laptop didn't have the driver for audio installed and I wanted to try xenocide on it. It crashes because it can't init the audio driver. Don't know if we want it to ignore this so game is still usable with out a soundcard.

Yes, that's a bug. However, I think it's going to be a very rare one, and I can't see any solution that is small and non-complicated and efficient (Pick any two.) So I'm going to put this on the list of "bugs I'm not going to fix". That said, if people feel it's going to be common I'll revise the decision. And of course, if anyone wants to try and find an elegant solution, as always, they're free to try.

[red knight]

The solution for that is adding that into the MSI installer to make sure it doesnt install at all... for now that should be kept in the "Known Issues" category. What should be done is throw a SoundEngineException when the Sound Engine cannot initialize.

 

Greetings

Red Knight

[[dteviot]]

The solution for that is adding that into the MSI installer to make sure it doesnt install at all... for now that should be kept in the "Known Issues" category. What should be done is throw a SoundEngineException when the Sound Engine cannot initialize.

 

Greetings

Red Knight

Actually, I think it does throw an error if it can't initialize. However, the exception isn't caught, and the game exits. (Which does look like a crash to the average user.)

[red knight]

Then we are done

 

Greetings

Red Knight

[SupSuper]

Figured I'd post this here: There's a bug with craft handling.

 

For once, in the Sell screen, the game seems to count every CraftType to show the quantity of any one Craft. (eg. having 2 Gryphon-1 and 2 Gryphon-2)

 

For second, even after selling one Gryphon, you can't dismantle any of the landing pads. Sell 2, and you can dismantle one. Sell all the craft, and you can dismantle all the landing pads.

[[dteviot]]

Figured I'd post this here: There's a bug with craft handling.

 

For once, in the Sell screen, the game seems to count every CraftType to show the quantity of any one Craft. (eg. having 2 Gryphon-1 and 2 Gryphon-2)

That's not a bug. You've got 2 items of type "Gryphon"

It's a bit more useful when it comes to soldiers and the like, when it's not so easy to know how many you have.

For second, even after selling one Gryphon, you can't dismantle any of the landing pads. Sell 2, and you can dismantle one. Sell all the craft, and you can dismantle all the landing pads.

That sounds like a bug.

[[dteviot]]

Figured I'd post this here: There's a bug with craft handling.

For second, even after selling one Gryphon, you can't dismantle any of the landing pads. Sell 2, and you can dismantle one. Sell all the craft, and you can dismantle all the landing pads.

That sounds like a bug.

That was a bug. It's now fixed.

[Darkhomb]

Rare equip soldier blue screen bug that seems to happen to me only. I have narrowed it down to the changes in rev 1765. No problems closing in 1764.

 

Further inspection, I updated to 1765 and reverted EquipSoldierScreen back to 1764, again works fine.

 

The only code difference is this.

		/// Removes the frame from the display
	/// </summary>
	protected override void Dispose(bool disposing)
	{
		if (disposing)
		{
			if (scene != null)
			{
				scene.Dispose();
				scene = null;
			}
		}
		base.Dispose(disposing);
	}

	/// <summary>

 

And just to test, I updated to latest version (1781) and took out that code. Works fine. Curious why it works for everyone else.

Edited January 2, 2008 by Darkhomb

[red knight]

Rare equip soldier blue screen bug that seems to happen to me only. I have narrowed it down to the changes in rev 1765. No problems closing in 1764.

 

Further inspection, I updated to 1765 and reverted EquipSoldierScreen back to 1764, again works fine.

 

The only code difference is this.

		/// Removes the frame from the display
	/// </summary>
	protected override void Dispose(bool disposing)
	{
		if (disposing)
		{
			if (scene != null)
			{
				scene.Dispose();
				scene = null;
			}
		}
		base.Dispose(disposing);
	}

	/// <summary>

 

And just to test, I updated to latest version (1781) and took out that code. Works fine. Curious why it works for everyone else.

 

Make sure that the dispose methods isnt been called multiple times; with that you will narrow its scope. And see what happens if you take out the scene=null or scene.Dispose and combinations of those 2.

 

Greetings

Red Knight

[Darkhomb]

Bluescreen is I take out scene = null;

 

works if I take out scene.Dispose();

 

[red knight]

Sounds like the dispose is unregistering the screen while it is still in use... mhhh interesting. Post a Call Stack when it gets called ... you can get it putting a breakpoint and copying the Call Stack window into notepad

 

Greetings

Red Knight

[[dteviot]]

Sounds like the dispose is unregistering the screen while it is still in use... mhhh interesting. Post a Call Stack when it gets called ... you can get it putting a breakpoint and copying the Call Stack window into notepad

 

Greetings

Red Knight

What it tells me is that the problem is in EquipSoldierScene.Dispose()

looking at the code,

		/// <summary>
	/// Implement IDisposable
	/// </summary>
	/// <param name="disposing">false when called from a finalizer</param>
	protected virtual void Dispose(bool disposing)
	{
		if (disposing)
		{
			if (spriteBatch != null)
			{
				spriteBatch.Dispose();
				spriteBatch = null;
			}
			if (content != null)
			{
				content.Dispose();
				content = null;
			}
		}
	}

I'll bet 2 hours of sleep tonight the culprit is this bit:

				if (content != null)
			{
				content.Dispose();
				content = null;
			}

Darkhomb, if you can confirm that removing these lines makes the bluescreen go away, I believe I know how to properly fix the problem.

[Darkhomb]

didnt work, i have to go thought will try tomorrow.

[[dteviot]]

didnt work, i have to go thought will try tomorrow.

Scratches head.

Well, see if removing

				if (spriteBatch != null)
			{
				spriteBatch.Dispose();
				spriteBatch = null;
			}

works. (If should do, it's the only other code in the function.)

If it doesn't, then remove all code from inside the function. Just to confirm we ARE in the right place.

[Darkhomb]

I put back the other part and removed this only, it now works.

 

				if (spriteBatch != null)
			{
				spriteBatch.Dispose();
				spriteBatch = null;
			}

 

 

I just tried latest build on my laptop (vista x64) and it works fine. I have no clue why this is not working on mine.

Edited January 3, 2008 by Darkhomb

[[dteviot]]

Next thing to try for Darkhomb's blue screen problem with Equip Soldier screen.

Want to find out if the dispose is killing CeGui, or the entire graphics system.

Not easy to tell, because closing Equip Soldier Screen returns to the Soldier List screen, which is purely CeGUI.

So, solution is modify EquipSoldierScreen so on close button, it disposes of things, then creates a new EquipSoldierScreen.

change line in Xenocide\Source\UI\Screens\EquipSoldierScreen.cs

from:

				ScreenManager.ScheduleScreen(new SoldiersListScreen(SelectedOutpostIndex()));

to

				ScreenManager.ScheduleScreen(new EquipSoldierScreen(soldiers, Soldier));

When close is pressed, does the whole screen go blue, or is it just the buttons that are lost?

 

Another thing to check, after blue screen occurs, see if EquipSoldierScreen.Draw() is being pumped.

Probably easiest way of doing this is once blue screen occurs, put a breakpoint on first line of Draw() function, and see if execution stops at breakpoint.

Edited January 12, 2008 by dteviot

[Darkhomb]

Ok when I change that, it works how it should, i see everything. I know it redraws the screen because the font problem I told you about earlier (loses a line when clicked). RK had me put some breakpoints in places I don't remember how far we got though.

[[dteviot]]

Ok when I change that, it works how it should, i see everything. I know it redraws the screen because the font problem I told you about earlier (loses a line when clicked). RK had me put some breakpoints in places I don't remember how far we got though.

Scratches head. That's weird. If theory is correct, we should either loose the buttons, or the whole screen.

With latest build 1788, StatisticsScreen disposes of it's sprite batch. What happens when that screen is closed?

[Darkhomb]

Works fine.

[[dteviot]]

Works fine.

Hmm. Could it be an interaction between disposing the sprite batch, AND what the parent screen does on return?

Test, modify the List Soldiers screen to go to the statistics screen when "equip soldier" is called, and modify the statistics screen to go to the List Soldiers screen when it's closed. (i.e. Replace the Equip Soldier screen in sequence with Statistics Screen.)

Does the blue screen still appear?

[Darkhomb]

can you tell me exactly which lines you would like me to replace?

[[dteviot]]

can you tell me exactly which lines you would like me to replace?

In StatisticsScreen.cs, replace

		private void OnGeoscapeButton(object sender, CeGui.GuiEventArgs e)
	{
		ScreenManager.ScheduleScreen(new GeoscapeScreen());
	}

with

		private void OnGeoscapeButton(object sender, CeGui.GuiEventArgs e)
	{
		ScreenManager.ScheduleScreen(new SoldiersListScreen(0));
	}

 

In SoldiersListScreen.cs, replace

		private void ShowEquipSoldiersScreen()
	{
		if (null != SelectedSoldier)
		{
			ScreenManager.ScheduleScreen(new EquipSoldierScreen(soldiers, SelectedSoldier));
		}
	}

with

		private void ShowEquipSoldiersScreen()
	{
			ScreenManager.ScheduleScreen(new StatisticsScreen();
	}

[Darkhomb]

I click stats it takes me to stats. I click geoscape it takes be to the soldier list but not the equip screen, i click equip takes me back to stats.

[[dteviot]]

I click stats it takes me to stats. I click geoscape it takes be to the soldier list but not the equip screen, i click equip takes me back to stats.

That's doing what I was after, that is, replacing the EquipSoldier screen with the StatisticsScreen.

However, result isn't what I expected.

Looking into matter a bit more, problem is StatisticsScreen DOESN'T call Dispose(). StatisticsScene has a Dispose(), but the StatisticsScreen doesn't call it. A bug that I'll need to fix. Which renders the previous experiment invalid.

Could you add this code to the StatisticsScreen and try again?

		/// <summary>
	/// Removes the frame from the display
	/// </summary>
	protected override void Dispose(bool disposing)
	{
		try
		{
			if (disposing)
			{
				if (scene != null)
				{
					scene.Dispose();
					scene = null;
				}
			}
		}
		finally
		{
			base.Dispose(disposing);
		}
	}

[Darkhomb]

ok that did it. Click on geoscape button now have blue screen.

[[dteviot]]

OK, to summarize the data we have, my deductions and where to go from here.

• Initial problem reported by Darkhomb. When closing the equip soldier screen (and returning to the list soldiers screen) the list soldier screen doesn't show, it's just an empty "blue screen".
  
• No one else is seeing the problem. (Darkhomb is using an 8800 GTS, no one else is.)
  
• After some trial and error, it was found that if the SpriteBatch used on the equip soldier scene was not disposed, the list soldier screen would behave correctly.
  
• The only other screen that uses a SpriteBatch is the StatisticsScreen. Interestingly, when closed, it returns to the GeoscapeScreen, and Darkhomb reports no problems on closing the StatisticsScreen.
  
• Experiment 1: I modified the Equip Soldier screen to go to the Geoscape screen when closed. The result was the Geoscape screen appeared.
  
• Experiment 2: Modified the Statistics screen to go to the list soldier screen when closed. The result was the the "blue screen" when statistics screen was closed. Commenting out the "SpriteBatch.Dispose()" made the list soldier screen appear.
  
• Conclusion: It's not just Disposing the SpriteBatch that's the problem, it's an interaction between the ListSoldier screen and SpriteBatch.Dispose.
  
• Hypothesis: The obvious difference between Geoscape and ListSoldier screens is that the Geoscape has a 3D scene which it draws before running any CeGui code. So, I suspect the problem is when SpriteBatch is disposed, it's changing some of the render state. When we draw the 3D scene, we reset the render states, and then CeGui manages to render. This could be tested by commenting out the 3D scene drawing code in the Geoscape and see if the blue screen appears when the StatisticsScreen is closed. e.g. these lines in PolarScreen.cs:
  

  		public override void Draw(GameTime gameTime, GraphicsDevice device)
  	{
  		scene.Draw(gameTime, device, scenewindow.Rect);
  	}

  
  

• If this confirms problem, a possible work around is add the various "initialize scene" commands to ListSolider, until we find the ones that make the blue screen go away. This would hopefully allow us to know exactly what we're looking for in SpriteBatch.Dispose().
  
• Use Reflector to examine SpriteBatch.Dispose(), is there anything in there that looks suspect?
  
• Alternate workaround: Have a single, global SpriteBatch, and use it with all screens. Don't dispose of it until we close game.
  

[[dteviot]]

How to set up reference DirectX renderer. Use to check if driver is responsible for drawing artifacts.

http://www.riemers.net/eng/Tutorials/XNA/C...ence_device.php

[[dteviot]]

• The alien (and other combatant models on battlescape) need a scale so that they can be set to correct size (current code isn't good enough.)
  
• Models also need to be correctly centered in cells.
  
• if you go to sound options, change settings and hit ok, everything is fine, when you go back into options its back at full volume. The value is saved, but when it does a check for the checkbox after you reopen it, it sets its value to 1f.
  

 

edit: fixed a couple of the bugs.

Edited March 29, 2008 by dteviot