Debugging Work: The Palborough Mines Elevator Issue

Forum rules
NO LONGER BEING MAINTAINED!
Post Reply
starlightknight
Posts: 25
Joined: Sun Apr 06, 2014 11:43 am

Debugging Work: The Palborough Mines Elevator Issue

Post by starlightknight » Sun Apr 06, 2014 12:41 pm

So I hit the bug with the elevator when attempting to run San'dOria Mission 2-3 (client: 30140319_0) - http://bugs.dspt.info/show_bug.cgi?id=952

Since this bug blocked me from proceeding further without using GM commands, I tried to troubleshoot it further, and ultimately got stuck. So I'm going to summarize my findings here and hope that someone who knows more than me can make something of it.

First, I added a ton of debug logging specific to this elevator (elevator id = 22), so that I could watch its behavior in the console log. I'll attach my transport.cpp with debug logging if someone is interested.

After reviewing the logging, I noticed the following:

With the current code, startElevator gets called for this elevator by the RunElevator lua command. However, the elevator never triggers arriveElevator.

After reviewing the code further, it seems that the reason for this relates to this elevator not being a permanently moving elevator. If the elevator is not permanently moving, the TransportTimer sets IsStarted to false once it thinks its done moving it:

Code: Select all

						if (!elevator->isPermanent)
						{
							elevator->isStarted = false;
						}
One problem is, it seems like nothing ever can set this elevator to isStarted = true. After tracing the Lua command RunElevator, which is triggered when you pull the lever, I couldn't find anywhere in the code where this was done. So this elevator appeared to be "stuck", because even after I pull the lever, it doesn't get set to isStarted = true;

After I found this out, I added the following to the startElevator function (reflected in my transport.cpp) -

Code: Select all

						if (!elevator->isPermanent)
						{
							elevator->isStarted = true;
						}
After this was added, the elevator would now trigger arriveElevator shortly after starting like it should. At this point, if I compared my debug logs for this elevator (id = 22), against one of the elevators in metalworks (id=26), then they look like the same basic flow now.

The problem was, the platform still didn't move. So next I compared the elevator entry in the db to one of the other working elevators. The logging told me that the npc it was trying to move was "_3zz", so I looked it up in the NPC list. I noticed that the starting animation for this elevator was listed as "9" for its animation. That was interesting, cause according to the animation enum I see this:

Code: Select all

	ANIMATION_OPEN_DOOR				= 8,
	ANIMATION_CLOSE_DOOR			= 9,
	ANIMATION_ELEVATOR_UP			= 10,
	ANIMATION_ELEVATOR_DOWN			= 11,
"_3zz" was in one of the door states. When I compared to the Metalworks elevator id=26, which after debugging, I found out was id npc id "@6l0". Both this elevator and the other elevator were in states 10 and 11.

I tried swapping "_3zz"'s animation to 11 (since it starts at the top), but this was no good. In fact, it caused me to not even hear the sound of the elevator moving anymore. So I reverted that...

Then finally I noticed one last interesting thing: both of the other elevator's npc name started with "@". In the very next line after "_3zz"'s definition in npc_list.sql, there exists an "@3z0", which is in elevator state 11, which happens to be the top state which is where the elevator starts off at. The positioning to "_3zz" is similar as well.

So I guess my question is....
Is it possible that the reason the elevator doesn't move is that we're trying to move the wrong npc? I don't know enough to know how we associate "_3zz" as being the elevator npc, but it seems to me that that might be the door and "@3z0" might be the elevator, but I don't know how to try this out.

Thoughts?
-SLK
Attachments
transport.cpp
(19.62 KiB) Downloaded 592 times

starlightknight
Posts: 25
Joined: Sun Apr 06, 2014 11:43 am

Re: Debugging Work: The Palborough Mines Elevator Issue

Post by starlightknight » Sun Apr 06, 2014 5:43 pm

A solution has been reached for this. As I expected at the end of my investigation notes in the original post, the elevator code is trying to move the wrong NPC.

I noted at the end of my notes that I thought the next npc up in npc_lists.sql was actually the elevator based on my debug logs, but didn't know how to test that. Apparantly, by incrementing elevator, upperDoor, and lowerDoor in the sql by 1, the elevator is functioning well again.

Special thanks to forum member forgottenandlost for providing me with a tip on how to adjust the SQL. I will get together a patch for this shortly and then we can finally have this long standing bug fixed.

With the adjusted sql, the change to startElevator is not necessary either. It seems the behavior of the elevator never arriving was a side effect of the elevator code trying to move an npc that wasn't an elevator to begin with

Edit: Pull Request #119 has been submitted to fix this issue: https://github.com/DarkstarProject/darkstar/pull/119

User avatar
kjLotus
Special Guest
Posts: 1813
Joined: Sun Jul 22, 2012 2:16 pm

Re: Debugging Work: The Palborough Mines Elevator Issue

Post by kjLotus » Sun Apr 06, 2014 6:25 pm

a little background info: every now and then a client patch will shift all the npcids in a zone (usually by 1). since nobody has set up a way to keep all these ids in a single centralized place, whenever a zone changes, it has to get updated in like 4 different places, and sometimes one will be forgotten. i can pretty much guarantee you that the elevator worked, then palborough got shifted by 1 and the elevators file didn't get shifted with it. it's also possible that other elevators or transport are broken as well

starlightknight
Posts: 25
Joined: Sun Apr 06, 2014 11:43 am

Re: Debugging Work: The Palborough Mines Elevator Issue

Post by starlightknight » Sun Apr 06, 2014 6:31 pm

kjLotus wrote:a little background info: every now and then a client patch will shift all the npcids in a zone (usually by 1). since nobody has set up a way to keep all these ids in a single centralized place, whenever a zone changes, it has to get updated in like 4 different places, and sometimes one will be forgotten. i can pretty much guarantee you that the elevator worked, then palborough got shifted by 1 and the elevators file didn't get shifted with it. it's also possible that other elevators or transport are broken as well
That makes a lot of sense based on how some of the other ability / spell / trait ids are ordered as well. Good to know. Thank you very much for the extra info :-)

Claud123
Posts: 1
Joined: Mon Feb 20, 2017 2:31 am

Re: Debugging Work: The Palborough Mines Elevator Issue

Post by Claud123 » Mon Feb 20, 2017 2:44 am

i think it has been explained very well, thanks for the info :)

Post Reply