Advanced Optimisations and Hacks - Revision history

Sapient at 01:12, 20 February 2026

2026-02-20T01:12:28Z

Celtic Minstrel: What? No it's not deprecated, it's just not recommended

2023-02-14T02:13:40Z

What? No it's not deprecated, it's just not recommended

Octalot: /* Many common events in scenarios */ Clarify that unbalanced WML in unit_types is deprecated

2023-02-11T03:41:01Z

‎Many common events in scenarios: Clarify that unbalanced WML in unit_types is deprecated

Octalot: /* Many common events in scenarios */ Deprecate, and suggest using the [resource] tag instead

2019-07-02T20:49:37Z

‎Many common events in scenarios: Deprecate, and suggest using the [resource] tag instead

Gfgtdf: /* Hacking events into other campaigns */

2017-02-17T14:19:41Z

‎Hacking events into other campaigns

Iceiceice at 21:23, 6 April 2014

2014-04-06T21:23:53Z

Dugi: /* Many common events in scenarios */ Fixed a small error

2013-12-20T09:36:27Z

‎Many common events in scenarios: Fixed a small error

Dugi: /* Hacking events into other campaigns */ Added a small note, fixed a minor and quite obvious error.

2013-12-19T21:34:34Z

‎Hacking events into other campaigns: Added a small note, fixed a minor and quite obvious error.

Dugi: /* Hacking events into other campaigns */

2013-12-19T21:07:48Z

‎Hacking events into other campaigns

Dugi at 19:42, 29 October 2013

2013-10-29T19:42:42Z

@@ Line 250: / Line 250: @@
 When the inventory is viewed, we can avoid having to use [show_if] for all possible items, we just read what is inside the unit (or look it up in the items variable array). The message can be composed in a variable and then asked via insert_tag.
   {VARIABLE message.message "Which item do you want to manipulate?"}
   {FOREACH unit.modifications.object i}

@@ Line 5: / Line 5: @@
 == Many common events in scenarios ==
-This trick is useful if your (multiple) scenarios contain a lot of common WML. This happens if your campaign adds some additional functionality, like inventories. It might be also useful if you are using repetitive macros that fire the same events. Or when you need to add event-based weapon specials with [object]s and therefore need to insert these events into all scenarios and not into the unit via macros using unbalanced WML (which is also deprecated). It might be even useful if you have a lot of death message events.
+This trick is useful if your (multiple) scenarios contain a lot of common WML. This happens if your campaign adds some additional functionality, like inventories. It might be also useful if you are using repetitive macros that fire the same events. Or when you need to add event-based weapon specials with [object]s and therefore need to insert these events into all scenarios and not into the unit via macros using unbalanced WML (which is not recommended). It might be even useful if you have a lot of death message events.
 The problem that comes from using the same WML events in many scenario is that they are preprocessed and loaded into RAM once for each scenario, and it can be dozens of times, resulting in huge RAM consumption and annoying loading times. This tricks inserts in through a unit so that it is loaded only once. Its downside is that prestart events can't be loaded this way, but start events can set up pretty much anything, they are fired before you see the scenario.

@@ Line 5: / Line 5: @@
 == Many common events in scenarios ==
-This trick is useful if your (multiple) scenarios contain a lot of common WML. This happens if your campaign adds some additional functionality, like inventories. It might be also useful if you are using repetitive macros that fire the same events. Or when you need to add event-based weapon specials with [object]s and therefore need to insert these events into all scenarios and not into the unit via macros using unbalanced WML (as it is usually done). It might be even useful if you have a lot of death message events.
+This trick is useful if your (multiple) scenarios contain a lot of common WML. This happens if your campaign adds some additional functionality, like inventories. It might be also useful if you are using repetitive macros that fire the same events. Or when you need to add event-based weapon specials with [object]s and therefore need to insert these events into all scenarios and not into the unit via macros using unbalanced WML (which is also deprecated). It might be even useful if you have a lot of death message events.
 The problem that comes from using the same WML events in many scenario is that they are preprocessed and loaded into RAM once for each scenario, and it can be dozens of times, resulting in huge RAM consumption and annoying loading times. This tricks inserts in through a unit so that it is loaded only once. Its downside is that prestart events can't be loaded this way, but start events can set up pretty much anything, they are fired before you see the scenario.
