Fix for Inverted Doors
(All changes are located in 'doors.cpp')
Step 1: Add the following to definitions: Code:
#define INVOPEN_DOOR 0x03 Step 2: Change all 'md->action = OPEN_DOOR' to this: Code:
md->action = invert_state == 0 ? OPEN_DOOR : INVOPEN_DOOR; Code:
md->action = invert_state == 0 ? CLOSE_DOOR : INVCLOSE_DOOR; Code:
if((md->action == CLOSE_DOOR && invert_state == 0) || (md->action == INVCLOSE_DOOR && invert_state == 1)) properly, unless there are issues not related to 'doors.cpp' (There is an apparent bug in the actual GFay client door model. Sometimes you will 'miss' the elevator and you'll be left floating in the air. I remember this behavior from early 'live'.) I'm still running into other issues with incorrect or missing database values. I'll post updates for 'NPCOpen', 'ForceOpen' and 'ForceClose' after I make the proper changes in them. This should add my fix as well as the fix to 'ForceClose' suggested by someone else. U |
Could you please post a diff of the changes? It's easier to patch a diff than to search through the source replacing lines.
|
I'll have to get a 'clean' copy of doors.cpp for posting because mine is heavily modified with debug code, but I can post the modified
'HandleClick' if the dev's don't mind a ~380 line posting :) It may take until tomorrow afternoon until I can get back online to post it. I don't have access to the internet at my house. U |
Here is the current doors.cpp in the SVN repo:
http://projecteqemu.googlecode.com/s...zone/doors.cpp |
The best thing to do is finish your changes, diff against the repository and remove any debug code you wouldn't want to check in, then test with that file. If all tests were successful and you'd be happy checking that in then make a diff and post it.
|
Never done this before, but the diff file, patch action and build appear valid, and the game works as intended.
doors.cpp.patch Code:
Index: doors.cpp If you are waiting to go up the lift, you need to be about 3/5ths or more onto the lift or it will leave without you. The reverse is true for coming down - no more than 2/5ths way coming from Kelethin. Cycling the actuator seems to bypass this particular bug. The lift in 'Vergalid' and the 4-part Doors in 'Gyrospire' are not fixed by this, nor is 'Stonehive.' The 'Stonehive' lift actuators are not assigned trigger doors in my db (and are also exhibiting some really erractic behavior), and the other two will probably require a scripted action to work correctly. (They can be assigned as triggerdoors in sequential order, but if someone clicks a door somewhere down the chain than the 'starting' one, all preceding doors will not be triggered.) Since I have no experience with the scripted door actions for quests and npc's, I will need to parse out the logic states before I submit fixed versions of 'NPCOpen', 'ForceOpen' and 'ForceClose.' U |
All times are GMT -4. The time now is 01:21 AM. |
Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.