[teleport] VS seperate moveto event.
Moderator: Forum Moderators
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.
- DEATH_is_undead
- Posts: 960
- Joined: March 4th, 2007, 3:00 pm
- Location: Northern United States
[teleport] VS seperate moveto event.
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?
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.
The best way to learn is to follow. In order to learn WML, you have to follow other's work, and check their codes.
Re: [teleport] VS seperate moveto event.
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].
Code: Select all
for an instance:
[event]
name=prestart
{TELEPORTTHINGUMMY X Y }
Guys I never thought I'd come back to this forum after 8 years this is wild
- DEATH_is_undead
- Posts: 960
- Joined: March 4th, 2007, 3:00 pm
- Location: Northern United States
Re: [teleport] VS seperate moveto event.
See, the reason I'm avoiding it is because I have the quest and the teleports in separate files.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].
Code: Select all
{~add-ons/RPG_test/marcos/teleports.cfg}
{~add-ons/RPG_test/marcos/monsters.cfg}
{~add-ons/RPG_test/marcos/quest01.cfg}
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.
The best way to learn is to follow. In order to learn WML, you have to follow other's work, and check their codes.
Re: [teleport] VS seperate moveto event.
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:
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.
I may not be reading this right, but this is what I would do:
Spoiler:
[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
- DEATH_is_undead
- Posts: 960
- Joined: March 4th, 2007, 3:00 pm
- Location: Northern United States
Re: [teleport] VS seperate moveto event.
Not quite. What I have right now is:Boldek wrote:
I may not be reading this right, but this is what I would do:
Spoiler:
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.
The best way to learn is to follow. In order to learn WML, you have to follow other's work, and check their codes.
Re: [teleport] VS seperate moveto event.
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
- Simons Mith
- Posts: 821
- Joined: January 27th, 2005, 10:46 pm
- Location: Twickenham
- Contact:
Re: [teleport] VS seperate moveto event.
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:
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.
Code: Select all
#define IFQUEST01CONTINUE
[if]
<whatever conditions you need>
[then]
{QUEST01CONTINUE}
[/then]
[/if]
#enddef
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.