Think

The assumption that YMIR made proper working code is not correct either, some are definitely not serious, but there are actual logic issues (which got ignored by them, too). Warnings can also be about the performance of the code - and if you are going to supress each warning, then your better off fixing them....

Add in makefile -w at CFLAGS and delete -Wall.

Can we at least agree on the fact that that's a bad idea? (terrible, imho, but no need to agree on that level)

#pragma is not used only on VC++, even though for gcc it's a different syntax. You can use: http://stackoverflow.com/questions/3378560/how-to-disable-gcc-warnings-for-a-few-lines-of-code to disable warnings for specific parts of code. I'm not aware that anything that works with clang, but there might be.

There's always solution for all warnings (that are not due to external library usage, in which case, you can supress them: http://stackoverflow.com/questions/7159348/disable-single-warning-error). Some are a bit dumb, but they still point to potental problems with your code.

Warnings are not compile errors, but they can be logic errors. If you have a warning-free source, and you make a mistake, you'll see it right away. Ignoring all warnings is not a good idea.

Keep in mind that Unknown packet headers do not only happen on static packets but due to misreads of dynamic ones or simply because Metin2 temporary buffers suck and they get overriden and used for other stuff while processing the packet, so when the packet handler receives the control back its all messed up (yay).

Considering he's just commenting a line, I can't see how that would not work, so yeah, no problems. While you are at it, you can also delete the line that goes afterwards, you don't need to SetCount to the same count you already had.

Are you passing a count as an argument? item.remove(10), or just calling item.remove()? Because item.remove() won't do anything in your case.

But but you still didn't use code tags, it's not pretty

i did what @Shisui say but mob_proto didnot was like official server.. min_yang&max_yang&exp not orginal 

 

need help pls fast  

If you downloaded from official server I'm not sure how it was not like official server.

... that happens on most if not all programming languages Adrian. Syntax matters, because it's parsed by something that needs to distinguish different parts of your code. In this case, the comma is simply a way of separating elements. Nothing to be scared of.

Ontopic: It's cool, but what if the player database is not called player or the log database is not called log?

There are tooons of threads about this:

(Just to link a few)

The search is your friend

And of course, your own thread:

None of them have got a clear answer as far as I saw, and one reason is that changing max gold limit is a mess. You can change pretty fast it in a few obvious places, and it will mostly work, but you basically need to go over each and every use of gold to make sure you won't be overflowing it anytime, that its not stored in an int (or a DWORD, depending on what you are raising it to), that kind of stuff.

If you know C++, you can go ahead and change all gold ints to gold long longs. I'm guessing you don't and thus come here. But well, that's mostly "all" that you need to do. Find everywhere that gold is mentioned/used/stored and make sure it can handle a long long. In my opinion, raising the gold limit is a waste of time and a source of issues. Reduce your Yang drop rate, introduce a new currency, whatever, but increasing something that's already way beyond manageable (2.000 million is a lot) is possibly not the best way to go.

m_expireTime = MIN(1800, g_iPlayerCacheFlushSeconds);

Therefore, the min time for caching is 1800 no matter what you type in

Read that again Alina!

MIN(1800, 0) is most certainly 0.

Max time for caching is 1800, though.

But but but

Also, for trying that, I hereby declare you guilty of trying to break your own server! No go to a dark corner and cry full of shame! Well.. Maybe that's exaggerated a bit. But you still shouldn't do something like this. Never. Ever.

+1 haha

The only way that such a script can work is if you make sure that the player is offline when you run it, and has been off for at least N minutes (where N is the flush timeout for your db player cache). If those conditions are not met, player actions will overwrite the values you set on DB.

As you've been told, you can reduce the flush time but that's not advisable, the cache is there to reduce the load of constant DB read/updates and the extra processing that also takes on the game's database executable.

Yeah, but what would you use it for? What are win32 phase modules even?

All I find are virus/trojan descriptions.

btw, credits?

Which, ahem, "MalwareTech", this definitely sounds malware-y.

Sure thing, http://wiki.metin2.co.uk/ ?

