Jump to content
The Dark Mod Forums

Itches, Glitches & Anything Else...


Recommended Posts

Weird, I could've sworn I had removed that check for the upgradepaths.xml. Please take the upgradepaths.xml from the other installation (0.8.1), it's the very same file (and it's actually unused). I think it's not worth an entire new package upload just for this.

Link to post
Share on other sites
  • Replies 1.9k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Since I've stumbled over the same issue (and even tracked a needless bugreport), I've just commited the following:   Index: def/tdm_mover_base.def ===================================================

That's a pretty ambitious project that will require almost every trick in the book. I can sort of envision how you might use fences, skyboxes, and archways to assist with compartmentalization but over

I'd say it is perfectly doable if you make it almost planar, or with only mild height differences. The images below show how I would do it:   See how the mountains and houses always block the view f

Posted Images

OK, got it loaded so it was just that one file. Just had time for a quick look and I don't think I've got the dark mod resources so I need to look at that. I can't even select it. The close down error I mentioned before I got everytime has gone so that's one less thing to worry about. I have to go eat now I'll check back later...

Link to post
Share on other sites

Old branch? It shouldn't be. I'll have to reupload a new build to make sure.

 

edit: ARG, I accidentally put the 0.8.1 exe files into the package. A new upload will be on FTP soon.

Link to post
Share on other sites

Yep that loads. A couple of comments from just a moment's look:

 

-the browse to game dialog at the beginning gives me a 'cannot load path' or something error, because it's trying to load "c:\program files\doom 3" which I've never told it to do. I don't accept this value of course; when I hit browse to find my actual path is when it gives me the error. Doesn't happen with my previous version. minor

 

-I don't have all of the new button icons again. I swear this was fixed before, I had for example three selection buttons at top (complete tall, etc), but now they're gone again (just the original two again), and the rotation button on the left panel which I never quite understood (:blush:), but that's gone again now too, even after I delete the config and restore my backup configs. I don't know what's causing this. Is there stuff written in the registry, or install folder, that is overwriting my stuff in my user folder? Additionally I am asked for the doom3 path on every launch, but admittedly my 'main' install is several weeks old. I don't believe the buttons vanishing has to do with that though; that is XML related IIRC. Unless - did the GTK2 build (or the previous one) wipe out/break my XML files?

 

-the S/R dialog problem I had with it going off screen is handled different (it now goes in a smaller box, 2X columns instead of single) so I can't really be sure if the new libs help the prob. Either way, it's addressed though.

 

Edit: Yeah it's gotta be that the new, or the previous new package (probably that, the 0.8.1 .exe) screwed up the config files again. If I delete them all, the buttons are back. Maybe I should just grab my colors section and keep it somewhere, ready to paste back in by hand when this happens. That also fixed the Doom3 path on startup each time. Gotta be it.

 

Edit: Woot, I forgot about the inclusion of SuperMal! Heh, that makes it a bit easier. :)

Link to post
Share on other sites

Wow! You have got the stim selector adding in one! The dream selector! Yes! Don't think you need that Add button now. Maybe change the word type to Add: or Add type:

 

The crash after clicking Apply with empty fields in the effect dialog seems to be cured too so that's more good news.

 

The effect combo box now also is cured and can be left clicked on normally to select. This wants to be a few characters wider on mine though as it truncates... correction! I can stretch the dialog a little and the combo widens too so no problem.

 

I don't know what the repercussions are but I created a new stim called testStim and added it to a couple of entities. Later I accidentally hit the remove button. It still remains presumably fully operational as stim #1000 but blank name in the s & r. Don't see how you can protect names from this. If I create a new name NewTestStim then it is allocated 1000 and becomes the name of the one already used.

 

In Dark Radiant I used to be able to double click the camera window title bar and the entity selector to go full screen and found this useful as I keep them quite small normally and have a max orthoview I can. Has this option been removed intentionally? I can still drag resize but I got in the habit of the double click.

 

