[ Dead Download Link ] Vanilla Core 2.4.1 [ We Need You ]

[Night 363]

and why dont you fix the critic hit bug

(higher deffence = more dmg from critic hit)

 

[Vanilla 1451]

it's not that you get more damage from letting the enemy building up defense.

It's just that your base damage gets doubled. That's all. The defenses of the enemy doesn't get doubled and that's why critical strikes seem to be stronger because they double the raw damage, not the calculated.

It's not a bug, I think it's intended. Chaning it would possibly change the balance (if there is any) in the game.

The whole thing about defense is getting weird because it only reduces the raw damage by a flat amount - your defense. To create a better balancing you'd have to recalculate how armor works. Same goes with magic resistance which is currently more than useless.

 

But I've now added a penetration effect. When you hit someone and it's penetrating, then a effect packet will be sent to the client (it's up to you if your client is able to interpret it or not).

SE_PENETRATE is the penetration flag.

[kiev6859 0]

I have a problem ... 

 

Channels, DB and Auth start normal but the game99 gives me the following error in SYSERR.

 

SYSERR: May 30 13:47:26 :: pid_init: 

Start of pid: 9865

 

SYSERR: May 30 13:47:27 :: Boot: item table size error

SYSERR: May 30 13:47:28 :: pid_deinit: 

End of pid

 

Could you tell me the solution please. 

 

Thanks and sorry for my english.

 

[Night 363]

 

I have a problem ... 

 

Channels, DB and Auth start normal but the game99 gives me the following error in SYSERR.

 

SYSERR: May 30 13:47:26 :: pid_init: 

Start of pid: 9865

 

SYSERR: May 30 13:47:27 :: Boot: item table size error

SYSERR: May 30 13:47:28 :: pid_deinit: 

End of pid

 

Could you tell me the solution please. 

 

Thanks and sorry for my english.

 

SYSERR: May 30 13:47:27 :: Boot: item table size error

 

this is your error bro

just post it on the right place 

this is not vanilla problem

[M4cheteros 2]

Version 2.4 was with many problems. 

I look forward to version 2.4.1/2.5, where all problems will be solved.

[Mord 0]

Hello

Can you fix bug with hp quest ( affect.add_collect(apply.MAX_HP, 5000, 60*60*24*365) ) in next version?

When I do relog/use skill (dash) hp back (hp with quest).

[M4cheteros 2]

Recap: What are the problems of vanilla core 2.4?

[Sober 37]

Implement these questfunctions if you can please :

pet.get_owner_id()

add a new event onupdate and this event is triggered every some time which will be specified in config

also a questfunction to check if a player has a specific bonus.

e.g:

affect.check(apply.MAX_HP, 5000)

[Syreldar 1823]

+ QUEST_TRIGGER_ENABLE: 1/0

Default is 1. Lets you define if you want to use the new execute-trigger.

Can you explain this?

[Night 363]

 

+ QUEST_TRIGGER_ENABLE: 1/0

Default is 1. Lets you define if you want to use the new execute-trigger.

Can you explain this?

 

 

well only this part

 

new execute-trigger.

[Vanilla 1451]

Happy news to you! Vanilla 2.4.1 now uses a better implementation of XTEA to encrypt it's packets.

Don't worry! Your client will thank you! The client already uses XTEA to encrypt the packets. So it'll be fully compatible with your binaries. But if you plan to change the algorithm, you'll notice that it's now by far easier to change it in the game then before! Because now it uses the same structure than in the client.

 

Additionally I took some time and fixed a minor bug. In the game, there's a new size for the exp so it can go higher than approx. 2,100,000,000,000. But the client still uses the lower value. When you hit the maximum of the exp-table there'll be a new value that'll determine the new exp needed for further leveling. This exp was higher than the maximum in the binary. That caused some problems for some users. Now I tuned it down to the 2.1 mentioned before. Additionally there'll be a CONFIG option to tune it by yourselves. This will make sure there's compatibility with every normal binary but still makes you able to access all the cool features of vanilla 8)

[Night 363]

Happy news to you! Vanilla 2.4.1 now uses a better implementation of XTEA to encrypt it's packets.

Don't worry! Your client will thank you! The client already uses XTEA to encrypt the packets. So it'll be fully compatible with your binaries. But if you plan to change the algorithm, you'll notice that it's now by far easier to change it in the game then before! Because now it uses the same structure than in the client.

 

Additionally I took some time and fixed a minor bug. In the game, there's a new size for the exp so it can go higher than approx. 2,100,000,000,000. But the client still uses the lower value. When you hit the maximum of the exp-table there'll be a new value that'll determine the new exp needed for further leveling. This exp was higher than the maximum in the binary. That caused some problems for some users. Now I tuned it down to the 2.1 mentioned before. Additionally there'll be a CONFIG option to tune it by yourselves. This will make sure there's compatibility with every normal binary but still makes you able to access all the cool features of vanilla 8)

 

cool

waiting for the next releases 2.4.1 - 2.5 -till 3.0

can you add the function

give_dm

it would be great if you do so

[Vanilla 1451]

I can. But currently it'd make no sense because I already installed a mysql implementation (to use queries directly from the core). And such a function would be easily realized in lua using this mysql-function. It won't have any sense to make it directly into the core, also not everyone would use it.

 

Additionally I'm going to make some further changes regarding to encryptions.

I've noticed that already a DES and a GOST-implementation is currently in the game source. I'll maybe be able to activate them and use them. But this will require some binary changes because the binary would need to handle the other algorithms too.

 

Also the mismatch (client uses xtea, server uses tea) could've lead into some packet errors. Maybe the different way of encrypting/decrypting could possibly make some wrong en-/decryptions which could lead into packet errors.

Now both are using xtea, that'd make client and game fully compatible

(tested and works). Also the encryption should be now faster and more secure (xtea fixes some security issues discovered in tea)

[metin2team 743]

 

can you add the function

give_dm

use pc.charge_cash()

-- syntax : pc.charge_cash(amount, charge_type)
-- warning: 	1. 'charge_type' : "cash"(default) | "mileage"
-- 	   	2. 'amount' must be positive number.

[Splash 0]

Hey Guys.

How i can enable the Globalchat (Empire_Chat) at vanilla Core?

at my last gamefile i use this system (Here).

Thanks for help :-)

 

