[teleport] VS seperate moveto event.

[DEATH_is_undead]

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?

[Boldek]

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

[DEATH_is_undead]

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.

[Boldek]

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:

Code: Select all

correct me if I am wrong
[event]
 name=moveto
first_time_only=no
   [filter]
        side=1
        x,y=X,Y
        [/filter]
            [if]
              [variable]
                   name=questdone
                  equals=yes
                    [/variable]
                                   [then]
                                        {TELEPORTTHING2}
                                  [/then]
                                                    [else]
                                                        {TELEPORTTHING1}
                                                     [/else]
          [/if]
 [/event]
                                      

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.

[DEATH_is_undead]

I may not be reading this right, but this is what I would do:

Spoiler:

Code: Select all

correct me if I am wrong
[event]
 name=moveto
first_time_only=no
   [filter]
        side=1
        x,y=X,Y
        [/filter]
            [if]
              [variable]
                   name=questdone
                  equals=yes
                    [/variable]
                                   [then]
                                        {TELEPORTTHING2}
                                  [/then]
                                                    [else]
                                                        {TELEPORTTHING1}
                                                     [/else]
          [/if]
 [/event]
                                      

Not quite. What I have right now is:

Spoiler:

Code: Select all

[event]
	name=moveto
	first_time_only=no
		[filter]
		x,y=3,12
		[/filter]

{~add-ons/RPG_test/marcos/quest01continue.cfg}

			[teleport]
			clear_shroud=yes
			x,y=70,6
			[/teleport]
				[scroll_to]
				 x,y=70,6
				[/scroll_to]
[/event]

With quest01continue.cfg having:

Code: Select all

[if]
		[variable]
		name=oldman
		numerical_equals=1
		[/variable]

[then]
	[set_variable]
	name=oldman
	add=1
	[/set_variable]

			[message]
			speaker=narrator
			message="Oldman Variable is $oldman"
			 [/message]
		[teleport]
		[filter]
		 x,y=52,3
		 [/filter]
		  x,y=70,2
		 [/teleport]
	[remove_item]
	x,y=52,4
	[/remove_item]

		[teleport]
		[filter]
		side=1
		[/filter]
		x,y=70,4
		[/teleport]
	[teleport]
	[filter]
	side=2
	[/filter]
	x,y=70,4
	[/teleport]


Blah blah blah.

I wanted a different event so I could avoid a first_time_only=no conflicting with my other event, that is to trigger only once. Although I do have a [if] [variable], I still feel this a sloppy way of doing it, but I do believe it is better then having all of the code in one big file. (In other words, I could prefer to be able to put quest01continue into quest01's file, if possible.)

[Boldek]

Are you trying to use this {~add-ons/RPG_test/marcos/quest01continue.cfg} to send the program to the other file like a macro?

[Simons Mith]

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.