Author Topic: Prerelease/Expans 2.001ZE (Hive Golem, New Save Format, Train Population Nerf)  (Read 12820 times)

Offline x4000

  • Chris McElligott Park, Arcen Founder and Lead Dev
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,651
I'm wondering, will FRD be fixed in the next prerelease?

What's wrong with it, other than the rally posts thing?
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 HellishFiend

  • Hero Member Mark II
  • *****
  • Posts: 758
I'm wondering, will FRD be fixed in the next prerelease?

What's wrong with it, other than the rally posts thing?

It's described in this topic:
http://arcengames.com/forums/index.php/topic,2604.0.html

I've noticed them acting like that before, but never put my finger on the fact that its a glitch until I read that topic.
Time to roll out another ball of death.

Offline Oewyn

  • Sr. Member
  • ****
  • Posts: 330
new exception:

12/22/2009 11:36:09 PM (2.001ZE)
-----------------------------------Application_ThreadException-----------------------------------System.InvalidOperationException: Collection was modified; enumeration operation may not execute.
   at System.ThrowHelper.ThrowInvalidOperationException(ExceptionResource resource)
   at AIWar.ForegroundObject.MovePlayerUnit(Boolean RecalculateFull) in C:\vcprojs\AIWar\Framework\ForegroundObject.cs:line 6648
   at AIWar.GameForm.RunNextCycle(Boolean DoRendering, Boolean DoScrollingAndInput) in C:\vcprojs\AIWar\GameFormParts\GameLoop.cs:line 1125
   at AIWar.GameForm.gameLoop() in C:\vcprojs\AIWar\GameFormParts\GameLoop.cs:line 245
   at AIWar.GameForm.GameForm_Load(Object sender, EventArgs e) in C:\vcprojs\AIWar\GameFormParts\Startup.cs:line 241
   at System.Windows.Forms.Form.OnLoad(EventArgs e)
   at System.Windows.Forms.Form.OnCreateControl()
   at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
   at System.Windows.Forms.Control.CreateControl()
   at System.Windows.Forms.Control.WmShowWindow(Message& m)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
   at System.Windows.Forms.ContainerControl.WndProc(Message& m)
   at System.Windows.Forms.Form.WmShowWindow(Message& m)
   at System.Windows.Forms.Form.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Do you have a savegame that is able to trigger this?  I can't find anything that seems amiss in the code here, so I'm not sure precisely what is causing it.

Here is a save, it happens just before/at the bomber waves.

Also, i noticed several buildings have the word "false," on them, see "Pugifat's Homeworld", crystal manufacturies.

Offline Fiskbit

  • Arcen Games Contractor
  • Master Member Mark III
  • *****
  • Posts: 1,752
Yeah, FRD mode has been broken for a while now, I think. I moved that to recommend critical because it's really important, but I think that may have been a bad idea as it currently seems like the Recommendations forum is where topics go to die. :P Currently, ships in FRD seem to be unwilling to stick to targets and seem to like going to ships that are really far away.

When that gets fixed up, I think that a single other change to ship intelligence will make FRD mode (and every other kind of chase-and-attack mode, including simple attack commands) really effective, which is making it so that ships chase enemies before those enemies leave their range, so they can keep firing while chasing them (ideally, they'd chase with the enemy within their range, but outside of the enemy's range if possible). This is especially useful for ships of the same speed, since right now they have to wait for their targets to stop or change direction to get a shot off, and then resume the pointless chase a moment later.
Have ideas or bug reports for one of our games?  Click here to get started with Mantis for Suggestions and Bug Reports.  Thanks for helping to make our games better!

Offline Spikey00

  • Lord of just 5 Colony Ships
  • Master Member Mark II
  • *****
  • Posts: 1,704
  • And he sayeth to sea worm, thou shalt wriggle
I sure hope so--either way though, knowing Chris it will be coming soon.
I'd take a sea worm any time over a hundred emotionless spinning carriers.
irc.appliedirc.com / #aiwar
AI War Facebook
AI War Steam Group

Offline x4000

  • Chris McElligott Park, Arcen Founder and Lead Dev
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,651
Yeah, FRD mode has been broken for a while now, I think. I moved that to recommend critical because it's really important, but I think that may have been a bad idea as it currently seems like the Recommendations forum is where topics go to die. :P Currently, ships in FRD seem to be unwilling to stick to targets and seem to like going to ships that are really far away.

