Vanilla

This weekend I'll release the next rev. Expect some great additions like I mentioned before. Also thanks to the community this new build will have a lot of minor bugs fixed. Going open source was the best decision in my opinion, I'd never have found them since some of them require a special setup which I'd never do. So yeah, I'd like to thank the community for it's suggestions and fixes. Even though I have very limited spare time to work with the core these days I was able to make big steps with the core and that's all thanks to the community. So yep: Thank you.

The error appears when you compile with -Ofast. Try lowering it to -O3 and if that doesn't hit it, then go with -O2. IT happens only on game, not db I recommend not removing -Wl,-rpath,/usr/local/lib32/metin2 since this specifies the path where libraries are loaded. Of course, that's a typo of mine in the public release (which will be fixed in next version too). It'd be -rpath and not just rpath, which is why you get the error.

at first CFLAGS += -stdlib=libc++ is not needed anymore since FreeBSD already uses libc++ with the most recent versions since.. well, clang is the default compiler and libc++ is now a part of the base system There's no need in adding this variable. Next you need makedepend. It'd be located in devel in the portstree. Also you'd check if your portstree is up to date. To do so, try portsnap fetch update. If this doesn't work (which mostly happens if you install a clean freeBSD [and it's not a wonder ;D]) then just go ahead and use portsnap fetch extract. I recommend rebuilding every port after updating the ports tree. Your warnings were because you used an outdated portstree and the ports are marked as a security risk since.. yeah, they're outdated and maybe have security flaws. After all this you'd be ready to go. Ah, and don't use gmake depend. The instruction is declared as gmake dep and not gmake depend

There's no need to install libcxxrt and libc++ in recent FreeBSD distributions since it's now part of the base system and already included. You don't need to install it manually.

Hey everybody! I've got some news on the upcoming release. Thanks to people sending me code snippets I'm able to crush some bugs that I wasn't able to notice (due to not using the functions as my daily driver). Additionally further vanilla revs will no longer use different locale-files depending on the country. What I mean with this is that it will always read locale.lua in your quest-folder instead of anything else. Though the countries still does count, since it will still be used when moving to the quest directory (for example locale/de or locale/gb). Only the locale.lua is a unified way of reading this file. Next is a total conversion into utf8. This means that also the database will be read with utf8 encoding. If you go ahead and convert your client to utf8 too, you'll be able to send and receive messages with characters you may not be able to use before. utf8 is a unified way of handling charsets and the future vanilla revs will only run with this charset. Of course this may or may not break backwards compatibility. I've chosen to go this route since it fixes a few things I'm also planning for the future and is less error-prone if you only have to deal with one charset. Also it's more simple since the database can (and should!!!) be changed to utf8 and this way represent all the needed characters. Ultimately, if you want to upgrade to higher python versions, utf8 will be needed since it's the only charset more recent python versions will use. And thus, having a server set up for exactly this charset is just perfect. One important note on this - I will not break the easiness of installing the core. This means that I don't want you to have to follow steps just to use the core. I will only turn these features on when you specify it in your CONFIG file. So expect a new option. But I will print a warning if you don't activate the option since it's more or less the future and some day I will just merge in the changes and remove the ability to opt-out.

try it with this: Taken from working sources. No one knows what you did with your client source, how are we supposed to know the details? There's literally nothing we can do but throw working codes from our sources at you and hope they do work.

News to the current state: Game & db are both in final testing. If it works without any kinks I'll ship. Expect it very soon!

1.) What's the bug about this? You're most likely got a gold rush, that happens rarely or from specific bosses. So either you raised the rate or you just got that, which of course doesn't get affected by your third hand. 2.) What's wrong with the attack? You have tons of options how to boost your attack in polymorph, even in the source you'd do that.

Sorry, but our crystal ball is in cleansing today. If you have a bug with someone's stuff you'd ask him. Not everyone here on this board bought his source so it's the wrong place to ask for support.

This is a thread for the vanilla source, so please send a PM if you're interested in help with other topics. I do not have your source and therefore I am unable to help you with this error unless you give me a proper bug report. Please refrain from error reports which are not related to the vanilla source published here. If you modify anything on the source I can't help you with this especially since people will think the source would be buggy. Please send a Pm for such concerns.

News about the update - yep, I have some. I'm currently figuring out what's going on with the newer mysql libs. I'll tell you a long story and a tl;dr for everyone who is lazy to read. It's a really strange occurance. The game and db boot fine but I tried to upgrade to more recent mysql libraries. As soon as I'm using the new libraries, the connection values (host, etc.) have really weird characters. It looks like an encoding issue to me but it really does not make any sense since the characters occur even when I print debug messages long before any function from the library is called. I therefore decided to fix a warning that's been bugged me for a while and go for the all-utf8 stuff. Now every source and header file is converted into utf-8 with all the characters still remaining (except for one occurance where I had to short a function in empire_text_convert.cpp. So the core will still be stable but the conversion may need further testing, but I guess it'd work like before). The error with the weird characters still appeared but only at the first boot with the changes. Every new boot now seems to work fine, game and db connects perfectly. But since the error had occured at least once I'm not ready to ship. tl;dr: Weird bug with libmysqlclient that seems to be fixed, but needs further testing, then I'll ship For editing CONFIG and all the stuff you need to visit one of the basic tutorials about server configuring. You need to understand the parts of your serverfiles. You can think of the gamefile as the kernel of your server (though of course It's not a kernel, just for your imagination). While the serverfiles in it's whole is the system (with using scripts like quests and all that stuff) the core itself is the first thing your client will come in touch (of course only after the OS, etc..) when connecting to the server. It delegates and of course does the main job. That's why it's called a core. The dbcache does support the core and handles all the mysql stuff and does the caching job. Vanilla is NOT a serverfiles replacement, it's a core-replacement. It also is NOT a client modification at all. It only affects the core and is backward compatible with serverfiles and clients beginning from r34k (recommended: r40k). As soon as you understand the parts of your serverfiles and get a view on it's structure you're also able to adjust the CONFIG to your needs and fully unlock the possibilites vanilla core holds. But even without utilizing the CONFIG files you're having a lot of fixes and stuff that's not in the 40k source.

Everything mentioned in here: and everything I mentioned in this thread. There ar lots of source changes, some minor and some major. It has a unique system, new quest triggers, a mysql class for quests, new quest functions and is fully customizable, not only via CONFIG and txt's but also via source since it's fully open source. You can use very client compatible with r34k and above. No need to adapt anything, vanilla core is a drop-in replacement for your game and db file being backward-compatible with official server setups.

It's one of the older options, thanks for pointing out the typo. I've fixed it in the next version. I've also tested it once I implemented the option. I highly recommend not to disable the sequence check but sometimes it can cause trouble and since the sequence table can easily be read from the binaries it's advisable to be disabled in some rare occasions. Disabling the sequence could lead to other binaries be able to connect (if you have for example standard encryption passphrases). So yep, it's best to leave it on but if you disable it, the sequence will automagically be accepted, no matter if it's wrong or right. That's all the disabling does, the packets are still send to max out compatibility. I dunno if the client binary does care about the sequences or not, that's what I didn't look into since I'm not modding the client.

News: New build in work. The next builds will drop mysql libraries in favour of mariadb. You won't have to compile mariadb by yourself since I'll add a new directory called "External" which holds the mariadb libraries and includes. Next build will be distributed soon. I also looked at the problems reported with the release build. At my pc it's working fine but some people reported core crashes. I hereby advise to reduce the optimization flags to -O3 instead of -Ofast. You can just search -Ofast in your Makefile (located in game/src) and change it to -O3. If it still crashes, you can further reduce it to -O2 but most likely that won't be needed. Additionally I've fixed (and you can do that too) the linkflags on db. It's a minor cause but it'll end up with your db not loading the libs from /usr/local/lib32. You only have to change the lines for DTARGET and RTARGERT so it's using the right linkflags. $(DTARGET): $(OBJ_DBG_FILES) @echo $(CC) $(CLINKFLAGS_DBG) $(LIBDIR) $(LIBS) -o $(DTARGET) @$(CC) $(CLINKFLAGS_DBG) $(LIBDIR) $(OBJ_DBG_FILES) $(LIBS) -o $(DTARGET) $(RTARGET): $(OBJ_REL_FILES) @echo $(CC) $(CLINKFLAGS_REL) $(LIBDIR) $(LIBS) -o $(RTARGET) @$(CC) $(CLINKFLAGS_REL) $(LIBDIR) $(OBJ_REL_FILES) $(LIBS) -o $(RTARGET) Since I'm not able to virtualize and compile (thanks to a beta bios update yay) the next release will have pre-compiled binaries too!

The following script should work. You'll have to create a textfile in locale called coordinates.txt (the segment for loading this file is right beyond the exp-table loader in config.cpp). First you'll have to define the map index for each empire from 1 to 3. Next are the coordinates of the map where the player should spawn when created. Lastly, the coordinates of the start can be applied. For example, if a player gets created, he'll start a certain point. And everytime he dies on this map and chooses to respawn "at town", he'll be send back to the coordinates provided by start_position. So the segment could look like this #maps 1 2 3 #create_coords 10 10 20 20 30 30 #start_coords 10 10 20 20 30 30 Of course the coordinates and map index in this "example" do not make any sense. But it's here for showing you how the system works. Note that you can comment lines via # so the core won't read them. Regarding unique bugs - make sure you're running the system properly and try to run unique.init() first (you can even use it on boot to make sure the system works). If you extract it from my core and place it in yours I cannot give any support since I honestly don't know what you're doing and what your core is doing with that. So best is to try it with the vanilla core and if an error occurs, feel free to post a syslog and a detailed error report: What happens? When does this happened? Is this error reproducable? If the error is reproducable, what are the steps to cause it? This is an example how I'd like to receive error reports. I will work at them and help you but please understand that I need proper details.

Vanilla rev 70220 released! News to everyone! I have the next build ready but I'm running into a few issues. I'm seriously unable to virtualize 32 bit systems so I'm not able to compile a new core. But! I'm here to reveal the source code of the new revision. Note that this is a somewhat dev-hybrid build. I was not able to test the changes to some features, but the core itself is stable if you do not use the experimental features (all the experimental features must be user by the admin itself, users cannot trigger any of those). Download (binary): Download (source): [Hidden Content] password: vanillamt2 What's the changes? (good old vanilla-style): ~General~ * changed from BETA to STABLE * changed to c++1z (don't know if that was the case with the older builds too..^^) * Fixed some compiler flags that broke the release build * Re-added the lib32-rpath stuff * Fixed some minor bugs with messages from the unique class * code cleanup at some parts * Fixed minor warnings introduced with more recent compilers + Added new window for items - the VOID. It's a dark place and guaranteed to be spooky. And it's a place where you can safely deposit items which no character should have access to but still maintain the owner. So yep, items placed in the void will still be saved in the item table. (experimental!) * Implemented elevation for m2. You can enable it via CONFIG flag and use a standard key for testservers (also changeable). ~CONFIG~ + elevation_enable (bool): If enabled, the elevation system is active. It prevents users from getting >=gm privileges until they elevate via the su command and the specified passphrase. Note that you need to add the table column if you want to use this function (and that's the reason I didn't auto-enable it, backwards-compatibility) + elevation_key (string): This is the default elevation key. It's only used if you're running a testserver. So you'd probably change this to something else then default. ~Message system (experimental!!!)~ This system works with quests (and may be altered to other stuff). You can send messages via the new message class. It is even possible to add a fee (which would cost the receiver money if he wants to redeem what's inside) and multiple items. Items attached to messages are sent to the void (see above). Players can fetch all their messages and even redeem their contents. Messages are stored on the server in textfiles. Yep, there's even a new quest trigger (look below) ~questfunctions~ + item.void(): sends the current selected item to the void (2spooky4me) + npc.walk_to_pos(x(int), y(int)): let's the current selected npc walk to the given coordinates + unique.walk_to_pos(key(string), x(int), y(int)[, container(string)]: Let's the unique mob walk to the given coordinates ~questtriggers~ + message (example: when message begin): Does trigger when the player receives a message Developers note: I know it's been a looong while. And I have some apologies for it. Not only rl. But well, here it is. I've focused on implementing experimental stuff that's actually optional. If you don't want to use the message or void function, you don't have to. So we won't go into any security risks. The core has been proven to be stable. So well, let's call it like that. Elevation is a must-have in modern servers, especially since so many security flaws in the past could lead to people receiving GM-status. This will break those possibilities since even a testserver would still be a protected environment. No one could get implementor rights without elevating, though all the testing stuff is still possible. I think this may be a big step forward if people start to use it. Best Regards Vanilla

Nope, the error is not related to the quest at all. You might want to try and reproduce the quest to see which conditions are needed for this bug to trigger. Maybe something in your quest is wrong.

you've built devIL the wrong way. Make sure it's built with clang and 32 bit (it you're running a 64 bit os). The linker found your lib but it can't use it (that's why it's telling you it's skipping the incompatible lib).

simple as that - don't let the bonus overexceed 100 There are some bonuses that do not increase your rates by a certain amount but the chance to actually get a boost. Stacking exp bonuses for example doesn't work like you'd expect it to. The most common exp bonus doesn't add to your exp, but it is chance to get a bonus. If you exceed these bonuses over 100 the server is warning you since.. well, it isn't made for p-servers and their unrealistic high bonuses. So how to fix it? Either disable it via source/dif or simply don't let the people exceed them. The warning even tells you what bonus you're exceeding and how far you're doing that.

But he is absolutely right. The Client normally doesn't handle damage values if there's a critical hit. Though there's still something implemented which you can use for your needs. The client is able to display different styles depending on the damage types. For example poison could possibly be showed in a different style - and critical hits too. He even showed you the line which does that. Normally it's commented so the client doesn't use it. If you remove the comment, the client will use the critical.mse to determine the way it shows critical hits. And in effect\affect\damagevalue you can find everything you need, even the critical.mse with which you can display different colors. In your case that is violet. I think both of you need to calm down a bit... There's no need for insulting each other. We don't need prejudices against romanian people and we also do need to insult others as idiots.. especially when they present you the solution to your problem.

Are there any relevant logs? Check syslog at the time you're opening the cube and place some items. This way we can determine if there's any error or strange behaviour from the server. Not being able to place items could also be related to the clientside part but I wouldn't count on that.

most of the stuff is in the client source as the colors are defined by the damage type. For example if the damage you're dealing is marked as a critical strike, the client chooses different files for displaying the damage. You need to change that in the source, it's not too difficult once you've found it.

you can simply replace the g++ with c++ but if the source isn't adapted you may run into some problems when compiling with clang. You'll have to make some changes to the source.

check your Makefile and change your g++ to a compiler that's actually present in the system. g++ is from older systems where gnu cc was the standard compiler. Now we have clang and there you'd use c++ or install a compiler manually. This way you can also install and use gcc but you shouldn't use "g++" as your compiler in your Makefile.

That's actually a quite good idea. Next vanilla release will have a offline message system based on c++ and txt. Also mail system incoming. With open source you can just get it from the vanilla sources then. No need to pay