Jump to content

Vanilla

Developer
  • Posts

    471
  • Joined

  • Last visited

  • Days Won

    58
  • Feedback

    0%

Everything posted by Vanilla

  1. @Grantix: Makes no sense. People replace dbcache with official versions and suddenly pet system and syncing works.
  2. I've made a mistake in the changelog, it'd be as Nightwish said: TXT_STARTUP = 1 if you want to run the db-cache with txt-protos instead of sql. I already saw the problem with the yang limit and it seems like there's an overflow and that's why it won't work. I recommend NOT using it unless I've released a fixed core. The crash is caused by the problem with the yang limit. Remove the line from your CONFIG-file and the core will be stable. I'm neither having problems with syncing, but I didn't test the pet system (and I didn't change anything related to the pet system in the dbcache. Seems like there's some deeper stuff going on here). I'll look for it. If you want to use the pet system you'd stick to vanilla dbcache 2.1; I'll make further investigation on this and release fixed game core and dbcache ASAP.
  3. So, nothing to laugh at anymore, huh? @Mehti: I changed nothing there except for the new quest function, but if there are any errors then please go on and tell me what exactly you mean by "not work". What happens? Are there any messages? Please provide more information, otherwise I won't be able to help you.
  4. @Summex: Thanks for the list. Some of them are already included but I'll have a look for the rest. @SonGoku: If you don't tell us what's actually happening we won't be able to help you.
  5. oh yes, I thought I'd changed that. belt_all_allow_items: 0/1 Allow Players to store every item in their belt inventory @SonGoku: Please give us further information what's going wrong with the quest.
  6. @C. AAlexandru-Sorin: Your FreeBSD is a way too old. Vanilla needs at least 9.1 so please consider updating it. Same goes to Tasho. You'd have at least FreeBSD 9.1, better 9.2 or 10.0 @4l0ns0xD: Internal IP should be fixed with 2.2 Do you still have any problems with it?
  7. You can disable the need of these both roles. There are 2 CONFIG options for that. One is for the skillbook time delay (set it to 0 and you'll have no time waiting) and the other one is skillbook_always_book, set it to 1 and you won't need enhancers anymore. Same goes with item.remove() quest function. Bugfix for skillbooks are already there. I fixed every entry for it. It'll now reduce the stack size by 1 and if there's only one left, it'll destroy the item. I don't know if a event flag exists for the percentage. But if you use skillbook_always_book you'd achieve 100% percent with master books.
  8. Nope. I'll add minimum requirements in the first post. You'll need at least FreeBSD 9.1 or higher.
  9. vanilla 2.2 changelog New conf.txt options (refers to dbcache): New CONFIG options: New quest-functions: Please note that the gamefile will be uploaded this evening and will be available for download 00:00 CET. This changelog will be merged into the first post and added to the second post.
  10. @ATAG: It's not needed if you use g++. There it's already included. If you declared gcc instead of g++ then you'll need it of course. @Originale: Sorry, didn't see that you've edited your post
  11. Hey there, I've got a critical error which leads into a trash gamefile if not solved. I don't know when exactly it happened (I reverted the last changes I made to the source code but still the error occurs). That's why I'm asking here. It stops me from finishing vanilla 2.2 so help could be great for everyone. Now to my problem: It seems the gamecore can't read the coordinates where players are located. When I log in (after char creation or simply using an existing character) I get disconnected shortly at the beginning of the loading screen. The following syserr occurs: The problem is: these are NOT the coordinates I have. My character stands at x=469300 y=964200 map_index=1 which should clearly be the red empire. Coordinates are valid too (if I used another gamecore everything works well). I also made a "prevent-this-bug" with adding an error handler which resets your x,y and map_index if you land on coordinates you shouldn't land (which would cause disconnects, you may know this). But still after resetting the coordinates the error is still there. Additionally when I use another core, I can log in AND see that the caracter is completely messed up. Some Stats are totally weird (somewhere over 9000) and I can distribute a stat point even if I'm level 1 with no exp. So I guess there's a problem with handling player information (reading and writing). Maybe someone could help me if you got the same problem once or maybe know where it'd be located (since the source is huge and I'm already looking into the connection game<->db without success) €: Problem solved. Shouldn't edit the length.h so careless.
  12. yes, I'll explain how you can do it. Either I'll edit it here or make a new topic for the how to. Depends on if it's better to make a new topic or if it's not enough to be a own topic.
  13. He meant the bug that when you overkill someone, you'll loose hp in cause of the hp drain. In 34083 you'll need a lib because there's no room for further number checkings. It's in the source, you may search for the applying bonus. There the hp drain will be calculated but not checked if it's < 0. Just make a check and if it's less than zero, multiply it with -1. This will revert the value and makes sure you'll always gain hp, not loose some.
  14. yes, that's all. I've created a list with all the new config-options. You can add every option you want to use into your CONFIG-file and change the value to everything you want. MAX_STATUS: int means you can use it like this: MAX_STATUS: 100 This will set the maximum status point you can distribute on every stat to 100 (so you'd possibly have 100 con, int, str and dex). There're more options to explore. You can also set special stat limits, so you can allow up to 100 points in con, 200 points in int, 150 points in str and 100 points again in dex. You're free to do what you want, just look at the CONFIG-options I posted in my thread.
  15. No, don't do this. If you're using true or false for a variable, then always use bool. bool g_bCheckClientVersion = true; // função ativada false desativa const char* g_stClientVersion = "1215955205"; // "1215955205" chave -key const char* will do the trick. Make it constant since you won't have to change the version in your code. It keeps as it is. And if you're using char* you won't need atoi anymore.
  16. M2 Download Center Download Here ( Internal ) Welcome to my new release, this time it'll be a source code for a new program: vGuard. What is vGuard? -> As I learned from .Alessa (who you may know; got the permission so don't worry) we developed a program that checks for the runninc processes. Earlier it was written in vb, but then we ported it to c#. vGuard will bind itself to the metin2 process (it'll start the client and check the binding every cycle) and scans the environment for: -> Bad running processes (like cheating programs) -> Bad files in the client (you won't be able to put .py/.pyc-files into the client) You are allowed to adapt the source like you wish to. I won't keep any copyrights, it's free for all. But please be kind and say who developed the main program. Normally the system goes like this: Patcher (in this case metin2.exe) starts vGuard.exe (you may change the file name if you really want to) vGuard.exe runs your client (metin2client.bin) You can protect your client binary with Enigma protector to make it unable to change the file name (so it forces users to keep the filename "metin2client.bin") and create a dependency (you can define that vGuard has to be running and check the md5-sizes so that people can't replace vGuard.exe) If you have any questions, feel free to ask. Don't blame me for the strange variable names and the bad coding. It's just an older work, but feel free to modify it as you want to.
  17. Still that won't work. It'll not disconnect you. You have to change some more. if (LC_IsEurope()) { g_bCheckClientVersion = true; } else { g_bCheckClientVersion = false; } This should be removed. Makes sure you always check the version even when you don't use Europe locale. Next, I've changed the check variables to char* so the server won't have to convert the versions into integers (which may overflow and result into false values). It'll just use char's instead. You can compare them with strcmp. This version works fine (tested on my vanilla core).
  18. If you want to run the core then just deliver the needed sources. You don't have to install the newer gcc version on your server, you only need the libraries. If you run it, you'll see it
  19. Welcome to the second part of my guide series. This time I'll tell you how you can compile with gcc48 or even gcc49 like it's the case in vanilla and how you can use c++11 which will allow much more and faster instructions than the old one. At first we need to have a look at our Makefile. Make sure you edited the Line SVN_VERSION so you won't receive any errors. Try it e. g. to SVN_VERSION = mt2 Next, you'll have to declare what compiler you want to use. Of course you first need to install the compiler, but I guess it's clear (if you haven't done so, just use cd /usr/ports/lang/gcc49 or even 48 and use make install clean). The line normally say: CC = g++ This is the standard compiler. You may want to change this line to: CC = g++49 Or if you're using 48, change it to CC = g++48 Now before you compile it, you'd recompile all needed libs with gcc48/gcc49 too! So change the compiler in the makefile and recompile the sources in the following directories: libgame/src libpoly libserverkey libsql libthecore/src And then you need to recmopile cryptopp with the newer gcc version too! It's located in the Extern/cryptopp-directory. Now you can compile your game and even your db source with the newer gcc version. You may experience a much smaller file size. The newer compilers will produce an even more faster and smaller gamefile than before. Oh and if you want to carry out the lib-files you're using on your compiling machine (to make sure everything runs smoothly) you may use the following CFLAG: -Wl,-rpath,/usr/local/lib32/metin2 You can change the path to whatever you want! If you specify this, you instruct the linker to use this path so whenever you start your game/dbcache it'll first look in the given directory for the right libs and then, if it can't find the libs there, it'll look elsewhere. Using c++11 is a must-have if you want to make new statements. The source code how to load the database without txt-files needs the newer c++ version, so you'll have to upgrade at least the dbcache for it. But you'll experience even more smaller file sizes with this change so it keeps up with more and more advantages. First you may want to specify the new CFLAG. It's called: -std=c++11 This tells the compiler to use c++11. Keep in mind that not every compiler can use c++11! The newer gcc version can deal with it without any problems. If you compile your source then, you may find a new error occuring! Open every .cpp and .h-file in Notepad++ and do the following things (you can use the mass replacement of Notepad++): replace typeof with __typeof replace auto_ptr with unique_ptr Watch out for the common-directory too! Then you can recompile the source and it's done! Oh and for this you don't need to compile every other sourcecode with c++11. You can e. g. only compile the dbcache with it. Last small hint: You can play with the tuning flags to get even more optimization. -O2 can sometimes be good, but sometimes it's better to use others flags. You can even use -O3 or -Ofast. But be careful with this and consider using -fstrict-aliasing so the compiler won't optimize instructions that'd lead into a crash if it'd optimize them. And always: Pay attention to the warnings your compiler throws at you! They aren't there to just "hang out". They'd lead into crashes, so care about them. Lastly I hope you enjoyed the guide. As in the last one, please tell me if it's good or not and if you have any questions: Feel free to ask.
  20. Hello and welcome to the first guide for beginners (and even those who have more experience but still need some small hints and ideas). This series of guides will be about "how can I edit the source code?". While this thread is nothing you'd visit when you're starting to edit the source code for your first time, It'll help you greatly when you want to customize your source code or - as I did in vanilla - make more options for people using your core. If there's further interesting, I'll create more guides like these and even some who help people with the basic editing of the source code. At first we need our source code. It'd be working of course! All we need to edit are two files: config.h and config.cpp In this guide you'll learn how to declare a extern variable which will depend on your CONFIG-setting and can be used everywhere. At first we need to think about a new variable. Let's just start with something easy. We'll create a new gold-limit for players! That'll depend on your CONFIG so if you don't want to have such high gold limits, you can tune it down as you want. So. We've got an idea now what we want to do. Let's start with the real guide. declaring our new variable so we can use it as a new limit! You simply need to open config.cpp and there you'll find a lot of code. As you can see there are many variables declared: ...and so on. At this point we can figure out how we declare our variable: We want to have it globally so the whole script can use it. That's why we declare our variable here at this point. Since it's in no function it'll be used as a global variable. Let's think.. What should we write? For this step we need to know the data types in c++. I won't go in that deep so you'll have to look on your own since it's really easy to find what datatypes can store which sizes. For your gold limit we'll use unsigned long long. long long can store very huge numbers while unsigned lets you store even higher numbers AND since no one shouldn't be able to have - gold it's the best to keep it over 0. So our line should look like this: long long yang_max; Now we should declare a standard value for our yang maximum. Why? Because if we don't edit the variable by using CONFIG (e. g. if you just don't want to set your yang limit by your CONFIG file) it'd turn out to be 0 (so: If we don't declare a specific number for long long the compile will use 0). So we set a new limit: long long yang_max: 2000000000; Next we'll edit the config.h file. There we just scroll down and add our new variable. We can just put it where the other variables (for example extern bool bXTrapEnabled;) are. But this time we won't give it a standard value and we'll add something at the beginning: extern long long yang_max; The extern will allow other scripts to use this variable. At this point we'd simply use the variable anywhere! editing the variable by using the CONFIG-file But we want to let people edit the variable by using the CONFIG-file. So back to config.cpp There we scroll down and wait! What do we have here? There are other CONFIG-options listed (e. g. TOKEN("max_level") and TOKEN("pk_protect_level"), if you don't find them just search for one of them). So maybe we'd just simply add one of these procedures for our variable, hm? Okay, let's try it. We copy the whole TOKEN-statement from "max_level" and paste it just under it. This should be there twice now. Let's edit this so we can use it for our own variable. At first we change the TOKEN. It's the thing the gamefile will look for when it processes your CONFIG-file. We change it to: TOKEN("max_yang") or whatever you want so the gamefile will fire up the following code when it reads yang_max in your CONFIG-file (now matter of lower- or uppercases). Next we change the variable name. In this case they're putting the value you specify in your CONFIG-file into the variable "gPlayerMaxLevel". But we don't want this! We want it to be in yang_max, our variable! So change it everywhere. It'd look now like this: So now let's analyze the rest of the code so we can finish our work. In the first line (str_to_number(yang_max, value_string) the value you specify in your CONFIG-file will be written into your variable "yang_max". The second code line uses the MINMAX-function. This trims the value up or down to a specified value. So in this case, "yang_max" can't be lower than 1 (if it is, it'd be set to 1) and not higher than PLAYER_MAX_LEVEL_CONST which is a global constant. Since we don't want to have our limits like this we need to adjust at least the MAX-value. Let's change it! So in this scenario the yang_limit could only be a number between 1 and 9.999.999.999 I set ULL after our huge number so the compiler won't generate a warning and read it properly as unsigned long long. You can play with these numbers but make sure you don't go higher than your variable can store, so pay attention to your data type!!! Now we need to edit the last line. You may look up for the fprintf-command and you'll find out about the mysterious %d. But I'll tell it to you: %d represents the value of an integer variable you give to the function at a later time (in this case yang_max will be used). But wait! We don't just use a normal integer variable. We have unsigned long long (or to be exactly: unsigned long long int). So we need to adjust it: fprintf(stderr, "PLAYER_MAX_LEVEL: %ulldn", yang_max); %ulld stands for "unsigned long long digit". If we don't adjust this statement, the core will immediately crash when accessing this instruction. So be careful and pay attention to the warnings you get! Ad last, PLAYER_MAX_LEVEL isn't an appropriate name. fprintf prints out a message so the user can read that his CONFIG-option will be used properly. You can change it to YANG_MAX. Our command will now look like this: fprintf(stderr, "YANG_MAX: %ulldn", yang_max); And now we're finished with our config.cpp using our variable in other scripts Welcome to the last part of this guide. It's much shorter than the other parts, so you may be happy now! We're almost done. At this point we need to open the source-code we want to change. In this example we just want to use it in another source file, let's say we use it in char_battle.cpp. You can - of course - use your variable in every file, but in this example I'll just add it there. So let's open char_battle.cpp At first we need to make sure our config.h (that's where we defined our variable to be extern, you remember?) is included in this files so we can use our variable. Have a look at the first lines, there are many #include-statements. We'll look for our config.h and here we got it: In line 3. If it's not there, you need to add it! Just add the line at the end of the #include-section: #include "config.h" Next we can jump to the end of the include-section. At this point we simply tell the script to use our extern variable globally in this file (you can use the following statement only in the functions you'll use your variable too, but in this example I'll just make it global so you can use the variable everywhere in the script). So we simply add the following line under the #include-section: extern long long yang_max; Since it's extern it'll look for externally declared variables and there it is: In our config.h which uses the variable modified in config.cpp! Now we can simply use it everywhere. We can replace limitations with our new variable or even use it in another way. Try to experiment with it. I hope you enjoy the first part of the guide-series. If you want me to keep up with this, just leave a comment below. Oh, and if you have any questions, feel free to ask.
  21. yeah and It'd be really cool to spawn some special bosses and let users kill them (maybe there'd be a special event where one or more of the same bosses are spawned but only one is the chosen one and that'd be solved by creating unique IDs)
  22. vanilla project closed. I'm not going to develop any future versions of vanilla core. Since there's no purpose of vanilla core, it's nonsense to continue wasting my time adding features nearly no one will ever use. I'll spend the time with more important things than developing a useless core. I'll help others creating their owns and developing their own features. If there's demand, I'll give some peeks into the source code of vanilla 2.2 and I'll be - of course - still active here and share my ideas and codes with you. Within this change it's better to close this thread.
  23. Oh sounds like an idea for a new feature. Maybe we'd add unique-functions globally and not limited to dungeons?
  24. nvm I got used to it @Mehti: sorry, can't reply to every suggestion but I saw it and I definitely have plans for loading an external exp-table. But only if there's a table - otherwise the standard exp table will be loaded. But first the game should work stable and I'm still pending on some tests. For now it works without any problems but I'll really make sure to it. Some new cool features are already there (everything I announced and some of your suggestions). Oh, and there's no determined release date. In the next few days I've got MUCH more time than before so it'll mean for us: More time for vanilla core. I've "reworked" the update progress and this will be only a "one-time"-thing. The core seems to be stable now and that's the point where I can work on creating new features and stuff'.
  25. FreeBSD 8.2 is a way too obsolete. Please consider upgrading it. @.InyaProduction: I'll check it. YMIR didn't apply it for nothing, so I'll try to work on it in a reasonable way.
×
×
  • 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.