DarkRadiant 1.7.0 pre-release test

[grayman]

- Especially aimed at grayman: I fixed that one layer issue we PM'd about, and the layer corruption on map load might be fixed in this build. Please beware that loading a map saved with the recent prereleases will almost certainly corrupt your layers - I'm sorry for that but I can't do much against that. Loading a 1.6.1 map should be fine though.

 

I loaded my latest map, where the layers were probably 99% correct, and 1.6.3 loaded it fine. I probably only have about 10 items out of place, and they might very well have been that way when I shut down 1.6.2 a few mins ago.

 

Thanks!

 

(save often, save often, save often ... )

[grayman]

I noticed today when working with 1.6.2 that a couple items were assigned to the Default layer when that layer was hidden.

 

I had two layers visible and added these lights:

 

atdm:statue_with_gothic_torch_left

atdm:statue_with_gothic_torch_right

 

They showed up fine, but a while later, when I did "show all", "hide all", and then made the 2 layers I was working with visible, the two statues disappeared.

 

I found them in Default.

 

Perhaps this is related to #2759, which is fixed in the beta (though I haven't verified that).

 

I found this comment by Fidcal in #2494: "It might need a 'set current layer' button or similar so the mapper chooses where all new stuff goes whether visible or not."

I think that's an excellent suggestion.

[grayman]

This problem is fixed.

 

Thanks!

[grayman]

When I select "Hide Unused" on the Textures tab, decal textures that are in use are hidden.

 

If I use a decal texture that was hidden because of this bug, it stays visible after I select "Hide Unused" again.

 

It's as if DR thinks decals are "used" only if they're applied since that last time the "Hide Unused" button was pressed.

[grayman]

Just had my first DR crash.

 

Performed about a dozen undoes to correct a mistake, then went to delete 4 func_static parts and it crashed.

 

 

Save often, folks.

 

I suspect that if you cancel an autosave (because it's intrusive and you're in the middle of something), it corrupts the previous autosave. I tried opening the autosave and DR crashed coming up. So keep that in mind.

 

Edit: And, as an extra added benefit, all my layers are now corrupted, which means hours of work getting things back where they belong.

 

I really really really wish the layer data was kept in the *.map file, and not in a separate *.darkradiant file, because keeping the two files in sync is apparently a major problem.

 

 

[grayman]

DR 1.6.3 messes up brush textures after a clip.

 

Here's a highlighted brush I'm about to clip. Note the normal brick texture, which is scaled 0.25/0.25.

 

 

Here's the same brush after the clip, with both pieces highlighted. Note the bad texture on the larger piece. This is still the same brick texture, but it's badly scaled, even though the surface inspector pane says it's scaled 0.25/0.25.

 

[greebo]

I had two layers visible and added these lights:

 

atdm:statue_with_gothic_torch_left

atdm:statue_with_gothic_torch_right

So you're saying that these entities were created in Default while that layer was not visible? Or how can I reproduce that?

 

When I select "Hide Unused" on the Textures tab, decal textures that are in use are hidden.

 

If I use a decal texture that was hidden because of this bug, it stays visible after I select "Hide Unused" again.

 

It's as if DR thinks decals are "used" only if they're applied since that last time the "Hide Unused" button was pressed.

I guess the Texture Browser is pretty much the oldest piece of UI code in DarkRadiant - it's possible that it doesn't work properly anymore. Has it been working in 1.6.1?

 

Just had my first DR crash.

 

Performed about a dozen undoes to correct a mistake, then went to delete 4 func_static parts and it crashed.

Any chance this can be reproduced?

 

I suspect that if you cancel an autosave (because it's intrusive and you're in the middle of something), it corrupts the previous autosave. I tried opening the autosave and DR crashed coming up. So keep that in mind.

You can cancel an autosave? Didn't realise that. Which autosave mode are you in - snapshots or regular? If regular, can you tell me what exactly happened and which file had been corrupted afterwards?

 

 

Edit: And, as an extra added benefit, all my layers are now corrupted, which means hours of work getting things back where they belong.

Was this due to the save cancellation or something else?

 

I really really really wish the layer data was kept in the *.map file, and not in a separate *.darkradiant file, because keeping the two files in sync is apparently a major problem.

In order to maintain compatibility with D3 editing I can't really mess with the .map format. Keeping stuff in comments is a major pain and it's not clean design, meaning I'd have to re-write the map parsers not to ignore the comments (while comments always should be ignored by design). It'd be possible to increase the map file version for TDM, but then we'd lose layers functionality for regular Doom 3 or Quake 4 editing. Hence the design decision was to create the satellite .darkradiant file next to the .map.

 

DR 1.6.3 messes up brush textures after a clip.

 

Here's a highlighted brush I'm about to clip. Note the normal brick texture, which is scaled 0.25/0.25.

 

 