[ricky92 29]

An encryption algorithm can't be changed, improved or fixed while mantaining compatibility with a previous version. It might have been named "TEA", but it was instead an XTEA implementation, and implementations can be improved: that's the case with the two functions you're mentioning, one had a for loop while the other was "unfolded" (for better performance).

Anyway, if you're compiling using the "improved packet encryption", I urge to let you know that packet encryption is a completely different process, and very far from the old and insecure XTEA, so you probably made a worthless effort, sadly :

[Vanilla 1451]

Of course, If you'd change it from XTEA to DES, then you're completely right. But XTEA is a modified TEA-Algorithm. That's the reason why it'd possibly be able to realize it. I told before, I'm not that sure about it, and it may be. But that's no guarantee that it actually does behave like this.

But in fact, the XTEA encryption did have some influence since changing the algorithm would lead into not being able to connect to the server anymore. So it may be that xtea is still encrypting packets, but of course it's not everything done to the packets.

I don't know how the new binary and gamefile works on this, but I know that every other binary/game-combination didn't work when I changed the algorithm in only one part and I was granted with invalid packet headers.

 

I'm gonna try to create new txt-files to make more adaptions. Maybe it'll be that in 2.4.1 the MAX_LEVEL option will be thrown away and instead it'll read out a exp-table you simply install with creating the file

exp_table.txt

in your locale/localename-directory.

The gamefile will read the file line by line and when there's a valid exp-value, the max-level will be increased by 1.

 

Additionally I'm planning on letting you enhance the configuration more with creating such files. For example I'd think of making a way of letting you create a txt-file to specify some maps where people are not allowed to teleport (with marriage ring, warpscroll or group teleport for example). But let's hear your thoughts about it!

 

At least:

I realized what's the problem with raising the maximum inventory. It'd need more than just making a option. The equipment starts from MAX_INVENTORY+1 and if I set it to 180, like it's in the source, then the equipment would start at 181. But! The client will still behave like the equipment would start at 91, that's why it won't display the equipment correctly. Though the file where the max-inventory size is specified (and the other sizes too) does not include the config-file it's more complicated to edit the level afterwards. Additionally it's specified as an enum that's making it even more hard to get a rework. So it'll ake some time to merge the two gamecores (4_inventory_pages and 2_inventory_pages) into one.

[Night 363]

Of course, If you'd change it from XTEA to DES, then you're completely right. But XTEA is a modified TEA-Algorithm. That's the reason why it'd possibly be able to realize it. I told before, I'm not that sure about it, and it may be. But that's no guarantee that it actually does behave like this.

But in fact, the XTEA encryption did have some influence since changing the algorithm would lead into not being able to connect to the server anymore. So it may be that xtea is still encrypting packets, but of course it's not everything done to the packets.

I don't know how the new binary and gamefile works on this, but I know that every other binary/game-combination didn't work when I changed the algorithm in only one part and I was granted with invalid packet headers.

 

