Itches, Glitches & Anything Else...

[Diego 201]

Diego, do you have an nvidia gpu? If so, have you disabled "threading optimizations" ?

Yes and no, respectively. It worked! Thanks

[ungoliant 120]

Just wanted to post, I reaaaally think the rotate/scale tool should have a default hot-key. This isn't something that should be swept under the carpet. (meaning the tool, not my suggestion)

Edited February 19, 2012 by ungoliant

[Tels 279]

Hm, thought I'd pickup DR for some small mapping session and it seemingly has lost the ability to resize brushes by click-and-drag on their sides. Does anybody know what could cause this?

 

(There is also this weird problem that no matter what kind of "fs_game" etc paths I select, DR suddenly tells me they don't exist (but they still do!) and asks me if I want to correct that infinitely...

[Fidcal 175]

Only normal reasons for drag resize not working I can think of off-hand are:

 

You're in clipper mode (press X to switch by default)

The brush is a func_static (press Tab to tab through brushes)

 

If you can't get the game path to take then try exiting DR and set it in the config file:

 

C:\Users\<user>\AppData\Roaming\DarkRadiant\user.xml

 

This is what mine looks like. I alter it a lot as I switch between game folders:

 

 

 

 

 

<?xml version="1.0"?>

<user><paths>

 

 

 

<enginePath value="G:/doom3TDM1.07/"/>

<mapPath value="G:/doom3TDM1.07/campaign/maps/"/>

<prefabPath value="G:/doom3TDM1.07/campaign/prefabs/"/>

</paths><game><type value="Doom 3"/>

<typeIndex value="0"/>

<fs_game value="campaign"/>

<fs_game_base value="darkmod"/> </game><ui>

<brush><textureLock value="1"/>

<emitCSGSubtractWarning value="0"/> </brush>

<mainFrame>

 

 

 

Funny, 'code' couldn't handle the above in this post.

[Tels 279]

Only normal reasons for drag resize not working I can think of off-hand are:

 

You're in clipper mode (press X to switch by default)

The brush is a func_static (press Tab to tab through brushes)

 

No, none of these are it. Just start with an empty map, drag out a brush and then I can't resize it

 

Giving up for today, wasted too much time to find out why.

[Fidcal 175]

I just remembered another situation where it 'seems' that you can't drag/resize brushes. It's when you have a very large grid size and the brush is moderate to tiny, eg, door size or smaller. You put the mouse just outside the brush as normal and go to drag it but of course the grid size is so out of scale for what you're trying to do that the mouse doesn't even reach the next grid line at all. It catches me out now and again - just did in fact! Then I remember.

[Tels 279]

Hm, no that is not it, I changed the grid from 1..8 and it did occur on all sizes. Out of ideas.

[RPGista 604]

I've actually been getting a strange crash, the screen will blink black a couple of times, and then will go black and freeze, most times coming back with an error message about how the graphics board was forced into an error but was able to recover. Once it took me to the blue screen and windows had to restart, not to damage the laptop... It only ever happens when Im working with DR, will investigate this further, because I didnt really take notes of all the messages.

 

I'm also getting pretty much consistent CTDs when I highlight some specific light prefabs, when you spend too much time browsing the animation viewer, and when sometimes you try to use the filter options inside the model/entity browser.

[plasticman 16]

The resize bug Tels ran into -- I can see it on my system as well. It has been there for months and makes for a very limited DR experience (i.e. renders DR completely useless).

 

I think bug #0002952 and bug #0003021 are related to that.

 

To me it looks like DR on Linux is basically broken (and has been for a while). People just don't complain that much because there are not that many Darkmodders on Linux with most of them beeing players not mappers. The remaining few are either the geeky kind that go through the hassle of building the editor themselves and succeed or the less geeky kind that fails to do so and sticks with a broken version from the PPA (me).

[OrbWeaver 662]

I tried downloading the PPA version and could not reproduce the behaviour, however since it has been a long time since the last release and that version has several serious render bugs which have since been fixed, it is probably time for a new release anyway. Perhaps your issue will have been fixed in a later revision.

[Fidcal 175]

If it's that bad then re-install the last version that worked for you until it's fixed. I did that once for a while ages ago.

[Flanders 12]

When picking locks or using a key a glowing green or red indicator is used on the inventory icon. However I guess it's supposed to be like a smooth aura but (at least on my system) the gradient is jagged. This could be because the source file is saved as an DXT3 DDS with only a few alpha channel values where a DXT5 for a smooth gradient is more appropriate. Just guessing.

[plasticman 16]

Unfortunately, there is no such a thing like "the last version". When Orbweaver updates the Launchpad repository I get the new binaries automatically, and the previous ones are like gawn forevar!

 

But my guess that all the distributed binaries are broken could be falsified at least. Orbweaver has a working version and I just tried it on a fresh Ubuntu 11.10-install, where I spent like 10 minutes dragging and resizing a brush because I could do it and it felt so good after all this time...

 

The same test in a fresh 10.10-VM however shows the bug, just like on my real system. But there is no point in doing any updates for the maverick Meerkat anymore, since it is officially dead for a week now. I plan on doing a reinstall when the Pangolin arrives at the end of the month. We will see how things go from there.

 

Anyway, thanks for all the work you put into this.

[ERH+ 662]

I've just realised that fire arrow can be confusing for players not familiar with Thief environment. It light up player without proper warning, making him vulnerable to all AI in sight. Maybe it will be better to add a light cone around inventory icon, or just take all what's come with fire source and put in-game a light point similar to pocket lantern?

Another thing are rats: they sometimes randomly wander in corner of door frame and stuck there, causing human AI unable to pass by doors (and if there are no alternate route, and door is unbreakable, even player could be trapped and forced to restart mission). Is there any monster_clip_aas_rat to place around movables?

[Bikerdude 3742]

Another minor bug:

 

Export to .ASE dosent work and looking in the DR console I got the following

 

Error while executing file: commands\convert_to_ase_and_replace.py:
Traceback (most recent call last):
 File "C:/Program Files/DarkRadiant/scripts/commands\convert_to_ase_and_replace.py", line 418, in <module>
   execute()
 File "C:/Program Files/DarkRadiant/scripts/commands\convert_to_ase_and_replace.py", line 159, in execute
   GlobalSelectionSystem.foreachSelected(walker)
 File "C:/Program Files/DarkRadiant/scripts/commands\convert_to_ase_and_replace.py", line 140, in visit
   import re
ImportError: No module named re

[ungoliant 120]

I have no idea whats going on, but it appears that using a clipper tool on anything that results in a vertex off-grid messes up the resulting faces somehow.

this is a direct result of using clipper tool, and displaying the new faces. edges and vertices look to be in proper places, but in face select mode, I get this.... I don't know if it will create problems, but it sure as hell doesn't look safe.

[SeriousToni 485]

Do you build a rocket? =)

