The discussion over featured text has led to a number of developments in my SP utilities.
First you may recall that I was preparing three functions for use by Lua scribes, two of which I published. Some changes have accrued since then:
The link function has been split into two due to the next change.
This pair will now provide default text. This is the text that is generated by the event filtered hard code messaging system. (For cities and units - I have no idea what would happen with tiles.) It is for this reason that the function was split into two since you need to choose a different type of link if you expect the unit or city to be dead by the time the user gets to see the message.
I have actually provided a third form, which is used to create a 'short form' bbcode sequence. This form is prepared by the chat tool kbd/mouse shortcut, and has the benefit of providing a unique identifier (notably for units).
Also, I have provided the ability to obtain the default text so that the scribe can prepare complex messages.
At this point, I had a dilemma. The support code was growing rapidly, and I was reluctant to include this in EVERY utility, so I changed tack and will now provide individual support modules for different classes of SP utilities.
I have a number of utilities that I have classified into four types:
- Utilities that need no support. Currently, techtrade is the only one in this class and is UNCHANGED. Technically it could use bold for the heading (making it type 2) but I leave that as an exercise, which I recommend if you plan to write your own utilities using any of the materials I am providing.
- 'Basic' direct script utilities that require no user input and are run by simply loading the script. This class includes ukd, unh, and a new one - pollution. In the next post I will publish replacements for ukd and unh together with pollution and the two prerequisite modules.
- 'Extended' utilities that need user input typically userdata object (Tile, Unit, or City), plus various options. This class of utility needs to be loaded before it can be used. This step is similar to loading the prerequisites in (2) above but requires more advanced support modules - a set which can also be used for the (2) class utilities. To actually run the utility one needs to enter a function call using /lua cmd .... in the server or directly in the client command line. The userdata object (when used) can be prepared by any Lua expression such as find.unit(<id>), but for convenience, it is also possible to use a string that has featured text prepared by the kbd/mouse shortcut. So for example, if one prepared a chat command line /lua cmd home(' ') and then moved the cursor to somewhere in the string followed by indexing an object with <ctrl><alt><RMC> (City) or <ctrl><shift><alt><RMC> (Unit) (and then enter), the utility will be activated with the object and report accordingly. Note that these chat tool shortcuts will ONLY place the text into the chat line, so to use this in the client you then need to cut and paste the text. For details on the kbd/mouse shortcut see Help -> Chatline (or Help -> Controls).
- 'Continuity' utilities that require tolua features found only in the server. Typically these are:
- Callbacks. These utilities will do nothing if used in the client.
- Tables. To use these reliably across save/restore the tables need to be saved into the 'vars' script. To do this you will need to use the replacement version of _freeciv_state_dump. For INEXPLICABLE reasons the client offers no facility to save and restore data. These utilities can be used in the client but it is not recommended because of the lack of continuity across save/restore. This is an especially acute problem considering the GTK client (on windows) has a habit of occasionally dropping into a processor loop after using the console - requiring a quit-idle restart.
- tolua tables not available in the client. Currently, there is one utility that uses edit.
Edit minor typo for techtrade comments
Edit: more typos (all renumbering type 1 to type 2)