Author Topic: [Solved] Potential 1.013D Bugs  (Read 5851 times)

Offline Kalzarius

  • Sr. Member Mark II
  • ****
  • Posts: 422
[Solved] Potential 1.013D Bugs
« on: August 04, 2009, 09:36:51 pm »
I don't recall seeing any reports relating to these bugs or release notes in more current pre-releases regarding them, so I am including them here in the case they have not yet been spotted.

Lazy Turrets

Turrets right next to an enemy won't fire if another turret's shot will destroy it.  This even happens when that other turret is a sniper turret on the opposite side of the planet.  A great deal of damage can be done by these ships if it takes too long for that shot to reach them.  Could the priority be tweaked so that this doesn't happen?

The Incredible Seeking Minor Electric Shocks

I don't recall precisely what type of shot it was (I think it was a minor electric shock from an anti-starship arachnid), but I swear one or more projectiles from a battle followed my teleport battle stations through a wormhole.  I had them parked next to my engineers when all of the sudden, three of the teleport stations exploded.  It was also the case that, in the enemy system, there were literally hundreds of shots still following the teleport stations from one side of the planet to the other.  If you need a save, I'll toss one of our recent ones up.

Attack Formation Timer\

Whenever we have a 'attack forming wherever' message, the timer starts at 8:00 and then goes directly to 3:59.  Where did the other 4 minutes go, or were they even there to begin with?

Galaxy Map Background

When you switch through planets using control groups on the galaxy map, the background of the galaxy map changes.  Is this intended behaviour?
« Last Edit: September 25, 2009, 09:34:10 am by Fiskbit »

Offline x4000

  • Chris McElligott Park, Arcen Founder and Lead Dev
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,651
Re: Potential 1.013D Bugs
« Reply #1 on: August 04, 2009, 10:55:03 pm »
I don't recall seeing any reports relating to these bugs or release notes in more current pre-releases regarding them, so I am including them here in the case they have not yet been spotted.

Thanks!

Lazy Turrets

Turrets right next to an enemy won't fire if another turret's shot will destroy it.  This even happens when that other turret is a sniper turret on the opposite side of the planet.  A great deal of damage can be done by these ships if it takes too long for that shot to reach them.  Could the priority be tweaked so that this doesn't happen?

This is actually by design, to an extent.  If a ship has more damage incoming than its health, then for the sake of efficiency the other ships won't shoot at it.  I don't think there is much here that I can change without breaking something else or causing too many checks and thus more CPU overhead.  Right now these numbers are all handled in aggregate, which is a lot more efficient, but which does not differentiate between shots from snipers or shorter-range ones.  I could put in code to ignore sniper-type shots in this scenario, but then you get into issues with fast-moving ships (like autocannon minipods) fleeing from missiles that are slower to catch up.

