• Content count

  • Joined

  • Last visited

Vanilla last won the day on June 12

Vanilla had the most liked content!

Community Reputation

852 Unstoppable

About Vanilla

  • Rank

Profile Information

  • Gender
  • Location

Recent Profile Visitors

6,749 profile views
  1. 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!
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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!
  9. 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.
  10. 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):!QXARHJDb!rwDcnuFHPKRsbK1hU1Mwn1BjpN07f9Iuksm_-0WiqpE 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
  11. 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.
  12. 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).
  13. 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.
  14. 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.
  15. open

    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.