miguelmig

Look at the db.core

add me on skype: miguelmigpt, I only sell if you give me the paysafe code first.

Disclaimer, this only makes it update in real time for the player itself, should I add the part to broadcast to nearby players in this post, or create another topic?

In InstanceBase.h after protected: DWORD m_dwDuelMode; DWORD m_dwEmoticonTime; paste this public: DWORD GetLevel() const { return m_dwLevel; } void SetLevel(DWORD lvl); In InstanceBase.cpp, in the end of the file paste this: void CInstanceBase::SetLevel(DWORD lvl) { m_dwLevel = lvl; } and then on PythonPlayer.cpp near this line: CInstanceBase* pkPlayer = NEW_GetMainActorPtr(); if (pkPlayer) pkPlayer->UpdateTextTailLevel(lValue); add brackets and "pkPlayer->SetLevel(lValue);" inside the if statement, like this: CInstanceBase* pkPlayer = NEW_GetMainActorPtr(); if (pkPlayer) { pkPlayer->UpdateTextTailLevel(lValue); pkPlayer->SetLevel(lValue); }

The game99 core is not very special in these levels, it's a game core like the others, but the maps are usually independent of the channel, therefore the reason that there is only 1 game99 per server. The maps in that core will be "global" and when a player leaves a map on game99, he will always return to channel 1

It's a possibility, but I would prefer keeping all the cores up to date with the elevations (which is simple enough) rather than having to worry about creating and deleting files. Edit: Well, upon reflection, miguelmig, I do agree that sending everything everywhere for the simplicity it carries with it might be worth a second thought. Don't wanna offend you or anything, but P2P packet is nothing more than Game -> DB -> All other Game Cores, plus, all the game cores should know if the player is indeed elevated, in case the player logs in to those cores, he should already be elevated. If the elevation is a one-time thing ( the player would remain elevated after the server shutdowns ), the elevated accounts should be stored either: 1. in a cache file ( not a single file for each player as you said ) or 2. in a mySQL table. You should never keep any information in auth, auth is the busiest connection/core of them all, it's the most prone to overflowing and shouldn't be responsible for that data.

I didn't exactly suggest to store it via auth even though I was thinking of something like that (But not really indepth as now xD). There's an inherent problem with Metin2's auth where it is impossible to track someone after they teleport. There's no linking of one desc to the other, and db also receives a logoff. For all intents and purposes, a rewarp is almost like the player closed the client and logged back in (directly into their char that is). The second problem lies with passing around things on login: login is this continuous bouncing of packets and checks. Not fun to work with in my experience. Nevertheless, you made it sound easy. If you know some existing way to keep track of the user (which I could have missed somehow!), please do tell! However, as far as I'm aware, there are not too many options. Way 1 Elevate -> notify db -> which notifies auth -> which stores IP and current timestamp. Login, which goes through auth, checks if the player was already elevated (recently), and if the elevation was on the same IP, marks the user as elevated in the login. The last part, well, I implemented a few things in login already, and I really don't like working with it much. But this way is definitely better than... Way 2 (less painful, less clean as well) Elevate -> Notify all P2P peers -> store it in some map again with IP and timestamp (Even maybe start an event that clears the map entry). Login -> On PlayerLoad, check the map. Profit! In your way 1 you're just taking a worthless step. Plus, auth shouldn't store nothing at all really, the auth core is only meant to Authenticate the user on login, and maybe send some of those hybrid keys, all the rest is done on db and game cores. Your second option is the most logical one, and the best approach as well.

what is that Z core project? Explain it a bit

Never trust the Client. If you want to prevent chat spamming, do it Serverside, same with most of the Security, it should be done on Serverside where you are certain that nobody can disable it without your permission.

Yeah, let's just delete everything about Win32, that will work! /s

SYSERR: Aug 4 07:00:04 :: SpawnGroup: NOT_EXIST_GROUP_VNUM(4294967291) Map(209) 4294967291 Dat number seems like it's an overflow, look for any vnum calling any negative number. Or post the regens from that map in here so we can see.

if (!strcmp(ch->LastPlayerMessage, buf) && (thecore_pulse() < (ch->LastMessageAt + SPAM_WAIT_SEC * 25)) && !ch->SpamAllowBuf(buf) You shouldn't hardcode the passes per second as 25, some people might change it... so you should replace * 25 with * passes_per_sec

why would you disable it like that? If they add it, it's for a reason. Don't just disable the check for multihacks, or else your server will be filled with cheaters