Obsttorte

You have to be patient, as it will last at least two months. But then I guess I just pm you. Well, it's an unusual contest. Actually I can't remember why I have choosen to place them there. Maybe I was drunk. EDIT: I hope you didn't mind me to correct the quote.

I guess this can be seconded. If it will be only possible to take out a guard with one arrow when he is unalerted, I guess the player has earned it himself to get his arrow back. On the other side I would not miss that feature. And as said, if mappers don't like it they can just turn it off.

Just wondering if this was an insult If I'm going to make it look like your maps (in terms of good) I will be finished in two years or so.

Yep, great work dude. I would second what Tels said. Keep it on the player and try the string-based function call. I use script events quite often in my maps and would appreciate it

Another point is that when you apply this to "classical" doors, too, thus meaning doors that can actually close visportals as you cannot see through them, would cause graphic errors when standing on the side were the visportal is closer to the player then the door. (This is quite obvious so maybe I misunderstood you). My suggestion for the glass door thingy would be to use a new entity, that completely behaves like a door, with the only difference that it does not cause a visportal to be closed if the door is closed itself. The mapper would still have to place the visportal "inside" the door, what is, as grayman noted, much more failsafe. Anyways, I second the argument that the sound occlussion caused by doors is something that, in a logical way, should be caused by spawnargs on the door. I also like the idea of partial sound occlusion caused by partially opened door. The question is if this would be worth the effort (both in terms of implementation as in terms of runtime calculation) as I'm not sure that players would really notice the difference. (sound occlusion caused by doors isn't that terrible high). As we are just talking about what may be possible to implement: (beware ) Currently doors (and windows if implemented soon hopefully) does only apply an occlussion in terms of volume. Normally (in real life) such occlussion does also have an effect on the actual sound, or in other words the frequencies that pass through (I'm not sure this is understandable, so please tell me if not). Beside the obvious implementation effort the question would be if it is even possible to implement such a behaviour. Personally I think it would be a quite big push regarding the sound of TDM (that is quite good yet). Don't know how you think about it. Possible? Worth the effort?

I guess he didn't knew the band. You have to be permissive with Biker, he sometimes needs a while. I always wondered if the name has something to do with Niels Bohr.

Sounds good. :smie:

Why would you want to pick up an unusable arrow. Anyways, the behaviour can be disabled by the mapper. The problem is, that as it is used in all FM's so far it would be inconsistent and people would complain about it.

Thanks.

@RPGista: It is blue. But I guess depending on other light sources and the textures used in some location this is not good to see. @Bikerdude: I don't know what a 'Storte' is (or if I get ever used to the name rape). Anyways, I always betatested my FM's. And if this particular one is ready, you are invited to test this one.

I looked and didn't find it there. After some searching I ended up in the visportal tutorial. There is written I will make some tests myself to see if there is a workaround and post the results.

As all the objective methods are on the player, these here may fit there, too. It makes sense as these methods provide information about what the player has done.

scriptEvent void startMouseGesture(float key, float thresh, float test, float inverted, float turnHinderance, float decideTime, float deadTime); Start tracking a mouse gesture that started when the key impulse was pressed. Discretizes analog mouse movement into a few different gesture possibilities. Impulse arg can also be a button, see the UB_* enum in usercmdgen.h. For now, only one mouse gesture check at a time. thresh: Waits until the threshold mouse input thresh is reached before deciding. test: determines which test to do (0 = up/down, 1 = left/right, 2 = 4 directions, 3 = 8 directions). inverted: inverts the movement if set to 1, does not if 0 turnHinderance: Sets the max player view turn rate when checking this mouse gesture (0 => player view locked, 1.0 => no effect on view turning) decideTime: time in milliseconds after which the mouse gesture is auto-decided, in the event that the mouse movement threshold was not reached. A DecideTime of -1 means wait forever until the button is released. deadTime: how long after attack is pressed that mouse control remains dampened by the fraction turnHinderance.

Little update: Basic brushwork is almost done. I have to add two more areas what I hope to accomplish within two weeks. After that I'll go adding models, AI, pathways and so one. I guess I save detailing it out for the end, as I don't know how performance will be after I've added a bunch of things. Add the current state it runs smooth in all areas, but that's not really surprising as there is not much in there Mission size (in terms of volume) will be roughly two times of what Old Habits was like, so I hope people will spend a long time playing it.

Thanks, as said this is still early WIP. (And I have choosen the parts of the map that look best )

Looks like they have haemorrhoids

I wish I could map in light speed.

Contest FM. WIP. Still a lot to do.

OK. Will take a look at that. Thanks

A doors only occluding sound if they are touching a visportal? I'm asking this because you can't place visportals in a glass door (one you can look through).

Actually only the executable names. tdmlauncher.linux is now thedarkmod.x86 tdmlauncher.macosx is now thedarkmod.macosx

Actually the factor-approach would be much easier to implement. We just have to tell the mappers that 10dB is equal 0.5 and 20dB is equal 0.25 and so one. Using a dB-based approach is probably easier for the mappers, but ths would mean that the code has to translate the dB value given by the mapper into an actual distance to apply into the routine. This means more implementation affort and in addition is also a bit slower than the factor-approach.

The wiki was updated. It seems someone updated the web page instructions for Windows, but somehow missed the other two OS.