Yeah, I never look in those -- I just don't think of it, I'm keeping an eye on the other forums.  Instead of doing it that way, with those "recommend" forums, how about just flagging them if they seem to be critical, etc?  I'm taking a look at this issue now, ugh -- first I'

When that gets fixed up, I think that a single other change to ship intelligence will make FRD mode (and every other kind of chase-and-attack mode, including simple attack commands) really effective, which is making it so that ships chase enemies before those enemies leave their range, so they can keep firing while chasing them (ideally, they'd chase with the enemy within their range, but outside of the enemy's range if possible). This is especially useful for ships of the same speed, since right now they have to wait for their targets to stop or change direction to get a shot off, and then resume the pointless chase a moment later.

There is no CPU-friendly way that I can think of to handle this, honestly.  It would add range checks and movement angle checks and such that I don't think are going to make enough of a difference to really make this worthwhile.  What might be an interesting alternative is to make the AI ships always be slower than the player ships.  Say, reduce the AI ship speed by 20% across the board (of course speed boosters would negate that, but those are more rare).  Might make defense a little easier to manage in general, in a way that might enhance the strategic possibilities (rather than just being swarmed when there are too many, etc).  Thoughts?

Also, Oewyn, thanks for your savegame, I'll take a look at that tonight, too.
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 quickstix

  • Sr. Member
  • ****
  • Posts: 297
  • Buy Now
An AI unit speed reduction sounds interesting. When AI ships get past my defenses and start swarming everywhere, they tend to get away from my ships pretty quickly, and I end up thinking more about how to cut and corner AI ships off and less about whether I can chase them around. This kind of makes FRD less useful for me, as taking control of my ships is a more efficient and protective policy than having my ships chase after AI ships, as my ships don't catch up before the AI starts destroying infrastructure.

I suppose the major balancing point lies on whether players gain a significant advantage when they themselves are on the attack on an AI planet. Is the advantage there bigger than the one AI players get from being able to easily swarm and wreak havok on a planet where a player is relying on FRD?

In my opinion, it might be worth a test.

Offline Spikey00

  • Lord of just 5 Colony Ships
  • Master Member Mark II
  • *****
  • Posts: 1,704
  • And he sayeth to sea worm, thou shalt wriggle
They still would wander mainly aimlessly... I don't know if a speed reduction would be much of a difference (and the main gameplay would be affected).
I'd take a sea worm any time over a hundred emotionless spinning carriers.
irc.appliedirc.com / #aiwar
AI War Facebook
AI War Steam Group

Offline x4000

  • Chris McElligott Park, Arcen Founder and Lead Dev
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,651
An AI unit speed reduction sounds interesting. When AI ships get past my defenses and start swarming everywhere, they tend to get away from my ships pretty quickly, and I end up thinking more about how to cut and corner AI ships off and less about whether I can chase them around. This kind of makes FRD less useful for me, as taking control of my ships is a more efficient and protective policy than having my ships chase after AI ships, as my ships don't catch up before the AI starts destroying infrastructure.

I suppose the major balancing point lies on whether players gain a significant advantage when they themselves are on the attack on an AI planet. Is the advantage there bigger than the one AI players get from being able to easily swarm and wreak havok on a planet where a player is relying on FRD?

In my opinion, it might be worth a test.

To be honest, on defense a speed reduction might actually be a help to the AI players on their planets.  Might make them more clustered and thus more effective.  Of course, not the melee ships, but still.  Actually, in thinking about this more, I think perhaps the opposite might work better -- increasing the speed of the players ships, rather than decreasing the AI player's ship speeds.  That might speed up games without making the game more difficult (since it is only sped up for human players).

Spikey00 -- the "wander aimlessly" is a separate issue that has actually already been fixed for the next release. Fiskbit was referring to how AI ships are able to get away from player ships in FRD by getting out of their range and then staying out of their range based on how the player ships give pursuit.
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
As per fortresses - perhaps make them a rally point/longer ranged repair station?  no tugs or anything...

