[teleport] VS seperate moveto event.

The place to post your WML questions and answers.

Moderators: Forum Moderators, Developers

Forum rules
  • Please use [code] BBCode tags in your posts for embedding WML snippets.
  • To keep your code readable so that others can easily help you, make sure to indent it following our conventions.
Post Reply
User avatar
DEATH_is_undead
Posts: 960
Joined: March 4th, 2007, 3:00 pm
Location: Northern United States

[teleport] VS seperate moveto event.

Post by DEATH_is_undead » November 21st, 2011, 6:49 pm

I have a dilemma with one of my maps. I have a moveto event, that teleports a unit. But then I have a separate event that adds a value to a variable when the unit moves to the hex that teleports them. I would like to keep the events seperate, but unfortunately, it seems impossible, and the variable event is not triggered, unless I do [if] and [then]'s to the teleport event. Unfortunately, I would like to avoid this, because I consider the [teleport] file to be more of a "Core" of the map, and the event one to be just a side quest.

Is there a work-around that I can do to eliminate the need for the [if] and [then]'s in the [teleport] event? And is this even intended behavior?
3P MP Scenario - Great Dwarves Escape
The best way to learn is to follow. In order to learn WML, you have to follow other's work, and check their codes.

User avatar
Boldek
Posts: 576
Joined: April 14th, 2011, 6:37 pm

Re: [teleport] VS seperate moveto event.

Post by Boldek » November 21st, 2011, 8:21 pm

If you're avoiding the [if] and [then] because they are cluttered, how about just writing the entire thing as a macro and keep it tidy?

Code: Select all

for an instance:
[event]
          name=prestart
         {TELEPORTTHINGUMMY X Y }
I don't think there is any way to avoid the [if] and [then] tags without making the process much longer though, my personal advice is just to stick to [if] and [then].
Guys I never thought I'd come back to this forum after 8 years this is wild

User avatar
DEATH_is_undead
Posts: 960
Joined: March 4th, 2007, 3:00 pm
Location: Northern United States

Re: [teleport] VS seperate moveto event.

Post by DEATH_is_undead » November 21st, 2011, 8:46 pm

Boldek wrote:If you're avoiding the [if] and [then] because they are cluttered, how about just writing the entire thing as a macro and keep it tidy?
...
I don't think there is any way to avoid the [if] and [then] tags without making the process much longer though, my personal advice is just to stick to [if] and [then].
See, the reason I'm avoiding it is because I have the quest and the teleports in separate files.

Code: Select all

{~add-ons/RPG_test/marcos/teleports.cfg}
{~add-ons/RPG_test/marcos/monsters.cfg}
{~add-ons/RPG_test/marcos/quest01.cfg}
Teleports is for all of the teleports that don't involve quests. quest01 is for quest one. The issue that I have is that, by putting a part of the quest into teleports, I may lose track. To avoid this, I made another moveto event with the same coordinates in quest01.cfg. Unfortunately (even with teleports.cfg after quests.cfg, in hopes it will read the quest event first), it still teleports without changing the variable in question.
3P MP Scenario - Great Dwarves Escape
The best way to learn is to follow. In order to learn WML, you have to follow other's work, and check their codes.

User avatar
Boldek
Posts: 576
Joined: April 14th, 2011, 6:37 pm

Re: [teleport] VS seperate moveto event.

Post by Boldek » November 22nd, 2011, 3:48 am

hmm :? If you wanted to keep track, couldn't you write a macro in the teleports file to the quests? I too struggle with these kind of things sometimes, but I suggest not trying multiple events to cover one thing, I prefer long tags. I am pretty sure that the variables are read from file to file, as long as you keep the directories mentioned, they should.

I may not be reading this right, but this is what I would do:
Spoiler:
To make sure the computer reads the correct files, I suggest removing the second moveto. Second: In your Teleport.cfg event, just say
[set_variable]
name=questdone
value=yes
[/set_variable]
You might want to go in quiests or where you start and set that variable to 'no' just to help it along, but I am not really sure hwo to handle this. You have the directories connected in all your files, right? I sometimes forget that part.

I am probably not getting this, but I am certain that variables and macros should be able to reference each other as long as the directories are there.
Guys I never thought I'd come back to this forum after 8 years this is wild

User avatar
DEATH_is_undead
Posts: 960
Joined: March 4th, 2007, 3:00 pm
Location: Northern United States

Re: [teleport] VS seperate moveto event.

Post by DEATH_is_undead » November 22nd, 2011, 4:33 am

Boldek wrote:
I may not be reading this right, but this is what I would do:
Spoiler:
Not quite. What I have right now is:
Spoiler:
3P MP Scenario - Great Dwarves Escape
The best way to learn is to follow. In order to learn WML, you have to follow other's work, and check their codes.

User avatar
Boldek
Posts: 576
Joined: April 14th, 2011, 6:37 pm

Re: [teleport] VS seperate moveto event.

Post by Boldek » November 22nd, 2011, 5:43 pm

Are you trying to use this {~add-ons/RPG_test/marcos/quest01continue.cfg} to send the program to the other file like a macro?
Guys I never thought I'd come back to this forum after 8 years this is wild

User avatar
Simons Mith
Posts: 784
Joined: January 27th, 2005, 10:46 pm
Location: Twickenham
Contact:

Re: [teleport] VS seperate moveto event.

Post by Simons Mith » November 22nd, 2011, 6:25 pm

If you top and tail the quest01continue.cfg file with #define QUEST01CONTINUE and ... #enddef you can call it from the original scenario file with {QUEST01CONTINUE}, you could pass parameters to it if you needed to, you can put an [if] and [then] round it if you want and provided it remains in your macros directory you can still keep it as a separate cfg file. If you don't want visible ifs and thens, you can still do this:

Code: Select all

#define IFQUEST01CONTINUE
[if]
<whatever conditions you need>
[then]
{QUEST01CONTINUE}
[/then]
[/if]
#enddef
and then call that from the original scenario file with {IFQUEST01CONTINUE} instead.

I've been doing a lot of tidying by this method; my current utils folder has items.cfg, deaths.cfg, sides.cfg and so on, each containing various closely-related macros. Including raw WML code, as you appear to be doing, makes it harder to have more than one action per file. Wesnoth campaigns are mostly built on the assumption that you have a main scenario file calling on a library of macro files as needed. You can do it your way, but it's unusual and it's harder to make it state-aware. But you need state-aware programming to control your event triggers the way you want.
 

Post Reply