[ungoliant 120]

no its a roof, i'm rebuilding some towers in my first map project from 2-3 years ago to align more closely with the tutorial video series i made. (the first ones were very poorly constructed)

[SeriousToni 485]

Ah okay,cool!

So did you make a cylinder, extruded it and clipped the sides?

You could also have just moved the vertexes of them, that may work better (?)

[Bikerdude 3742]

no its a roof, i'm rebuilding some towers in my first map project from 2-3 years ago to align more closely with the tutorial video series i made. (the first ones were very poorly constructed)

That's one of the bugbears with DR atm, is that bloody annoying vert point snapping in always the wrong place, I have 'sort of' become less fussy about my building as I have wasted too many man-hours trying to keep everything aligned. maybe this will get fixed in DR 1.8....

[Sotha 1909]

Why not use patches for roofs? Create a cone and transform it a bit?

[ungoliant 120]

It's playable inside and out, and needs to seal.

[Bikerdude 3742]

Why not use patches for roofs? Create a cone and transform it a bit?

It's playable inside and out, and needs to seal.

Also a conical roof made from a single patch never textures properly, Ungoliant would have to make the thing from 12 separate patches othewise.

[Sotha 1909]

I've routinely used conical roofs and nobody has complained about texturing. They looked fine to me too.

 

If it must be playable in and out:

Make a brush sealing crude roof: make a square brush and cut it into triangles. Select all triangles and grab the middle vertec and raise it up. Then cover the thingy from the inside AND outside with a proper conical patch. Remember to use caulk for the sealing roof.

[RPGista 604]

That is completely unrelated to the problem at hand, but thinking about the discussion on brushes gradually becoming corrupt with DR mapping sessions, I think clipped solids that dont have all points on the grid (and even then...) like that are huge candidates to become deformed with time, so you might NEED to create the simple core/patch surface arrengement Sotha is talking about. If I had nothing better to do with my finger's cartilage (too much clicking), I would make my map completely out of patches, with a brush core for functional reasons.