-Deprecated: {{DevFeature1.13|2}} added the [[ModificationWML#The_.5Bresource.5D_toplevel_tag|[resource]]] tag, which provides a non-hacky way to do this, and also supports prestart events.
+Deprecated: {{DevFeature1.13|2}} added the [[ModificationWML#The_.5Bresource.5D_toplevel_tag|[resource]]] tag, which provides a non-hacky way to do this, and also supports prestart events. [[WML_Abilities]] shows how these combine with unit abilities.
 First, create a dummy unit like this:

← Older revision		Revision as of 20:49, 2 July 2019
Line 8:		Line 8:

	The problem that comes from using the same WML events in many scenario is that they are preprocessed and loaded into RAM once for each scenario, and it can be dozens of times, resulting in huge RAM consumption and annoying loading times. This tricks inserts in through a unit so that it is loaded only once. Its downside is that prestart events can't be loaded this way, but start events can set up pretty much anything, they are fired before you see the scenario.		The problem that comes from using the same WML events in many scenario is that they are preprocessed and loaded into RAM once for each scenario, and it can be dozens of times, resulting in huge RAM consumption and annoying loading times. This tricks inserts in through a unit so that it is loaded only once. Its downside is that prestart events can't be loaded this way, but start events can set up pretty much anything, they are fired before you see the scenario.
		+
		+	Deprecated: {{DevFeature1.13\|2}} added the [[ModificationWML#The_.5Bresource.5D_toplevel_tag\|[resource]]] tag, which provides a non-hacky way to do this, and also supports prestart events.

	First, create a dummy unit like this:		First, create a dummy unit like this:

@@ Line 272: / Line 272: @@
 == Hacking events into other campaigns ==
-This is the most dangerous trick, but it lets you make an add-on that mods the game - you can easily give inventories to mainline campaigns (without editing them at all), remove all randomness from campaigns, create a dungeonmaster kit for multiplayer survivals (without editing these survivals), change the general balance... possibilities are unlimited.
+{{DevFeature1.13|2}} deprecatd since Wesnoth 1.13 supports sp [modification]s
 It is wholly based on the repetitive scenario events optimisation mentioned above in this article. It allows you to add events into scenarios, without actually editing the scenarios. If you don't protect it by any #ifdef, it will affect all scenarios! This is usually the best way to get kicked in the butt by other add-on writers, but in this case, you'll have to make it carefully and with the knowledge that it will affect all scenarios in all campaigns (or just some, you can wrap it in #ifndef MULTIPLAYER if you want it to be singleplayer-only).

← Older revision		Revision as of 21:23, 6 April 2014
Line 313:		Line 313:

	An add-on named No Randomness mod uses this, although it is entirely written in lua, you might want to see it to know more possible combinations around customising the mod, but it will require you to know lua.		An add-on named No Randomness mod uses this, although it is entirely written in lua, you might want to see it to know more possible combinations around customising the mod, but it will require you to know lua.
		+
		+	[[Category:WML_Tips]]

@@ Line 102: / Line 102: @@
+              }
               -- And now we do WML action itself
-              wesnoth.wml_actions.unit{ id = "Event Loader" , side = 1, x = 1, y = 1}
+              wesnoth.wml_actions.unit{ type = "Event Loader" , side = 1, x = 1, y = 1}
               wesnoth.wml_actions.kill{ type = "Event Loader", animate = false}
        end

@@ Line 280: / Line 280: @@
       id=Event Loader   #It can be different, but it is assumed in the following code that it will be 'Event Loader',
                         #if you name it differently, you will have to rename it in the rest of the code!
       alignment=neutral
       advances_to=null

@@ Line 1: / Line 1: @@
 From time to time, especially if working with some advanced WML, you will come to need things that WML does not support. And you might be in a bad need to do that. This isn't a tricky of using WML, it is actually doing what the developers didn't plan to support. I have mostly used it to write much more effective codes at the cost of low understandability.
-Note: It is supposed that you are skilled with WML. It is expected that you know most WML tags, comprehend the contents of save files and have good understanding of variables and variable arrays in WML. It is also assuming that you've read Dunno's article about [[Wml_optimisation]], and do these things before.
+Note: This article was written supposing that you are skilled with WML. It is expected that you know most WML tags, comprehend the contents of save files and have good understanding of variables and variable arrays in WML (not all of them are required by each of these). It is also assuming that you've read Dunno's article about [[Wml_optimisation]], and did these things before trying ''these'' optimisations.
@@ Line 67: / Line 67: @@
   #enddef
-Now, we need to add the events in the unit into the scenario. It is trivial. Keep on mind that it means that only start events can be loaded this way, prestart events will be loaded, but will never be fired. It is useful to wrap it in a macro so that only one line makes it load.
+Now, we need to add the events in the unit into the scenario. It is trivial. Keep on mind that it means that only start events can be loaded this way, prestart events will be loaded, but will never be fired. It is useful to wrap it in a macro so that only one line makes it load. Because it disappears in prestart, it does not clear shroud for the player.
   #define GLOBAL_EVENTS
   [event]
@@ Line 81: / Line 81: @@
        [/kill]
   [/event]
-  #GLOBAL_EVENTS
+  #enddef
 This should be placed in all events. If you need to control your events with some variables it will check, it might be useful to use them as arguments for this macro and set them in the event.
 There is also a way to do it without touching the scenarios at all, but its use in multiplayer is severely limited. It is based on lua, which is always executed when the scenario is loaded (even if it is in the middle from a save file, because lua environment isn't saved), and can be later accessed only by defining new WML tags or event hooks. Placing this into your _main (inside the campaign's #ifdef wraps, to avoid hacking other campaigns!).
   [lua]
      code = <<
@@ Line 106: / Line 107: @@
   >>
   [/lua]
+ #endif
 == Getting rid of AMLA clutter ==
@@ Line 268: / Line 269: @@
    [/insert_tag]
 Then the properties of the object chosen will be in a variable named item_chosen.