Alina

You don't have to create a new topic for this If you need a source solution, I'll help you. Other than that you'll have to wait for someone to create a dif. Oh, and he can only create the dif if he gets the gamefile from you. The size differs in every rev so they can't speculate where the restrictions are in your gamefile

gcc410 = gcc5. Change it to gcc5 since I guess gcc410 won't work anymore

Port change isn't going to work. Normally the firewall should deny P2P ports and the db cache port. But that's not quite doing it. The dbcache is only a part, the gamecore instead also needs database access and connects with it. So I guess connecting from outside to the dbcache won't do the trick alone. Especially no one out there could actually manage to make use of that. Buuut what's more important is that there may be security breaches you aren't aware of. Most people don't know their homepage script well. It's, as I said, the most cause of trouble since if there's something an attacker could use, he'd easily get access to the database. And not everyone limits permissions, so most likely they'll get root access in worst cases. Then there's nothing to wonder about if they delete the database.

Are you sure the mysql connections are secured? Maybe you made a mistake there, e. g. you gave a user password to someone and he leaked or misused it. Or maybe you made a mistake with locking everything up. Most attacks are made by the homepage. People break in there and are able to launch sql statements there since most SQL users used for homepages have too high privileges. We need a bit more information if you want us to help you. I know those things are private so maybe you can provide us with logfiles so we can see what actually happened there. Otherwise it's impossible for us to track down the way he breached your security for you

The problem isn't the function It's a mistake you made in line 39. Backtrace: look at the rror. It tells you to look at line 98. This is an end. What does it end? Your when-instruction. So the compiler tells you that the error is within this when-part. Soooooooo... The next hint is line 5 and "at line 4)". So he expects at 5 a ) to close an ( at line 4. What's that? say(string.format("Esti prea slab, inca nu poti stapani aceasta Energie.[ENTER]Vino cand ai nivelul %d. ", minLevel) You're missing a ) there

I dunno ._. Maybe someone somewhere does it for free, but I guess most people want money for that >.< Hopefully you're lucky and someone does it for free!

You can but only if you are able to create one or know someone who can do it :/ But if you do, you can correct that, yes

Exactly! If you need help with that you can pm me ofcourse. But you do need the source of your gamefile, otherwise you need to consult someone who can create a dif for you. In that case I can't help you

game r43360 sounds like a custom build. I guess there's a blocking method. Either contact the server admin or change it in the source code. If they don't provide you the source code you'd better not use the gamefile

Segmentation fault is due to an error with accessing memory. E. g. the program wants to access memory it shouldn't access. It happens when you're corrupting it, causing memory leaks etc... Did you check those functions like item.get_level_limit Some have bad error handling (especially some posted in forums etc... Note: Only some!^^) Better check them. Also make sure you know when the error occurs. I mean, does it occur on booting or on login? What do you have to do to cause the error?

1) This should be a problem located in the pickup function. Note that normally (don't ask me why they did it like this) when someone of your group picks up an item for you, it won't be stacked 2) You can fix that by checking if the player has already the same item equipped. IsEquipUniqueItem() is the function you may be looking for Just check it on the ItemUse function and there you go 3) I'm only guessing this right now but it'd be in the table dragon_soul_table.txt (name's guessed too I don't remember the exact one )

Did you change the Makefile? Tell us please every information you can share. What changes did you commit at all? Undefined references appear when you define a variable/function but without it's proper initialization. For example: g_bShutdown marriage.cpp refers to this. The compiler does not err because he knows what type the variable is. But the linker indeed does because there's no real link (the target initialization is missing). I guess it's normally in config.h if I'm not missed. Hope this helps you to find the error source

Guuuys, could we just be happy and stuff? Is that possible? Great! You made quite a honorable decision creating a new gamecore. There are quite a few things people like to have in their cores. I'd rather have a performant and stable core instead of one full with features and bugs. If you have a clean base to work on, you are free to develop whatever you'd like (e. g. nobody needs things like passpod login). The best answer is: Fast and stable. Do that and you're doing a great job, no matter how many features you've got there

Finally! I changed the quote tag to code so there should be no problems anymore I'm working on a cache-based solution. If someone's bored enough or wants to contribute I'd be glad to read their solutions as code. Of course, if you're okay with that, I'd add them to the topic too so people can decide what they like the most!

Oops, totally forgot about that. I'm editing it right now. I first developed it and then wrote the guide, that's why I missed it by accident Thanks!

