Obsttorte

OK, found it out. I can set equip_action_script and dequip_action_script on the AI. The specified scripts then get called when (un)shouldering the AI.

Some other starting point: I noticed that whenever I shoulder the body there is the line "Equip called" writtten to the console. when I drop the body, line "Dequip called" is printed to the console. I'll see if that gets me somewhere.

I just made another test. As long as you shoulder an unconscious or dead body, the AI completely ignores it. It only gets alerted when you drop the body. This is really weird behaviour.

The success script does not get any arguments. Obviously I could just go through all the AI's in the map, but if you have like three douzens of them, this gets quite unhandy. And everytime you change something, you have to change the script. Another question: Is there a possiblity to find out whether the player is currently holding an unconscious body. I tried entity heldEntity(), but this only gives you the unconscious AI if you frobbed it. Once you shoulder it, this method returns $null as if your hands were empty.

Is it possible to change an AI's team once it gets to a certain alert level?

Thank the guys who wrote that.

If you buy such tools I guess it is relatively expensive. But I barely remember reading an article about constructing such things on your own. IIRC the only things you really need is a webcam (I think this is part of a lot of laptops nowadays) and three LED's. Than you need something to attach the LED's to, that you can wear on your head and a power supply for said LED's. There is free software available that can be used to get the heads position from the webcam footage. I think it has somethink to do with positioning and brightness of the single LED's.

Update: I found out now how I can accompish the specific behaviour. It's quite close to what grayman suggested in the Newbie DR Thread. This will be added to the script, which continuosly checks whether the player carries a weapon. I will update the wiki entry soon, but the basic steps I shall explain here: - check if the player is highlighting something that is locked - check whether the player has selected the lockpicks (one of them) - check if the locked entity has a door handle - check whether the handle is rotating The only sidekick here is the case, when a locked entity, for example a little treasure chest, has no handle attached to it. This would lead to two possible cases: - the AI won't notice the player lockpicking it - the AI will behave as seeing the player lockpicking it if the player has just frobhighlighted the chest with the picks in his hands Both possibilities are not very satisfactory, but can be bypassed by the mapper by adding a (possible invisible) handle to the specific chest In the cases of doors and chests that have handles, the AI will only be alerted when the player really attempts to pick the lock, not just by having the lockpicks selected and looking on the door. I think this is an improvement. Wiki update will follow. Edit: This method suggests, that the player should not be able to enter through locked doors. Just for notice.

Well I searched for "lockpick" and "script" and found some discussion in the Newbie DR thread. You gave the solution btw. So the result was that if the player highlights a door AND have lockpicks selected the AI would get alerted if seeing the player. This is relatively close but not exactly what I want. This solution inhabits the following problem: Imagine the player stands in front of a door he just tried to open by simply frobbing it and sees, that it is locked. He knows that there are far too much guards around to try anything illegal, so he now plans how he could make progress. He scrolls trough his inventory to see what tools he has left and that could help him. Doing so, he also scrolls trough the lockpicks while still looking at the door and BOOOM, as there are guards nearby he suddenly becomes a thread. I know this sounds a bit constructed. What I'm trying to say is, that scrolling through your inventory may not occur to most players as really taking the things out of your bag and looking at them. Especially when it comes to lockpicks, which are pretty small I think and could be hidden in the hands. I think that most players would expect only the attempt of actually lockpicking the door as illegal, not having them selected while looking at a door. I will see if #I can change this behaviour a bit.

http://wiki.thedarkmod.com/index.php?title=City_Street_Visportal_Tutorial Here ya go.

Beneath my keyboard I use a dragball mouse for some years now. This is a mouse with a big ball on it that you use for "moving the mouse". So in fact, you do not have to move the mouse at all, just the ball. It takes some time to get used to it (I needed three months or so until I was able to hit a desktop icon on first try). But it is really worth a try, as you don't need th space you need for a normal mouse and it is way more precise once you get used to it. I have a Logitech Cordless Optical Trackman

Well there were a lot of discussions about changing team relations and about the already in the wiki article described features.

Well, doing a rough search doesn't give me much useful (in fact nothing). If you have something special in mind...?

Just so I understand you. Does this mean that you play PC Games without using a mouse? Sounds awful.

