Think

Or just delete all references to this since it's useless.

Are you editing the client & server length? I mean, if you increase it over 255 and change the data type, the packet is going to need a type change as well. Why's that relevant? It will flush most of the player's items and those who don't get flushed will get flushed when you shut it down.

Isn't that kind of a bad start? If you don't know how it works, how can you claim you solved it? If you wish to fix the bug, fix it in the origin, setting/removing immune flags. Although someone else already published a solution in the forum, but well, it basically consisted of removing the recalculation of the flags so you'd get immune even if you didn't have the shield equipped, if I recall correctly. So that one was not a solution, and yours is definitely better compared (I think there were two posts, but I don't recall the other fix just right now, which I think was not correct either). Now, besides well, not being optimal as you say, for (int i2 = 0; i2 < ITEM_APPLY_MAX_NUM; ++i2) // we check the bonuses from proto why do you do that after you said Well, avoid them if you want to get the actual immune flag, but not if you want to get the proto immune flag! PS: Yes, yes, I whine a lot, it's attempted to be constructive criticism, sorry if it comes out that way.

Your problem is that Table 'log.invalid_server_log' doesn't exist Based on that query, create that table with fields locale_type - int(11), log_date - timestamp, ip - varchar(32), revision - int(11). This error should not be critical though.

Yeah, and will bring others (security, performance, etc). Downgrading to even more legacy software which is not supported anymore should never be a solution.

Please, think this through. You say that creating items on db is long and slow And then propose a solution which: Is just as long. Uses the database. Requires to change everything in item table to varchar (Please, don't! There are types for a reason) Isn't it easier to say "TIP! If you create items on the MALL window it will be reloaded when you check without having to wait 10 minutes."? I don't know... less hassle. I'm sure we all appreciate effort for helping out others nevertheless

Worth mentioning you are leaking memory and not returning any value.

Nah... the whole points system was made by someone with weird concepts (has to have been... it's overcomplicated and poorly implemented all around the code with tons of checks and crap), so I would not call anything in it "easy" xD Lectures aside, and unrelated to the complexity of this, I can think of something that would fail if you carry out that change. Let's say HP is bigger than Max HP (HP = 200, Max HP = 100), the affects/pet system are supposed to reduce the HP/SP (by for example 50) but all they do is set it to a value that it's still over the max, so the final HP will be 100, effectively ignoring the intended decrease.

One would think you don't have any function called notice_multiline. Have you maybe thought about trying to read errors and understanding them first? It really is not going to do you any good to just come here and ask... if you can't do anything alone believe me you are going to get bored very fast of this.

This looks like going backwards more than forward. Besides that, it looks pretty nice. Keep up

Yes, I don't know where that is but I assume you basically removed the waiting time between states (Monsters are handled by a state machine with wait, move, attack etc)

Because you are in a const function, you are not allowed to modify this, yet you are passing it to a function that treats it as a plain CHARACTER pointer, not constant. That is what you can't do. Remove the const at the end of the declaration helpCountBeltSpecifyItem.

If your db crashes all the cores start mismatching most packets to DB because it goes out of sync. You have to restart db along with the cores or it won't work.

Vanilla decided to unlink herself from the forum, so I doubt you'll get any.

You are getting an exception, and a warning is being thrown. You don't require any warning lib, but rather to see where the exception is coming from and fixing it.

Not quite true... Due to how Metin2 expects packets to work, you can't get rid of unknown packet errors unless you rework the system or analyze packet by packet receival and sending (Not the packet.h file, each call in each file). Of course, that is assuming that Packet.h in client and in server are the same (Same packet numbers, same packet structures). (Yeah, it sucks).

Immune against faint by default is 90%.

@daniel, I would suggest you that you remove the accepted answer, or people won't try to help you because the question has been answered already. The error is self explanatory, though: "attempt to call global `mysql_query' (a nil value)" You don't have the mysql_query function. But that's not your only problem, as that won't make your client crash.

Shouldn't change much (I'm pretty confident because I was stuck at this bug for some hours last week so I recall the related code and hard tested it ._.), but it's nice that you try different solutions, I probably would too! Note, however, that if you delete the contents of start you will then miss the jump to run, and as you'll quickly realize, your quest will never do anything, unless you jump directly with the /set_state or /setqf ingame commands (or are at the state already). I'm not, but hey, thanks!

For a first post it's very well laid out, so don't worry! To the point...: 1. The quest seems fine. If it compiles, then it's probably double fine! 2. The gamecore source is a bit buggy, but in general - In this specific case, you could say it's just not implemented thoroughly. Possibly YMIR made the change before implementing this dungeon (I can imagine how, but I refuse to implement the crappy solution anyway) to allow server_timers on other states. The thing is that because server_timers are not associated to any player, they are attempted to be ran from the start state, because they don't save which state they were called at. If you want to solve the problem in source, you only need to associate the quest npc created for the timers to the state. I know it probably sounds weird but if you take the time to understand how timers go in Metin2 you'll understand. Solution #2 and much simpler would be to move all your when xxx.server_timer handlers to the start state. You'll still be able to start them normally from any other state. Also, I don't quite recall atm if the functions are state-bound (i.e you can't call a function from another state), but if the functions are throwing errors because they don't exist or something, create a new state called state __FUNC__ and paste all of them there. I usually use a __FUNC__ state when I need shared functions between states (Looks more organized to me, and I forgot already if there was a forced reason to do it).

Why do you even want this?

Which functions? I only see it in the monster-only section "SetProto".

Hmm, that's weird. Make sure you are seeding with time, otherwise the number will always be the same. The game seeds automatically possibly (random guess xD)

@iRemix: That is because you are not seeding again. Do math.randomseed(os.time()) -- or math.randomseed(get_global_time()) before the syschat.

By removing m_pOwner->SetImmuneFlag(dwImmuneFlag); You are just removing the flag setting. i.e, no immune bug, because there won't be any immunes anymore! The rest of the code is therefore useless because you just change a locally scoped variable which you don't use.