I would like to work with dinamic instances for dungeons, special events , tournaments.
Something like CreateInstance(instance id,x,y,width,height,REALM)
And then using the rest of functions with (instance id) for (REALM id).
Thanks
Feature request: Instances.
Moderator: POL Developer
You know, I've thought about this, and if you used some seriously intense packet hooking you could probably pull off instancing dungeons and houses and stuff.
If you don't know what instances are, it's when a location has multiple instances. If a dungeon or zone is instanced, it means if you and your party go inside, it will be just you there, even though other people and parties are at that same location. So you could have a huge player base and only a few dungeons and no one would step on each other's toes.
Pulling this off with POL now may be possible but it would be incredibly complicated and resource intensive. You would have to have multiple copies of objects in an area and send only the copy that is instanced to that player.
You might be able to do this by keeping a template for zones stored in datafiles of every object/npc, and it's location and all of it's properties. Then when someone enters an area you'd create every object stored in that template at the defined location and then set two cprops, let's call them InstanceZone, which would be a name for the zone, like "Evil Dungeon" and InstanceIDs, which would be an array of the character serials who entered the zone. Then you'd hook the send object packet and whenever an object is sent, check that object for the InstanceZone property. If it exists, only send the packet if the character serial in the packet hook is in InstanceIDs. You'd also have to tweak the AI to only interact with characters that it is instanced to, so again, check if character serial is in InstanceIDs.
So you could have a script/gump menu thing that would take in cordinates for a zone, just like with spawn region. Then the script would cycle through every object in the cordinates and save it in a datafile as a template. Whenever someone enters a zone, recreate the zone from the template, set cprops accordingly. Only objects that pass the send object hook are sent to the client can be interacted with. It may also be necessary to hook other packets that would normally be sent to the client, such as animation packets and other stuff, to keep the client from crashing. I'm not sure what would happen, but I'm fairly sure that if it crashes easily it would take an enormous number of hooks to implement.
When all characters in InstanceID leave the area, a timeout is started, so after 5 minutes or so, every object that is instanced to those players will be deleted.
If the above logic is correct, then saying adding this functionality to the core would be difficult and time-consuming a true understatement. You make it seem like it would be easy by the way you ask for it.
... I'll still probably try and do it with hooks when I have some free time.
If you don't know what instances are, it's when a location has multiple instances. If a dungeon or zone is instanced, it means if you and your party go inside, it will be just you there, even though other people and parties are at that same location. So you could have a huge player base and only a few dungeons and no one would step on each other's toes.
Pulling this off with POL now may be possible but it would be incredibly complicated and resource intensive. You would have to have multiple copies of objects in an area and send only the copy that is instanced to that player.
You might be able to do this by keeping a template for zones stored in datafiles of every object/npc, and it's location and all of it's properties. Then when someone enters an area you'd create every object stored in that template at the defined location and then set two cprops, let's call them InstanceZone, which would be a name for the zone, like "Evil Dungeon" and InstanceIDs, which would be an array of the character serials who entered the zone. Then you'd hook the send object packet and whenever an object is sent, check that object for the InstanceZone property. If it exists, only send the packet if the character serial in the packet hook is in InstanceIDs. You'd also have to tweak the AI to only interact with characters that it is instanced to, so again, check if character serial is in InstanceIDs.
So you could have a script/gump menu thing that would take in cordinates for a zone, just like with spawn region. Then the script would cycle through every object in the cordinates and save it in a datafile as a template. Whenever someone enters a zone, recreate the zone from the template, set cprops accordingly. Only objects that pass the send object hook are sent to the client can be interacted with. It may also be necessary to hook other packets that would normally be sent to the client, such as animation packets and other stuff, to keep the client from crashing. I'm not sure what would happen, but I'm fairly sure that if it crashes easily it would take an enormous number of hooks to implement.
When all characters in InstanceID leave the area, a timeout is started, so after 5 minutes or so, every object that is instanced to those players will be deleted.
If the above logic is correct, then saying adding this functionality to the core would be difficult and time-consuming a true understatement. You make it seem like it would be easy by the way you ask for it.
... I'll still probably try and do it with hooks when I have some free time.
-
Obituary
Yes maybe it could be done with extreme packet hooking, but expensive in performance 
I think its a cool feature for the new core. Some work on this has been done in runuo http://www.runuo.com/forums/showthread. ... =instances
I could try to make it with packethooks if the core team isn't interested on add it. But probably its a waste of time due to performance impact.
I think its a cool feature for the new core. Some work on this has been done in runuo http://www.runuo.com/forums/showthread. ... =instances
I could try to make it with packethooks if the core team isn't interested on add it. But probably its a waste of time due to performance impact.