Here's the same brush after the clip, with both pieces highlighted. Note the bad texture on the larger piece. This is still the same brick texture, but it's badly scaled, even though the surface inspector pane says it's scaled 0.25/0.25.

 

Weird, I'll look into that one.

 

Huge thanks for testing, grayman, this is appreciated. It's needed to get DR 1.7.0 into a stable state. It's a "big" release, 'cause there are about 3 months of continuous coding in between 1.6.1 and this 1.7.0 with major code changes in it.

[Bikerdude]

Huge thanks for testing, grayman, this is appreciated.

Any thought on the selection bug I mentioned or is it the same the issue GM mentioned..?

 

And also the weird prefab crash that only happens on some far only 1 of my maps..?

[greebo]

Sorry, missed your post.

 

This is still the case.

Can you give me that small section and save it as a testmap, please? With some reproduction steps?

 

Also only on 1 map do I get a crash when importing a tdm prefab (in this case the Ai_eating prefab). Other maps I can import the prefab just fine - The error is below.

If this is reproducible in your map only, I'm gonna need a copy of it to debug it. Can you upload it and send me the link via PM, please?

 

On another note, thanks for making the func_emitters wireframe, much easier to see the particle effect now!

You're welcome, I meant to mention it in the list above.

[Bikerdude]

• Can you give me that small section and save it as a testmap, please? With some reproduction steps?
• If this is reproducible in your map only, I'm gonna need a copy of it to debug it. Can you upload it and send me the link via PM, please?

• Will do when I get home this afternoon!
• Yes!, will pm you a download link.

[OrbWeaver]

In order to maintain compatibility with D3 editing I can't really mess with the .map format. Keeping stuff in comments is a major pain and it's not clean design, meaning I'd have to re-write the map parsers not to ignore the comments (while comments always should be ignored by design). It'd be possible to increase the map file version for TDM, but then we'd lose layers functionality for regular Doom 3 or Quake 4 editing. Hence the design decision was to create the satellite .darkradiant file next to the .map.

 

Would it be of any benefit to have an MD5/SHA-1/CRC32 checksum of the .map file inside the .darkradiant file, so that DR would know not to load the wrong .darkradiant file for the current map? It wouldn't prevent data loss of course, but it might help with crash problems where the files both exist but are not synchronised.

[greebo]

If we can figure out a way of computing a reliable checksum - then yes. Keep in mind we have many rounding effects going on in the .map file: even if nothing changes almost every line in the map file is different between saves.

[Bikerdude]

Greebs, you have a Pm.

[Tels]

If we can figure out a way of computing a reliable checksum - then yes. Keep in mind we have many rounding effects going on in the .map file: even if nothing changes almost every line in the map file is different between saves.

 

Yeah, but since the .darkradiant file only contains entities and their layers, wouldn't it be sufficient to just hash this data (entity ID, and layer ID) and compare these? If these are equal, everything is well (even if the rest of the map file changed, loading the "wrong" file won't have any visible changes) and if these differ, something is amiss.

 

Which leads to the question, couldn't we embedd this data directly into the map file as extra entity spawnargs that get read (and removed) upon map load, and get written upon map write?

 

The engine could then be simply teached to ignore any "layer" spawnarg, or even "dr_*" (as in "dr_layer", "dr_comment", "dr_bla") spawnargs. (Even if it does not ignore it, they would not do much harm).

 

I am pretty sure this was rejected for a reason, but maybe it is time to reconsider it? That way the user wouldn't have to bother with two files, they could never get out of sync etc etc.

[grayman]

Which leads to the question, couldn't we embedd this data directly into the map file as extra entity spawnargs that get read (and removed) upon map load, and get written upon map write?

 

Worldspawn brush layers can also be corrupted, and they collectively have only one set of spawnargs.

 

If we have to have the darkradiant file, what about giving it different data, rather than depending solely upon order? Rather than equating node order with layer number, write the brush # or entity # along with the accompanying layer #? That would tie a layer to a specific item. In the case of entities, they all have names, so the layer could be tied to the entity name (in case the root cause is that entity numbers are getting corrupted, and not node numbers per se.)

 

Somehow the ordering is being messed up, which makes using layers frustrating at best, useless at worst. The strongest evidence is that it occurs at read or write time, but I swear I've had things switch layers on their own during DR sessions. So far, it's been impossible to nail down a specific sequence of events that lead to corruption.

 

I'm sure it'll get fixed at some point.

 

Thanks.

[grayman]

So you're saying that these entities were created in Default while that layer was not visible? Or how can I reproduce that?

 

I have two layers visible, neither of which is Default. I just tried this with two different pairs of visible layers, with the same result.

 

Create the two light entities mentioned above.

 

Hide either of the two visible layers, and the statues disappear.

 

Show the layer I just hid, and it comes back, but the statues don't.

 

Show Default. The statues appear.

 

