View Full Version : Keyed teleport doors bringing along group
Problem statement is here:
http://www.projecteq.net/phpBB2/viewtopic.php?t=6669
In live someone who possesses the key to a particular floor in Tower of Frozen Shadow has the power to bring his/her entire group with them when they click on the doors. On PEQ however it only relocate the person who possesses the key meaning each individual group member needs to have their own key to each floor. As the key drops are somewhat rare it makes this zone rather undesirable. I was wondering if there is any way to fix this?
Changes are:
http://nolaquen.com.phtemp.com/eqemu/changes/groupdoors/
I'll get a unix-style diff once I get that set up.
By the way, a couple notes on implementation here:
This change applies the group teleport mechanic on all teleport "doors" globally (except for LDoN). To my recollection, I believe this is the way it worked on Live--I can't think of a clicky teleport that wouldn't bring along your whole group (in a close vicinity) if the door was keyed.
This may be incorrect. What may more likely be incorrect is that this implementation pulls your whole group along with you even if the door is not keyed. On this, I'm less sure that this is the way it worked.
If the latter is incorrect, it's a simple change to the above implementation.
If the former is incorrect, it's probably more appropriate to implement this using a database field for each door to indicate it's "group"ness. I can make both changes if anyone feels that's a more true version of representing Live.
=== the diff is based on rev 992 ===
Shin Noir
09-30-2009, 05:31 PM
Sebilis, Charrasis, Sleeper's Tomb? Probably need a quick db field to differenciate, yeah. It would also be possible to do this sort of conditional check on a script when you utilize a door too, I would think. Assuming we don't want to add another field to the DB and the above source edits. (I was meaning to make ToFS be a group-teleport system. I'm not sure of other doors that were group based key teleporting).
I seemed to remember that only one person needed the key for Seb but most people got it anyway so that they could zone in solo. Didn't think of Charasis. Never went to Sleeper's Tomb. :)
If the entire mechanic is scriptable, then I suppose it makes sense to leave it out of code.
Anyway, I'll add the db field tonight while y'all are deciding on that point. :-D
Shin Noir
10-01-2009, 11:43 AM
Wrote a perl version. Got stuck on one method though, which sucks. But 75 lines of code in a script not as intrusive as a source modification and new field in zone. Both are totally doable as options though!
http://www.eqemulator.net/forums/showthread.php?t=29697
Thanks Shin Noir! There might be a few perl enhancements that can be made to make it easier, like keeping the range argument on the TeleportGroup function (thereby avoiding having to iterate through group member list). I can look into the GetInv() failure, but otherwise, I like the script. I noticed you have to be explicit with the destination locations--that data already exists somewhere. Maybe the best approach here is a coupling of DB-sourced data, slight extensions to some functions (range check on TeleportGroup) and perl-sourced execution.
Sorry I haven't followed up on this. I got distracted with Spirit Shrouds. I should be able to submit a patch that has them working some time next week (I'm hoping) and then I'll come back to this.
Shin Noir
10-02-2009, 12:37 PM
Well, I couldn't think how to get the door's location. It's private information in the door object, destination is more public, but perl doesn't have access to the door object. (That's pretty easy to fix though).
I gave myself a limitation: No source modifications. Haha.
With source mods I could reduce the perl code substantially, for sure. And the entity loop was because I can't seem to access the Group object via perl. If I know the client ID's of each group member I don't have to loop through a ton of entities to match up group members.
That's probably two things that should be added to perl scripting, but, meh.. I made due without. ;)
It'll be a good example for others who want to delve into the perl scripting langauge a bit more.
I agree, it's a great way to approach this. Attempt it entirely in scripting, see where the limitations are, and then resolve just the limitations in code.
cavedude
10-14-2009, 07:06 PM
Since this is resolvable using Perl, I'm moving to Development since it's more a discussion now.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.