Jump to content

Alina

Inactive Member
  • Posts

    174
  • Joined

  • Last visited

  • Days Won

    13
  • Feedback

    0%

Everything posted by Alina

  1. Nah, that won't happen The effects are loaded clientside, not by the server itself. Especially not armor effects
  2. That's the point. If you're copying the libs then everything works with newer versions. But if not, the game will complain about the newer version of your gcc libs. Your usual approach is exactly the way to do it. I've set up a test server a few days ago. It was running on FreeBSD 10 and I had no problems. I didn't even need to install gcc, I just copied the libs and everything worked That's what I meant with uploading the usual libs.
  3. The bug appears after teleporting? Seems like a problem with saving the affects. Better have a look on that, maybe you changed something in source. Try it with logging out, if the buffs disappear there too, it's clearly a bug with saving your affects
  4. Sorry, I prefer chocolate over vanilla but thanks
  5. Hi everybody! I've written a small class. It's meant for development and technical functions and direct communication with the core. For example you can write into syserr/syslog, create a file backup or trigger log rotation. If you have any ideas what I could add, feel free to tell me Maybe I'll add them. Also feel free to pm me for any ideas I'd do. I'm a little bit bored Here it is Just add it as any other quest extension to your source Sorry for the indentation again.. Quote tag! >.< Oh and one thing you should note: If you're getting errors with luaL_Reg then just replace it with luaL_reg Why? Because in newer implementations of lua luaL_reg is replaced by luaL_Reg. That's why I'm following up with that change. But if you're using the standard lua, then you're free to rollback Thanks to flygun for pointing towards the confusing name change
  6. There's no problem with uploading the libs he normally uses. As long as he doesn't overwrite any system libs it should be okay. I guess he'll run into compatibility problems if he doesn't upload them. Installing gcc from ports won't do it, libstdc++ would be from a higher version. The server won't boot I guess.
  7. Well..... All serverfiles do work on FreeBSD 10 If you want to update your system, just connect it to the internet and upgrade it. They're all compatible as long as you provide the right libs for them (and the gamecore won't need any new libs when you upgrade your system)
  8. Yeah sorry, my bad. I was thinking a bit oversized. I'm correcting it right now. Edit: Corrected. I've made a test and got about 100~250mb.
  9. Better install it via portstree instead of packages. This way you can make sure everything works with your system (and even build your own faster versions if you have a more recent version of your compiler than the package was build with) portsnap fetch extract (if you don't have a portsnap) portsnap fetch update (if you have a portsnap and want to update it) cd /usr/ports/lang/python && make install clean Should do the job. Make sure you've got internet connection. Otherwise download python and do it yourself
  10. Try it with this Open config.txt in your dbcache directory. There you find your mysql data. At the end of every line you'll see a 0. Change this 0 to your new port. That will fix db cache. Same procedure when you're working with CONFIG files (but there could be no 0 at the end of the line. You can just add a number, it should work)
  11. Nope. A core takes about 100~250mb RAM when idling. In most cases the main core is the one getting ~250mb (it's the core where the starting maps are located and players start to connect) So let there only be the main core (village maps, etc.) in every channel you'd get approx. 1gb ram full with all of your channels. But the other cores are also running. Additionally, you have ch99, dbcache and auth. Mysql is running too and all these values are only correct if your server is running without players. As soon as they get in, you'll need more RAM. You see, it's way too less. Using swap space is a possibility, but if you're doing this, you're going to have a baaad time :´) Let alone the bottleneck you'd create with using your disk as swap space. You could possibly run the server, even with 1gb, but I can't recommend it. But it's just my two cents about this topic, if someone knows better he can correct me anytime
  12. M2 Download Center Download Here ( Internal ) Hi everybody! Tired of chaotic servers just because someone broke into a gm account? With the following guide we'll stop that once and for all! 1.) What's the idea behind that? Most systems (I can't imagine any system who doesn't do it at least a little bit like this) allow you to elevate processes or users and temporarily grant them higher permissions. Metin2 doesn't do something like that. If you get into a gm account (and you don't use ip binding which in most cases is useless) you'll most likely get full access to his permissions. Though many admins do limit the rights of their team members, some are left with higher permissions and you never know what happens. So what to do? We implement such an elevation system into metin2. It's nothing that big. We just simply add a new column to our gmlist. This will store a special password for every gamemaster. If there's no special password set, elevation won't have any effect and the user is left with special permissions permanently. If you log in, you'll have to further use the new su-command to elevate yourself. This command takes the password as an argument. If it's the correct password, the player will be elevated for the current session. If he logs out, he'll have to run su again. Without su, he won't be able to use any of his privileges. Most important are IMPLEMENTOR characters. LOW_WIZARD most likely won't need elevation so you can simply leave the password field blank for those guys. Additionally on testing environments you can specify a special passphrase. People can't use gm commands unless they elevate with using su and providing it with your passphrase - but they will be able to have every other feature of your testing environment (e. g. debug logs, shorter waiting times etc..) But enough of that! Let's get the party started! After each section you will be able to compile your game and test it. 2.) What do we need to edit? - char.h - char.cpp - cmd_general.cpp - config.cpp - config.h 3.) Add elevation status In this section we will add the elevation status as a bool variable. Files to be edited: - char.cpp - char.h Open char.h Find DWORD m_dwLastGoldDropTime; and add: bool bIsElevated; Add the following functions in any public-section below: void SetElevation(bool elevate) { bIsElevated = elevate; } bool GetElevation() { return bIsElevated; } Now close char.h and open char.cpp Find m_dwLastGoldDropTime = 0; and add below: bIsElevated = false; That's all! Compile it and you'll notice.. Nothing. We just simply add a new variable. Well. At least it's a beginning! 4.) Manage elevation In this section we will allow people to use the su command for elevation. It won't ask for a password yet, that'll be added in the next section. Files to be edited: - char.cpp - char.h - cmd.cpp - cmd_general.cpp Note: We edit cmd_general because users will get normal privileges when logging in. So restricting the command to gamemaster doesn't make any sense. Though the command will do nothing unless they really have privileges (that's why we need a new command to determine if the player using su actually can receive higher privileges. First open char.cpp and find the following function: BYTE CHARACTER::GetGMLevel() const First remove the const at the end of the declaration (also make sure you remove it at char.h). Add at the beginning of the function the following statement: if(GetElevation() == false) return GM_PLAYER; By now people won't receive the status of a gm anymore. They first have to elevate. But how? Let's do this! First close char.cpp Open cmd.cpp and add the following ACMD anywhere near the ACMD section: ACMD (do_elevate); Now add the following entry to the cmd list: { "su", do_elevate, 0, POS_DEAD, GM_PLAYER }, Close cmd.cpp and open cmd_general.cpp. There you can add the following function: ACMD(do_elevate) { if(ch->GetElevation()==true) return; ch->SetElevation(true); ch->ChatPacket(CHAT_TYPE_INFO, "You have been elevated!"); } That'll allow our players to elevate. But! We don't want normal players to elevate. So we need something to determine if they are worthy at all. We need a true function that displays the gm level without having any impact on the source itself. We'll add that! First open char.cpp and add our new function: BYTE CHARACTER::GetRealGMLevel() const { if (test_server) return GM_IMPLEMENTOR; return m_pointsInstant.gm_level; } Note that this function is const (unlike our new GetGMLevel() function) Also add this function inside a public part of your char.h: BYTE GetRealGMLevel() const; Now we can close char.h and char.cpp. Open cmd_general.cpp and edit our function. Add to the beginning of it: if(ch->GetRealGMLevel() == GM_PLAYER) return; That's all! Compile and Test it. By now the following should occur: At login you won't have gm permission. You will be able to use the su command. By doing so, you'll receive a message that you have been elevated. If you are a normal player, elevation won't work. There's currently no special password or passphrase. 5.) Securing elevation In this part we'll add a passphrase to our gmlist! What we need to edit: - char.cpp - char.h - cmd_general.cpp But first we need to run the following SQL statement: ALTER TABLE common.gmlist ADD passphrase varchar(45) DEFAULT ""; You can now give your gm characters a special passphrase. How you build up your passphrase is up to you (plain text is not recommended! Best solution is something like salt + mysql password function). For this guide I'll just use the mysql password function but you'd adapt it to your needs Example query to set a passphrase: UPDATE common.gmlist SET passphrase=PASSWORD('your_pass') WHERE mName='targetcharactername'; After doing so we'll now write the function to elevate! Add void DoElevate(char* pwd); To your char.h inside a public section. You can close it and open char.cpp There we add our new DoElevate()-function. void CHARACTER::DoElevate(char* pwd) { char szQuery[1024]; snprintf(szQuery, sizeof(szQuery), "SELECT mID FROM common.gmlist WHERE mName='%s' AND (passphrase='' OR passphrase=PASSWORD('%s'))", GetName(), pwd); std::unique_ptr<SQLMsg> result( DBManager::instance().DirectQuery(szQuery) ); if (result->Get()->uiNumRows == 1) { ChatPacket(CHAT_TYPE_INFO, "You have been elevated!"); sys_log(0, "Player %s elevated successful!", GetName()); SetElevation(true); return; } sys_err("Player failed to elevate! %s with %s result %d", GetName(), pwd, result->Get()->uiNumRows); ChatPacket(CHAT_TYPE_INFO, "Failed to elevate!"); } Now we can close char.cpp and open cmd_general.cpp There we navigate to our previously added ACMD sequence and replace it: ACMD(do_elevate) { if(ch->GetRealGMLevel() == GM_PLAYER) return; if(true == ch->GetElevation()) return; char a1[256]; one_argument(argument, a1, sizeof(a1)); if(!*a1) { char safe[] = "nopass"; ch->DoElevate(safe); } else { ch->DoElevate(a1); } } Now we can close everything and compile. Get ready to elevate! 6.) (optional) Elevating with testserver In this section we'll make elevating compatible with testserver. You can simply provide a special key you can change everytime (we'll do that via config, that's the best way!) you want to. People need to elevate themselves by using this key. Note that you'll get everything in your syslog, so no one can do something bad What we need to edit: - char.cpp - config.cpp - config.h First open config.h. We'll declare our variable: extern std::string ElevationKey; Then we can close config.h Let's open config.cpp and add our new variable: string ElevationKey = "testkey"; Now we only need to be able to modify our variable. Let's do that too. Find TOKEN("pk_protect_level") and add under the block our new token: TOKEN("elevation_key") { ElevationKey = value_string; fprintf(stderr, "ELEVATION_KEY: %s", ElevationKey.c_str()); } Close config.cpp too. We can now open char.cpp and edit our DoElevate()-function. Add to the beginning of our function: if(test_server) { extern std::string ElevationKey; if(strcmp(pwd, ElevationKey.c_str()) == 0) { ChatPacket(CHAT_TYPE_INFO, "You have been elevated!"); sys_log(0, "TESTSERVER! Player %s elevated successful!", GetName()); SetElevation(true); return; } } Note that while test server is active, both su-methods are allowed. You can either su with the passphrase or, if you do have a gm account, then you can use your passphrase. 7.) Fixing elevation in quests Thanks to Think I was able to think (joking with words, huh?) about a problem I didn't notice earlier: When logging in, quests requiring gm permissions on login won't work anymore. We first have to elevate before we are registered as a GM. How are we going to fix it? Easy! We just have to edit questlua_pc.cpp Find pc_is_gm() and pc_get_gm_level() Replace the function name GetGMLevel() with our real function: GetRealGMLevel() That's all for fixing that! But wait! We want to be secure, right? For this, we just add two new quest functions! int pc_is_gm_safe(lua_State* L) { LPCHARACTER ch = CQuestManager::instance().GetCurrentCharacterPtr(); lua_pushboolean(L, ch->GetGMLevel() >= GM_HIGH_WIZARD); return 1; } int pc_get_gm_level_safe(lua_State* L) { LPCHARACTER ch = CQuestManager::instance().GetCurrentCharacterPtr(); lua_pushnumber(L, ch->GetGMLevel()); return 1; } They're... well.. they're the same than our old functions. We just changed the old functions to make sure quests will work as they did before. Now we can use the safe equivalent outside of login calls (e. g. when you're using it in a chat-trigger or button/info). Just add them to our list and we're finished! { "is_gm_safe", pc_is_gm_safe }, { "get_gm_level_safe", pc_get_gm_level_safe }, Compile and run the gamefile. Quests will work like they did before! Happy elevating!
  13. Everything depends on how many cores you are running You don't need that much if you don't run 100000 channels. 2gb should be fairly enough
  14. On my way You can just type in
  15. M2 Download Center Download Here ( Internal ) Hi everyone! Today I want to show you how to make the big notice work. You may have already noticed that the command /b only works for you. No one else will get messages sent by /b. As soon as we're finished, /b will work without any flaws! The best thing about this: We're not going to add any functions! We only alter them and edit a packet. We also make sure our code is compatible with old function calls, so /n will still work even when the source needs it. But enough chit-chat. Here's the guide! I made sure everybody can understand what I'm writing so I made simple steps. 1.) which files do we need to edit? - cmd_general.cpp - cmd.h - cmd_gm.cpp - packet.h - input_p2p.cpp - input_db.cpp 2.) what are we planning to do? First we observe how the game handles our beloved notice-function. As soon as we backtrace the function calls, we'll learn that our /n command refers to ACMD(do_notice) which forwards the argument given by our command to the BroadcastNotice-function where a p2p-packet is created (to ensure that other core instances also send the message). In the last step the SendNotice-function is being called. It uses a struct to send the message to everyone connected to this core instance. Note that the packet triggers our SendNotice function in other game core instances. So what can we do? The simplest way is to extend our functions. We'll add a bool variable which we can set to true if we want to use the big notices. We also have to edit the packet since we need to carry our bool variable with it: Other core instances need to know wheter they'd use the big notices or not. 3.) First altering the functions What we want to edit in this section: - cmd_general.cpp - cmd.h - cmd_gm.cpp At first open cmd_gm.cpp. Find void BroadcastNotice(const char * c_pszBuf) and replace with: void BroadcastNotice(const char * c_pszBuf, bool IsBig) Then find: void SendNotice(const char * c_pszBuf) and replace with: void SendNotice(const char * c_pszBuf, bool IsBig) Then find struct notice_packet_func and replace it with this: struct notice_packet_func { const char * m_str; bool m_big; notice_packet_func(const char * str, bool big = false) : m_str(str), m_big(big) { } void operator () (LPDESC d) { if (!d->GetCharacter()) return; d->GetCharacter()->ChatPacket(m_big == true ? CHAT_TYPE_BIG_NOTICE : CHAT_TYPE_NOTICE, "%s", m_str); } }; You just have to compare your struct with the new one. I simply added a new bool variable and used it at the end to determine if it's a big notice or not. You can simply copy pastarino those 3 lines and are ready to go Next is the SendNotice-function. There you'll find std::for_each(c_ref_set.begin(), c_ref_set.end(), notice_packet_func(c_pszBuf)); Replace it with std::for_each(c_ref_set.begin(), c_ref_set.end(), notice_packet_func(c_pszBuf, IsBig)); At last find ACMD(do_big_notice) And replace it's content with BroadcastNotice(argument, true); Then find For now we can close cmd_gm.cpp Next open cmd.h Find extern void SendNotice(const char * c_pszBuf); // 이 게임서버에만 공지 extern void BroadcastNotice(const char * c_pszBuf); // 전 서버에 공지 and replace them with: extern void SendNotice(const char * c_pszBuf, bool IsBig = false); // 이 게임서버에만 공지 extern void BroadcastNotice(const char * c_pszBuf, bool IsBig = false); // 전 서버에 공지 we're finished with cmd.h Now open cmd_general.cpp Find extern void BroadcastNotice(const char * c_pszBuf); and replace with: extern void BroadcastNotice(const char * c_pszBuf, bool IsBig); We're done with cmd_general.cpp too. Finish with opening input_db.cpp And there find extern void SendNotice(const char * c_pszBuf); and replace with extern void SendNotice(const char * c_pszBuf, bool IsBig = false); Compile and we're done! If you type in /b test you'll get the following result: you and everyone connected to the same core as you will receive the big notice. Everyone not connected to your core will receive a normal notice. 4.) Editing the packet In this section we want to edit the notice packet sent to other core instances by p2p so everyone will be able to see the big notice instead of our normal one. Files we want to edit: packet.h input_p2p.cpp cmd_gm.cpp First open packet.h Search for SPacketGGNotice and add the following variable: bool bIsBig; Close packet.h and open input_p2p.cpp There we search for int CInputP2P::Notice(LPDESC d, const char * c_pData, size_t uiBytes) and replace the following line SendNotice(szBuf); with SendNotice(szBuf, p->bIsBig); Now close input_p2p.cpp and open cmd_gm.cpp again. In our SendNotice-function we just have to find p.lSize = strlen(c_pszBuf) + 1; and add the following line below: p.bIsBig = IsBig; That's all! Save and compile Best Regards, Alina
  16. c:usersuserdesktopclientuserinterface../eterLib/StdAfx.h(23) : fatal error C1083: Cannot open include file: 'd3d8.h': No such file or directory You'd have a look on this. d3d8.h is missing but StdAfx.h wants to include it in line 23
  17. I'd like to contribute to your work. But I'm a bit afraid of using Git (even though it's your own github as we can see). Also the DCMA scared me a bit off. If you still need someone developing feel free to send me a pm, maybe we can find a solution I'm only contributing my own stuff, nothing from YMIR/Webzen etc.. (e. g. wolfman is a no-go)
×
×
  • Create New...

Important Information

Terms of Use / Privacy Policy / Guidelines / We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.