View Issue Details

IDProjectCategoryView StatusLast Update
0000257DarkRadiantMap Editingpublic27.06.2008 23:14
ReporterSneaksieDave Assigned Togreebo  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version0.9.0 
Target Version0.9.7Fixed in Version0.9.7 
Summary0000257: Bad name increment for entities after saving
Description-Open a new map
-Create a func_static
-Save the map under any name
-Duplicate the func_static

Now they are (presumably) named both func_static_1.
TagsNo tags attached.

Relationships

related to 0000431 closedgreebo cloning path entities creates broken connections 
related to 0000657 closedgreebo Properties needing smart increment on load of prefab and duplicate 
child of 0000635 closedgreebo Fix or rewrite Namespace module 

Activities

greebo

greebo

05.06.2007 08:47

administrator   ~0000669

This seems to happen with "unnamed" maps only. Saving a named map ("test_duplicate.map") under a new name ("test_dup2.map") doesn't produce this bug.
greebo

greebo

05.06.2007 14:14

administrator   ~0000670

Last edited: 05.06.2007 14:14

Ok, I give up on this now. There is something weird going on.

For the records: the GlobalNamespace is somehow being emptied when an unnamed map is saved under a new name. This does not happen when saving previously named maps.

This occurs somehwere in a destructor chain. The ReferenceCache::ResourcePtr of the Map is newly set on renaming and right after the old ResourcePtr is replaced (which triggers the ModelResource destructor) the Namespace is empty. I have no idea what is going on here, probably something nasty.

SneaksieDave

SneaksieDave

17.06.2007 17:04

reporter   ~0000707

Hmm, I get the bug even with a map named, e.g., test14.map.

New map
Create brush, convert to func_static
Deselect
Save as test14
Re-select and duplicate brush; I now have two func_static_1's.

Anyway, it's still pretty easy to work around. Reloading the map clears the problem; duplicating twice clears the problem.
greebo

greebo

17.06.2007 18:01

administrator   ~0000708

I know, for some reason the list of namespaced items gets cleared when saving unnamed maps, and I don't know why this occurs.
tels

tels

03.11.2007 12:19

reporter   ~0000813

Just for the record, I get the "duplicate" names issue quite often, and I do not save "unnamed" maps at all :)

However, I couldn't really find out when this happens, I just know I have this like twice a day :/

What would help if there was a way to find duplicate named entities in DR, or even search for an entity by name (given my luck, it is probably already implemented, but I can't find it :)

Right now the only time you find out about duplicates is loading the map in doom - and then it can be quite difficult finding the culprit.
Baddcog

Baddcog

03.01.2008 21:39

updater   ~0000971

Last edited: 03.01.2008 21:43

I've been getting this too.

I have saved maps under a name: bc_manor_01, 02...

Duplicate names happens when I clone and also when I create a new entity.
 Can't say I've had the problem when creating a model, not sure about that.

It doesn't seem to happen for any particular reason. It happens alot.
------
Guess this goes here too.

Door names/or door handle names change.

Door1 and handle 1, one will become door01, or door0.
Haven't determined how exactly the name changes, will try to keep an eye on that.
 Doesn't happen as much as the other objects but happens too much.
Makes the door handles end up attaching to another door or just not attached to door at all.

SneaksieDave

SneaksieDave

02.03.2008 20:16

reporter   ~0001079

Last edited: 02.03.2008 20:18

I've changed the description from "func_*" to "entities". I've gotten this numerous times over the past two days for lights. My guess is it's the first duplicate created after a re-launch of DR or load of map. I get duplicate "light_1" entities after every time I have to shutdown and restart DR (because it and Doom3 are battling for system resources), and then I make a copy of a light.

Komag

Komag

02.04.2008 23:43

reporter   ~0001123

I've had it happen again recently and it seemed to be right after I saved my map with a new name (from komag_city60 to komag_city61) and then duped a few things like lights. It sure it annoying

Issue History

Date Modified Username Field Change
08.04.2007 17:51 SneaksieDave New Issue
08.04.2007 19:22 greebo Status new => acknowledged
05.06.2007 08:47 greebo Note Added: 0000669
05.06.2007 14:14 greebo Note Added: 0000670
05.06.2007 14:14 greebo Note Edited: 0000670
17.06.2007 17:04 SneaksieDave Note Added: 0000707
17.06.2007 18:01 greebo Note Added: 0000708
03.11.2007 12:19 tels Note Added: 0000813
07.12.2007 09:11 greebo Relationship added related to 0000431
03.01.2008 21:39 Baddcog Note Added: 0000971
03.01.2008 21:43 Baddcog Note Edited: 0000971
02.03.2008 20:16 SneaksieDave Note Added: 0001079
02.03.2008 20:17 SneaksieDave Summary Bad name increment for func_* after saving => Bad name increment for entities after saving
02.03.2008 20:18 SneaksieDave Note Edited: 0001079
25.03.2008 11:41 greebo Severity minor => major
25.03.2008 11:41 greebo Projection none => major rework
25.03.2008 11:41 greebo ETA none => 2-3 days
02.04.2008 23:43 Komag Note Added: 0001123
04.04.2008 07:36 greebo Target Version => 0.9.7
05.04.2008 08:53 greebo Status acknowledged => confirmed
08.04.2008 18:22 greebo Relationship added child of 0000635
03.05.2008 07:18 greebo Relationship added parent of 0000657
03.05.2008 07:18 greebo Relationship deleted parent of 0000657
03.05.2008 07:18 greebo Relationship added related to 0000657
27.06.2008 21:36 greebo Status confirmed => assigned
27.06.2008 21:36 greebo Assigned To => greebo
27.06.2008 21:36 greebo Status assigned => resolved
27.06.2008 21:36 greebo Fixed in Version => 0.9.7
27.06.2008 21:36 greebo Resolution open => fixed
27.06.2008 21:38 greebo ETA 2-3 days => < 1 month
27.06.2008 21:38 greebo Build => 3636
27.06.2008 23:14 SneaksieDave Status resolved => closed