View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0005354 | The Dark Mod | Feature proposal | public | 04.10.2020 17:23 | 09.01.2023 22:39 |
Reporter | Geep | Assigned To | stgatilov | ||
Priority | normal | Severity | normal | Reproducibility | have not tried |
Status | resolved | Resolution | fixed | ||
Product Version | TDM 2.09 | ||||
Target Version | TDM 2.10 | Fixed in Version | TDM 2.10 | ||
Summary | 0005354: Feature: Pointfiles for Debugging of Info_Location Overlaps | ||||
Description | When the info_location system is used for ambient light and sound, after dmap and during the "map <FM>" phase, any info_locations that overlap are so reported to the console as a warning. However, diagnosis of the actual problem cause is difficult. It is proposed, if technically feasible, to extend the pointfile system to help with this diagnosis. In particular, what is desired is a pointfile that runs between the two info_location objects involved in the overlap, via an info-location-overlap path. The name style of such pointfiles should be clearly different from that of the visportal pointfiles. A suggestion is: pointfile_<info_location_name1>_overlaps_<info_location_name2>.lin | ||||
Additional Information | Related forum posts about debugging an overlap: https://forums.thedarkmod.com/index.php?/topic/9082-newbie-darkradiant-questions/&do=findComment&comment=451983 https://forums.thedarkmod.com/index.php?/topic/9082-newbie-darkradiant-questions/&do=findComment&comment=452084 It is recognized that, if the naming of pointfiles is modified, a system that cycles through pointfiles automatically in DR, instead of needing manual renaming, could be impacted by this. | ||||
Tags | No tags attached. | ||||
I'm afraid it will be done during dmap then. Although in principle it is possible to do in game too (in fact, dmap never looks at location entities yet). Players won't be happy to see all those files generated. |
|
I take what you're saying is, it would be better to do it during dmap, but there's no code to help with that yet in dmap... so not easy to implement. | |
Any test map? UPDATE: Ok, I just took Accountant 2 and it has such errors due to now-dropped visportals. |
|
In some cases two info_location-s are in different areas during dmap, but somehow end up in same area during game start. Is there any spawnarg/entity which can merge areas together?... |
|
I forgot about the damn system of info_locationseparator-s. Do they serve any other purpose except for splitting info_location-s? I wonder why D3 creators did not simply add second visportal material... This "entity box intersects visportal box" system does not sound very reliable. |
|
As far as I know, the separators are only there to split locations. If you break anything, you will quickly find that EFX reverb fails to work as well as dynamic ambient lighting. Location System based script events may take longer to find. |
|
I agree with nbohr1more, the separators apparently are only there to split locations. I have no idea why they were invented, rather than a different type of visportal material. But even if the implementation had used the latter, my requested feature would still be appropriate and valuable if provided. Regrettably, I have no insights about "Location System based script events" and how they might impact this proposal. |
|
Is it true that on a correct map: 1) info_locationSeparator must touch a visportal 2) info_locationSeparator must not touch two visportals at the same time 3) two info_locationSeparator-s must not touch the same visportal ? I'd like to add warnings on all of these issues. |
|
And another question. Do I understand that doors do NOT block locations in TDM? I see this explanation in entityDef: "Touch a visportal with this to break location name flood filling without using a door." It is probably true for doors in Doom 3, but TDM doors do not change anything. |
|
Interesting fact: visportal can be split into several by opaque geometry. This happens when one connected part of portal separates A from B, and second connected part separates A from C or even C from D. In such case same brush+side is treated as several separate visportals by the engine. When engine searches for the portal which is covered by location separator, it finds the first one that suits and blocks it. If visportal is split into several, they all have same winding, so each of them "suits", but only one (arbitrary one) is actually blocked. I have noticed one such case on Accountant 2, and I must admit it can be very surprising and hard to find! I will not change the way how engine works for now, so mappers will see warning in such cases (location separator covers several portals). |
|
Some internal discussion here: https://forums.thedarkmod.com/index.php?/topic/20226-dropped-visportal-diagnostic/&do=findComment&comment=459474 I have committed the changes: r9285. Preliminary refactoring for upcoming dmap improvements. r9286. Preliminary refactoring for upcoming dmap diagnostics for locations. r9287. Added dmap diagnostics for info_location-s and info_locationSeparator-s. Only the last commit actually adds new diagnostics, the first two are preparations. |
|
While looking through results, I have detected two type of "errors" which might be very confusing to mappers. 1) Visportal is covered by location separator entity it its BOUNDING BOX touches the entity box. If visportal is not axis-aligned and large, then some other location separator can be assigned to this visportal (while you clearly see in DR that they don't contact). Such additional assignments will result in several warnings now, and it is good because such situation can lead to problems in-game. 2) Sometimes one visportal brush is turned into two visportals with the same rectangle. It happens when opaque geometry splits visportal face into two connected components, and these components separate different pairs of visleafs/areas. If you apply location separator to such visportal, you will see warning like this: WARNING:Separator locationsep_on_double_portal covers both portal 203 at 4 -380 -112 and portal 203 at 4 -380 -112 Which tells you that location separator covers the same portal twice =) Believe it or not, this can cause problems with locations in-game, so you should fix it. The only way to fix it is to change visportal brush, so that it is not broken into two visportals in-game. Note that you cannot reliably detect such situations with "r_showPortals 1". |
|
"Is it true that on a correct map: 1) info_locationSeparator must touch a visportal 2) info_locationSeparator must not touch two visportals at the same time 3) two info_locationSeparator-s must not touch the same visportal ?" Sounds right, referring to the side of the visportal with that texture. "Do I understand that doors do NOT block locations in TDM? I see this explanation in entityDef: 'Touch a visportal with this to break location name flood filling without using a door.' It is probably true for doors in Doom 3, but TDM doors do not change anything." It is my understanding that TDM doors should not affect location separators. So the entityDef comment might be revised to (and replacing easily-misinterpreted word "break" with "block"): "Touch a visportal with this to block location name flood filling. Works whether or not the visportal has a door." "Interesting fact: visportal can be split into several by opaque geometry. This happens when one connected part of portal separates A from B, and second connected part separates A from C or even C from D. In such case same brush+side is treated as several separate visportals by the engine...." Is "opaque geometry" just worldspawn, or includes func_statics? I don't know what A,B,C,D are referring to. I'm guessings it's the NOT A-D scenarios shown in the figure of "Visportals, Func_statics and Worldspawn Brushes" of "Visportals" "When engine searches for the portal which is covered by location separator, it finds the first one that suits and blocks it. If visportal is split into several, they all have same winding, so each of them "suits", but only one (arbitrary one) is actually blocked. I have noticed one such case on Accountant 2, and I must admit it can be very surprising and hard to find! I will not change the way how engine works for now, so mappers will see warning in such cases (location separator covers several portals). " By "winding" I'm taking this as the locations of the 3+ corners defining the visportal texture boundary, all in the same plane. I think the proposed message - "location separator covers several portals" - doesn't quite describe the problem you indicated. Better would be "visportal is split by worldspawn, making location separator not fully effective". "Some internal discussion here: https://forums.thedarkmod.com/index.php?/topic/20226-dropped-visportal-diagnostic/&do=findComment&comment=459474" I evidently don't have permission to view that content "I have committed the changes: r9285. Preliminary refactoring for upcoming dmap improvements. r9286. Preliminary refactoring for upcoming dmap diagnostics for locations. r9287. Added dmap diagnostics for info_location-s and info_locationSeparator-s. Only the last commit actually adds new diagnostics, the first two are preparations." Very good, work in progress "While looking through results, I have detected two type of "errors" which might be very confusing to mappers. 1) Visportal is covered by location separator entity it its BOUNDING BOX touches the entity box. If visportal is not axis-aligned and large, then some other location separator can be assigned to this visportal (while you clearly see in DR that they don't contact). Such additional assignments will result in several warnings now, and it is good because such situation can lead to problems in-game." I'll put a description of this problem on my "WIKI TO DO" list. Let me know what warning messages to expect. "2) Sometimes one visportal brush is turned into two visportals with the same rectangle. It happens when opaque geometry splits visportal face into two connected components, and these components separate different pairs of visleafs/areas. If you apply location separator to such visportal, you will see warning like this: WARNING:Separator locationsep_on_double_portal covers both portal 203 at 4 -380 -112 and portal 203 at 4 -380 -112 Which tells you that location separator covers the same portal twice =) Believe it or not, this can cause problems with locations in-game, so you should fix it. The only way to fix it is to change visportal brush, so that it is not broken into two visportals in-game. Note that you cannot reliably detect such situations with "r_showPortals 1". " I think this is what was discussed above. Again, I think a more useful warning would be: WARNING: Portal 203 at 4 -380 -112 is split by worldspawn, making location separator locationsep_on_double_portal not fully effective While the new warnings will be helpful for some cases, I'm still interested in the original request, to provide a pointfile between connected info_locations. If it cannot be fulfilled at this time, maybe some time in the future. |
|
I think I will leave things as they are and wait for more widespread feedback from mappers. It is not clear yet what to do when visportal is split into several disconnected parts: complain about the visportal itself, change the way how location separators work, or adjust the warning message. Saving pointfiles between overlapping locations is done too (the same r9287). |
|
"...overlapping locations is done too". That is splendid. Thanks! | |
In the "Location Settings" wiki page, I've updated "The Location Entities" section with your work and findings. Please review and revise as you see fit. | |
Posted announcement: https://forums.thedarkmod.com/index.php?/topic/20905-210-dmap-locations-diagnostics |
|
Date Modified | Username | Field | Change |
---|---|---|---|
04.10.2020 17:23 | Geep | New Issue | |
09.04.2021 16:40 | stgatilov | Note Added: 0013829 | |
11.04.2021 23:31 | Geep | Note Added: 0013839 | |
12.04.2021 02:34 | stgatilov | Assigned To | => stgatilov |
12.04.2021 02:34 | stgatilov | Status | new => assigned |
14.04.2021 15:26 | stgatilov | Relationship added | related to 0005129 |
15.04.2021 16:35 | stgatilov | Note Added: 0013853 | |
15.04.2021 16:38 | stgatilov | Note Edited: 0013853 | |
15.04.2021 17:06 | stgatilov | Note Added: 0013854 | |
15.04.2021 17:48 | stgatilov | Note Added: 0013856 | |
15.04.2021 20:36 | nbohr1more | Note Added: 0013857 | |
15.04.2021 22:01 | Geep | Note Added: 0013859 | |
17.04.2021 05:43 | stgatilov | Note Added: 0013867 | |
17.04.2021 08:40 | stgatilov | Note Added: 0013868 | |
17.04.2021 09:32 | stgatilov | Note Added: 0013869 | |
17.04.2021 14:31 | stgatilov | Product Version | => TDM 2.09 |
17.04.2021 14:31 | stgatilov | Target Version | => TDM 2.10 |
18.04.2021 05:23 | stgatilov | Note Added: 0013870 | |
18.04.2021 05:59 | stgatilov | Note Added: 0013871 | |
18.04.2021 05:59 | stgatilov | Status | assigned => resolved |
18.04.2021 05:59 | stgatilov | Resolution | open => fixed |
18.04.2021 05:59 | stgatilov | Fixed in Version | => TDM 2.10 |
18.04.2021 15:58 | Geep | Note Added: 0013876 | |
18.04.2021 16:19 | stgatilov | Note Added: 0013877 | |
19.04.2021 20:12 | Geep | Note Added: 0013878 | |
20.04.2021 01:14 | Geep | Note Added: 0013879 | |
30.04.2021 05:17 | stgatilov | Note Added: 0013938 | |
09.01.2023 22:39 | stgatilov | Relationship added | related to 0006224 |