Consolidated "Lifts" Thread

[John Adams]

Here is a list of the topics related to Lifts/Elevators, going back 3+ years. The direct vertical lifts used to work, but stopped working after initial implementation. I do not believe the current malfunction is not a DoV/CoE thing, but something else. I saw convo on IRC about it, and thought I'd help by doing a search

Here are some topics, rather than re-inventing the wheel (I thought Jab recently implemented UseWidget() for this exact purpose) -

http://eq2emulator.net/phpBB3/viewtopic ... 8885#p8885 Working example (elddar grove lift)

http://eq2emulator.net/phpBB3/viewtopic ... 069#p10069 (Alfa)

http://eq2emulator.net/phpBB3/viewtopic ... 992#p11992

http://eq2emulator.net/phpBB3/viewtopic ... 995#p11995

http://eq2emulator.net/phpBB3/viewtopic ... 268#p12268 (Movement Bug, LE hinted at a fix)

http://eq2emulator.net/phpBB3/viewtopic ... 945#p23945

http://eq2emulator.net/phpBB3/viewtopic ... 082#p24082 Jabantiz UseWidget()

http://eq2emulator.net/phpBB3/viewtopic ... 112#p23112

Since the vertical lifts used to work, I wasn't sure what Jab's "UseWidget()" was for, or if it's even related. The lifts we failed to get working were the acorn lifts in GFay, even using these same settings. And of course, the roll-away doors in various dungeons/zones.

I think I even had the Freeport library lifts working at one point.

[Jabantiz]

The current issue I am running into is that the lift in Elddar grove works great in DoV but doesn't work in CoE.

If you run up to it in CoE it is solid and can run around on it, once you hit the switch the lift will pass straight through you if you are standing still, if you are moving around on the lift then it will work, stop moving mid way and the lift will pass straight through you again leaving you floating in mid air. In DoV the lift works perfectly.

I even logged on 2 clients at the same time to play with lifts, 1 DoV and 1 CoE, put both client on the lift then hit the switch, on the DoV client it showed both clients going up on the lift like there was no problem, however on the CoE client it showed the lift pass straight through both clients.

Xinux got a log of the Elddar Grove lift to see if there was anything special now but I don't see anything, I have tried changing move_type and move_mode values in the spawn struct to match packets thinking that is the issue but that had no effect. Even tried screwing with the player movement code to see if something was wrong in it causing issues but found nothing (probably isn't in that code). I saw nothing special in the log so no clue why it is not working in CoE, can only assume something has changed in the spawn struct that I have yet to identify but not even sure that is it.

[John Adams]

Dumb question time...

Code: Select all

#define ACTIVITY_STATUS_SOLID_1188					128 //used by zone objects to remain solid

Is this somehow getting removed from the values? And is "activity_status" the field that should have this value? I haven't played with anything but visual_states in eons, so I cannot remember. Just thought I'd mention the obvious.

Maybe 128 is not the actual value, or when it's on the move the value is something else.

[thefoof]

/Dr. Orpheus

So I spent some time today looking at widgets to see if I could figure out how they work in the db. Just to add some more controversy as to the current state of lifts, the Eldarr Grove lift worked perfectly fine on my local (1199 client, milestone 1 data). So I figured I would try to get the kelethin lifts working or atleast one, I can tell you they definitely weren't set up right in the db, although not sure that they were ever worked on so that could be why .


I was able to get the lifts to elevate and drop back down perfectly fine, but experienced the problem of the lifts passing right through the player, so the question is why does the Eldarr Grove lift stay solid and the acorn lifts not? Possibly the widget ids are wrong (would that effect it?) or need the values set to something hardcoded in the zone files possibly?


EDIT: I noticed if I got in the acorn while it was going down that it would put me on an invis platform where the widget currently is if I stop and when I would move I'd fall down to the floor of the acorn . I could run against the walls without going though also, so maybe the widgets can't force the player to move? (but then why does the eldarr grove one work)? posting some stuff so others can see the conditions I'm testing with and try it themselves if they want.

Data Query

Code: Select all

insert into spawn (id, name, sub_title, race, model_type, size, size_offset, targetable, show_name, command_primary, command_secondary, visual_state, attackable, show_level, show_command_icon, display_hand icon, faction_id, collision_radius, hp, power, merchant_id, merchant_type) values (1149999, 'Tunares Sapling Acorn Lift', NULL, '0', '49', '32', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '409', '0', '0', '0', '0', '0');
INSERT INTO `spawn_widgets` (`spawn_id`, `widget_id`, `widget_x`, `widget_y`, `widget_z`, `include_heading`, `include_location`, `icon`, `type`, `open_heading`, `closed_heading`, `open_y`, `action_spawn_id`, `open_sound_file`, `close_sound_file`, `open_duration`, `close_y`, `linked_spawn_id`, `house_id`) VALUES
(1149999, 1958019821, 60.6389, 9.14952, 16.9433, 0, 1, 0, 'Door', -1, -1, 88, 0, '0', '0', 0, 9.14952, 0, 0);