I guess the Texture Browser is pretty much the oldest piece of UI code in DarkRadiant - it's possible that it doesn't work properly anymore. Has it been working in 1.6.1?

 

This is the first time I've noticed this behavior. I usually work w/o hiding unused textures, and I must've hit the hide button by mistake and suddenly I couldn't see the decals. Took some time to figure out what was making them hidden.

 

 

Any chance this can be reproduced?

 

With one layer visible that uses scorch_circle, if I hide unused textures, that decal is missing from the set. At this point, the only decal that shows is grime_corners_medium, which isn't used in the layer.

 

Have to go. Will answer other questions later.

[Bikerdude]

Did some more testing and the prefab preview disappearing issue is still there!

 

And with regard to the prefab crash issue, DR popup says "importing map" should it say importing prefab..? I have treble checked and I am defiantly importing a prefab using the import prefabs option/s

 

And another bug with version pre3: If the skin of a model is changed is goes invisible, but can still be selected (which is the only way you can see where it is), see attached. When reloading the map the model is visible again. Also DR wont commit the any changes made to the skin of a model.

[grayman]

You can cancel an autosave? Didn't realise that. Which autosave mode are you in - snapshots or regular? If regular, can you tell me what exactly happened and which file had been corrupted afterwards?

 

Yes, autosave has a Cancel button. Lately, with a large map, I've been hitting it when I'm in the middle of an editing groove, and waiting for autosave to finish breaks the spell.

 

Regular, I guess, because the "Save Snapshots" box wasn't checked.

 

It was after the crash, and I started DR again and loaded my map. After noting that the layers were now corrupted, I tried to open the autosave version. DR's loading bar filled up real fast, hit 100%, and it crashed.

 

The last autosave attempt before the initial crash was one I aborted, which makes me think the previous file is wiped before writing the new one, and Cancel doesn't restore what was there.

 

 

In order to maintain compatibility with D3 editing I can't really mess with the .map format. ...

 

Understood. Having chosen a design, the design's bugs just need to be wrung out. This one is particularly painful, because when it happens, it takes hours to undo the damage for a large map.

[grayman]

I notice that the AI models in DR now have their arms at their sides, instead of straight out.

 

Does this mean that AI ragdolls will now fall differently at map start? Or is it just DR's representation of them that has changed?

[grayman]

@greebo: sent you a PM re: layer problem.

[grayman]

I'm going to table DR testing for a while and get back to coding.

[grayman]

Well, I'm using DR 1.6.3 while testing bug fixes.

 

And I find that if I add an AI, then create any other entity, the AI disappears from the camera view when the "create entity" preview window paints the new entity. It's as if the AI's image in the camera view gets wiped when his image in the preview window gets wiped to make way for the new entity's image.

 

The AI is still drawn on the ortho views, but he only shows up in the camera view if he's selected.

 

I'm using the "checkerboard" camera view, whatever that's called.

 

Another example is that I created a barrel, then when I brought up the entity dialogue to create an AI (trying to rest the reverse sequence), the first barrel disappeared from the camera view when the entity dialogue painted it in the preview window. Didn't need to change entities in this case.

[grayman]

This problem also occurs when two brushes are merged. The texture scale goes awry.

[Bikerdude]

This problem also occurs when two brushes are merged. The texture scale goes awry.

 

Ah yes I noticed this but forgot to mention it.

[greebo]

Ok, I've got a new pre-release build (#4) here for grabs:

 

http://www.dramtheth...t-1.7.0pre4.exe (32 Bit)

http://www.dramtheth...7.0pre4.x64.exe (64 Bit)

 

The following changes have made it into this build since pre3:

 

- Model skin handling should be fixed now - before models were disappearing or not reflecting their skin setting. This also fixes post #72 in this thread.

- Fixed brush texture scales going off limits when doing operations like merge, clip, hollow, make room or subtract.

- Fixed grayman's report of entities being placed in the Default layer: (issue #2864 or post #52)

- Fixed the crash when importing prefabs (bikerdude's report in post #50).

- Cancelling a save operation no longer leaves corrupt files behind. DarkRadiant is now writing to temporary files which are moved over the destination when the saving went through (issue #2863).

- Also, DarkRadiant creates a .bak version of the .darkradiant file now too, not just the .map file. (issue #2865)

- Fixed some window textures not highlighting when selected (bikerdude's report in post #45).

- Fixed a crash when rendering MD5 models which don't have an idle animation.

 

Unfixed:

- The texture browser (show/hide unused) problem.

- The About dialog.

 

Finally, re: grayman:

I notice that the AI models in DR now have their arms at their sides, instead of straight out.

 

Does this mean that AI ragdolls will now fall differently at map start? Or is it just DR's representation of them that has changed?

No, it's just that MD5 models get the first frame of their idle pose assigned instead of the T-pose. This shouldn't affect ragdolls in any way, please let me know if you notice anything.