DarkRadiant 1.7.0 pre-release test

[Bikerdude]

Between the crashing and the FS duplication that causes Doom3 to crash I am going back to 1.6.1 till the next version of 1.7

 

Oh and I dont know if this can be fixed in DR1.7.x but the old bug where importing an FS into DR and the name gets changed so that there is a '2' on the end is also getting very tiresome, when I have to do leaking fixing on an entire map and find all of my entity names changes etc.

[greebo]

I could reproduce the func_static issue reported earlier, I'm looking into it now.

[Bikerdude]

ta.

[RPGista]

Great, that one really made me loose some good work... My fault for not saving compulsively.

[Bikerdude]

Yes, definitely.

 

-bug tracker 02914

[greebo]

Ok, issue #2914 is fixed, here is the new pre-release build (1.7.0pre11):

 

http://www.dramthethief.com/darkmod/files/darkradiant/darkradiant-1.7.0pre11.exe (32 Bit)

http://www.dramthethief.com/darkmod/files/darkradiant/darkradiant-1.7.0pre11.x64.exe (64 Bit)

 

Changes:

 

- Fixed the func_static renaming/corruption issue

- Fixed the crash during rendering

- Fixed entity colours gone missing (some entity boxes were rendered with "shader not found")

[Bikerdude]

testing..

[RPGista]

Reporting:

 

* Func_static issue: has been solved, in the sense that undoing and then redoing a "revert to func_static" operation doesn't makes DR crash to the desktop anymore, but strangely whenever I redo a func_static, it is rendered as invisible on the viewports - you can select it, and they will show up, but will only display correctly if you revert back to world_spawn.

 

* The Background image still doesnt work for me, all I get is a square plane with no shader texture.

[Bikerdude]

can you do some tests so i can test from my end.

 

Also i found another bug of sorts.

 

If while opening up the insert model lister window, you click on the x to close window whiles its trying list all the models it freezes inplace, DR dosent crash per say but you cant do anything.

[greebo]

* Func_static issue: has been solved, in the sense that undoing and then redoing a "revert to func_static" operation doesn't makes DR crash to the desktop anymore, but strangely whenever I redo a func_static, it is rendered as invisible on the viewports - you can select it, and they will show up, but will only display correctly if you revert back to world_spawn.

Confirmed, I'll try to look into this today or tomorrow.

 

 

* The Background image still doesnt work for me, all I get is a square plane with no shader texture.

I haven't looked into this one yet.

 

If while opening up the insert model lister window, you click on the x to close window whiles its trying list all the models it freezes inplace, DR dosent crash per say but you cant do anything.

You mean you hit the X on the progress dialog which showing how many models were found?

[Bikerdude]

You mean you hit the X on the progress dialog which showing how many models were found?

yeah.

[greebo]

can you do some tests so i can test from my end. Also i found another bug of sorts. If while opening up the insert model lister window, you click on the x to close window whiles its trying list all the models it freezes inplace, DR dosent crash per say but you cant do anything.

Hm, can't reproduce that, for me it just shows the Model Selector, but no hang or crash.

 

* The Background image still doesnt work for me, all I get is a square plane with no shader texture.

The background image is rendering for me. Which type of image (format) are you trying to display?

[Bikerdude]

Ok will try to knock up a reproducible set of steps etc.

[RPGista]

After some trials I was able to render the image, maybe it had something to do with file size, since they were all JPGs...

 

So far, no new bugs. I'm also just doing basic geometry building, so I guess a more experienced mapper would be needed to check for advanced features; I was sure there was a problem with grouping brushes into a func_static, the new "grouped" entity would not carry the original shape's layer, and I would need to set the static to that layer again. But then I ran some more tests and it worked, it retained the layer of the original brushes (regardless of the default layer, which is what I wanted), so I was probably just being paranoid. It also seems to work the other way around, if you set a new layer for the grouped static, when you revert back the brushes also keep the new layer, which is perfect. Just need to test these things methodically, there are too many layers and little objects in my map right now... EDIT: Now that I read this, it doesnt make sense, if you want to group a set of objects all on different layers, the func_static should probably override those and set them all, along with itself, to the default layer? Could you please explain how it works exactly greebo?

 

