It doesn't solve your problem, but I wouldn't call it a bug. That's pretty much how I'd expect an automatic door to behave.
Given how the engine is written, there's little else to do with a door but hold position or reverse if it can't close without interference.
Looking at the SDK, it would be nigh unto impossible to determine if the way is clear for the door to close if there's an object in the way. When an object takes damage, it's up to the object, not the door, to determine it's fate.
Just because something in the engine doesn't do what you want doesn't mean it's a bug.
If you want to make a mod, however, it's possible to change the func_door behavior with coding.
Good for you for not reinstalling. Unfortunately, most new mappers think reinstalling is the answer for most problems.. and it rarely, if ever, is the answer.
Perhaps I'm misunderstanding what you mean by the "same" position. There is an absolute position of the player in any map. But that doesn't have to be the absolute position (and rarely is) of the player in the map to which he transitions.
The player ends up in the same relative position to the landmark in the second map that he had in the first map.
If he is ten units "west" of the landmark in the first map when the changelevel is triggered, he will be positioned ten units "west" of the landmark in the second map, whereever that landmark is (in absolute position) in the second map.
The landmarks don't have to be placed in the "same place" (whatever that means since there are two separate maps).
The landmarks can be placed in similar looking locations such that it appears that the second map continues where the first one left off. But it can be placed anywhere in the second map.
I volunteer to help out with the coding. I suck at the graphics part but am familiar (though a bit rusty) with uploading/downloading, url checking, login/logout, mySQL, etc. - the behind-the-scenes stuff.
Good for you to continue pressing on (pun intended) when something didn't work. The best way to avoid mistakes is with experience. The best experience comes from making mistakes.
FYI, OpenGL was out for years before Microsoft developed DirectX. Similar to Bill Gates forcing the Microsoft version of "Javascript" on the world although Sun's Java is more than adequate.
DirectX is used for many games simply because Microsoft ships and supports DX in Windows and does not support OpenGL well at all.
OpenGL is open library software. DirectX is proprietary.
DirectX, in general, is very computer unfriendly as it goes below the operating system layer to take over video cards and IO devices directly for the sake of speed. I honestly don't remember having to powerdown or reboot when running an OpenGL application.
Just add an output to the func_button for each lock.
With the func_button properties dialog open, click the Outputs tab, click Add, fill in the info for the first lock; click Add again, fill in the info for the second lock.. you get the idea.
Simply put a BlockLight brush in the doorway. Don't parent it or tie it to any entity. That will prevent the flickering light from appearing in the second room.
As Kasp said, during the game, the light from one room won't affect the light in the other.
You should be able to use ai_relationship entities.
Set the NPCs disposition to LIKE until the !player triggers the prox trigger. Then trigger an ai_relationship and have the ai_relationship change the NPC's disposition to HATE (or FEAR?). When the player leaves the prox trigger (OnEndTouch or the like), trigger another ai_relationship to change the NPC's disposition back to LIKE and he'll reholster his weapon.
EDIT: I tried it and it should do what you've described.
ai_relationship named ai_like, starts enabled, subject: the npc, object: !player, disposition: Like
ai_relationship named ai_hate, starts disabled, subject: the npc, object: !player, disposition: Hate
Setup a trigger_multiple near (or Parented to) the npc.
When the player gets near the npc, he draws his pistol and begins firing. When the player runs away, the npc holsters his weapon and goes to an idle animation.
You may be able to use scripted sequences to achieve something close, with Action Animation = draw pistol, PostIdle loop = idle angry.
Looking in the SDK, I haven't figured out yet how to put the NPC into combat mode to get the idle angry part, but there is an animation ACT_METROPOLICE_DRAW_PISTOL (for instance) which you can use with a metro police.
From the code, it appears that, if the npc is in a combat state, ACT_IDLE will get translated into ACT_IDLE_ANGRY and the npc will stand with weapon drawn. Otherwise, ACT_IDLE causes the npc to go to the normal (weapon at side) stance.
So, without being in combat state the result is a quick draw followed by normal idle = not what you need
HL2 - When adding in a stairway using handrail props, add the handrail prop and a couple of steps (if not all of them) of the desired width and height before finishing the room or adding the floor to which the stairway leads.
If not, the odds are you're going to have to reposition the entire stairway or upper floor to make the top and bottom of the handrail appear correct.
I don't have a data2.cab in my XSI installation - only data1.cab.
Did you get as far as registering your mod tool installation? After installation, you MUST register it with Softimage for it to start up. Back when I installed it (long time ago), immediately after the first startup, you have to do a File-Save and a registration screen pops up. Fill out the registration (you'll get spam from your email address so be prepared), submit the form and you'll get an email with a registration code which you then need to use after you restart XSI to get anything(!) to work.
FYI - my installation of the the mod tool always requires an active internet connection and it will hang on the splash screen if your connection is borked or the Softimage server is slow.
For me, with 1 G RAM, 4G CPU and 512k cable, XSI takes about a minute to start up.
Softimage has a forum site for the mod tool (don't know whether it's still up) and you can get some help there.
IMO, using other than XSI to model is a pain in the rear. With XSI, you export your file and after one drag and drop on a desktop shortcut, the model's ready for use.
Looks like a nice texturing job, CP (to be expected from you). It certainly looks better than the last time I saw it when it was all dev and purple/black checker textures!
I commented on your maps, bal. There is no problem with the entity setup at all. The problem is that your levels are not sealed. You use the AAATRIGGER texture for the box surrounding the levels and that's what's causing the problem. Change that texture (see the problem map vault comments).
Also, I noticed that the monster entities are too close to the walls, causing the yellow "flies around the monsters" indication.
Also, your light entity intersects with the ceiling brush. It should be moved down a little so that it doesn't intersect with any brush. If the center of the entity is inside a brush, no light from it will be rendered in the map. The lights in your maps are okay as-is, but if they're moved even a little, your maps may go dark.
You SHOULD see a "Loading.." message (if only briefly) between maps.
bal: You have to give some information to us for anyone to help. No-one knows what "fixed a few minor details" means, so that's no help at all.
Did you check the properties of the brushes and entities as suggested? Did you construct brushes using the AAATRIGGER texture and tie them to a TRIGGER_CHANGELEVEL entity, one in each map? Did you check the properties of the trigger_changelevels and the name of the info_landmarks as suggesteed?
For a changelevel, there're only 2 AAATRIGGER brushes and 2 info_landmark entities involved: a trigger_changelevel brush in each map and an info_landmark entity in each map.
Make sure the trigger_changelevel in each map has New Map Name set to the other map (spelled correctly AND both map bsps have been compiled correctly and exist in the correct directory) and each trigger_changelevel in each map has Landmark Name set to the one name of the info_landmarks.
Make sure BOTH info_landmarks (one in each map) have the exact same name.
The actual location of the info_landmarks really doesn't matter provided there's room at their locations for the player to spawn when the map changes.
You can also zip both maps (RMFs) together and post them to the problem map vault for someone to look at.
If you're public relations, you really should consider mentioning what your product is about.. is it a mod? an addon? what platform? are you targetting CS or what?
You had the fire working before so nothing should have changed. Sounds like you don't have the button setup correctly.
Do something simple like turning a light on and off that's very obvious and get the button working correctly. Then add to the button just the fire start and make sure that works. Then add the fire extinguish temporarily, etc.
If you get entirely frustrated, perhaps you should post the map to the problem map vault and let someone take a look at it.
First of all, if you don't know already, a hint brush has only one surface covered with the hint texture. To construct a hint brush, construct the brush with the SKIP texture and then apply the HINT texture to just one surface of the brush.
Yes, it's okay if the hint surface intersects with a world brush, or even another hint surface. Normally, though, if you're applying it correctly, it would intersect with just an edge and not actually cross the surface. An exception would be a doorway with an irregular shape.
For instance, if, by "irregular shaped," you mean an arched doorway and you want a visleaf to be created at the doorway, use a single vertical hint brush and have it overlap the entire arch and the rest of the doorway, one brush covering the entire opening.