grayman
-
Posts
13591 -
Joined
-
Last visited
-
Days Won
199
Posts posted by grayman
-
-
maybee your map is leaked ? I had same problem until my map was leaked
dmap can't find the map, so it hasn't had a chance yet to see if there's a leak.
-
Uninstall Heart. Alternatively...
If you want to both play FMs and develop your own map and test play it in its own game folder as you are then create a new doom3 shortcut. Do not use tdmlauncher - keep that only for managing and playing other FMs. Add to your doom3 shortcut the args:
+set fs_game mymap
So with the console enabled it reads something like:
C:\doom 3\Doom3.exe +seta com_allowConsole 1 +set fs_game mymap
I'm not sure about the space in your doom 3 folder. If a problem then remove it.
Thanks for the suggestions.
I had already tried uninstalling Heart, and dmap still failed. Some setting was silently changed for running fms, and uninstalling didn't change it back.
Using the command line options on a Doom 3 shortcut allows dmap to find the map, but it knows nothing of the darkmod resources, so it fails loading textures, etc.
I added the options to the tdmlauncher shortcut, but dmap still can't find the map.
Still broken.
-
My file structure is "doom 3/mymap/maps/mymap.map".
I invoke dmap using "dmap mymap.map".
This has worked fine for a couple months, but after playing a fan mission (Heart) for a while, dmap now says it can't find mymap.map.
How do I get dmap back on track?
Thanks.
-
Bug filed in bugtracker.
Thanks.
-
Bug filed in bugtracker.
Thanks.
-
When the Clipper is toggled on, duping a brush doesn't offset the clone.
I created countless duplicate brushes before I realized what was happening. (In one case, as many as five.)
Clones should always be offset, regardless of the Clipper setting.
A problem worth filing a bug report on?
-
I should add that until I realized what was going on, I was recreating what I thought were deleted patches. So I ended up with more than a few duplicate patches sitting on top of one another. So there is a downside to the current patch behavior.
-
So, you're saying the new patch is created on the Default layer event though it was not visible at that time? This is the standard behaviour for all nodes.
I can change the behaviour such that the patch ends up in the first visible layer after creation.
Given 3 layers: Room, Blocks, Default, all visible.
Create a new brush. It gets assigned to the Default layer. That's fine, and makes sense.
Hide Default.
Create a brush. The editor now has Room and Blocks to choose from, and it picks Room. (I don't know how it decides. Maybe it's the last visible layer in the alphabetical list.)
Hide Room. Only Blocks is now visible.
Create a brush. It gets assigned to the Blocks layer, the only visible layer.
Now, if you create patches instead of brushes, they all appear to be assigned to the Default layer, regardless of what layers are visible, and regardless of whether the Default layer itself is visible. This isn't logical.
So there are two problems:
1. Patches are assigned to Default, regardless.
2. The editor doesn't recognize right away that a new patch, now belonging to the hidden Default layer, shouldn't be displayed. It waits until you do something else, like hide/show layers, or create another patch, or resize a brush, or whatever.
The upshot is that if you create patches when the Default layer is hidden, they will suddenly disappear at a later time. The workaround is that you have to immediately move a new patch to the desired layer, which is illogical if that layer is the only one visible.
IMHO, patches should behave like brushes.
-
I've encountered a problem with patches. I doesn't occur with brushes.
Use layers.
Have one layer visible.
Create a patch in that layer. The new patch now belongs to that layer.
Hide the layer.
Show the layer.
The new patch is missing. Show the Default layer and--voila!--there's the patch. It was moved to the Default layer when its true layer was hidden.
However, if you create a new patch when only one layer is visible, and explicitly move that patch to the visible layer, it stays put across layer hide/show.
Has anyone else seen this?
-
It's an old problem - when manipulating AI it's the rotation key which gets calculated by DarkRadiant. The angle key doesn't get incorporated into the rotation value.
How did you get the angle key there in the first place? Did you put it there by hand?
Yes. I have a ghost AI whose angle is important. He doesn't walk around, and needs to look in a certain direction.
-
-
Has anyone else had problems with AI losing their angle when they're moved in the editor?
My guys lose the angle key if I move them, which defaults their angle to zero.
-
The hour hands run clockwise. It's just the minute hands that run backward.
Nice clocks, btw.
-
I have a few patrolling guards in my map. Tonight, one of them decided to go AWOL. I couldn't believe he'd disappeared as I tracked his route and he was nowhere to be seen. Then, I went off to test something and in a little while he walked right past me. I started following him, and found out what he was doing.
I've been adding a new area over the past week, and this guard added it to his route, even though it has no path_corners in it.
So instead of taking the short route (about 200 units) from point A to point B, he's taking a very very much longer route out into the new area, which eventually brings him to point B, but from a different direction.
I thought AI took the shortest path.
There's nothing new between A and B, so he's not avoiding func_statics or too-high steps or anything like that. He's diligently walked the same route for a month, until tonight.
Has anyone else seen their AI striking out on their own?
I don't mind him doing this; I'm just curious about the unanticipated behavior.
-
Right, KotOR did well without it for example. The idea seems a little concept-braking for a thief-like game (what, of course, should not stop you). Will be interesting to see how it turns out.
I'm considering something like this as well.
What does "KotOR" refer to?
-
Can't reproduce the crash. I tried it with both my SVN environment as well as with the public TDM 1.01 release. No crash here.
Anything else happened since you updated? New drivers or something like that?
If that doesn't help, I can only suggest to install VC++ Express on your system and use the debugger on your system to see where it's crashing. Setting up the SVN build environment is connected to some effort though.
I have VC++, so I'll look into creating a build environment. I'll probably be back w/questions about the setup, though.
I'm not the only one seeing this.
I haven't updated any drivers. I was using the Editor okay in the previous DR rev (though the chars weren't appearing in the picture), upgraded to the current rev to see if the drawing problem was fixed, and encountered the crash.
-
The grandfather clock model also tells time backwards.
-
The clock_wall.lwo model has a moving pendulum and hands (though I didn't wait long enough to see if the hour hand was moving).
One problem is that the minute hand moves backwards.
Another problem is that both hands start pointing straight down. For a clock whose hands move, when the minute hand is pointing at VI, the hour hand has to be halfway between one of the hours. This clock's hour hand starts out pointing at the VI.
I tried to find a script or such that controls this, but failed.
I didn't rotate the clock when I placed it.
I haven't tested any other clocks.
Can someone point me to the script that controls this clock (assuming it doesn't have to be done by a coder), so I can write a workaround?
Thanks
-
Can you provide me with the map and the xdata so that I can try to reproduce the issue in my debugger?
Create a new single-room map.
Add a book.
Select the book and bring up the Readables Editor.
Try to type in the leftmost 'Book' field. It crashes at the first char.
This isn't specific to my WIP.
-
I can't provide console output from the crash, because it's a crash and the console goes away with DR.
Below is the log just prior to the crash. All this shows is me creating a readable book and opening the Editor.
Open the Editor, type one character into the leftmost body field and it crashes.
I extracted the fonts folder and that didn't solve the problem.
[shaders] Loaded texture: models/darkmod/props/textures/book_t1_ed
[shaders] Loaded texture: textures/common/collision
createEntity
OpenGL window configuration: colour-buffer = 32bpp, depth-buffer = 32bpp
[shaders] Loaded texture: fonts/english/mac_humaine/mac_humaine_0_48
[shaders] Loaded texture: fonts/english/mac_humaine/mac_humaine_1_48
[shaders] Loaded texture: fonts/english/mac_humaine/mac_humaine_2_48
[shaders] Loaded texture: fonts/english/mac_humaine/mac_humaine_3_48
[shaders] Loaded texture: fonts/english/mac_humaine/mac_humaine_4_48
[shaders] Loaded texture: guis/assets/readables/books/book_background01B
[shaders] Loaded texture: guis/assets/readables/books/book_background01B_left
[shaders] Loaded texture: guis/assets/readables/books/book_background01B_right
-
I had a number of readables before the Readable Editor came out in 1.2.0. The Editor read them just fine, and I could change them, but I had a problem in that no text was displayed in the preview window.
I assume this is the bug that was fixed in 1.2.1.
However, when I bring up the 1.2.1 Editor on an existing readable, DR crashes. I tried it with two different readables; one I created prior to 1.2.0 and one I created using 1.2.0. Both crashed while trying to paint the Editor window.
I tried to create a new readable using 1.2.1, and got as far as typing in the text. At the first character, DR crashed.
So I assume the crash is related to displaying text in the text field (not in the Preview window).
Anyone else having this problem?
Thanks.
-
Also, wrt to arrows, all arrows pass through him except for the fire arrow. When it hits him, he bends over in his pain animation and a splat of soot is painted in the air where his chest was when the arrow hit him. It looks a bit strange.
So the fire arrow can see him when every other arrow can't.
-
I'm putting a ghost into my map.
I came across Springheel's 'ghost' thread, which showed me it was possible. Thanks for that.
At this point, I have a Builder Priest ghost who's fully translucent, casts no shadows, can't be killed (doh!) and for the most part ignores what happens around him. For story purposes, he won't need to worry about paths or AAS data; he just stands in one place. I'll provide some dialogue for him, so I've turned off his idle chatter, etc.
The last hurdle is his solidity. Even though all of his textures are marked "nonsolid", and the model is marked "solid" "0", I still can't walk through him. I can shoot arrows through him just fine, but he reacts to the blackjack and sword with a pain animation (even though I've set "pain_threshold" "1000", which means he shouldn't run his pain animation unless he gets hit with 1000+ points of damage).
What am I missing that would allow me to walk through him, and to make him impervious to pain?
Thanks.
-
In tdm_stone_natural.mtr, textures/darkmod/stone/natural/light_grey_rough02 is defined as "grass".
Looks like stone to me.
But when you walk on it, you get the grass-walking footstep.
Problem?
Help! Can't dmap
in TDM Editors Guild
Posted
That did it.
Thanks!
Now back to my map.