Ah, shift-Alt, nice tip, Blue, but anyway pathing. The problem frozenfire that you're having with the zombies, I think, is that you need to repath, but maybe it's more than that. Here's what works and doesn't work for me with paths:
If you move even a single apple (pathnode): repath. So leave pathing to the very end of your mapmake, if you can.
Think of each apple as being connected by lines, which they were in older unrealeds, so you knew whattheFyouweredoing.
So, with the lines in mind between the apples, there obviously needs to be line-of-sight between each connecting apple. 'Line-of-sight' gets more finicky, meaning: EG: if you path from a passageway into an open area, try not to let too many apples in the open area see apples deeper in the passage. IE: the zombie leaving the passage may try and choose a weaker path to the open area via a secondary (weaker) line (or path), so the zombie may walk into the wall.
In open areas, place apples on hills (again, keep connecting apples line-of-sight).
Max apple distance, from what I've read says that apples shouldn't be further than 1200 unrealed units apart (right click on map and choose gridsize -- from there you can work out 1200 max). In some 'pro' KF maps, I've noticed stacks and stack of unncessary apples and it's probably because they've taken notice of the dumb whinging node assessment thing that pops after pathing is done: IE: xnode is too far apart (or something like that -- too great a distance....) I suggest you Ignore it. Also if you place the apples too close, then the node whingy thing gets confused as well and talks crap. So, a reasonable stone's throw with line-of-sigh in open areas is usually good. Moving from narrow to open is the only really tricky bit which I'll explain. Although when the whingy thing says a path is invalid, I take heed. If an apple is 'stuck in the terrain' I take heed, and when there's no 'connecting node,' but often you've got to use your own best judgement. The whingy thing will give 'no connecting node' when its knee deep inapples because it gets confused.
With apples, less is usually more.
In this version of Urealed(V3) I've found pathing improved and even 768 distance is plenty -- but of course, there's those corners: passages to open spaces etc -- line-of-sight so very, very important, apple to apple. So like, if you have a door frame or a narrow way the zombies must get through, place an apple in the middle. Then from that middle apple, choose placement of the apples either side carefully. IE: try to avoid letting the apples on either side of the narrow way see each other through the narrow way (if the narrow way is where you want the zombies to go.) I say 'try not to let one side see the other' but the pathing in V3 is pretty good and isn't easily confused providing you space your apples well and keep line-of-sight in mind.
Up ramps: aim pointer at base of ramp, place a apple. Then aim pointer at top of ramp, place an apple. For jumpspot, place an apple in middle of ramp or top, but remember jumpspots doubleup as apples, as do playerstarts/weapon and some spawns. ---You know of course how to make a zombie jump (besides the obvious?) Apple, Navpoint properties: navpoint > 'forced' properties and open 'forced paths' and enter jumpspotnameX (that is: in the jumpspot properties > object it'll say: jumpspot2 or whatever.) So first the apple is placed and then the jumpspot below, to where the zombie can jump. (In my map, KF-A_Bargain, I also used 'proscribed paths' in apples (below 'forced paths'). 'Proscribed' makes the zombies in my map some who start on the other side of a valley, to encourage the zombies to walk around and not try to go straight across the valley to the players. Also there's a jumpspot on the plank that crosses the valley in which I used the above node > jumpspot.
So pathing. Think of it as leading a cross-eyed, shortsighted dog. Can the dog see me? When I call the mut will it choose other people it sees and then try running to them, thence banging its stupid self into a wall?
Phew, and your second question...
Doors. (choosing them works like choosing textures) IE: Choose a static mesh door. (Not all doors work to be welded. I got mine from 'lab meshes.') Then right click moverchooser option thing in unrealed and choose kfmoverdoor and so you'll place your chosen mesh door (the door colour in the overview/side map viewer is bright purple bluish) It will appear on the map in the middle of wherever you've left the red lined BSP builder). Next the actor: which is: kftrigger. In its properties > Events, 'EVENT' 'kftrigger properties' type anything. Next your door(s). In the door(s) 'Event's' 'TAG' put whatever you put in the trigger EVENT into the door TAG. (so one's in one and one's in the other...) That way when the kftrigger is touched the door(s) will open IF(you've set the mover), to set this: place door where you want it on the map (place door first before you set your open/close keys or you'll have the thing flapping around because you're chosen placement of the door will be key0 automatically!). Next, in unrealed 'side view or topview' rightclick (not doubleclick) and you'll see 'kfdoormover properties 1 selected' and below it MOVER > key1. Select key1 then move the door to your chosen open position. You've just made key1 or open position. Key0 is where you've already placed the door as closed. So now if you choose key0 the door should swing back to closed -- choose 1 again and it will open and so on and on 0 1 0 1...
If you shift the door to another place on the map after setting key0 and 1, the door won't like it.
Wow, typing practice. I was thinking, frozenfire you can load other KF maps and study them if you want, nobody minds, I don't think...? I never asked anyone. You can copy and paste between maps, even nick a whole map. Copying doors is tricky because their keys will have been set.
Hope that helps.
![[AM]Echo 419 Avatar](http://img142.imageshack.us/img142/2489/allyourbasearebelongtoumn2.jpg)