I'm gonna try to create new txt-files to make more adaptions. Maybe it'll be that in 2.4.1 the MAX_LEVEL option will be thrown away and instead it'll read out a exp-table you simply install with creating the file

exp_table.txt

in your locale/localename-directory.

The gamefile will read the file line by line and when there's a valid exp-value, the max-level will be increased by 1.

 

Additionally I'm planning on letting you enhance the configuration more with creating such files. For example I'd think of making a way of letting you create a txt-file to specify some maps where people are not allowed to teleport (with marriage ring, warpscroll or group teleport for example). But let's hear your thoughts about it!

 

At least:

I realized what's the problem with raising the maximum inventory. It'd need more than just making a option. The equipment starts from MAX_INVENTORY+1 and if I set it to 180, like it's in the source, then the equipment would start at 181. But! The client will still behave like the equipment would start at 91, that's why it won't display the equipment correctly. Though the file where the max-inventory size is specified (and the other sizes too) does not include the config-file it's more complicated to edit the level afterwards. Additionally it's specified as an enum that's making it even more hard to get a rework. So it'll ake some time to merge the two gamecores (4_inventory_pages and 2_inventory_pages) into one.

 

as long as you dont have time just work on the actuale bug it would be way better than adding thing that might end-up with new problems

and a small question is the exp-table the same as --GF-- ?

[Mehti 76]

 

1 month ago I wrote request for this wonderful system to add to the vanilla c0re.. ) Now you have started to work.  I was very happy when I saw the description.

 

thanks vanilla 

Edited August 15, 2022 by Metin2 Dev
Core X - External 2 Internal

[Summex 69]

Your future Plans and changes for Vanilla sound really great ! Keep up the awesome work. Vanilla is becoming better and better

[Vanilla 1451]

Currently updating the software on my building environment.

GCC will also now be updated in a part of this process.

If the libraries are updated, you may update them too (I'll of course upload the libs within the packaged). Furter information is coming regarding to this.

 

Oh, and there are a bit more consequences. Vanilla just got a level up if you can call it like this. It's now bigger, approx. 50mb. This is caused by new optimization flags that're now pending test

(Oh and don't think the bigger the file is the faster it is -> that's not true! The bigger file size is caused by new optimization flags that're now optimizing the code, making it bigger but faster. For example loops are getting unrolled so they'll be executed faster. The standard gamefile didn't use these compiler flags. They're big like this because they used a very old gcc version, that has nothing to do with an optimized code).

 

In this version I'll also recompile the database. Maybe it'll get some love in this version too!

 

At this point I also want to thank you for your contribution all the time. Appreciating my work is one of the best ways to show me how much you value this project and I wouldn't work on it right now if you wouldn't support the project that much. I want to thank you for that!

(I'm not gonna copy pasta Pewdiepie to give you a brofist, but still you'd know that I'm really happy to have people like you supporting me! You'll get a wink instead!)

[Splash 0]

Hey Vanilla.

How i can enable the Globalchat (Empire_Chat) at vanilla Core 2.4?

empire_chat: 1 at CONFIG ?

[Night 363]

Hey Vanilla.

How i can enable the Globalchat (Empire_Chat) at vanilla Core 2.4?

empire_chat: 1 at CONFIG ?

 

yes ;but for some reason it does not work for me

[Vanilla 1451]

empire_chat is marked broken right now.

 

I reimplemented the global chat. Code's gotten a bit messy that's why two options were leading to the same thing:

empire_chat and global_chat. But none of them actually made a change.

 

However, in 2.4.1 empire_chat is removed and global_chat will work.

 

New thing in 2.4.1:

gcc now updated to 4.9.1

Also I've changed the compiler optimisations. Now everything except for the gamecore itself is compiled with the -Ofast flag. Additionally I've enabled gold to feature linker optimizations in combination with lto!

however the game got some new flags. It's now building with -O2 and a few options from -O3 to keep the new performance gains without breaking the gamefile.

Both tested and marked stable with the new changes. I'll make some further testing regarding to the changes I made and if everything's working now and then I'm ready for the release build.

 

There's something more! Normally using lto and g together (g is for debugging) may cause some trouble. So that's why I currently deactivated it seeing a huge decrease in filesize! It's now shrinking down to 17mb (unstripped of course so you won't have to worry about editing the gamefile).

I'm currently testing a bit. Maybe it'll hit in 2.4.1 too and it may be a huge step.

[Night 363]

about the player max speed i set it 300 but looks like 250 is the max

can you make a higher default (300-350) my server is a pve but still when my brother was testing he got that probelm