Itches, Glitches & Anything Else...

[Fidcal]

To add to the above, I saved a prefab and it saved a .darkradiant layer file with it. Is that intended?

[greebo]

To add to the above, I saved a prefab and it saved a .darkradiant layer file with it. Is that intended?

Not exactly, it's just a consequence of me not thinking about that yet. It will likely be removed, as prefabs layers cannot be reasonably merged into the map file.

[Fidcal]

Can't see the multiple renaming bug on bugtracker. I thought that was still open? I've had quite a bit of that recently with cloning and just now a massive one of maybe 50 or more in groups of 2 and 3 with the same entity name.

 

I have a theory if instead of cloning I saved out as a temp prefab and load it back in might have been OK. But just cloning a set of rooms seems disastrous if there are lot of entities in them.

 

 

On another topic. I saw the email saying the layer/opening last file bug is resolved for 097. Will that be available in a pre-097? At the moment I have to remember to delete the .darkradiant file every time before I launch DR.

 

I found a use for layers. When rotating rooms, entity origins get thrown into the void. Some are not easy to track down as the leak pointfile, even if it correctly names the entity, I can't always see it if it is small and lost in the maze and not near the origin. Assigning it to a layer and hiding the default helped find a vertical slender patch entity.

 

I'm having a fun afternoon here.

[greebo]

Can't see the multiple renaming bug on bugtracker. I thought that was still open? I've had quite a bit of that recently with cloning and just now a massive one of maybe 50 or more in groups of 2 and 3 with the same entity name.

Yes, this is probably the most pressing DarkRadiant issue ever, there must be about 5 bug reports regarding the entity names/duplication/number increase problem by now.

 

On another topic. I saw the email saying the layer/opening last file bug is resolved for 097. Will that be available in a pre-097? At the moment I have to remember to delete the .darkradiant file every time before I launch DR.

The crash I encountered when using your user.xml file was due to DarkRadiant trying to open a non-existent "last file", and the renderer crashed subsequently. I could fix both causes, but for a new pre-release you'd need to wait until the evening, when I get home.

[Fidcal]

That's OK - Don't rush. I just wasn't sure if it would be weeks in which case I might have gone back to 094.

 

I'm not sure about what you say about 'last file'. If I delete or remove the last map, DR doesn't crash - it just opens normally without the map. No problem.

 

The problem is if it DOES find the last file - then it crashes.

[greebo]

Ok, please try it again with this package:

 

http://208.49.149.118/TheDarkMod/DarkRadia...t-0.9.7pre4.exe

 

These issues have been addressed:

- Crash when changing maps and trying to save the preferences

- Crash on open if 'reload last map' pref set (need feedback, if this was actually fixed, maybe there are 2 issues)

- RMB mouse trap in Texture Browser

 

Regarding your problem with the "auto-load" feature, I need your feedback. If the problem still persists I need to test it again - I couldn't make out any crashes with your user.xml and the provided map apart from the one I fixed.

[Fidcal]

Hey thanks greebo! That seems to have fixed the autoload crash and also the texture browser RMB trap. Don't know about the preferences one. Did someone else post that? Or was it me?

[greebo]

Hey thanks greebo! That seems to have fixed the autoload crash and also the texture browser RMB trap.

You're welcome.

 

Don't know about the preferences one. Did someone else post that? Or was it me?

Angua told me. And I could debug that crash more or less by accident while hunting for the RMB texture browser bug, so it was some kind of a lucky strike.

[Fidcal]

I can confirm what I said yesterday that instead of cloning, saving out a large prefab containing entities then reloading it and the entity renumbering seems OK. Maybe there's a route there to fix the clone/renaming problem - perhaps save the clone to memory or even temp disk and reload it using the same function.

[Fidcal]

Below is the ground floor of my map. There is a similar upper floor but hidden here. I used region. From select it wouldn't work - maybe just too much or maybe (I thought later) I didn't wait long enough as a big selection like this takes a few seconds to process I guess. So I did this by surrounding it with a brush and set the region from that. I can't see any sign of the 'missing entities' problem I encountered last year (though it's hard to tell without a detailed comparison) so was that fixed?

 

Anyways, I'm just exploring the possibilites of what we can do now to hide/view different areas including this new layers method. One thing that concerns me about layers is it is a set of selected items. So if I made a layer of my ground floor and upper floor and hid one while I worked on the other, the layers would not include changes presumably from session to session - I'd have to add manually.

 