Sneaksie - I have the rotation button OK (though like you I have not yet understood it's three dimensional control. I found it easier to open a second ortho view then rotate in the top view while looking at the side view - but in reverse!

 

[EDIT]Actually just tried it again and think I begin to see how it works. It is especially clear with an object like a chair. Need to experiment some more though.

 

Isn't there an 'opt out' checkbox on that doom3 path thing at start?

Link to post
Share on other sites

I do understand the rotate func_* one (invaluable!), but not the models one. Maybe it's not implemented in my build yet. Time to upgrade methinks... is the current build mostly good, no major problems? If so, I can wipe out my several weeks old folder and move up.

 

Edit: the config probs and doom3 check at start were a result of the 0.8.1 package downgrading the XML files apparently.

Link to post
Share on other sites

Thought I'd try that rotate tool a bit more and think now I'm getting the hang of it. Very clever how it lets you rotate in three directions. Then I tried to rotate the brush back to how it started to test how precisely I could control it. When it was as near as I could get it I hit ctrl G to snap it to grid. Then I noticed - my brush which started out as a regular block had become a wedge! How is that possible? I did not touch the clipper tool; I just rotated the brush around. I saved it with a new name and reloaded the original map and the regular brush is still there.

Link to post
Share on other sites
I don't know what the repercussions are but I created a new stim called testStim and added it to a couple of entities. Later I accidentally hit the remove button. It still remains presumably fully operational as stim #1000 but blank name in the s & r. Don't see how you can protect names from this. If I create a new name NewTestStim then it is allocated 1000 and becomes the name of the one already used.

Ah, yes, I didn't think of that case. I'll have to take all the other entities into account as well when saving the custom stims (or deleting them). If the stim is still used on other entities, it must not be deleted. Rather major bug.

 

In Dark Radiant I used to be able to double click the camera window title bar and the entity selector to go full screen and found this useful as I keep them quite small normally and have a max orthoview I can. Has this option been removed intentionally? I can still drag resize but I got in the habit of the double click.

I'll have to see to that. I never used this myself, so it may well be that this is broken.

 

Isn't there an 'opt out' checkbox on that doom3 path thing at start?

What do you mean by opt-out for the engine path?

 

@SneaksieDave: The assertions at shutdown are a known problem. This is gonna be fixed soon (it will either be me or Orbweaver beats me to it).

 

I do understand the rotate func_* one (invaluable!), but not the models one. Maybe it's not implemented in my build yet. Time to upgrade methinks... is the current build mostly good, no major problems? If so, I can wipe out my several weeks old folder and move up.

The "rotate models independently" toggle button lets models rotate about their own axes each. Duplicate a few models and try it out - it should work. If not, I'll have to look into it.

 

When it was as near as I could get it I hit ctrl G to snap it to grid. Then I noticed - my brush which started out as a regular block had become a wedge! How is that possible? I did not touch the clipper tool; I just rotated the brush around. I saved it with a new name and reloaded the original map and the regular brush is still there.

The snap to grid command is more or less rounding the floating point numbers to the nearest grid number. It may well be that the brush ended up slightly towards another grid point after the rotation. You can't really do much against it, but you can correct this problem by using the "Edge" manipulator.

Link to post
Share on other sites
@SneaksieDave: The assertions at shutdown are a known problem. This is gonna be fixed soon (it will either be me or Orbweaver beats me to it).

 

Unfortunately I can't see these errors in Linux, which means I would have to boot into Windows to investigate it (which I can do, but often don't get round to). If you wanted to look at it I suspect it is a problem with the destruction of GTK elements contained within a PropertyEditor subclass -- the widget will get destructed when the shared_ptr<PropertyEditor> gets destroyed, but if it is still packed into the parent widget (which it will be if an entity is selected at shutdown) it would get destroyed again by the cascading destruction of GTK widgets.

 

I could also just implement a fix on Linux and hope that it solved the Windows issue.

Link to post
Share on other sites
I can look into it as well, so you don't have to mess around in your windows build. Just tell me where to look and I'll resolve that. :)

 

In the virtual destructors of all of the PropertyEditor subclasses (e.g. Vector3PropertyEditor) there should be a gtk_widget_destroy(_widget) statement. Probably the simplest thing to do is put it in a conditional, i.e.

 