You know, I like both of those ideas.  I'll also add that in for the next version.  Having the fortresses be really multi-functional, rather than just beefy combat vessels, should make them more interesting in general.  Good call!
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 quickstix

  • Sr. Member
  • ****
  • Posts: 297
  • Buy Now
To be honest, on defense a speed reduction might actually be a help to the AI players on their planets.  Might make them more clustered and thus more effective.  Of course, not the melee ships, but still.  Actually, in thinking about this more, I think perhaps the opposite might work better -- increasing the speed of the players ships, rather than decreasing the AI player's ship speeds.  That might speed up games without making the game more difficult (since it is only sped up for human players).

That sounds like an interesting idea. Slowing down might keep the ships too clumped around guard posts and such, which encourages brute force a bit more. Making player ships a bit faster still keeps the AI somewhat grouped around defensive positions and dangerous when they slip through your defenses, but encourages player strategies like bluffs and distractions. All in addition to making defense management more efficient.

Hmm, interesting ideas.

Offline x4000

  • Chris McElligott Park, Arcen Founder and Lead Dev
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,651
To be honest, on defense a speed reduction might actually be a help to the AI players on their planets.  Might make them more clustered and thus more effective.  Of course, not the melee ships, but still.  Actually, in thinking about this more, I think perhaps the opposite might work better -- increasing the speed of the players ships, rather than decreasing the AI player's ship speeds.  That might speed up games without making the game more difficult (since it is only sped up for human players).

That sounds like an interesting idea. Slowing down might keep the ships too clumped around guard posts and such, which encourages brute force a bit more. Making player ships a bit faster still keeps the AI somewhat grouped around defensive positions and dangerous when they slip through your defenses, but encourages player strategies like bluffs and distractions. All in addition to making defense management more efficient.

Hmm, interesting ideas.

In practice, so far it feels a lot more fluid and fun to me with this speed bump, actually.  I'm really digging this, myself.
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
Here is a save, it happens just before/at the bomber waves.

Also, i noticed several buildings have the word "false," on them, see "Pugifat's Homeworld", crystal manufacturies.


This is fixed for ZF.  From the look of it, this was caused by area mines blowing up AI ships in a system where there was also a regenerator train.  No wonder this was not seen more commonly!
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 Fiskbit

  • Arcen Games Contractor
  • Master Member Mark III
  • *****
  • Posts: 1,752
I feel like there could be ways to 'cheat' to get my proposed chase feature in there cheaply. Currently, a ship chases another ship when that ship leaves its range, but it could have a range smaller than its actual firing range that it uses to decide if it starts to chase enemy ships. If the targeted ship is in range and not moving, don't move toward it, but if it is outside the firing range or is moving and is outside the smaller range, then move toward it like you would if it were outside your full range. This smaller range could be a temporary thing set based on the range of the ship being attacked, or it could be some value specific to each type of ship (or maybe always be something like half the larger range). I feel like this could work really well without being too heavy on the cycle use.
Have ideas or bug reports for one of our games?  Click here to get started with 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
I feel like there could be ways to 'cheat' to get my proposed chase feature in there cheaply. Currently, a ship chases another ship when that ship leaves its range, but it could have a range smaller than its actual firing range that it uses to decide if it starts to chase enemy ships. If the targeted ship is in range and not moving, don't move toward it, but if it is outside the firing range or is moving and is outside the smaller range, then move toward it like you would if it were outside your full range. This smaller range could be a temporary thing set based on the range of the ship being attacked, or it could be some value specific to each type of ship (or maybe always be something like half the larger range). I feel like this could work really well without being too heavy on the cycle use.

It's based on the hit percent chance it has, not the range, but basically the same idea.  Problem is, this is the same logic that causes ships to stop "at range" for firing at other ships, so even if we cheated this would have very negative side effects like potentially causing frigates to walk into the range of special forces guard posts when they shouldn't, and things like that.  Of course, you can do a bunch of other gyrations to try to get to the specific cases where this would work right and wouldn't interfere with "at range" firing or anything else, but I'm not real motivated to work on that problem, honestly.  Simply adjusting the speed, which I've already done, is a faster solution in terms of programming time and CPU cost, has other ancillary benefits, and doesn't have any possibility of interfering with the "at range" logic.  At this point it sounds like you're trying to solve the problem just to solve the problem; or am I missing something?
Have ideas or bug reports for one of our games?  Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!