A question/suggestion: I mostly use func_static as a way of grouping many related objects (I'm also aware they have other technical aspects, but I'm just not there yet). I'm experiencing difficulties when trying to convert a series of objects that include grouped statics already, in this case you cannot apply group changes to the whole selection, such as reverting them all back to world spawn or making it all a func static - you would have to manually select and modify each object so you can then apply a group change to the now homogeneous set of objects. Would it be useful to be able to overide existing differences between world spawns and func statics inside a selection and just apply a group change to all of them at once, keeping unnaltered those that already possess the wanted state - ex: a set of 10 objects selected, 8 brushes and 2 func static, you want to overide that and make them all a single func static, without having to manually revert back both the existing statics and THEN applying the change. The problem I already see is that if you do the opposite and apply a revert back to world spawn on a selection of func_sttics that includes statics that can't be reverted, like models and etc... Unless they are already immune to the command.

 

Maybe I'm thinking of func_statics the wrong way, as too much of a grouping tool. It would be nice to be able to group objects, then group groups of objects on "layers" (a group that includes other groups), and then be able to apply simple changes to all objects inside the group - textures and the like. Unless you create a layer for each set of related objects (so you can insta-select the whole bunch), there's no simple way to select them all to apply group changes, specially when objects in the same layer are scattered around the whole building (like a "wood structure" layer, for example). I do that by grouping them with func_static, but since you can't do any changes to them as you would with a normal selection of a set of objects, it gets a bit risky to be reverting them back to change something, you better not let go of that selection!, otherwise you'll have to hand pick all the related objects to be able to make them a group again.

 

These are just ramblings, you CAN overcome all of these difficulties with patience and time, so not a crucial feature by any means.

Edited November 15, 2011 by RPGista

[greebo]

EDIT: Now that I read this, it doesnt make sense, if you want to group a set of objects all on different layers, the func_static should probably override those and set them all, along with itself, to the default layer? Could you please explain how it works exactly greebo?

The primitives you are converting to func_static are indeed all assigned to the same layer(s), in fact it's the last primitive which determines the target layer set. In other words, after the operation all func_static members have the same set of layers, the one of the primitive last selected.

 

ex: a set of 10 objects selected, 8 brushes and 2 func static, you want to overide that and make them all a single func static, without having to manually revert back both the existing statics and THEN applying the change.

There is the "Reparent Primitives to entity" option in the context and/or Edit menu. IIRC you need to select a couple of primitives and as last object select the func_static, then the option should be available. It adds the selected primitives to the func_static. I'm not quire sure but I think you can't do it with 2 func_statics, so you have to convert one of the func_statics to worldspawn first, then select the other primitives and then select the func_static as last object, before combining them all.

 

Maybe I'm thinking of func_statics the wrong way, as too much of a grouping tool. It would be nice to be able to group objects, then group groups of objects on "layers" (a group that includes other groups), and then be able to apply simple changes to all objects inside the group - textures and the like. Unless you create a layer for each set of related objects (so you can insta-select the whole bunch), there's no simple way to select them all to apply group changes, specially when objects in the same layer are scattered around the whole building (like a "wood structure" layer, for example). I do that by grouping them with func_static, but since you can't do any changes to them as you would with a normal selection of a set of objects, it gets a bit risky to be reverting them back to change something, you better not let go of that selection!, otherwise you'll have to hand pick all the related objects to be able to make them a group again.

The "parenting" or "grouping" feature is a very old request to DarkRadiant, and incidentally one that is very hard to implement, much harder than layers have been.

 

Just to make sure you're aware, there is the "Selection Set" feature accessible through the top menu bar which allows you to save or recall selections by name. It's not something that is preserved between DarkRadiant sessions, but as quick measure it's working ok.