I wanted to try some things that could enhance the possibilities for Hitman-style map (referring to the fact that you're counted as non-hostile by default). The feature I'm aiming for is to let the AI get hostile to the player when they see him lockpicking a door. So I thought I could use the stim response system for this. The problem is that the door seems not react to any stims. I tried frob, water and gas. Especially the first case seems a bit strange to me as a door entity is something that should react to frobs by default. I used such things one loot some time ago and it worked very nice. Any suggestions what may be the problem here? Thanks in advice. If someone has another suggestion on how such a feature could be implemented I'll be happy to here.

This "problem" also occurs to me. Btw., if this was intentional, I think the Editors Guild would fit more in the Feedback and Support part, as many people are asking (and answering) questions there. Just my two cent.

I always uses mouse and keyboard for games that have nothing to do with sports or so. I once tried out my gamepad on Skyrim, and find it terrible manuvering. Don't know how anybody can play such games like this, but maybe one has just to get used to. RE joypad: It is really strange what names are given to those things by native speakers. In germany, we call those things gamepads. And mobile telephones are called handy here (so both english expression, but not the same as the english speaking people use). I have an XBOX PC controller.It's a logitech F510. I think I paid 30-40 € for it when I bought it three or four years ago, and it is still working pretty smooth. What is quite good about it is that only the front positioned shoulder pads are buttons, the two behind them are whips. This is quite nice when playing race games. In addition you can switch between direct and xinput via a lever on the backside. There is also an wireless version of this model, but I think it is a bit more expensive. The cable length is two meters and the force feedback is relatively stronge and fine-tuned. It is suited for large hands.

http://wiki.thedarkmod.com/index.php?title=Containers,_Chests,_etc. This is an article from Fidcal, describing how to make your own chests and the usage of the target entity there. So it may fit here.

BTW, very good work Watson.

3. Just for the list. Someone should add a wiki entry for this, as this seems to be something an unexperienced mapper can get nuts on. IIRC there is already a wiki entry about the use of the target_setfrobable entity for the above mentioned purpose, so it may be a good idea to add this as an advice there.

This is very odd. How can this happen? (And what exactly do you mean with the drawer beneath it? Isn't the target entity the only thing here creating such a list?) This is odd either, as the most cases in which this entity is used is to avoid the player to frob something through a wall or so. If, for example, you use the drawer without this entity, you are able to frob the key and the loot trough the closed "book door" This happens with other key entities, too. The strange thing is, that if you use a key model instead, everything works as suppossed to be.

Hi, I was wondering if anybody has a special opinion to the amount of loot a player should gather in a FM. I noticed that many FM authors used the Thief 3 approach like for example find 25%/50%/75% of the total loot (although they never write this in the objectives). I must say that I'm not a big friend of this, as it sometimes seems a bit randomly. My personal opinion about this topic is that the already gathered loot is something like a mission progress meter. It gives the player some feedback on how far his progress in the mission already is. Obviously this should be something difficulty dependend. In my own FM I used to write down the loot avaibable in the single rooms/areas and if they were just lying around or hidden or if you need a key or your lockpicks to get them. While someone playing on the lowest difficulty level may just go the straight forward way needed to accomplish his main objectives and mainly only catch the loot lying around and lockpick some chests someone playing on the highest difficulty level will most certainly go to every single room and may also search for hidden loot. In the latter case the player may also be less unsatisfied if he has to search for more loot after accomplishing his main objectives. I tried to take this into consideration when setting up the loot objectives. Not sure how good I've done this anyway. So what is your opinion about this topic? How important is this objective to you? Do you get bothered when you've accomplished your main objectives and still have to search for some additional loot? Should there be some kind of system behind this objective type, or does it not matter to you? Looking forward to your responses.

There are some other things you may consider. You can for example turn of the collision by making things like bushes nonsolid. Also not shadow-casting lights and or objects save performance. Also try to keep things "small", meaning not to build extraordinary long, broad or high "rooms". Doom3 was aimed at tiny indoor areas, so everything else needs some tricks. In reference to visportalization. There is a tutorial about city sections (or more precise about visportalizing them), which holds a lot of useful informations about this theme. Good luck, taffer.

Just thinking about it again I have a rough idea what may happen here. The m_EntsSetUnfrobable list seems to fit the purpose that only things that were set non-frobable the last time are set frobable this time. I'm not sure why this is needed, maybe if a mapper creates overlapping target_setfrobable entities. So I'm just thinking loud. This method is called upon map start to set everything within its borders to non-frobable. The key created by Biker therefore would be non-frobable now. This part works. What if, for any unknown reason, the name of the key gets changed afterwards. I know this sounds silly, but to me it seems that this is the only way why the code ignores the key. Has any behaviour in this direction ever been noticed? A simple fix would be to just delete the lines considering the m_EntsSetUnfrobable list. If the only purpose of this is the above mentioned, then I think we can lay the responsibility to the mapper. But it may be a good idea to ask the person who wrote this what the real purpose is or to just find out what happens to the key (or its name).

OK, here is the code that seems to handle things. // Before setting something frobable, check if it is on the // list of things we set un-frobable earlier I don't understand this part. When the target is activated, it looks what it has done last time via the variable m_bCurFrobState and then makes everything frobable or not frobable (except some exceptions). So, I don't really understand the purpose here. Another thing is that the m_EntsSetUnfrobable list does not seemed to be cleared after frobability change has taken place. So IMHO the lines that changes the frobability should look like this (in replacement for the for-loop)