In Dromed you could use an 'area brush' which defined a volume in the map for viewing and processing in other ways. So any changes you made, additions/subtractions would all show next session. I'm just wondering what would happen if I put a large say caulk brush around the whole ground floor and left it there? So just select it as needed and set the region from that? Problem is the brush is destroyed but I guess one could quickly clone then set the region. Would caulk round a whole area be a problem in-game? Or suppose a new texture with no properties called say 'volume' or 'region'?

 

[greebo]

So I did this by surrounding it with a brush and set the region from that. I can't see any sign of the 'missing entities' problem I encountered last year (though it's hard to tell without a detailed comparison) so was that fixed?

Yes, this was among the things that got fixed during to the scenegraph rewrite back in March.

 

Anyways, I'm just exploring the possibilites of what we can do now to hide/view different areas including this new layers method. One thing that concerns me about layers is it is a set of selected items. So if I made a layer of my ground floor and upper floor and hid one while I worked on the other, the layers would not include changes presumably from session to session - I'd have to add manually.

I'm not sure what you mean here. The layers associations are indeed saved and next time you load the map, your layers are still there (at least they should be). Or am I missing your point?

[Fidcal]

If I create a room and assign it and all its contents to a layer and save the map then the next session I can hide everything but the layer and see the room and its contents exactly as I made it yesterday.

 

Now I put a table and chairs in the room and make other additions. Next few weeks I work on something else. Then I go back to work on that room. I hide everything else except that layer. But will I see the table and chairs?

 

As I understand it, a layer is not showing what is in a particular volume but only the items you manually select and add to the layer. That's fine. It's a way of [EDIT] re-selecting re-viewing a group of previous selections exclusively. They do not even need to be in proximity to one another. It's a grouping method not an area method.

 

What I think would be useful would be like the Dromed area brushes which you can keep in your map like any brush. They are not compiled into the game they are editor only. You can select one and select 'Me Only' at which point everything else is hidden so you can work on that one section or that one room. Any additions/changes to the map within the volume enclosed by that area brush will show - you do not need to select them or assign them to anything. Dromed only shows what is enclosed by the volume of the area brush.

 

So I'm wondering if we can use some nodraw brush or something to outline a volume. Leave it in the map. Then, when we want to work on that area we select that nodraw brush, clone it, select Region using brush to hide everything else.

 

My only reservation is, is there a material we can use that will have no effect whatsoever on the game, even if many of them overlap and enclose whole areas of the map?

[greebo]

I see what you mean. You want a way of defining a volume using brushes and assign a name to it? If there is a way to save a brush along with the map that is completely disregarded by the map compiler, I don't see a particular problem, but if such a brush is not possible, we would need to save that "special brushes" into the .darkradiant file.

 

A first step would to investigate if a large nodraw brush encompassing whole map areas will harm anything.

[Fidcal]

I just tried three giant nodraw brushes overlapping across my map and can't see any obvious problem but I've been wondering how would one test that absolutely? I mean, perhaps some subtle effect won't emerge until a special situation. I'll try this for a few weeks/months using the region setting and see if there are any ill-effects that disappear when I delete the region brushes. This is workable this way anyway. All I have to do to select an area is select the brush, hit space to clone it then set region from it. The clone is deleted leaving the original in place.

[Fidcal]

This crash caused by the .darkradiant file has returned unfortunately. Strange, because I haven't used layers. My map was fine yesterday and this morning. Did a little more work on a bevel. Saved it. exited to run TDM. Closed TDM. Open DR and it locks up. Tried 3 or 4 times including a reboot. Then delete the current .darkradiant file and it is fine again.

 

Is it relevant what I said before about two instances of DR showing in Task Manager during the crash even though there is only one visible?

 

Does it tell us anything that it has suddenly started like it did before even though it was working fine? In fact I just tried some earlier maps and now none of them work so it's nothing to do with the map nor a fault in the actual layer file I don't think but something that DR saves changes the way it handles the layer file on auto-load. But why does it only affect me?

 

I've disabled 'load last map at start' and this helps but not 100% as I still found it crashed once when opening my main map out of only 2 or 3 attempts though.

 

Another bug has been occuring in the last few days : In the middle of a session the Esc to DEselect stops working until I close and re-open DR. Shift LMB still works and Esc is still shown as the hotkey. Esc still works in say Texture Tool so it isn't my Esc key failing.

[greebo]

Does it tell us anything that it has suddenly started like it did before even though it was working fine? In fact I just tried some earlier maps and now none of them work so it's nothing to do with the map nor a fault in the actual layer file I don't think but something that DR saves changes the way it handles the layer file on auto-load. But why does it only affect me?

