PDA

View Full Version : Blank/black map for single players



Weissrolf
January 26th, 2021, 09:14
Ahoi.

Yesterday's session ended when one of my players could not see the map anymore after me having dragged all player tokens outside the map (they went around). What happens is that the player only sees the whole map as black (LOS).

I had these happen a few times now, including when I connected to myself via a second instance. In that case I could solve it by simply closing and reopening the map. In another case when a player had the problem I could solve it by removing him from CT/map and then add his PC anew. In this case none of these helped, so we called it a day, since we were only minutes away from our session anyway and I did not want him to reconnect the client.

One of my many extensions may to be blame here, even though none of these should be map/LOS related.

BaneTBC
January 26th, 2021, 15:39
You could also try unsharing and resharing the map or resharing the map to that specific person (have them close it first). You can drag the link icon in the upper left of the map onto their Character Portrait in the upper left of the FGU Window and it will share that content specifically with that one person (i.e. you can also use this for any other information you want to share with one person and no one else).

Weissrolf
January 26th, 2021, 16:54
Unsharing will close it for all players, but we will try that next time.

SilentRuin
January 26th, 2021, 17:00
Unsharing will close it for all players, but we will try that next time.

You sure you had at least one owned player token in the area (activated) that you wanted the player to see? Otherwise, per design, they won't see anything in an LOS map. Unless they are there (with and owned token activated on map) to see that area they are in. Unless I'm misunderstanding something you described of course.

And of course, I skip over the possibility you had them in another map which would make them not see anything in any other map than the one they were in. Even if that map was closed and the one they wanted to see (but were not in) was open.

Weissrolf
January 26th, 2021, 17:11
Yes, and even specifically removed and re-added said token from CT and map. We used the same map and tokens just minutes before, but once I pulled all tokens to the side of the map to move them to another entry point only this one player had the map turn black.

We had this happen before and I even had it happen when I logged in alone to my own local server (simple close+open map solved it then).

SilentRuin
January 26th, 2021, 17:21
Yes, and even specifically removed and re-added said token from CT and map. We used the same map and tokens just minutes before, but once I pulled all tokens to the side of the map to move them to another entry point only this one player had the map turn black.

We had this happen before and I even had it happen when I logged in alone to my own local server (simple close+open map solved it then).

So you actually had them moving from map to map when this happened? My bet, someone's network dropped some packets and their local view was still wrong. Especially as you essentially resent out the network info by close/open and it started working. I suppose if they have their log files from this time period - or you do - you might be able to see some network issues. If they log them.

As far as the local thing happening - are you using LAN or cloud? Personally I never use cloud as its a whole other layer of communications I don't have direct control over.

Weissrolf
January 26th, 2021, 17:30
Same map to same map. There was no change in maps. I just pulled them out of the map area to the black sides and then back in. This needs to be done when you want to retain fog of war, but don't want to pull PC tokens all over the map. The latter of which reveals all parts traveled in between, so moving tokens outside the map is a workaround. I am open to other suggestions, but the main issue remains.

