View Issue Details

IDProjectCategoryView StatusLast Update
0002819DarkRadiantMap Editingpublic22.12.2018 09:51
Reportergrayman Assigned Touser81 
PrioritynormalSeveritynormalReproducibilitysometimes
Status closedResolutionfixed 
Product Version1.6.1 
Target Version1.7.0Fixed in Version2.6.0 
Summary0002819: Brushes, patches, entities, etc. change layers on their own
DescriptionAfter 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 ReproduceIt's impossible to recreate a specific sequence of events.
Additional InformationI 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.
TagsNo tags attached.

Activities

user81

22.07.2011 10:40

  ~0003947

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.
grayman

grayman

25.08.2011 13:49

administrator   ~0004003

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.
greebo

greebo

25.08.2011 16:39

administrator   ~0004004

Does this happen in small maps as well? Or just with our presumably large working map?
grayman

grayman

25.08.2011 17:35

administrator   ~0004005

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.
greebo

greebo

25.08.2011 18:28

administrator   ~0004006

Ok. But I gather it's kind of reproducible in your work-in-progress map? Might this be a suitable test bed for me?
grayman

grayman

25.08.2011 18:44

administrator   ~0004007

I can ship you a snapshot of my WIP for testing, sure.

Will send in a PM.
greebo

greebo

21.09.2011 17:14

administrator   ~0004038

I'll set this to resolved after the recent tests with 1.7.0pre5. Can be re-opened if necessary.

user81

18.03.2012 13:43

  ~0004416

This is still happening in 1.7.0 (using the x64 version)
grayman

grayman

25.09.2016 18:29

administrator   ~0008349

@Biker, is this still happening to you?

I haven't seen it in the last 4 years.

user81

25.09.2016 19:49

  ~0008355

Last edited: 25.09.2016 19:50

View 2 revisions

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.

user81

28.03.2018 09:26

  ~0010191

Last edited: 03.04.2018 11:13

View 2 revisions

I will monitor this and close the tracker, as I am the only one working on very large maps atm.

user81

22.12.2018 09:51

  ~0011022

This still happens on 2.6.0 but only for a small amount of item and even then only on very large maps.

Issue History

Date Modified Username Field Change
21.07.2011 14:17 grayman New Issue
22.07.2011 10:40 user81 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 user81 Note Added: 0004416
18.03.2012 13:43 user81 Status resolved => assigned
18.03.2012 13:43 user81 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 user81 Note Added: 0008355
25.09.2016 19:50 user81 Note Edited: 0008355 View Revisions
28.03.2018 09:26 user81 Assigned To => user81
28.03.2018 09:26 user81 Note Added: 0010191
03.04.2018 11:13 user81 Note Edited: 0010191 View Revisions
22.12.2018 09:51 user81 Note Added: 0011022
22.12.2018 09:51 user81 Status assigned => closed
22.12.2018 09:51 user81 Resolution reopened => fixed
22.12.2018 09:51 user81 Fixed in Version 1.7.0 => 2.6.0