Blazing Purgatory Quest - Timers aren't working

[Exynox 1531]

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.

[Think 117]

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

 

 

[Exynox 1531]

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? 

[Think 117]

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

 

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

I'm not, but hey, thanks!

[Exynox 1531]

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.