Hm. Can you send me your user.xml and the .map plus .darkradiant file which the editor tries to load when it locks up? It's got to be reproducible somehow.

 

Another bug has been occuring in the last few days : In the middle of a session the Esc to DEselect stops working until I close and re-open DR. Shift LMB still works and Esc is still shown as the hotkey. Esc still works in say Texture Tool so it isn't my Esc key failing.

That really sucks - I didn't notice that one for a longer time now, but I haven't been mapping very much lately, and my sessions were rather short. Hopefully you or somebody else can reliably reproduce that case, otherwise I can't get hold of that bug.

[Fidcal]

OK, well the most I can do is try to keep vigilant and make a note of what I was doing just before Esc stopped working. If I can do that a few times I might spot a pattern that will give us a clue.

 

Most map files other than very small seem to lock up DR if opened when there is a .darkradiant file so here is the current one with my user.xml...

 

https://darkmod.homelinux.com/contributor/b.../Fidcal/e08.rar

[greebo]

Most map files other than very small seem to lock up DR if opened when there is a .darkradiant file so here is the current one with my user.xml...

 

https://darkmod.homelinux.com/contributor/b.../Fidcal/e08.rar

I can load and save and re-load that map just fine (with restarts of DarkRadiant included), even with Auto-Load last map and your user.xml. What's the last thing you see when DarkRadiant locks up?

[Fidcal]

Just tried a couple of times and it loaded OK. But from what I recall it appears to load normally, the loading map dialog shows, loads primitives and enities, then I think focus passes to the entity inspector panel, maybe see a flash of an hourglass cursor, see the map shown in ortho and camera view. So looks as normal. But when I try to use it everything is locked down, mouse does nothing, keys do nothing. Sometimes they produce a whiteout panel as though it is trying to redraw a child window but can't. Then I pull up Task Manager which shows TWO instances of DR and both show 'not responding'.

 

I've seen this many many times - sometimes with other programs running, sometimes with nothing else running, even after a reboot. Then delete the .darkradiant file and it then opens perfectly every time.

 

Clearl some other factor though because now it is working again on the very same map and I've not done anything on that since - I was working on another map today.

 

I'll keep a look out and see if I can see anything else next time it crashes.

[greebo]

Two DarkRadiant windows, you say? Maybe there is a popup message behind all these floating windows? Can you still resize the windows when DarkRadiant is frozen? If yes, you could try to look "behind" these windows to check whether there is a hidden popup floating around.

[greebo]

I just ran into such a lockup on my end here. Of course, this happened while I was outside of the debugger, but I could attach to the running process. The program was hanging somewhere in the GTK binaries (two calls below gtk_main()), so I'm not sure whether this is an actual DarkRadiant problem. I couldn't reproduce it afterwards.

 

Maybe it's time to upgrade to a newer version of the GTK runtime library, the one we're using is quite old.

[greebo]

I looked into upgrading the GTK runtime binaries today (to the newest stable version 2.12.9) and in principle that works, but the PersistentTransientWindow stuff needs some thought. The minimise/maximise behaviour has been altered in newer GTK versions it seems and after restoring the main window the floating windows are still iconified. A gtk_window_deiconify() call doesn't do the trick as additionally to that the coordinates of the window are not stored correctly.

 

I already thought about a minor rework of that callback design, but I haven't got around to try that out. May take a few days/weeks until I will have time during work again.

[jdude]

The model viewer window still refuses to re-size in the latest build. I still have to maximize it to be able to his the OK button, afterwards I have to minimize then maximize again to be able to hit the OK button.

 

Also there is still huge slowdown on any target or bind parameter when applying it in saintlucia.map due to it's entity size.

 

Annnnddd: I get large slowdown the first time I apply a new texture+values to a face, then after it works fine.

[greebo]

The model viewer window still refuses to re-size in the latest build. I still have to maximize it to be able to his the OK button, afterwards I have to minimize then maximize again to be able to hit the OK button.

That's because I haven't changed anything concerning this issue. Plus, nobody seems to have reported it on the tracker.

 

Also there is still huge slowdown on any target or bind parameter when applying it in saintlucia.map due to it's entity size.

I haven't got around to fix this as well. You can use the workaround in the meantime (disabling the type in the doom3.game file).

 

Annnnddd: I get large slowdown the first time I apply a new texture+values to a face, then after it works fine.

That's because the MediaBrowser is being populated the first time you pick a texture using your MMB. Unfortunately this takes quite some time, but it's only a one-time hit.

[greebo]

@jdude: The issue with the ModelSelector: are you using a multi-monitor setup? Which screen resolution(s) are you using?