Jump to content
The Dark Mod Forums

Itches, Glitches & Anything Else...


Recommended Posts

  • 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

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 by ungoliant
Link to post
Share on other sites
  • 4 weeks later...

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...

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to post
Share on other sites

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.

Link to post
Share on other sites

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

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to post
Share on other sites
  • 2 weeks later...

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.

Link to post
Share on other sites
  • 2 weeks later...

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).

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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...

:rolleyes:

 

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.

Link to post
Share on other sites

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?

S2wtMNl.gif

Link to post
Share on other sites
  • 3 months later...

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

Link to post
Share on other sites
  • 1 month later...

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.

facesct.jpg

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.

Link to post
Share on other sites

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 (?)

"Einen giftigen Trank aus Kräutern und Wurzeln für die närrischen Städter wollen wir brauen." - Text aus einem verlassenen Heidenlager

Link to post
Share on other sites
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....

Link to post
Share on other sites
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.

Link to post
Share on other sites

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.

Clipper

-The mapper's best friend.

Link to post
Share on other sites

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.

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...