Jump to content
  • 0

Blazing Purgatory Quest - Timers aren't working


Exynox

Question

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 :blink: ... 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  :D .

 

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.

Link to comment
  • Answers 4
  • Created
  • Last Reply

Top Posters For This Question

Popular Days

Top Posters For This Question

Popular Posts

Exynox

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

Exynox

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

Think

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 no

4 answers to this question

Recommended Posts

  • 0

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

 

 

Link to comment
  • 0

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 :P - 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? 

  • Love 1
Link to comment
  • 0

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! ^_^

  • Love 1
Link to comment
  • 0

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.

  • Love 2
Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


×
×
  • Create New...

Important Information

Terms of Use / Privacy Policy / Guidelines / We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.