The important thing to remember is that this works both ways, so you get the benefit of this when you are attacking the enemy.  Given how many sniper turrets AIs tend to have, I think this probably works in your favor more often than theirs.  It's a tough one, and I imagine I'll revisit it at some point, but at the moment a solution is just not coming to me (this has come up before, if you can't tell -- in relation to the autocannons, not snipers, though).

The Incredible Seeking Minor Electric Shocks

I don't recall precisely what type of shot it was (I think it was a minor electric shock from an anti-starship arachnid), but I swear one or more projectiles from a battle followed my teleport battle stations through a wormhole.  I had them parked next to my engineers when all of the sudden, three of the teleport stations exploded.  It was also the case that, in the enemy system, there were literally hundreds of shots still following the teleport stations from one side of the planet to the other.  If you need a save, I'll toss one of our recent ones up.

If you have a save that demonstrates this, by all means toss it up.  But I've just gone through all the relevant code, and there's no way a shot will change planets -- there is no such logic anywhere on shots.  Most likely what happened is that the shots hit right in the brief second where the battle station  is invisible or nearly so, but not flipped over to the new planet just yet.  Then as it is hit, it pops over and explodes there.

There's also a chance that the shot had not quite yet registered that the battle station was on the other planet, and thus hit it from the shot's current planet.  I've made a code change for the upcoming J version that should prevent this issue if that's what it was.

Attack Formation Timer\

Whenever we have a 'attack forming wherever' message, the timer starts at 8:00 and then goes directly to 3:59.  Where did the other 4 minutes go, or were they even there to begin with?

This is a bug.  I'll look into it, but basically it is out of sync somewhere.  In a past version it was setting something like 10,000 hours of time on the timers, so I put in logic to cap this down to the actual supposed starting value.  Then evidently I may have tweaked the starting values since then, and just did not adjust the cap logic.  Added to the short-term list:  http://arcengames.com/forums/index.php/topic,612.0.html

Galaxy Map Background

When you switch through planets using control groups on the galaxy map, the background of the galaxy map changes.  Is this intended behaviour?

Wow, awesome catch -- that is super subtle, and was definitely not intended.  I've fixed that for J.  Thanks!
« Last Edit: September 25, 2009, 09:32:19 am by Fiskbit »
Have ideas or bug reports for one of our games?  Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Offline Kalzarius

  • Sr. Member Mark II
  • ****
  • Posts: 422
Re: Potential 1.013D Bugs
« Reply #2 on: August 05, 2009, 12:13:12 am »
Quote
If you have a save that demonstrates this, by all means toss it up.  But I've just gone through all the relevant code, and there's no way a shot will change planets -- there is no such logic anywhere on shots.  Most likely what happened is that the shots hit right in the brief second where the battle station  is invisible or nearly so, but not flipped over to the new planet just yet.  Then as it is hit, it pops over and explodes there.

I've attached a singleplayer save (from 1.013I) so you can see that the shots are trailing from one side of the planet to the other.  Just grab the battle stations from Onnokosav and take them into Erchuro to one of the command posts.  It shouldn't be too hard to get shot at.  Then teleport to the other side of the planet and watch them follow.

Quote
There's also a chance that the shot had not quite yet registered that the battle station was on the other planet, and thus hit it from the shot's current planet.  I've made a code change for the upcoming J version that should prevent this issue if that's what it was.

I believe this indeed the case.  I should mention, however, that I watched the shots trail the entire planet to the wormhole, where they disappeared on arrival.  They then hit the ships that were in the other planet, parked away from the gate and repaired prior to their arrival (before the shots even reached the gate).  A couple exploded and almost all of them were damaged from the attack.  Note that the shots were not visible on the other side, which makes me believe it is the delayed reaction you mention.

Focus Issues

When I first started this post, I was sitting paused at the planet screen after alt-tabbing to Firefox.  There was major lag (both keyboard and mouse were sluggish) until I brought the game into the galaxy map.  I can only think the game is still rendering despite not being visible.

Offline eRe4s3r

  • Core Member Mark II
  • *****
  • Posts: 2,825
Re: Potential 1.013D Bugs
« Reply #3 on: August 05, 2009, 11:33:32 am »
Just to throw that in, of course the game is still rendering when you alt-tab or pause and then alt-tab. This is not a bug but a feature (You can still give orders during pause) i can for example (and do it right now) let the game play in the background and write this post ;) And move my mouse pointer over the warning icon and click on it and instantly be back in focus. You can also alt tab out of the game when hosting and the game will continue to work for all clients.

Do you have a single core cpu?

I can confirm the trailing shots though, take any teleporting ship and get some sniper shots at you and then you can play catch me with them ;)
« Last Edit: August 05, 2009, 11:54:09 am by eRe4s3r »
Proud member of the Initiative for Bigger Weapons EV. - Bringer of Additive Blended Doom - Vote for Lore, get free cookie

Offline Kalzarius

  • Sr. Member Mark II
  • ****
  • Posts: 422
Re: Potential 1.013D Bugs
« Reply #4 on: August 05, 2009, 06:54:40 pm »
Quote
I can confirm the trailing shots though, take any teleporting ship and get some sniper shots at you and then you can play catch me with them

The sniper shots are supposed to have unlimited range.  Missiles, MLRS, bombs, and minor electric shocks should probably die instead of trailing ships ad infinitum.

