Mitachi

Well, I did something to remember this in the past, as @ Syreldar said, the Type drop is actually 400% oriented.

There are more than 3 types counting thiefgloves, but the mostly used are these 3:

1. Type    drop
2. Type    level_limit
3. Type    kill_drop

Type drop (really common)

#1.	Type	drop
	He hasn't a 100 pct, but 400 pct

[*] > Example:

Group	Example_Type_Drop
{
	Mob	101
	Type	drop
	1	19	1	400 -- 100%
	2	29	1	32  -- 8%
}

Type level_limit (used usually for certains monsters, like Deathripper)

#2.	Type	level_limit
	He have a 100 pct.
	The limit determines which level you can get the item from

[*] > Example:

Group	Example_Type_Level_limit
{
	Mob	2071
	Type	limit
	level_limit	60
	1	19	1	100 -- 100%
	2	29	1	32  -- 32%
}

Type Kill_drop (really rare, used for monkeys only I guess)

#3.	Type	Kill_drop
	He have a 100 pct, the peculiarity is:
	You can determine after how many monsters you have the % to drop the item.

[*] > Example:

Group	Example_Type_Kill_drop
{
	Mob	5162
	Kill_drop	10 -- Every 10 mob, you have the% to get the item
	Type	drop
	1	19	1	100 -- 100% prob(Every 10 mob)
	2	29	1	32  -- 32% prob(Every 10 mob)
}

@ Mali be careful, Webzen wants to take you out, it's a trap.

Every time this guy releases something he gets slapped in the face, I'm sorry for that.

When you release something it has to be ready to use, unfortunately.
In another context that would be fine, but in a forum where 10/10 releases are ready to install/use, people WANT THIS.

Dungeons should clearly be done in Lua, doing them in c++ just complicates your life, there is no real pattern, you use *10 lines of code and throw 15 years of hard tested lua dungeons pratices in the trash. But it's a release and plus it's not the first time you've released a dungeon in c++, clearly you can do whatever the fuck you want!

ff: Since I've been on metin I've only known 3 developers who did only lua, all 3 swore they were the best in the world.

7 hours ago, Nuzzo said:

Thank you for this release but I don't understand one thing

With ctr+b it sends the mount away but the seal remains in the costumes, to recall the mount I have to remove the seal and put it back on or use the horse's book. Is that right?

Is it just my problem?

Actually it is intended to be so, you get on and off the mount often during farming, equipping the item at the beginning avoids having to equip it every time (and even in the case of waiting seconds)
To recall the mount you just have to do CTRL + G

If you want CTRL + B to remove the seal anyway, that's enough:

Or if you want CTRL + B don't remove your mount:

For those who want bonuses to be awarded even if you are not riding, but simply have the mount summoned:

Hi devs, I wanted to add this feature to my mainlines, being that this system is now considered standard in all servers.
I downloaded the public version that emulated how the Pet System worked, but I decided to make my own
(and am sharing it so you can test it for me as well)

In game pic:

Pros:
Fewer lines of code (50 or so, versus 1200+ in the public system)
By not using apply_type and value to assign the monster to ride, we will not lose a usable bonus
Being horse-based, trivially it is code that has been tested for years.
If you are on the mount and warp, you will still be on the mount at login (being that we use EnterHorse)
You can take advantage of the horse name system with a few modifications
You only get mount bonuses if you are riding it and not while it is summoned 

Cons:
I couldn't find any

Thanks to @ HFWhite for testing.

It seems a bad use from quest, anyway, you can check the ptr before use

bool CDungeon::IsUniqueDead(const std::string& key)
{
	auto it = m_map_UniqueMob.find(key);
	if (it == m_map_UniqueMob.end())
	{
		sys_err("Unknown Key or Dead : %s", key.c_str());
		return true;
	}

	return it->second ? it->second->IsDead() : false; // 0x0 check
}

9 hours ago, martysama0134 said:

The game is single-thread, so I highly recommend you to add the if (quest::CQuestManager::instance().GetPCForce(GetPlayerID())->IsRunning()) check before the for loop.

It will be either always true, or always false.

