Implementing: Instancing

[Jabantiz]

I zoned into The Estate of Unrest and i have 25 minutes left and it is green and the reset timer is greyed out but i'm pretty sure the reset timer won't be available till my time left has expired.

Thanks will stop trying to get the time remaining to show red, the button seems to react client side as well.

Here's a screenshot of some different messages. I think you get one in-game when an instance expires too but not 100% sure. The yes and no window is when leaving a lockout instance that isn't persistent and you have a lockout, the first message is when a lockout is set, the second is trying to go back into a locked instance.

Thanks, messages will help, completely forgot about the pop up and will have to think of a way to handle that.

[Jabantiz]

Fixed the timer related messages to match the screen shot foof posted, also fixed the lua functions so they couldn't set the timer again after it had already been set.

[Jabantiz]

Added support for public / tradeskill instances, will start a new zone if population goes over max population set in rules. If multiple zones are active it will pick the zone with the lowest population to put the player in.

Also added Quest instance type, just creates an instance and puts the player in it, they are not bound to the zone so if they leave and reenter it will be a new instance, not sure if this will be an issue or not, think most zones that would use this type are small with nothing good in them to be worth the effort of doing that.

Also cleaned up client::TryZoneInstance() so the code that makes the message for lockout isn't repeated and now the switch should handle creating new instances.

[thefoof]

Here's a bug with instances I can replicate.

Code: Select all

MutexMap<Spawn*, float>::iterator itr = spawn_range_map.Get(client)->begin();
			while(itr.Next()){
				spawn = itr->first;
				if(spawn && itr->second < max_distance){
-------->Here			if(!spawn->IsPlayer() || (spawn->IsPlayer() && GetClientBySpawn(spawn))) //we don't want to send a half loaded player
						spawn->RefreshPacketData(pos_version, info_version);
				}
			}
		}
	}
}

This happens if you zone to 2 different instance zones rather quickly then zone back to a normal zone. I did this by zoning to Cave of Illboding dark[516], then Cave of Illboding Dark: The Source[517], and then to Frostfang. Also getting error catches about invalid spawns being sent to player->ShouldSendSpawn()

I got this results with both public and quest instances, didn't try any others.

[Jabantiz]

How did you zone from 1 version of the instance to the other? was it just /zone 516 and /zone 517 ? If so that bypasses the instance code completely and puts you in the base zone.

Also getting error catches about invalid spawns being sent to player->ShouldSendSpawn()

This is making me think that the crash you posted is related to the issue I tried to cover up by putting a try catch in player->ShouldSendSpawn(), basically what is happening is pointers are going invalid. I will have to look into possible solutions as this is starting to show up a lot.

Was frost fang already running while you were in the caves?

[thefoof]

Yep frostfang was already running, and I was using /zone yes.

[Jabantiz]

Yup looks like pointers going invalid, damn...

Will do some research, mainly EQ EMU and see how they handle this, off the top of my head I can only think of 2 possible fixes and both will take some effort

[thefoof]

Sorry for not mentioning it was in ZoneServer::CheckSpawnCache() btw lol, I had it in there and edited the message or something and forgot to put it back in.

[Jabantiz]

NP, figured it out because of the spawn_range map.


I have 3 possible solutions, and to be honest all will take some work. All refer to the spawn_list in the zone server as that should be the master list that controls spawns
1. Switch the list to smart pointers, note that this is a c++11 feature so not all compilers will support it
2. When a spawn is deleted, before the actual delete go through all possible lists that could contain a reference to it and check to see if any of them have a reference, if they do set it to 0
3. Change the list to a map<int32, Spawn*>, the int32 being a unique id > 0, and have every thing outside the zone server point to the id instead of the spawn pointer and when they need the spawn pointer call a function to get the pointer

Code: Select all

Spawn* ZoneServer::GetSpawn(int32 id)

