View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002819 | DarkRadiant | Map Editing | public | 21.07.2011 14:17 | 22.12.2018 09:51 |
Reporter | grayman | Assigned To | |||
Priority | normal | Severity | normal | Reproducibility | sometimes |
Status | closed | Resolution | fixed | ||
Product Version | 1.6.1 | ||||
Target Version | 1.7.0 | Fixed in Version | 2.6.0 | ||
Summary | 0002819: Brushes, patches, entities, etc. change layers on their own | ||||
Description | After a map reaches a certain complexity, you can find things switching the layer they're in. For example, in my current WIP, I just started for the day and found that a couple items placed on the first day of work--the ambient light and the target_addobjectives entity--had moved from the Default layer into one of my other layers. Another example: two loot candleholders created at the same time in the same layer (one was dup'ed from the other) subsequently ended up in two different layers. | ||||
Steps To Reproduce | It's impossible to recreate a specific sequence of events. | ||||
Additional Information | I reported this a long time ago, but never put it into bugtracker because I couldn't create a list of steps to reproduce it. Since it can't be reproduced on demand, the only thing I can suggest is that the code that handles layers be inspected for possible places where this type of thing can happen. I noticed there's an existing issue about pieces of a func_static ending up in different layers. I also have that happening, and perhaps it's the same root problem. It's quite frustrating having to put things back where they belong, then later finding a different collection of things have changed layers and I have to do it all over again. | ||||
Tags | No tags attached. | ||||
Ah, I though was just me! I have been having this issue with a few large maps I have been working on, constantly having to re-add stuff to their respective layers. I though it was just me and I was loosing the plot. |
|
It appears that this primarily happens when loading a saved map. Probably what's happening is that the node order kept in the darkradiant layer information is getting out of sync. It's as if an extra node or nodes is being inserted into the order, or one or more are being skipped. My workaround is to keep DR open all the time. If I don't, I spend the first 30 min after loading the previous night's work putting things back into their correct layers. |
|
Does this happen in small maps as well? Or just with our presumably large working map? | |
I can't say for sure that this happens or doesn't happen in small maps. I just created a new map with 20 brushes, func_statics, and AI in it. I defined 10 layers and spent time putting the objects into layers, moving them among layers, closing, reopening, shutting down DR and reopening. The problem didn't occur. So either it's something that begins to happen as a map grows, or when a specific object type is added, deleted, clipped, made into a func_static, etc. Very hard to pin down. I looked briefly at the sources and the darkradiant layer file that's saved, and couldn't make hide nor hair of what could be wrong. Unfortunately, the layer information is kept 'per node' and there's no identifying info in the node data that ties it to a specific object, other than position in the node list. Something that might help in debugging this would be for DR to add an entity name / brush number / primitive number for each node as it's saved, and ignore that extra info when the map is read. This won't hurt DR function, but might provide a clue as to what's going on by looking at snapshots of the saved layer data as time goes by, especially near DR restarts and map reloads. |
|
Ok. But I gather it's kind of reproducible in your work-in-progress map? Might this be a suitable test bed for me? | |
I can ship you a snapshot of my WIP for testing, sure. Will send in a PM. |
|
I'll set this to resolved after the recent tests with 1.7.0pre5. Can be re-opened if necessary. | |
This is still happening in 1.7.0 (using the x64 version) | |
@Biker, is this still happening to you? I haven't seen it in the last 4 years. |
|
Yes, I am fairly sure I have seen this still happening. But can't say for certain which map I was working on when I saw it last. |
|
I will monitor this and close the tracker, as I am the only one working on very large maps atm. |
|
This still happens on 2.6.0 but only for a small amount of item and even then only on very large maps. | |
Date Modified | Username | Field | Change |
---|---|---|---|
21.07.2011 14:17 | grayman | New Issue | |
22.07.2011 10:40 |
|
Note Added: 0003947 | |
25.08.2011 13:49 | grayman | Note Added: 0004003 | |
25.08.2011 16:39 | greebo | Note Added: 0004004 | |
25.08.2011 16:39 | greebo | Status | new => acknowledged |
25.08.2011 17:35 | grayman | Note Added: 0004005 | |
25.08.2011 18:28 | greebo | Note Added: 0004006 | |
25.08.2011 18:44 | grayman | Note Added: 0004007 | |
11.09.2011 11:55 | greebo | Assigned To | => greebo |
11.09.2011 11:55 | greebo | Status | acknowledged => assigned |
21.09.2011 17:14 | greebo | Note Added: 0004038 | |
21.09.2011 17:14 | greebo | Status | assigned => resolved |
21.09.2011 17:14 | greebo | Fixed in Version | => 1.7.0 |
21.09.2011 17:14 | greebo | Resolution | open => fixed |
21.09.2011 17:14 | greebo | Target Version | => 1.7.0 |
18.03.2012 13:43 |
|
Note Added: 0004416 | |
18.03.2012 13:43 |
|
Status | resolved => assigned |
18.03.2012 13:43 |
|
Resolution | fixed => reopened |
24.03.2012 16:53 | greebo | Assigned To | greebo => |
25.09.2016 18:29 | grayman | Note Added: 0008349 | |
25.09.2016 19:49 |
|
Note Added: 0008355 | |
25.09.2016 19:50 |
|
Note Edited: 0008355 | |
28.03.2018 09:26 |
|
Assigned To | => user81 |
28.03.2018 09:26 |
|
Note Added: 0010191 | |
03.04.2018 11:13 |
|
Note Edited: 0010191 | |
22.12.2018 09:51 |
|
Note Added: 0011022 | |
22.12.2018 09:51 |
|
Status | assigned => closed |
22.12.2018 09:51 |
|
Resolution | reopened => fixed |
22.12.2018 09:51 |
|
Fixed in Version | 1.7.0 => 2.6.0 |