grayman

Yes. I have a ghost AI whose angle is important. He doesn't walk around, and needs to look in a certain direction.

Yes.

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.

I'm considering something like this as well. What does "KotOR" refer to?

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

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?

I just DL'ed DR 1.2.1. 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.

After further testing with snow, I can answer 1 and 4. 1) Patch size makes no difference. It looks like the engine creates a constant N particles per square unit of patch. 4) Visportals split weather patches. If part of a large patch is in an area that's "off" due to visportals, that part of the patch will not generate particles.

A few questions/remarks about making it snow. 1) Does the engine generate the same number of particles regardless of the patch size? It seems that a small patch set to "flurries" looks like a blizzard. 2) I think the tutorials say to have the weather texture on the bottom of the patch, but when I created a snow patch it tossed the particles UP before they started falling. I flipped the patch upside-down and now the snow comes out right. So the snow texture needs to point up at the sky. 3) In long, narrow snow patches I see ranks of particles descend together, all in line, like tiny soldiers on a parade ground. Line yourself up properly and you can look straight down what ends up being a waterfall of evenly-spaced particles all lined up nice and straight as they march toward the ground. Is there some minimum patch size we should use to stop this behavior? (Seems like the random particle generator isn't doing a good job of spacing the particles around the patch.) 4) Do visportals break up weather patches? If I have a patch that crosses a vp and the vp closes, and part of the patch is visible and part isn't, will the engine still produce particles in the non-visible area? Thanks.

This is timely. I decided yesterday to put snow in my map, and was considering creating decal snow textures to use at the snow/<something else> edges. Then I found this thread. Having models that blend any two textures would be a big step forward. Thanks!

Thanks for the replies. Here's what I did: I wrapped the AI's final path corner in a trigger_once_entityname and gave the trigger the keyword pair "entityname <AI_name>". (The docs don't tell you about this key, but the game will error out if it's not there, and tell you it's missing. A classic "trial by error".) The trigger targets a func_remove, which has the key "target <AI_name>". So when he reaches the last path_corner, the trigger recognizes him and tells the func_remove, which takes him out of the game.

I'm using path_hide in my map. Documentation says the AI becomes invisible and non-solid. A comment elsewhere suggests path_hide is useful for removing AI from the map, which is what I want to do. What it really does is only make the AI invisible. The AI is still solid (I can bump into him), and the AI continues to think, because he'll continue talking. I imagine CPU is used to cycle him through animations; they're just not painted each frame. So what you get is a blocking, talking, invisible character who's still in the game. Great for a ghost, I suppose.

I just discovered that if you set the key "run=1" on a path_corner, the AI will run TO the corner. So I guess the path_anim w/"anim=run18" duplicates this behavior. I spent several hours today trying to figure out how to make an AI run away from me w/o attacking him. It wasn't until I read the fm source maps that I found the "run" key. Ouch. One thing that would be nice on the wiki pages would be a listing of what keys each entity accepts. Even if it's limited to the most oft-used keys. (Though, having said that, the run key is only used in one of the released fm's.)

Okay, this leads to a question about path_anim. The docs on paths say that when you string them together, the AI does things based on the ordering of the path entities. So if a path_corner goes to a path_turn goes to a path_wait goes to a path_corner, the AI will walk to the first path_corner, turn, wait, and walk to the second path_corner. But path_anim doesn't seem to work that way, unless I'm seeing a special case. If I string a path_corner, path_anim, and path_corner together, I expect to see the AI walk to the first corner, and perform the animation while walking to the second corner, based on the ordering of the entities. But if the animation is run18, the AI runs to the first path corner, then walks to the second. So a path_anim with anim=run18 means "run to me", not "run away from me". Is this the expected behavior, or is this a bug?

Thank you.

I'm trying to find the list of AI animations to use with path_anim. I searched "animation" on the forum and didn't see a reference. The path wiki says to look for the list in the AI's def file. I read through a bunch and didn't find any animation list. I assume it exists somewhere. Can someone point me to it? Thanks.