Exynox

Personally, I use Virtualbox in order to run both Windows/Linux and FreeBSD at once:

https://www.virtualbox.org/wiki/Downloads

(the config may be tricky for some :-?)

Regarding compiling with VS2010,

I have seen that some of you have this kind of errors:

 

Error C2664: 'std::forward' : cannot convert parameter 1 from '' to '&'

The fix is simple:

1. Go to PythonSkill.cpp, line 920.
2. Until line 953 (including), add (DWORD) in front of SKILL_(stuff here), as I shown below:

Before:

m_SkillAttributeIndexMap.insert(std::map<std::string, DWORD>::value_type("NEED_POISON_BOTTLE", SKILL_ATTRIBUTE_NEED_POISON_BOTTLE));

After:

m_SkillAttributeIndexMap.insert(std::map<std::string, DWORD>::value_type("NEED_POISON_BOTTLE", (DWORD)SKILL_ATTRIBUTE_NEED_POISON_BOTTLE));

Another 2 errors that I have encountered and fixed are:

 

Error C2039: 'back_inserter' : is not a member of 'std'

Error C3861: 'back_inserter': identifier not found

Just add

#include <iterator>

in MarkManager.cpp, after #include "MarkManager.h"

Here comes my problem:

Linker errors... Help, anyone? (P.S. I already managed to compile mainline_released with VS2008, so I know I can do the same with novaline, but compiling with VS2010 looks to me a bit fancyer)

Edit: I got linker errors using VS2008 to compile, too. What the h**l?

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 renamed run to start, duuh  Maybe I wasn't too explicit.

By the way, the quest is freaking working this way!

Before:

quest flame_dungeon begin
	state start begin	
		when ENTRY_MAN.click with pc.get_level() >= 90 begin
			pc.give_item2(LIMITED_PASS_TICKET, 1)
			set_state(run)
		end
	end

	state run begin
	
	function setting()
		return 
		{
		["bossroom_entry_pos"] = {8109,6867},
		["boss_pos"] = {686,637},
		["doors_pos"] = {

After:

quest flame_dungeon begin
	state start begin
	
	function setting()
		return 
		{
		["bossroom_entry_pos"] = {8109,6867},
		["boss_pos"] = {686,637},
		["doors_pos"] = {

This is the only change we have to do! Indeed, the timers must be in the start state. So, they aren't linked to the state in which they are called.

See if this fix works for you. Thanks for your support

Solved.

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).

Thank you for your fast reply! I'm glad I've come over such friendly people. I'll stick to the community

I'll go with solution #2, to see if it pays off. Seems... intriguing, and much simpler for me, as I am a PHP programmer, and my C++ knowledge is not that good for me to try messing so hard with the code.

But I'll first try to delete the (contents of) state start, because it doesn't do anything important (see code below)

	state start begin	
		when ENTRY_MAN.click with pc.get_level() >= 90 begin
			pc.give_item2(LIMITED_PASS_TICKET, 1)
			set_state(run)
		end
	end

and put the contents of state run instead.

P.S. Your English is quite impressive! Are you a native? 

Hello, mates! (It's my first post on this forum, so don't kill me please  )

My problem is the following:

I'm using the original Gameforge quests together with my self-compiled mainline_released gamecore. Everything went well, I've translated the translate.lua into Romanian, all quests are working properly, except for flame_dungeon.quest.

There is a server timer called killed_A_1 (around line 457) which doesn't freaking start, although the syntax is correct  ... I've seen another topic, where a dude uploaded his modified quest which uses timers instead of server timers, because of the same reason: this piece of code wouldn't start under any circumstances, making a monster counter and some other stuff unusable...

My questions are:

1. Is there anything wrong with the quest itself? If yes, what? Does it have some .lua dependencies which I don't have?

2. If the quest itself is OK, is the Gamecore source buggy? I mean, I've seen curse words and such in the code, so I expect anything from those angry koreans   .

Any suggestions?

P.S. This is my quest if useful: http://pastebin.com/XtYLU6Gc . (It compiles successfully btw)

P.S. 2 - Nothing regarding this appears in syserr.

Thanks in advance.