It uses https://www.mediawiki.org/wiki/MediaWiki + some custom-made design loosely based on one freely available on the internet (you can fetch the CSS from their web nevertheless). I don't recall exactly which was the base one, but well, you can use any design you want anyway. There are a few out there.

If you absolutely must change things on player table, however, you can do so as follows:

• Run this command ingame: /flush <your pid> - Dunno how old it is, not sure in which game revs it works.
• Log out.
• Change things on your db (only those that belong to the user that you've flushed)
• Log back in, those changes will take effect immediately.

Use this sparingly, and most certainly try to avoid it on a live server unless you really really need it. There's a cache for something!

Sounds like you added extra "}"

Did you take a look over at this thread?

Good morning!

This exploit was apparently use somewhat often recently and therefore making the fix public is in order. We didn't earlier because it'd just cause a few more people to use the crash than the ones fixing it. There are two ways to exploit this, decently simple, we actually believe this happened by chance in WoM, so you should patch this asap. Not going to get into how its performed for obvious reasons.

Open cube.cpp

Find:

if (false == bCatchInfo)

Replace by:

if (!bCatchInfo || materialInfoText.size() == 0)

And then find

resultCount = resultList.size();

And add after:

if (resultCount == 0) {
	return;
}

You are all set! Fixed.

This affects several versions of the game, including r34 and of course source (Have no idea how far back this goes). This exploit was also present in Gameforge servers until we made them aware of it through crashing their beta servers on the Lycan launch (well aware that they'd be monitoring for crashes there, there was no intention of harming them).

Regards!

P.S: Thanks to MartPwnS, as he collaborated in finding and fixing this!

You should note that FreeBSD is not really good with cross-platform compiling/debugging.

Since game files are usually compiled for x84 (32bit), debugging on an x86-64 machine is quite hard.

 

I usually use an x86 VM or server for debugging instead of messing with this issue.

Interestingly we debug perfectly on a 64bit machine having a 32bit game compiled.

Did you apply some fix to the reatining-invisible-when-you-start-if-you-attack-problem? (I don't know how to call it :/)

That's because you are mixing libraries.

If you try to include PythonPlayer into an Gamelib file, it going to try to include all that's relevant to UserInterface (this has nothing to do with a circular reference). The problem is that even if you do include all the dependencies required for PythonPlayer to work, they are most likely going to conflict (on link time) with the ones on GameLib, because similar data and files are defined in each lib, plus extracting what's relevant from the stdafx.h is not fun either - each lib has their own stdafx and you can obviously not call both.

TL;DR: You are not going to be able to do what you are trying to do the way you are trying to do it, and even if you somehow managed, you shouldn't mix the two libraries anyway.

MaRRaTPL, replace

std::for_each(c_ref_set.begin(), c_ref_set.end(), notice_packet_func(c_pszBuf, isBig));

with

std::for_each(c_ref_set.begin(), c_ref_set.end(), notice_packet_func(c_pszBuf, IsBig));

(Note the case change on the last variable, that's the only thing I changed).

when kill with npc.get_race() == pc.getf("quest_name", "mob_to_kill") begin
  -- all the kill code
end

This is more or less what you want, I suppose. Make sure to use pc.getf and not getqf, because getqf does not work properly in when conditions (Due to how they are evaluated). Ah, and replace "quest_name" with your quest name

Where's your code ?

 

Anyway, I don't have this bug I think

If you don't use more than 2 inventories you don't. If you do, and you didn't patch it, you do.

Yeah, you are right @Cataclismo. WoM's logic is changed a bit, thus the difference. The problems of helping out after you change a few things xD

That's the reason for the GetCompany in

if (!(item = GetCompany()->GetItemByPosition(i)))

You are not being reasonable, nor replying to the actual question.

Maybe you did fix something, but if you did, I have to agree with Cataclismo, it's not published in this thread.

Instead of blindly doing gmake clean, explain why should it fix anything to add a variable.

Looks almost good to me:

INVENTORY_MAX_NUM /5 / 2

Should be / 5 / 4