INSERT INTO `spawn_location_placement` (
`zone_id` ,
`spawn_location_id` ,
`x` ,
`y` ,
`z` ,
`x_offset` ,
`y_offset` ,
`z_offset` ,
`heading` ,
`respawn` ,
`expire_timer` ,
`expire_offset` ,
`grid_id`
)
VALUES (
'114', '999999', '60.6389', '9.14952', '16.9433', '0', '0', '0', '0', '3600', '0', '0', '352540949'
);

INSERT INTO `spawn_location_entry` (
`id` ,
`spawn_id` ,
`spawn_location_id` ,
`spawnpercentage`
)
VALUES (
NULL , '1149999', '999999', '100'
);

Script I used to test with

Code: Select all

function spawn(NPC)
    UseLift(NPC)
end

function UseLift(NPC)
    AddTimer(NPC, 45000, "UseLift")
    UseWidget(NPC)
end

[Jabantiz]

This sounds like the issue we had with the elddar grove lift when we first started working on CoE, something to do with values changing in the spawn struct, will look at the code to see why elddar works now but the acorns don't

[xinux]

I also had to change a value in the DB and for the life of me i can't remember what it was. But i thought we fixed that so depending on what client version connected it sent the right value cause the value between dov and coe were different.

[thefoof]

Figured this out, you have to set icon = 12 in the spawn_widget field and it works o.0

Thanks xinux for the tip, I had probably changed every single field but icon and didn't think icon would affect it, but looking back at it, it seemed weird a widget that isn't highlightable had an icon set

[thefoof]

New code committed for boats/lifts. Changes are as follows:

Lifts
* Players should no longer port while riding a lift

* The default widget values for open_y and close_y should be set to 0 if you do not wish to use this value.

* Negative Y values are now supported on widgets, we well as X and Z values.

-- NOTE --
The lift must have icon set as 28, I added a new spawn set value for icon so this may be changed easier. Activity status must also be set to make the lift solid (set this value as 64).

[Jabantiz]

Nice job figuring this stuff out.

... this is because we do not yet calculate "current" XYZ values while a spawn is moving and therefore the update packets are imperfect, after stepping off a boat the player should show up correctly, however.

Spawns will update the XYZ values, however the way widgets are coded they do not utilize this code.

[thefoof]

Spawns will update the XYZ values, however the way widgets are coded they do not utilize this code.

Gotcha I see the code you're talking about now, I missed that

[thefoof]

Looks like I'm going to have to get that code to work for widgets as well for the frostfang boat, that's just a weird case because of how far it travels being a widget.

[thefoof]

Looks like I'm going to have to get that code to work for widgets as well for the frostfang boat, that's just a weird case because of how far it travels being a widget.

Okay new code committed for this. I also found after more testing my method of obtaining a spawn pointer for the boat/lift the player was using was unreliable at times, so I changed this to grab the nearest spawn in a list from the zoneserver. I also extended our movement code to allow for movement loops for widgets, and changed our widget code to use Jab's new movement code instead of the old X2, Y2 method so that we get accurate, realtime movement updates. (Widgets will not use the facetarget calls in movement loops but still use their open/close heading, just an FYI)

Use the lua function AddTransportSpawn(Spawn*) if a spawn is a lift. Not required but without it you will not get accurate movement updates, and depending on the situation can cause players to port.

To recap, for a spawn to be a lift it must:

• *Have activity status set as solid (value 64 in the server)
  
  *Icon set to 28
  
  *Set as a transport spawn with LUA:AddTransportSpawn()

[John Adams]

Foof, not sure if you fixed that raft in Frostfang yet, but I was just standing on it minding my own business when I went under the world. I did a /goto Galinda to get out, and my character is now invisible on the screen. Still works, just can't see him (grid issue?)

Just a heads up.

[thefoof]

If you scroll the camera up and back out your toon will come back, did you compile today? I haven't setup the boat's script yet so it shouldn't be working right no =p

EDIT:Ok script is up, should work now.

[John Adams]

I did recompile a few hours ago, yes. Been restarting Dev world too, loading new spells up and testing. I was scrolled back out on my cam, in and out, swirled it around, did all kinds of stuff. Camping and coming back fixed it.