Last time I used local it was via private cloud connect. We used to use NAT routing direct connections, but since I enabled IPv6 on my side at least one of my players cannot use IPv6 DNS resolve to my server. So instead of handing over IP numbers every time I decided to give the cloud thing a try (it's what you pay for in Unity).

Temmpest
January 26th, 2021, 17:33
This has happened a couple of times. I just tell the players to click on their token and it usually fixes the problem.

SilentRuin
January 26th, 2021, 17:36
Same map to same map. There was no change in maps. I just pulled them out of the map area to the black sides and then back in. This needs to be done when you want to retain fog of war, but don't want to pull PC tokens all over the map, the latter of which reveals all parts traveled in between.

Same map - or not - it still has to be communicated via network to the player. Even if the player is you locally logging in. Hence why I asked if you used LAN or cloud (as I never use cloud as its a whole other communication layer that can go wrong and I've had players have issues in the past).

Gist is, to me, it seems a network communication issue dropping things. But again, checking log might show that. Given I don't suffer this issue (where I can't determine it was legitimately not having a player - or myself - with and active token on the map so I can see), and I don't use cloud in my games so its pure LAN (and I have a very good network), I don't really have any other guess on what would cause it. It does not seem a code bug (except maybe how the network is working/being handled on retries) as that would tend to be duplicatable.

Anyway, just my thoughts. Good luck.

SilentRuin
January 26th, 2021, 17:38
This has happened a couple of times. I just tell the players to click on their token and it usually fixes the problem.

Correct - this is the only thing I've ever witnessed - which is not what thread seems to be saying is happening to them. A pure activate token problem is the only thing I've ever seen that prevents LOS visibility. As I said in my very first post in here...


You sure you had at least one owned player token in the area (activated) that you wanted the player to see? Otherwise, per design, they won't see anything in an LOS map.

Weissrolf
January 26th, 2021, 17:42
Network issues are well possible, especially given how flaky unsteady the whole network thing still seems to be. So thanks for the suggestion. I may go back to NAT based direct connections, although I thought that FGU's cloud creates direct connections anyway?!

Next time it happens I ask the player to click on his token. But me removing and re-adding the token should have worked then.

SilentRuin
January 26th, 2021, 17:45
Network issues are well possible, especially given how flaky unsteady the whole network thing still seems to be. So thanks for the suggestion. I may go back to NAT based direct connections, although I thought that FGU's cloud creates direct connections anyway?!

Next time it happens I ask the player to click on his token. But me removing and re-adding the token should have worked then.

They may have resolved the cloud issues since I got burned by it last summer. But we are happy on LAN and I have no reason to "test" that cloud issues are all resolved as I'm working fine with LAN for my spread out (geographically) player.

superteddy57
January 26th, 2021, 17:48
If you are feeling like this is a cloud/network related issue, we would appreciate if you would send your logs to support or posting them here. Every little bit of information would be helpful in nailing down the issues you are facing.

Weissrolf
January 26th, 2021, 17:58
Log file be here: https://easyupload.io/8j0c2v

Moon Wizard
January 26th, 2021, 22:00
It would not be a network/log issue. If the files weren't being transferred, they would still see the red X with the question mark.

It sounds like the tokens are not getting linked to the CT correctly. Please try again without extensions.

Regards,
JPG

fieldson
January 28th, 2021, 02:45
[QUOTE=Weissrolf;573877]Same map to same map. There was no change in maps. I just pulled them out of the map area to the black sides and then back in. This needs to be done when you want to retain fog of war, but don't want to pull PC tokens all over the map. The latter of which reveals all parts traveled in between, so moving tokens outside the map is a workaround. I am open to other suggestions, but the main issue remains.


Weissrolf,
If I understand what you are trying to do, there is supposed to be another way. If you are holding down shift while moving the token, it won't reveal any new areas until you set the token down.

Weissrolf
January 28th, 2021, 13:02
I will try the shift-moving thing, would be useful. The problem persists anyway, though. This was just one incident when it happened.

Weissrolf
January 31st, 2021, 22:41
Two cases where LOS for a single PC char (myself via localhost) differed from GM LOS for the same PC char. Tested with *no* extensions loaded, only a single PF2 AP module loaded.

- Deleted PC token from map, dragged token from CT to map.

This lead to the map staying entirely black for PC view while GM view showed proper LOS for said PC token. Only once the player (myself via 2nd instance) specifically clicked (selected) on the PC token on the map would LOS be displayed other than black.

Once I maximized and restored the map I could not reproduce the same behavior anymore.

- GM places PC token at 45° angle *outside* at the edge of a map (with map borders being simple wall LOS elements as far as I can tell). PC would see the map properly black, while GM would see FOW at diagonal angle for half the map. FOW would remain different for GM and PC for the same PC token.

So there are cases where GM and player instance of FGU do not properly communicate LOS status for the same PC token(s).

Moon Wizard
February 1st, 2021, 02:56
@Weissrolf,

I don't believe the items you mentioned are related to the original report. For the original issue, we need specific data files where the LoS never appears for the player when trying to select the token, and there is an actual exception.

For the items you mentioned:

The first one is a known item, but resolved just by clicking the token by the player.

For the second one, I'm not following; can you provide a screenshot/example?

Thanks,
JPG

Weissrolf
February 1st, 2021, 08:01
1) Why does it sometimes happen and then sometimes not (after max/min)? Should the LOS update process not be the same every time a token is placed?

