[posila][0.16.26] Logistic network connections don't always show
[posila][0.16.26] Logistic network connections don't always show
A long time ago we received a nice visual to show which roboports connect with each other via a thick yellow dashed line. Soon after an algorithm was added to not show all of the lines as it would otherwise block the player's view. But I just ran into a situation where there were too few lines.
In the image you can see 4 roboports in the top right, and a couple others in the bottom left. These two areas actually form a logistics network together as is visible in the center of the image where the logistics areas connect. However there is not a single yellow line that connects the group of four with the rest of the network.
The circled roboport is the only one to connect with the logistics area of the group of four, removing this roboport created two separate networks. As is obvious in the image, there is a different line between two other roboports, preventing a line from the circled roboport to the group of four. So it seems like the algorithm doesn't recognise that this line is required and thus doesn't mind drawing the blocking line instead.
The problem is very easy to reproduce, you just place the relevant roboports in roughly the same formation; one roboport in the top right connecting to one roboport in the bottom left; with two other roboports connecting in the bottom left such that their connection line is inbetween the first two roboports. Here's another image with the problem isolated:
I'm not entirely sure whether this can be counted as an actual bug, or whether it's acceptable behavior from the algorithm. I didn't see anything about this mentioned in the known bugs or won't fix areas.
I've omitted any other information such as a savefile or logfile as these shouldn't be needed/relevant; the problem is clear from the above images and description.
In the image you can see 4 roboports in the top right, and a couple others in the bottom left. These two areas actually form a logistics network together as is visible in the center of the image where the logistics areas connect. However there is not a single yellow line that connects the group of four with the rest of the network.
The circled roboport is the only one to connect with the logistics area of the group of four, removing this roboport created two separate networks. As is obvious in the image, there is a different line between two other roboports, preventing a line from the circled roboport to the group of four. So it seems like the algorithm doesn't recognise that this line is required and thus doesn't mind drawing the blocking line instead.
The problem is very easy to reproduce, you just place the relevant roboports in roughly the same formation; one roboport in the top right connecting to one roboport in the bottom left; with two other roboports connecting in the bottom left such that their connection line is inbetween the first two roboports. Here's another image with the problem isolated:
I'm not entirely sure whether this can be counted as an actual bug, or whether it's acceptable behavior from the algorithm. I didn't see anything about this mentioned in the known bugs or won't fix areas.
I've omitted any other information such as a savefile or logfile as these shouldn't be needed/relevant; the problem is clear from the above images and description.
Re: [0.16.26] Logistic network connections don't always show
Post the save please.
Re: [0.16.26] Logistic network connections don't always show
As you can see I already noted that there is absolutely no reason for such files for this specific problem. There are no weird oddities happening that could be found in a logfile. The problem is also very obvious from the post, and can be easily replicated which shouldn't take more than a couple seconds. There is no need for me to go through the trouble of uploading savefile when it can't provide any more information than I already have.Youri wrote:I've omitted any other information such as a savefile or logfile as these shouldn't be needed/relevant; the problem is clear from the above images and description.
Re: [0.16.26] Logistic network connections don't always show
Roboports only show lines to other roboports within a certain distance of them. I don't know if this would be considered a bug or not.
There are 10 types of people: those who get this joke and those who don't.
Re: [posila][0.16.26] Logistic network connections don't always show
the top robo port appears to be out of range/out of power, seems unusual to have this situation however.
if the roboports function as connected, when powered, then it is a simple UI issue.
i suggest that you create the situation from a fresh map and post the map save
a blueprint string could also be useful.
i could not reproduce your issue.
if the roboports function as connected, when powered, then it is a simple UI issue.
i suggest that you create the situation from a fresh map and post the map save
a blueprint string could also be useful.
i could not reproduce your issue.
Re: [0.16.26] Logistic network connections don't always show
They only show lines when their red logistics areas connect. In the center of both images you can see the two separate areas connect.Jap2.0 wrote:Roboports only show lines to other roboports within a certain distance of them. I don't know if this would be considered a bug or not.
Not all lines are shown however, like I said in the original post some algorithm reduces the number of lines drawn so as to let the player still view stuff fairly normally. The problem here is that the wrong lines are being omitted, which provides a confusing signal to the player as the red areas say there is a connection but the yellow lines say there isn't.
In the first image all roboports are powered normally. You can also see their red logistics areas connect in the center of the image. It IS a graphical issue, I never claimed the network to not be working. The two reasons why I'm unsure whether it's truly a bug, are 1) that this system has been untouched for quite a while (from what I know); and 2) that it can be (or already has been) deemed a won't fix as the extra logic would complicate the algorithm by too much.Philip017 wrote:the top robo port appears to be out of range/out of power, seems unusual to have this situation however.
if the roboports function as connected, when powered, then it is a simple UI issue.
i suggest that you create the situation from a fresh map and post the map save
a blueprint string could also be useful.
i could not reproduce your issue.
The second image server as clear instructions for reproducing the issue. In any save, all you need to do is place four roboports roughly like the formation shown, there is absolutely no precision involved. I used those to verify that I could easily reproduce the issue, so they're freshly placed and have their small amount of starter power stored. Hooking up power wouldn't change anything here as the red logistics areas still show.
Re: [posila][0.16.26] Logistic network connections don't always show
Wow, that's an unusual one.
Here's a blueprint of one I was able to reproduce, which is a little different:
VERY strangely, when I placed the blueprint in sandbox mode (only places ghosts), then manually put the roboports down again, they all connected normally.
Here's one of a very similar setup Youri created:
When I fiddled with it a little more by picking up and placing them down, just like the first one, then the connections were even more messed up than just missing one. I hit alt+enter to make it easier and have a smaller area to screenshot, and it screwed up the lines even worse, and now none connect, even when I alt+enter back to full screen. To reiterate--alt+enter caused the lines to disappear entirely, making it pointless to even screenshot.
Log:
I've added a save with two different situations of the lines not showing.
Here's a blueprint of one I was able to reproduce, which is a little different:
Code: Select all
0eNqN0NEKgyAUBuB3+a9dTFcZvsoYozYZwlJRG4vw3Wc22KAuujxy/s/DP6F7DtI6pQPEBHUz2kOcJ3j10O1zfgujlRBQQfYg0G0/T850xhoXEAmUvss3BI0XAqmDCkouRh7Gqx76Trq0sE4TWONTwOj5p4QwXlQEI8SBNUUVI1kpbIeSwwtD+TZz2sPQ+sswuq2UO5Qfkk9JJeUqxV/zBC/pfI7UDWeUNsealzF+AA5phfY=
Here's one of a very similar setup Youri created:
Code: Select all
0eNqN0NEKgjAUBuB3+a+ntKVO9ioRoTVioGcyZySyd29aUaAXXp7D+b8D/4S6GXTnDHmoCeZqqYc6TejNnapm3vmx01AwXrdgoKqdJ2dr21nnERgM3fQTioczgyZvvNFvYxnGCw1trV08WKcZOtvHgKX5U0REkeYMI1QiyjQPga0UsUNJfky+rRz3KFx+FMG3lWyHwvMvImckdrQ0qf6KZ3ho1y+RopSC8/JQyCyEF5xihcA=
Log:
Code: Select all
0.002 2018-02-27 18:42:32; Factorio 0.16.26 (build 35745, win64, alpha)
0.002 Operating system: Windows 10 (version 1709)
0.002 Program arguments: "C:\Program Files\Factorio\bin\x64\factorio.exe"
0.002 Read data path: C:/Program Files/Factorio/data
0.002 Write data path: C:/Users/JPB/AppData/Roaming/Factorio [161642/228384MB]
0.002 Binaries path: C:/Program Files/Factorio/bin
0.010 System info: [CPU: Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz, 4 cores, RAM: 2062/8191 MB, page: 2435/10111 MB, virtual: 148/134217727 MB, extended virtual: 0 MB]
0.010 Display options: [FullScreen: 1] [VSync: 1] [UIScale: system (100.0%)] [MultiSampling: OFF] [Screen: 255] [Lang: en]
0.011 Available display adapters: 2
0.011 [0]: \\.\DISPLAY1 - AMD Radeon HD 5800 Series {0x8080005, [0,0], 1920x1200, 32bit, 60Hz}
0.011 [1]: \\.\DISPLAY2 - AMD Radeon HD 5800 Series {0x80001, [-1280,169], 1280x1024, 32bit, 60Hz}
0.012 Create display on adapter 0. Size 1280x720 at position [310, 222].
0.082 Initialised Direct3D:[0] AMD Radeon HD 5800 Series; driver: aticfx64.dll 8.17.10.1433
0.086 Video memory size (dedicated video/dedicated system/shared system/available): 1010/0/3840/4087 MB
0.123 DSound: Starting _dsound_update thread
0.123 DSound: Enter _dsound_update; tid=6704
0.124 Device reset internal.
0.126 Desktop composition is active.
0.126 WARNING: You have vsync and desktop composition enabled on Direct3D. Consider disabling vsync to increase performance on some configurations.
0.126 Graphics settings preset: medium-with-low-vram
0.126 Graphics options: [Graphics quality: normal] [Video memory usage: all] [Light scale: 25%] [DXT: auto] [Shader: 1]
0.126 [Parallel sprite loading: 1] [Max texture size: 4096/4096] [Bmp cache: 0] [Sprite slicing: 1] [Low quality rotation: 0]
0.223 Loading mod core 0.0.0 (data.lua)
0.255 Loading mod base 0.16.26 (data.lua)
0.429 Loading mod base 0.16.26 (data-updates.lua)
0.515 Checksum for core: 2748671610
0.515 Checksum of base: 2519924345
0.652 Verbose ModManager.cpp:399: Time to load mods: 0.439111
0.676 Loading sounds...
0.809 Info PlayerData.cpp:65: Local player-data.json available, timestamp 1519777613
0.809 Info PlayerData.cpp:72: Cloud player-data.json unavailable
1.031 Verbose ShaderHLSL.cpp:29: [PSVersion: 3.0, NumInstructionSlots: 512]
1.031 Loaded shader file C:/Program Files/Factorio/data/core/graphics/shaders/game.cso
1.031 Loaded shader file C:/Program Files/Factorio/data/core/graphics/shaders/zoom-to-world.cso
1.032 Loaded shader file C:/Program Files/Factorio/data/core/graphics/shaders/alpha-mask.cso
1.079 Initial atlas bitmap size is 4096
1.086 Created atlas bitmap 4096x4095 [none]
1.092 Created atlas bitmap 4096x4092 [none]
1.096 Created atlas bitmap 4096x4089 [none]
1.100 Created atlas bitmap 4096x4089 [none]
1.104 Created atlas bitmap 4096x4094 [none]
1.108 Created atlas bitmap 4096x4095 [none]
1.109 Created atlas bitmap 4096x1557 [none]
1.109 Created atlas bitmap 4096x1940 [decal]
1.145 Created atlas bitmap 4096x4096 [compressed, mask]
1.184 Created atlas bitmap 4096x4096 [compressed, mask]
1.185 Created atlas bitmap 4096x72 [compressed, mask]
1.223 Created atlas bitmap 4096x4084 [compressed, mask, shadow]
1.265 Created atlas bitmap 4096x4092 [compressed, mask, shadow]
1.271 Created atlas bitmap 4096x668 [compressed, mask, shadow]
1.271 Created atlas bitmap 4096x2928 [mipmap]
1.284 Created atlas bitmap 4096x1568 [compressed, mipmap, mask, smoke]
1.286 Created atlas bitmap 4096x4060 [linear-minification, mipmap, terrain]
1.286 Created atlas bitmap 4096x616 [linear-minification, mipmap, terrain]
1.287 Created atlas bitmap 4096x1868 [no-crop, trilinear-filtering, icon, light]
1.287 Created atlas bitmap 4096x476 [alpha-mask]
10.177 Sprites loaded
10.177 Convert atlas 4096x4096 to: compressed
11.364 Convert atlas 4096x4096 to: compressed
12.465 Convert atlas 4096x72 to: compressed
12.484 Convert atlas 4096x4084 to: compressed
13.153 Convert atlas 4096x4092 to: compressed
13.761 Convert atlas 4096x668 to: compressed
13.856 Convert atlas 4096x2928 to: mipmap
13.922 Convert atlas 4096x1568 to: mipmap compressed
14.281 Convert atlas 4096x4060 to: min-linear
14.396 Convert atlas 4096x616 to: min-linear
14.418 Convert atlas 4096x1868 to: trilinear-filtering
14.475 Convert atlas 4096x476 to: alpha-mask
14.484 Verbose AtlasSystem.cpp:705: Atlas memory size: 661.11MB
14.484 Verbose AtlasSystem.cpp:706: Size of sprites outside of atlas: 0.00MB
16.093 Custom inputs active: 0
16.101 Info Updater.cpp:750: Downloading https://updater.factorio.com/get-available-versions?username=Jon8RFC&token=<private>&apiVersion=2
16.946 0 packages available to download (experimental updates enabled).
16.991 Factorio initialised
108.418 Verbose BlueprintLibrary.cpp:53: Loaded external blueprint storage: playerIndex = 0, nextRecordID = 2; timestamp = 1519777611; records: (id: 0, 1; label: "", preview: false, empty: false; book)
108.702 Loading Level.dat: 1096621 bytes.
108.703 Info Scenario.cpp:135: Map version 0.16.26-2
108.738 Verbose BlueprintLibrary.cpp:234: Loaded library shelves:
108.738 Verbose BlueprintLibrary.cpp:856: Game shelf: playerIndex = 65535, nextRecordID = 0; timestamp = 0; records:
108.738 Verbose Scenario.cpp:143: Loading level.dat finished: 0.035112 seconds.
108.740 Verbose BlueprintLibrary.cpp:53: Loaded external blueprint storage: playerIndex = 0, nextRecordID = 2; timestamp = 1519777611; records: (id: 0, 1; label: "", preview: false, empty: false; book)
108.740 Verbose Scenario.cpp:210: Entities setup finished: 0.001843 seconds.
108.747 Checksum for script C:/Users/JPB/AppData/Roaming/Factorio/temp/currently-playing/control.lua: 2103675736
108.748 Verbose Scenario.cpp:260: Map setup finished: 0.045997 seconds.
108.748 Verbose AppManager.cpp:499: Time to create game: 1.256965 seconds.
543.951 Device reset internal.
555.406 Device reset internal.
653.330 Verbose Scenario.cpp:531: Saving game as C:\Users\JPB\AppData\Roaming\Factorio\saves/bug_59238
653.632 Verbose Scenario.cpp:636: Time to save game: 0.30119
653.681 Info AppManagerStates.cpp:1595: Saving finished
656.587 DSound: Stopping voice
656.587 DSound: Joining thread
656.592 DSound: Exit _dsound_update; tid=6704
656.592 DSound: Waiting for voice to stop ... signaled
656.592 DSound: Joined thread
656.592 DSound: Destroying thread
656.592 DSound: Thread destroyed
656.592 DSound: Releasing buffer
656.592 DSound: Voice stopped
656.592 DSound: Deallocating voice
656.592 DSound: Deallocated voice
656.617 Goodbye
- Attachments
-
- bug_58238.zip
- (3.37 MiB) Downloaded 185 times
Last edited by Jon8RFC on Wed Feb 28, 2018 1:43 am, edited 3 times in total.
Re: [posila][0.16.26] Logistic network connections don't always show
Sorry for the junk quality...my old card isn't supported by Windows10 native recording:
https://youtu.be/1PVwAnA0Vo0
Powered, but the lines don't show.
https://youtu.be/1PVwAnA0Vo0
Powered, but the lines don't show.
Re: [posila][0.16.26] Logistic network connections don't always show
Thansk for the report.
@Jon8RFC Thank you very much for adding blueprint strings and the save.
I thought it is another bug in jcv_voronoi library which we used to replace boost::polygon::voronoi in our triangulation algorithm. After several minutes of debugging the library I realized using voronoi diagram for triangulation of connections in logistic network is completely flawed.
This voronoi diagram of the reported setup. Problem is, that green roboport has direct connection only to yellow one (their logistic areas touch), but they don't share an edge in the voronoi diagram, so the connection between them is not displayed. And the robports with which the green roboport does share an edge are not its direct neighbors so those connections are not drawn because they don't exist.
I think it pretty nasty issue, because it may bite you in the butt when you are trying to keep networks separated, so I'll think if there is some way how to fix it without completely changing triangulation algorithm. On the other hand this is the first report of this issue since the triangulation was added in 2015, so I don't think it needs to be solved in 0.16.
@Jon8RFC Thank you very much for adding blueprint strings and the save.
I thought it is another bug in jcv_voronoi library which we used to replace boost::polygon::voronoi in our triangulation algorithm. After several minutes of debugging the library I realized using voronoi diagram for triangulation of connections in logistic network is completely flawed.
This voronoi diagram of the reported setup. Problem is, that green roboport has direct connection only to yellow one (their logistic areas touch), but they don't share an edge in the voronoi diagram, so the connection between them is not displayed. And the robports with which the green roboport does share an edge are not its direct neighbors so those connections are not drawn because they don't exist.
I think it pretty nasty issue, because it may bite you in the butt when you are trying to keep networks separated, so I'll think if there is some way how to fix it without completely changing triangulation algorithm. On the other hand this is the first report of this issue since the triangulation was added in 2015, so I don't think it needs to be solved in 0.16.
Re: [posila][0.16.26] Logistic network connections don't always show
@posila: isn't this because you are using voronoi with euclidean metric while roboports use metric L-infinity (two robports connect when max(dx,dy)<=N)? You can solve this by changing voronoi metric to L-Infinity, or by changing roboports to use euclidean metric (roboport ranges would be circular, not square)
-- edit:
http://yunzhishi.github.io/voronoi.html - your image uses Euclidean, while roboports use Chebyshev. This may help
-- edit:
http://yunzhishi.github.io/voronoi.html - your image uses Euclidean, while roboports use Chebyshev. This may help
Re: [posila][0.16.26] Logistic network connections don't always show
@posila Here's a recording of the disappearing act. It's not as catastrophic as the first time I managed to make it happen, but it showcases the spontaneous disappearing in the game of the top-right roboport area (around 45 seconds), and then a couple of different times it changes (not as badly as the first time, yesterday) when I alt+enter.
Hopefully this is helpful information because if it's deterministic, it shouldn't (seemingly) randomly change its mind, right? This confuses me, and I'd love to try and understand the inner workings of why they disappear spontaneously like this, including with the alt+enter, if you have some time to further explain this. I was antsy to upload it and forgot to make blueprints or a save file. I'm happy to use a debug version to try and reproduce this, if you're interested. I'll do the minion's work and you can do the important stuff.
https://youtu.be/OT1mWdzB578
Hopefully this is helpful information because if it's deterministic, it shouldn't (seemingly) randomly change its mind, right? This confuses me, and I'd love to try and understand the inner workings of why they disappear spontaneously like this, including with the alt+enter, if you have some time to further explain this. I was antsy to upload it and forgot to make blueprints or a save file. I'm happy to use a debug version to try and reproduce this, if you're interested. I'll do the minion's work and you can do the important stuff.
https://youtu.be/OT1mWdzB578
- Attachments
-
- factorio-current.log
- (6.77 KiB) Downloaded 188 times
Re: [posila][0.16.26] Logistic network connections don't always show
@boskid: I was aware it wouldn't be problem if roboports used Eucliedean distance for "can connect" check. I thought the library we use wouldn't work if we modified it to use Chebyshev distance, but Oxyd said he didn't see reason why it wouldn't. So we tried it and it seems to work. So your message helped, thanks.
@Jon8RFC: that's normal behavior when roboport runs out of its internal charge. It stops working, so it disconnects from its network and you don't see connection to it when you hover over other roboports in the network, but when you hover over the disconnected roboport, it shows connections it will have when it becomes active again.
@Jon8RFC: that's normal behavior when roboport runs out of its internal charge. It stops working, so it disconnects from its network and you don't see connection to it when you hover over other roboports in the network, but when you hover over the disconnected roboport, it shows connections it will have when it becomes active again.
Re: [posila][0.16.26] Logistic network connections don't always show
Not resolved in [0.16.28]
There is this corner case where it is still not working properely
There is this corner case where it is still not working properely
- Attachments
-
- 0_16_28_RoboportsNotConnecting.zip
- (2.07 MiB) Downloaded 156 times
-
- 0_16_28_RoboportsNotConnecting.jpg (1.18 MiB) Viewed 7947 times
Re: [posila][0.16.26] Logistic network connections don't always show
The disappearing act I referenced before is easily reproducible here.
Using this blueprint, everything seems ok, at first.
Add a roboport here (or in a variety of other locations) and see that the issue occurs:
However, continue on to the disappearing act, and remove the roboport you've just placed and the lines don't return:
If you place the roboport again, things don't return to normal until you remove the surrounding roboports.
Code: Select all
0eNqd1FtuhSAQANC9zDc2d8BX2UrTNGrJDYmCAWxqDHsvWq9pIrbaPyDMgRkeE9TtIHojlQM+gWy0ssBfJrDyrqp2HnNjL4CDdKIDAqrq5p7Rte61ceAJSPUuPoGjfyUglJNOim9j6YxvauhqYcKELbqW90S0onFGNkmvWxHgXtsQqdW8ZNDSp4zACDxhoeU92Wn0isb+5Ng+tb2SbQrGlfTKphJKHx498LJLHstX7yDHfNPsUFtXLbGRbd1WJo8zxUnmd6U8UfAEixXBg5SeTymP08cyruDtFIMrM59blMGLBaYHWSG9VuJDh/3v/jA2e+E5L4+e//gjCHwIY5eYvCwoMsQizb3/AiawYSk=