Quote
Just to throw that in, of course the game is still rendering when you alt-tab or pause and then alt-tab. This is not a bug but a feature (You can still give orders during pause) i can for example (and do it right now) let the game play in the background and write this post And move my mouse pointer over the warning icon and click on it and instantly be back in focus. You can also alt tab out of the game when hosting and the game will continue to work for all clients.

Do you have a single core cpu?

I do have a dual core system and there is so much lag that individual letters do not come in as I type, but instead whole words.  I realize that it still processes while not focused (which is fine with me); however, if it's not being displayed, it should not be rendering and causing this problem.  Going into the galaxy map prevents this lag, which suggests to me that this is caused by rendering, because it will still be doing all of the other game processing while at the galaxy map.

Offline x4000

  • Chris McElligott Park, Arcen Founder and Lead Dev
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,651
Re: Potential 1.013D Bugs
« Reply #5 on: August 05, 2009, 08:21:36 pm »
Quote
I can confirm the trailing shots though, take any teleporting ship and get some sniper shots at you and then you can play catch me with them

The sniper shots are supposed to have unlimited range.  Missiles, MLRS, bombs, and minor electric shocks should probably die instead of trailing ships ad infinitum.

All shots have unlimited range once they are chasing a ship, they only die if they get out of range of the target at any point.  So if the shot is chasing over a long distance, as long as it stays within range the whole time it will hit just fine.

Quote
Just to throw that in, of course the game is still rendering when you alt-tab or pause and then alt-tab. This is not a bug but a feature (You can still give orders during pause) i can for example (and do it right now) let the game play in the background and write this post And move my mouse pointer over the warning icon and click on it and instantly be back in focus. You can also alt tab out of the game when hosting and the game will continue to work for all clients.

Do you have a single core cpu?

I do have a dual core system and there is so much lag that individual letters do not come in as I type, but instead whole words.  I realize that it still processes while not focused (which is fine with me); however, if it's not being displayed, it should not be rendering and causing this problem.  Going into the galaxy map prevents this lag, which suggests to me that this is caused by rendering, because it will still be doing all of the other game processing while at the galaxy map.

The game cannot tell whether you have other windows in front of it (such as when you are typing), or if you have just brought another window in front of it to temporarily lose focus.  A lot of people with multiple monitors or big monitors play with the game windowed or just on one screen, and then click over to the other screen to do something else like type in a chat program as they go.

You shouldn't be seeing that severe of lag, I don't know what would cause that.  But I can't make it stop rendering when the application doesn't have focus without causing a loss of functionality for a fair subset of players.  I could make a settings option for "halt rendering when application loses focus" if you want, but that's about all I can think of.

Bear in mind that this is not a true fullscreen application like a lot of games you might be thinking of.  This application runs in windowed mode at all times, only giving the appearance of fullscreen, so the render device is not lost and rebuilt when you tab out and back in, unlike most other applications.  This makes for extremely speedy alt-tabbing, but does not lessen the load on the GPU/CPU when the game is in an idle state (because it never goes into an idle state).

On thing that I will go ahead and put in the L release is this:

"The AI thread will no longer recieve "turn starting" messages when the game is paused, which will prevent it from issuing a bunch of orders while the game is paused and nothing is going on."

I think that may help with the load from the second thread, which may be a part of what you are experiencing...
Have ideas or bug reports for one of our games?  Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Offline x4000

  • Chris McElligott Park, Arcen Founder and Lead Dev
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,651
Re: Potential 1.013D Bugs
« Reply #6 on: August 05, 2009, 09:36:18 pm »
I've attached a singleplayer save (from 1.013I) so you can see that the shots are trailing from one side of the planet to the other.  Just grab the battle stations from Onnokosav and take them into Erchuro to one of the command posts.  It shouldn't be too hard to get shot at.  Then teleport to the other side of the planet and watch them follow.

Awesome, thanks!  There was definitely a bug there, and I was able to duplicate it.  The upcoming version L will have the fix in for that one.

I believe this indeed the case.  I should mention, however, that I watched the shots trail the entire planet to the wormhole, where they disappeared on arrival.  They then hit the ships that were in the other planet, parked away from the gate and repaired prior to their arrival (before the shots even reached the gate).  A couple exploded and almost all of them were damaged from the attack.  Note that the shots were not visible on the other side, which makes me believe it is the delayed reaction you mention.