2) Turns out it is not just 45° and the LOS angle seems somewhat arbitrary going back and forth when the token is moved further away or one blip up/down.

GM views:

https://i.imgur.com/w7gvJFE.png https://i.imgur.com/jU4pHq3.png https://i.imgur.com/UUuLPKd.png

https://i.imgur.com/F7H4lk0.png https://i.imgur.com/WYxuZ3W.png

Player views:

https://i.imgur.com/c1TtO6f.png https://i.imgur.com/18XVXLa.png https://i.imgur.com/jtwc1Rq.png

Weissrolf
February 8th, 2021, 22:31
Today the same player had issues with black image content. The original (first) image map was fine and we played for 3 hours. Then I shared another map and then an image, which 4 players could view except the one player who had problems beforehand (total 5 players + GM). Both of these images (one overview map and one monster image) do not use LOS.

Cloud connection. Lots of extensions being used.

I compressed the campaign folder after ending the session today. So I could send you the file for scrutiny.

Moon Wizard
February 8th, 2021, 22:37
We need the logs from both the player and the GM immediately after it happens. (Type /console, then Compile Logs button.)

If the problem is some sort of exception error on the player side, it should show up in their logs. If the problem is that the file transfer is blocked, then we would see the request from player, file send from GM, and no receipt from player. (which would mean something is intercepting on player side; and we've seen some security programs/settings doing this)

Also, you should really try without extensions; because it could just be that an extension is not setting the owner and vision flags correctly on the tokens.

Regards,
JPG

Weissrolf
February 8th, 2021, 23:01
We meet every 2 weeks on Monday evenings with this group of players. There is little to no time to test around with no extensions. I will try to get an extra session in with the affected player. Last time the same map that we played on for 2 hours went black, this time extra image being shared stayed black.

Moon Wizard
February 8th, 2021, 23:06
Understood on the timing; but this isn't a generally reported issue, so there is something unique to the scenario that we need to pin down. Without figuring out what that is, we don't have a way to look into solving...

Regards,
JPG

Weissrolf
February 22nd, 2021, 23:44
Today it happened again to the same player. It happened while he kept the affected map image window open. Since he suffers from low screen resolution he keeps resizing the map window to uncover other windows (like CT and charsheet). He exclaimed that sometimes when it appears to be happening he can quickly resize again to keep the content from going permanently black.

When it happens then the window content is completely black, he does *not* see his own token and thus cannot click on it. Clicking zoom to fit does not help either. Today I asked him to compile the logs and then restart FGU, which solved the issue.

The same player suffered from very slow token movement today (when tokens are locked and movement is approved by the GM). I moved a NPC via ALT-drag and approved its movement and for the player the token arrived at its destination 14 seconds later than for me (GM).

Player.log of player "Bastik" contains pages of "D3D11: Failed to create RenderTexture (1093 x 1004 fmt 9 aa 1), error 0x8007000e" error messages.

Logs of GM appended as well.

Moon Wizard
February 23rd, 2021, 00:37
Those are out of memory errors. If the player is shifting a very large image back and forth often, he may be creating a memory scenario. We have been investigating some scenarios like this with the out of memory issues; but reducing the size of images shared and avoiding sending images to background may help for now.

Regards,
JPG

Weissrolf
February 23rd, 2021, 00:43
The image/map is from a bought adventure path, it's not easily reduced in size, even less so without having to set up all encounters again. I bought this from the SW shop so that I don't have to do this kind of preparation work.

If by "sending images to the background" you mean to avoid other windows (like CT and charsheet) covering the map window that this is not easy to accomplish, but I can tell him to try (for testing) next time.

Overall FGU uses far too much memory for simply loading any image. Photoshop uses considerably less.

Moon Wizard
February 23rd, 2021, 18:57
Photoshop has about 100 dedicated full-time developers working on just that piece of software; we have 2. Not sure that's a good comparison.

As mentioned in the other thread regarding player's machine; their machine is under the minimum specs for use, and probably has an outsized impact on this issue. (regardless of implementation)

Regards,
JPG

Weissrolf
February 23rd, 2021, 19:02
That's another player's machine, though, who does not suffer from the black image issue. I will ask the player with the black image issue about his memory configuration.

FGU should not multiple times the memory of the uncompressed bitmap image it just loaded. This is too much, regardless of how many developers are working on the corresponding code.

Weissrolf
February 23rd, 2021, 22:11
The player suffering from black map windows uses Windows 7 with 4 gb memory, so maybe there is a W7/DirectX conflict?!

Sulimo
February 23rd, 2021, 22:32
The player suffering from black map windows uses Windows 7 with 4 gb memory.

FGU is not supported on Windows 7 (https://fantasygroundsunity.atlassian.net/wiki/spaces/FGCP/pages/1136984087/System+Requirements).

I know a lot of people are still on Windows 7, however, Microsoft officially ended support of Windows 7 on January 14, 2020 (https://www.microsoft.com/en-us/windows/windows-7-end-of-life-support-information), that is over a year ago now.

Anyone still on Windows 7 should upgrade asap, Microsoft is no longer releasing any security patches for Win7, so the number of vulnerabilities will just keep increasing as time goes on, making those users still on Win7 vulnerable to anything from cryptolockers to identity theft if they continue to use Win7.

Microsoft made Windows 10 available as a free upgrade for the first year of its release, however, they have quietly supported a free upgrade from Win7/8 even to this day (see here for how (https://www.forbes.com/sites/gordonkelly/2020/02/04/how-to-upgrade-to-windows-10-for-free-in-2020/)).

Weissrolf
February 23rd, 2021, 22:40
I know all of this, but thanks.

Sulimo
February 23rd, 2021, 22:45
I am trying to be patient with you. As are the developers (Moon Wizard mostly), and the rest of the community.

However, your insistence of running unsupported configurations and then having a condescending tone when that is pointed out is annoying.


I am surprised you as a software developer yourself don't respect minimum required specs more. I would bet money if a customer called your support line and it was determined that the customer's computer did not meet the minimum requirements, your support personnel would directly tell the customer that, and tell them to upgrade to a supported configuration.

Looks like both of your players that are suffering issues are because they are not at the minimum required spec, one is running on an unsupported OS, the other does not have enough RAM.

Weissrolf
February 23rd, 2021, 23:37
so maybe there is a W7/DirectX conflict?!
Obviously I found out about my players system configuration just now and reported it as possible culprit right away. Moon Wizard suggested this to be a memory issue, so I also inquired the player about his memory configuration and reported back. We are not talking about my own system here, my system meets the requirements by multiple degrees and still suffers from problematic performance.

By the way, both OS and graphic-card are listed in console.log and player.log, but memory configuration and CPU unfortunately are not. I suggest to include these in the logs to help with future analysis of performance problems.

Worth mentioning that basically W10 = W8 = W7 = Vista, unless you count DirectX 12 support, which FGU does not make use of. Still DirectX 11 incompatibilities could play a role.

Next time this happens we will check current memory consumption and try to do a simple /reload instead of a restart. The player will change image/maps windows less now, though, especially after learning that you can scroll via cursor keys.