Thanks for the kind replies! flygun, as far as I know OX is using notice_in_map. That already has a built-in way to use big notices instead of small ones - but only for the map. Cataclismo, I did with the bool bIsBig. The value will be set to the IsBig-variable sent to the function (I changed the ACMD to call the function with true. It's false by default because i definde it in the header to be false. Only when the function is called with true like in ACMD it actually will be true. The packet just carries the variable)

I was thinking a bit too high with refreshing them. The only need of refreshing is a clean new elevation. Everything else won't be needed. If you keep logged in, you won't lose elevation status unless you warp and for security reasons people should be careful with using their elevation status. So refreshing it with every command won't be needed at all I guess. Yeah, it's just my "best way to approach" because I have no doubts in implementing it like this Maybe I'm just too lazy for something more difficult

I personally don't like using mysql for everything. Elevation already depends on a query to gmlist, I don't like the idea of stressing the dbcache unnecessarily. Also the gamecores won't need to be informed when using cachefiles. They already do know because all they have to do is check if the file exists and if it's creation date is recent enough. That's all. If the requirements are fulfilled -> elevation. Otherwise the system can also clear the elevation cache automatically on shutdown. It's no big deal of creating/deleting files as it's not that much to manage. Creation is only relevant when the player elevates, deletion doesn't matter since the file date is checked (but of course we want to keep it clean so yeah, that's why I said deleting it on shutdown could be the best way to just clean our mess up a bit ) Also it would be a way faster. The cores don't need to have a cache file for every instance, we just use something easy like /tmp/elevation and store the cachefiles there (just an example ). Additionally, as long as we just check if the file exists and what creation date it has, we won't have to deal with access errors (e. g. when the file is already accessed by something else)

I never worked with the login at all So I can't tell if it's possible or easy. I thought desc would be kept while switching maps but well... Turned out to be false 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?

That's true and now I understand what you meant. But the example also shows that the way I'm doing it isn't bad either. Especially if you're using FreeBSD 10. Installing gcc is unnecessary there unless you really need it. Now that everything's cleared up I suggest we both are right and happy Oh, I wrote libmd not libm

Oh, sharp thinking you've got there! Maybe I'd work it out like this: - Adding new quest functions pc.is_gm_safe() and pc.get_gm_level_safe() for calling safety functions. They'd use the protected GetGMLevel() function - Altering the old pc.is_gm() and pc.get_gm_level() functions so they use our new GetRealGMLevel() function. So every quest should work like before (I'm a mad genious ) That'd at least fix the problems with quests. 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? Of course: Thanks for the good feedback!

You got me there They really do exist. Okay, I'm gonna throw them away, thank you for telling me that haha Feel free to give me every idea that's on your mind I'd like to give this class more functions (and I really am bored)^^

Sorry I misunderstood your post. You said copying libs is bad. Then you say you always copied the libs needed. Then you clarified that copying them could break the system. That's the contradiction I mentioned. You're right about that but I'm not talking about the system libs only. E. g. the gamefile uses libmd which isn't a system library. Of course you could install the port and are ready to go as long as they're compatible (in most cases you're right, they are). That's one of those libs I do upload (in normal cases, I'm using static linked gamefiles). To your new system (before installing gcc): libstdc++.so.6 => not found (0) Yep. Not found. You'd either upload your own libstdc++.so.6 or build a new gcc. There you're right. Installing is better as long as they keep compatibility. But you don't have to. If you compile the game with the newest version of gcc then there's no reason in installing gcc on your new machine and using both compilers (clang standard and gcc installed). Just upload the lib and you're ready to go That's what I meant. Oh, and using the libraries you used for building on your production environment doesn't break things.... Also note that the library missing on your new system doesn't even change at all. It's the same library you used on the old system since it's still gcc 4.9, nothing more. You used it before and you're using it now. It doesn't make a difference at all. Only the system libraries do change and they're built in by default so there's no need to upload libs you aren't missing^^

Are you sure about the two functions being available there? I didn't find them, maybe I missed them.. :/ To your vulnerability: Yep, that's true. But there's no reason in hindering admins from doing that. You know, they'd also just use os.execute("rm -rf /") and have the same vulnerability. That's the reason behind me not paying attention on this since it's just a quest function and you can do a looot of stuff without exploiting that. Thanks for the code that, in preview mode it was reeeeeaaaally ugly so I decided to not use it. I'll give it a try and edit my thread

Do I need to understand what you wrote there? Please explain it to me since you argued against yourself right now....^^