Outpost 2 suddenly closes when moving around minimap (1.3.0.8)

[steev]

I have supplied a video showing what happens. Moving the minimap faster seems to trigger it quicker. I would be playing for about an hour or 2 while moving the minimap slowly and it would still happen. Never had this before 1.3.0.8. I am on Windows 10. Went through the usual troubleshooting as shown in the video. New saves are also effected.

How to repro: Move minimap.


https://youtu.be/v1rZBk0KwfY

[Hooman]

Hmm, interesting. It crashes without any sort of error message or crash dump. I'll have to see if I can reproduce that locally. If not, a saved game file might be helpful.

Thank you for reporting this.

[steev]

No problem. Thanks for responding so quickly!

I think i may know what is causing it. It may have to do with the random Windows update i received which updated my build to 1909. Ever since i got that build two days ago Outpost 2 has been crashing. Gonna grab a ISO of 1903 and see if that may be the case.


EDIT: Turns out that is not the case. May be Nvidia drivers then.


EDIT 2: Turns out if i have my monitor playing it at 2560x1440... it causes the minimap crash.   Switch resolution to 1080p? It's fine.   Well then.

[Hooman]

There are some high screen resolution problems that have been reported in the past. I don't recall the problems being exhibited in quite the same way that you demonstrated. From what I understood, the game just crashed right away, without the ability to interact for some indeterminate amount of time. I've never had a high enough resolution monitor to test it myself though.

Still, this could be something we could potentially patch. In fact, we probably should try to patch it as higher resolution monitors will only become more common.

How reproducible is the problem? Can you crash any level right at the start of the mission, or does it only happen for certain missions, or only later in the game? If you play in windowed mode, does it still crash at high resolutions, or only when maximized at high resolutions?

Anyway, glad you've got a workaround for the problem.

[steev]

The crash is easily reproducible just by using the minimap at least on my end. Any mission does it.

When the game is in a small window like so, it doesn't cause the minimap crash.





But as soon as i go to maximized window mode interacting with the minimap causes the game to crash out with no error. I can play just fine if i don't use the minimap too often but the crash will eventually happen. I can keep the viewpoint on my colony for a while and i'll be all good.

[Vagabond]

Hooman, maybe this is an excuse for you to buy a nice monitor. 

Mine only goes up to 1080P, so I likely cannot reproduce the gripe. The couple of times I saw it crash in the provided video, the minimap was at the edge of the map, maybe coincidence though. I can add it to the bugs section of the change log. Anyone else have more info on this crash?

-Brett

[Sirbomber]

Is it possible the resolution is so high OP2 attempts to scroll off the map?

[leeor_net]

That is exactly what it is, it happens on high resolution monitors seemingly anything over 2K. I've heard this a few times with 4K resolutions where the game just crashes immediately on smaller maps regardless of playing with the minimap.

Best guess is an out of bound array index issue -- somewhere an assumption was made about resolution and how much would be displayed at once but then barfs on resolutions that far exceed those that the original developers ever considered. Not surprising, really.

[Crow!]

Could the functionality of the Maximize button be changed so that if the window would become larger than whatever the biggest the game can handle is, it instead only becomes that large?

[TechCor]

Nah. Shouldn't tie window size to supported resolution. Instead, the player's zoom level should not exceed the map bounds - render everything larger.

[Hooman]

Is it possible the resolution is so high OP2 attempts to scroll off the map?

That might be true of the main view area for small maps. I'm pretty sure the minimap itself is a fixed size, so I would assume it should be fairly resolution independent.

The drawing of the main view area does get broken up into segments. I suspect there may be a maximum number of segments it can draw. Depending on alignment, that might get exceeded. I wonder what would happen if the view area was scrolled by 1 tile at a time. Would it always crash at the same place (or 32 tile multiples of it)? If so, I would expect scrolling left/right to be a problem, rather than up/down.

At any rate, if anyone is able to produce a crash address (EIP value), that would be very helpful as a starting point to debug this.


Would be kind of neat if players could scroll in and out of the map, much like google maps, rather than just using the minimap.

[steev]

Is it possible the resolution is so high OP2 attempts to scroll off the map?

That might be true of the main view area for small maps. I'm pretty sure the minimap itself is a fixed size, so I would assume it should be fairly resolution independent.

The drawing of the main view area does get broken up into segments. I suspect there may be a maximum number of segments it can draw. Depending on alignment, that might get exceeded. I wonder what would happen if the view area was scrolled by 1 tile at a time. Would it always crash at the same place (or 32 tile multiples of it)? If so, I would expect scrolling left/right to be a problem, rather than up/down.

At any rate, if anyone is able to produce a crash address (EIP value), that would be very helpful as a starting point to debug this.


Would be kind of neat if players could scroll in and out of the map, much like google maps, rather than just using the minimap.

Anyway I can do that? I can re-pro it easily but not quite sure how to produce a EIP value for it.

[Hooman]

You can try running Outpost 2 under a debugger. A good free one is OllyDbg. (I've been using version 1.10, though I see there is a 2.0 now). Should be able to just download, unzip, and run, no installation needed.

Open OllyDbg. Use OllyDbg to open Outpost2.exe. Run the game using hotkey (F9), or the menu, or the toolbar button. Reproduce the crash in game.

If the game raises some kind of exception, it will likely be caught by the debugger before being handled by the game. That should cause it to pause execution and give control to the debugger. It will likely present a view of the code section, with assembly code, at the point where the problem occurred. The memory address of the highlighted line will be the EIP value. There will also be a register section at the top right, which should also list the EIP value, along with all the other registers. The bottom right is the stack, which can also provide hints as to where things went wrong.

The EIP value is the main thing of interest. If you're uncertain of what you're looking at, or think additional detail might be helpful, a screenshot would also be good.

There's a chance the debugger might not catch anything, and it'll appear the game terminated normally. That might happen if the game detects an error and just calls abort. I'm uncertain if the debugger would intercept that before the game closes. From what you described, something of the sort may be happening, though it's hard to know for sure.


Anyway, really appreciate it if you gave it a try.

[steev]

Here's what i got.


https://imgur.com/a/U9pHvau


Added a few more crashes.

[Hooman]

Excellent! That's very helpful. Interesting that there are multiple crash addresses.

For ease of reference, the crash addresses are:
004C2B9E  In function: _memcpy, Return address: 00470879
00470799  In function: Viewport.ScrollBitVector(char* bitVector, int bUpdateBackgroundToRedraw)

The return address from _memcpy leads to a function which has been documented, though was never given a name. The start address is:
004707F1

The unnamed function does appear to be drawing related code. It makes calls to:
Viewport.UpdateBackgroundRectToRedraw(Rect& absBitmapRect)
The parameters to the _memcpy call reference bitVector, much like the other crash point.

[steev]

Wonderful! Glad i could help. Does this mean there is a chance this could be fixed or nah?

[Hooman]

Yeah, it can probably be fixed. It's just a matter of when, based on the time and effort it would take. We have somewhat limited development resources. For reference, an interesting bug was posted a few months back, and we kind of dabbled a little bit to diagnose the cause, though it was about 2 months before we got back to it and started working on stuff for it. There might be a little less work in the way now, though it's hard to say.