Same deal here, I saw it and have now fixed it (in upcoming L).  There was a bug that I had not realized was there -- I had very few good test cases for this before, but your savegame was awesome for testing this.  Thanks for your help!
Have ideas or bug reports for one of our games?  Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Offline Kalzarius

  • Sr. Member Mark II
  • ****
  • Posts: 422
Re: Potential 1.013D Bugs
« Reply #7 on: August 05, 2009, 11:18:10 pm »
You shouldn't be seeing that severe of lag, I don't know what would cause that.  But I can't make it stop rendering when the application doesn't have focus without causing a loss of functionality for a fair subset of players.  I could make a settings option for "halt rendering when application loses focus" if you want, but that's about all I can think of.

Might I suggest instead a "minimize" button that essentially tells the game to stop rendering until its focus is restored?

On thing that I will go ahead and put in the L release is this:

"The AI thread will no longer recieve "turn starting" messages when the game is paused, which will prevent it from issuing a bunch of orders while the game is paused and nothing is going on."

I think that may help with the load from the second thread, which may be a part of what you are experiencing...

The lag I experience disappears entirely upon going to the galaxy map, which is why I assume it has to do with rendering, or at least is related to the planet map.

My laptop has an Intel GPU, so I wouldn't be surprised if it's just lagging because it doesn't like rendering to an offscreen surface.

Offline x4000

  • Chris McElligott Park, Arcen Founder and Lead Dev
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,651
Re: Potential 1.013D Bugs
« Reply #8 on: August 05, 2009, 11:21:54 pm »
Might I suggest instead a "minimize" button that essentially tells the game to stop rendering until its focus is restored?

Added to my short-term list:  http://arcengames.com/forums/index.php/topic,630.0.html

The lag I experience disappears entirely upon going to the galaxy map, which is why I assume it has to do with rendering, or at least is related to the planet map.

My laptop has an Intel GPU, so I wouldn't be surprised if it's just lagging because it doesn't like rendering to an offscreen surface.

Yeah, that's probably what it is, then.  Hmm.  A minimize button would definitely fix it, though.
Have ideas or bug reports for one of our games?  Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Offline Kalzarius

  • Sr. Member Mark II
  • ****
  • Posts: 422
Potential 1.013L Bugs
« Reply #9 on: August 06, 2009, 03:43:29 am »
I noticed this a few times with some of the previous 1.013 pre-releases, but until now I haven't had a save to demonstrate it.  Attached is a saved game you may have to leave running for a few minutes, but the bug I'm encountering is that the incoming raid or attack formation sound is playing, but no timer is being displayed and no raid occurs.  Is this intended behaviour or is it a bug?

Offline x4000

  • Chris McElligott Park, Arcen Founder and Lead Dev
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,651
Re: Potential 1.013L Bugs
« Reply #10 on: August 06, 2009, 10:35:09 am »
I noticed this a few times with some of the previous 1.013 pre-releases, but until now I haven't had a save to demonstrate it.  Attached is a saved game you may have to leave running for a few minutes, but the bug I'm encountering is that the incoming raid or attack formation sound is playing, but no timer is being displayed and no raid occurs.  Is this intended behaviour or is it a bug?

Well, this is a bug, but it is also intended behavior.  :D  Awesome savegame by the way, that let me duplicate it really easily, and a fix will be in M.

So here's the deal, basically, it was incorrectly triggering this logic:  http://arcengames.com/mediawiki/index.php?title=AI_War_-_No_Warning_On_Waves%3F

It was triggering that logic for one of the AIs, but not the other, because they AIs were mistakenly only warping into your planets from planets that they individually controlled (not by planets that the AI team as a whole controls).  So in situations where you have only one warp gate adjacent to your planets, one of the AIs would start coming in with no warning from their other planets on the higher difficulties.  This bug has been in there for a while, incidentally.  Thanks for reporting it!  You're quite the bug-hunter. :)
Have ideas or bug reports for one of our games?  Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

 

SMF spam blocked by CleanTalk