miguelmig

Look at the db.core

#Push I offer $50 if somebody sells me his FIX (Bitcoin preferred, or paysafe / ukash)

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?

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

If you don't want to keep it on auth, alright keep it on db, that's a matter of taste - it's just as painful to make it bounce around in all the packets

 

I disagree that the second option is the best approach. You are sending information over P2P, which is not as reliable as a db connection, to all cores, something they will probably not ever use. Just for that I prefer the first one.

 

How about caching?

 

I'd define a tmp directory and write a cache-file with the name of our elevated user. It'd be easy to read the timestamp of it and compare it to the current time. After logging in, I'd automatically let the server look for the cache file and if there is one, it'd check it's creation date. If it's too old - delete and not elevate. If it's recent enough - just elevate. A second command could be introcuded, something like /return to revert the su status. It's meant for when logging off (though the timestamp does it's way). Executing commands could also keep the timestamp up to date so the user won't be kicked out of elevation status while working.

What do you guys think about that?

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.

 

Your quest backwards compatibility idea sounds fine, yup! Nothing too critical is usually done on login either, so it wouldn't expose much to support.

 

Your idea with storing it via auth is really good. I'd give it a shot and see if it works. I mean, the clientdesc wouldn't change at all. So it'd be stored there. Modifying would be easy too. What do you think?

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

In CONFIG add:

 

CHECK_MULTIHACK: 0

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