I think 3 is probably the best solution, one of my original ideas and seems to be how EQEmu does it, will be supported by all versions of c++ (unlike option 1) and no chance of us missing a reference (probably a high chance of missing one with option2).

I will play around with some of this to see how much work it will actually take but what is every one else's thoughts on this?

Side notes:
This should probably be split off and moved to server bugs, also EQEmu moved to CMake and git???? WTF!!! guess I won't be screwing with their source any more

[alfa]

Quick question about instancing, I check table and not see field for this value so ask you. Have you take in count some requirement, like Max player in instance, need to be in group, need to be in raid (I assume Min / Max level handle with zones tables) ?

Short example, Raid of 24 ppl zone in VP, at first kill of a name each ppl in raid are taged with this instance. 1 ppl log out, raid leader invite another player, 1 If he have no timer, inform client it going to be flagged, 2 if player is tagged, a message in chat like Player have no requierement inform player he cannot zone in (this message also show list of player who need to reset when raid player try to zone in and some player need to reset). So player zone in, 24 ppl in instance and player who have log out log in again, IF there is aleready 24 ppl in zone player receive red message tell he is going to be kick from zone in some times (like 1 or 2 minute). If there is not 24 ppl in instance it's OK, but if another player group in raid and zone in, player ungrouped start to receive red message. It work for X2 raid, and I assume it work for Group too.

Some zone requiere to be in group or in raid to zone in.

A player who log off in persistent instance got back into it directly when they log again. If instance expired, you log in zone, and have message instance expired and get kicked from instance.

Hope you understand me ^^ And maybe you have planned to handle it with Zone script soooo... :p

[Jabantiz]

I wasn't aware that some zones have a max player limit. Flagging every one on the first kill can be handled in lua script. As for kicking people out of the zone, we haven't figured out the best way to handle that so it is not supported at all yet. The other requirements will probably need to be addressed in the zone access discussion as they prevent entry to a zone.

A player who logs off in a persistent will log back in, won't be kicked out if it has expired though...

[alfa]

A player who logs off in a persistent will log back in, won't be kicked out if it has expired though...

Tested on live, you have message (translate from french) This instance is exipred, it same you about 5 time and you automaticly zone out

[Jabantiz]

I think 3 is probably the best solution, one of my original ideas and seems to be how EQEmu does it, will be supported by all versions of c++ (unlike option 1) and no chance of us missing a reference (probably a high chance of missing one with option2).

I lied, it is actually very easy to miss a reference...

Did a simple test and converted spawn_list from MutexList<Spawn*> to a map<int32, Spawn*>, used the unique ID we already maintain for spawns also converted the spawn_range_map that has been causing the crashes in frost fang when zoning back and forth from the cave and frost fang and with a lot of zoning back and forth I have not had a single crash or error.

[thefoof]

I say whatever you think is the best way, can't say I know all of the mechanics with these different types (smart pointers ect). But whatever would be the least likely to be error prone in the future would get my vote.

Also if this is going to be a huge emu wide overhaul let me know what needs to be done and I'll help convert some of the .cpp's over.

[Jabantiz]

Also if this is going to be a huge emu wide overhaul let me know what needs to be done and I'll help convert some of the .cpp's over.

Thanks for the offer, it should be mostly in the zoneserver.cpp, spawn.cpp, entity.cpp, npc.cpp, player.cpp, and npc_ai.cpp, also it is not a simple conversion some code has to be rewritten to work with the new map. I think I have converted everything but a few lists in zoneserver already though, going faster then I expected.

I am still waiting for johns input, but almost have it all converted locally, I also haven't noticed the server crashes from zoning from cave of illboding to frostfang using the door, no random invalid spawn crash, and while I may have just been lucky I haven't had the ping time out when logging in. Also found a crash bug related to spells as a result of my testing, combat bug that prevented the player from auto attacking, and may have fixed the /reload spawnscripts that caused the zone server to crap out.