[greebo]

Here's another pre-release build (pre12) with the func_static-undo-redo-disappearing-brushes bug fixed:

 

http://www.dramthethief.com/darkmod/files/darkradiant/darkradiant-1.7.0pre12.exe (x86)

http://www.dramthethief.com/darkmod/files/darkradiant/darkradiant-1.7.0pre12.x64.exe (x64)

[RPGista]

Brilliant, nice work and thanks a lot for the explanations, I was confused there for a second. That reparent tool and the selection set will help for sure,

[grayman]

Just filed this.

[greebo]

I added a comment to the issue report, the newly clipped brush is only appearing to go into the preferred layer. It's properly assigned to the layer set of the originating brush, but it's visibility is wrongly calculated during the process. Expect it to be fixed in SVN and future builds.

[Bikerdude]

Has anyone been having surface selection problems? working on a map last night and I wasn't able to visibly select the surface of a brush with the "coloured water texture" on a bursh, and the only way I knew it was selected was the small blue dot...

[grayman]

Has anyone been having surface selection problems? working on a map last night and I wasn't able to visibly select the surface of a brush with the "coloured water texture" on a bursh, and the only way I knew it was selected was the small blue dot...

 

I haven't seen any general problems. I'm not working with water atm, though. I'll switch maps when I get a chance and try some existing water.

[grayman]

A couple pre12 nits:

 

1 - when the auto-write kicks in, the camera and ortho views will momentarily snap back to whatever they were prior to my most previous operation, for the duration of the write. When the write completes, the views snap back to what they were before the write. For example, I hid a layer and right after that, the auto-write started. My layer was visible again for the duration of the write, then it hid itself again. Yesterday I deleted a light, the auto-write started, and the light appeared again for the duration of the write, then it was gone.

 

2 - when selecting a file to open, if you're in Doom3/mymission/maps, the open dialogue box shows the file structure at the top of the screen with small labeled boxes: Doom3, mymission, maps. If you click on the Doom3 box, the main window travels up two levels to show you the contents of Doom3, but the file structure at the top still shows Doom3/mymission/maps. I think it ought to reflect which folder's contents it's displaying in the main window.

[greebo]

1 - when the auto-write kicks in, the camera and ortho views will momentarily snap back to whatever they were prior to my most previous operation, for the duration of the write. When the write completes, the views snap back to what they were before the write. For example, I hid a layer and right after that, the auto-write started. My layer was visible again for the duration of the write, then it hid itself again. Yesterday I deleted a light, the auto-write started, and the light appeared again for the duration of the write, then it was gone.

That has been like that for quite some time now, and I assume it's some kind of front-back-buffer swappage or something like that. When saving I'm completely blocking rendering in the ortho and camera view, so I don't really know where that is coming from.

 

2 - when selecting a file to open, if you're in Doom3/mymission/maps, the open dialogue box shows the file structure at the top of the screen with small labeled boxes: Doom3, mymission, maps. If you click on the Doom3 box, the main window travels up two levels to show you the contents of Doom3, but the file structure at the top still shows Doom3/mymission/maps. I think it ought to reflect which folder's contents it's displaying in the main window.

This is GTK behaviour, I guess it's by design. It allows you to move back to the deeper folder you previously where when copying files, or at least that's what I can make out of it. I can't really change it anyway, I'm afraid.

[Tirek]

That has been like that for quite some time now, and I assume it's some kind of front-back-buffer swappage or something like that. When saving I'm completely blocking rendering in the ortho and camera view, so I don't really know where that is coming from.

 

 

This is GTK behaviour, I guess it's by design. It allows you to move back to the deeper folder you previously where when copying files, or at least that's what I can make out of it. I can't really change it anyway, I'm afraid.

 

Yes, that is the expected behaviour of GTK. It's meant to replace the "forward" button.

[grayman]

Okay on both counts, then. Thanks.