Something like:

	if (bDropInventory) // Drop Inventory
	{
		const bool bIsQuestRunning = IsQuestRunning();
		std::vector<BYTE> vec_bSlots{};

		for (int j = 0; j < INVENTORY_MAX_NUM; ++j)
		{
			pkItem = GetInventoryItem(j);
			if (pkItem && !(bIsQuestRunning && pkItem->GetType() == ITEM_QUEST))
				vec_bSlots.emplace_back(j);
		}

		if (!vec_bSlots.empty())

People can somehow bug abuse the quest items, and throw them to the ground while using item.remove() or pc.item_remove()

::IsQuestRunning it's simply a function that returns the above expression, quest::CQuestManager::instance().GetPCForce(GetPlayerID())->IsRunning()

#ifdef ENABLE_MISCELLANEOUS
bool CHARACTER::IsQuestRunning() const
{
	return quest::CQuestManager::instance().GetPCForce(GetPlayerID())->IsRunning();
}
#endif

Literally in all clients, to restore, just remove terrain from patch1.

The files were never deleted, but overwritten. Index file gives precedence to files that are higher up, patch1(with the new textures) is above the old ones.

7 hours ago, Thorek said:

You can check if ifstream is open instead of using the filesystem library (which comes from C++17):

std::ifstream file(LocaleService_GetBasePath() + "/fishing.json");

if (!file.is_open()
	return;

// ...

Also you should remove #include <fmt/core.h> to avoid compilation errors.

no

The tutorial contains an already configured json file!

Q. What is trivially the difference?
A. Here's an example:

I tested it, here is some evidence + a dip into the past 

After installing, you can do /fish_simul to test if it works properly.

It's amazing the follow up to this post, when one releases something small, all the bots come out to be professors.
Instead, when a thick developer releases something, nobody says shit, everybody says "wow you have a really long dick."

Am I perhaps the only strange one that this check does in InstanceBaseBattle.cpp in  ::CheckAdvancing? I ask for the meme

BOOL CInstanceBase::CheckAdvancing()
{
...

		//NOTE : Skil을 쓰더라도 Door Type과는 Collision체크 한다.
		if( bUsingSkill && !rkActorEach.IsDoor() )
			continue;

#ifdef FUNC_WALK_THROUGH_ENEMY // https://www.youtube.com/watch?v=h3uBr0CCm58&ab_channel=Hazard
		if (!IsAttacking() && rkActorEach.IsEnemy())
			continue;
#endif

I did a small refactory, not tested yet:

On 3/13/2023 at 9:50 PM, Papix said:

I have worked on servers that use both files...

The focus of marty is to have a clean base and correct the errors by the crazy Chinese without adding systems.

The focus of owsap is to keep the server as similar as possible to the official one including systems.

If you want to learn to program I advise marty, if you intend to open a server I advise owsap.

Of course you can use marty to start a server but you don't understand much and it will cost you more to pay developers.

• If you don't understand much about it and want to create a server, your server will be an abortion.
• You don't learn to work on files by systems installing, cuz the first tasks should not be "Okay, I'll copy and paste until it works."
• @ martysama0134 is not aiming not to insert systems, but to create/refactor what he inserts.
• Exactly by "assistance," what is meant by extended mainline with few systems (tested for years)?

This post looks to me like a cleverly designed marketing strategy. Each answer is nothing more than a personal point of view, passed off as objective.

Best regards

Hi loves

USE_TUNING and USE_DETACHMENT are part of the same case and are divided by if/else (Probably for the item removed in 2013 by Italian wiki):
https://en-wiki.metin2.gameforge.com/index.php/Tincture_of_Heaven

At first glance, when I read it, I didn't understand shit about it, so I decided to improve it and publish it; it's an unpretentious post, so enjoy it.

I think it is the same person who posed as the owner of another forum, the same person who scammed 100 euros to my team a few days ago, kek.

Thank you for sharing, I appreciate these types of additions because they came about to facilitate other types of scripts. I find them very useful

Nice, thank you! I think it's the first cms released on m2dev

Well, there are a few things to consider:

• If the error occurs every time you perform a certain action, the problem is definitely in the packet in question.
• If, on the other hand, it doesn't always happen but the package in question is always the same, skip to the part where I talk about the sequence system
• The packet header number itself isn't a problem, packets have their own cases in a switch, if the case has the same number, the compiler will warn you.
• It's not just the packet header number that's the problem, packages are literally typed structs, like this:

/*
	We need to be sure that the data types used match
*/

// Server
typedef struct SPacketGCTest
{
	BYTE	bHeader;
	WORD	wSize;
} TPacketGCTest;

// Client
typedef struct SPacketGCTest
{
	BYTE	bHeader;
	int	wSize; // error, int <-> WORD are not the same.
} TPacketGCTest;

Usually the sequence system (or ENABLE_SEQUENCE_SYSTEM  if you using martysama) corrects for differences in packet weights automatically but I don't like it to be honest, I don't find a valid use for it today, perhaps once it could have been useful. Honestly I turned it off, removing it I noticed less random crashes.
TIP: If you have it enabled try disabling it, you will notice the error more easily.

I have also disabled _IMPROVED_PACKET_ENCRYPTION_ in my mainline (and not, he didn't cause crashes or at least I didn't notice).
But you have to change some things first, otherwise after some hours of activity you come across the sizebuffer error. PRO: More speed performance

34th packet are usually the HEADER_GC_WHISPER, do you have some custom system related? let me know.

*ending*
When it comes to mistakes of this kind, it is not black or white; there can be many reasons. I told you what I was going to do initially.

This guide can certainly be useful to you:

I really appreciate your 'optimization fetish', great job and thanks for sharing as always

Thanks for your constant contribution

Awesome, i like the idea!

As we all know, the only trigger for quests on metin2 that is activated upon receipt of an item is pickup trigger (when x.pickup begin).
Unfortunately, this only covers the case where you pick up an item from the ground, so it is very limited.
Some people were asking to improve this, so I created a new trigger, with which you can cover other cases.

For now, it works in these cases:

Trade
Buy from npc shop
Buy from npc shopEx
Buy from pc shop
Pick up from ground
/item command (for testing)

Example:

@ arves100 we want metin3 from you