if (GTK_IS_WIDGET(_widget))
gtk_widget_destroy(_widget);

 

This assumes that the shared_ptr destructor is being activated after the cascading GTK destroy, which I suspect is the case.

Link to post
Share on other sites
What do you mean by opt-out for the engine path?

 

Maybe it was something else and not the engine path but I can't see it any more to check because I opted out! What happened when I first installed that last download a small dialog or two popped up at the start and as I recall one of them had a couple of boxes to fill or change. It was there again the next time I opened DR. There was a 'don't show this again' check box so I checked it. When Dave said he kept being asked for the doom3 path I thought that was it.

Link to post
Share on other sites
The "rotate models independently" toggle button lets models rotate about their own axes each. Duplicate a few models and try it out - it should work. If not, I'll have to look into it.

You're right, my mistake, I remember we spoke about this before and I was thinking it was for any ent, not just models.

Then I tried to rotate the brush back to how it started to test how precisely I could control it. When it was as near as I could get it I hit ctrl G to snap it to grid. Then I noticed - my brush which started out as a regular block had become a wedge!

:blink: Crap, that sounds bad. I've tried a couple of times but so far, I've only gotten what looks like it might be a little distortion, but I'm not sure, because as soon as I bump the grid up high (4+), it goes right back to normal.

Link to post
Share on other sites

I hopefully could resolve the GTK assertions on shutdown. I moved the destructor and the getWidget() into the base class (as they were identical for every subclass, I of course kept them virtual to allow overriding), I hope you don't mind.

Link to post
Share on other sites
I hopefully could resolve the GTK assertions on shutdown. I moved the destructor and the getWidget() into the base class (as they were identical for every subclass, I of course kept them virtual to allow overriding), I hope you don't mind.

 

No, I was thinking that this might be a good idea. Presumably the _widget member is now constructed in the base class as a VBox, and is accessed in subclasses by calling getWidget()?

Link to post
Share on other sites

Yes, actually it's more likely for the rotated brush to be distorted after being rotated and snapped to the grid than staying normal except a few rare angles.

 

@EntityInspector: The _widget is now a protected member variable of the base class. The vbox however is not being constructed there, as I didn't check if the implementation of the subclasses is identical.

Link to post
Share on other sites
I don't know what the repercussions are but I created a new stim called testStim and added it to a couple of entities. Later I accidentally hit the remove button. It still remains presumably fully operational as stim #1000 but blank name in the s & r. Don't see how you can protect names from this. If I create a new name NewTestStim then it is allocated 1000 and becomes the name of the one already used.

I first thought this was a major bug, but thinking about this, I don't think I can easily prevent users from deleting custom stim types that are used by other entites. For the moment being I added a warning text to the custom stim editor so that the user is warned before deleting any custom stims. If this happens accidentally, the user would have to click on "Cancel" to prevent the changes from being written to the map.

Link to post
Share on other sites

As I understand it, snap to grid resizes a brush to the nearest current grid size and moves it to the nearest grid line? In Dromed it also rotates the brush to the nearest angle divisible by 22.5. Maybe there is a case for a second 'snap to nearest angle divisible by 90 without moving or resizing' button that could be used at the mapper's discretion, eg, after a rotation. I don't know all the repercussions of this so I won't push it but it seems to me that one should be able to snap a rotation to at least 90 without it losing its shape. It is not the user's intention to change the shape so it is a fault. In Dromed the brush properties, coordinates, orientation, and dimensions are listed just like any object and the user could type in any acceptable value in any of them. That is another reason I was suggesting that brush properties be displayed in the entity inspector.

Link to post
Share on other sites

I was thinking that'd it probably be a good idea to have a brush counter when you load the map as well as the entity counter. My map currently has 3726 brushes and only 292 entities and when you load it it takes nearly 40 seconds to load and looks like it has locked up at times as the progress bar always gets stuck. I expect to have nearly 3 - 4x amount the brushes by the time the map is done so that may cause potential issues.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...