[ian-reeds-games] Re: My maps! They broked!
- From: Ian Reed <support@xxxxxxxxxxxxxxxxxxx>
- To: ian-reeds-games@xxxxxxxxxxxxx
- Date: Wed, 28 Aug 2013 17:13:20 -0600
Hey Craig,
The 2 biggest features were outlined in 2 different emails which I've
pasted below for convenience.
Here's a snippet of changelog which hopefully got most of the changes:
40 Improved the way sounds were loaded and disposed which greatly
improved memory usage.
41 Added an option in preferences to turn off the graphics.
42 Significantly improved TB map rendering performance on large maps.
43 Significantly improved AI performance on large maps.
44 Added the ability to get the lists for units, structures, and effects
from a tile object in script.
45 Added the AllUnits property on the shared.Map object for scripters.
46 Added an in game updater that automatically checks for updates to the
game and gives the player an option to update.
47 Fixed a bug where a map pack that was missing Map Pack Settings.txt
and Author.txt would crash the game.
48 Added the new parser format for most files. That is parser version 10.
49 Added Event Subscriptions.txt for subscribing to global events.
50 Added the Script Flag Definitions.txt file for scripters.
51 Added the load_scripts flag to the Map Pack Settings.txt file.
And the best documentation for the bigger features is in the following 2
emails:
email number 1:
Greetings!
I thought I'd share what I'm working on.
It's going to require some changes by map creators and scripters but in
the end I think it will be a better experience all around.
My goal is to make it so map creators no longer have to specify events
like this:
after_create=add_transport_capabilities@ { Capacity: 10 }
But instead specify a script flag that might look like this:
transport_capacity 10
This will give map creators the experience they currently get with flags
built into the engine even when working with scripts.
The problem in the past was that scripters had no way of creating their
own flags so they were stuck with the uglier event syntax.
While working on the RPG I revised the flag text file format so it could
support multiple lists.
Then I added a way for scripters to define their own flags that go in a
script flags list.
I've been working on back porting both of these features to TB as well
as defining a way for scripters to hook into events themselves without
making the map creator do it on each object.
In the end I think it will really let scripters present a much nicer
interface to the features they add and reduce confusion about how to use
the scripts.
So working toward this goal I've released dev 28 which you can download
here:
http://BlindAudioGames.com/downloads/Tactical%20Battle%20Dev.zip
I actually released it through the in game updater but then found
another small bug in the updater which I've fixed and is now included in
the dev 28 release.
Any map creator using scripts will need to add a new flag to their map
pack settings.txt file.
The new flag is called load_scripts and takes a comma separated list of
script folder names.
So for instance:
load_scripts=craig_brett,abigail_prescott
If you don't have this flag then those script folders won't get loaded.
Sorry about this small breaking change. All in the name of progress,
right?
Most of the files support the new parser format.
It looks like this for a unit file:
Unit
10 // parser version
|flags
description A skilled melee fighter with additional armor and health.
add_skills attack,defend,move,armor
As you can see description and add_skills are now just flags.
The order of flags does not matter, also note that the equals sign is no
longer required if you are doing one flag per line and that some flags
support spaces when done without the equals sign, such as description.
Note that the add_skills line now separates skills by commas instead of
spaces.
This same base file structure applies to units, skills, effects, items,
points, and damage types.
The only thing that changes is the first line that specifies the type of
file.
I plan on moving almost all files to this new format as time goes on.
A couple new flags:
The friendly_name flag exists on skills, effects, items, points, and
damage types.
Use it to set a name that you want used instead of the name of the text
file when the object is announced to the player.
For Unit files use the friendly_type flag instead.
Both support spaces in the names.
If you don't use the flag then the file name is used instead as it has
always been in the past.
The inherits flag allows one object to automatically get all the flags
and script flags set on the object it inherits from.
For instance if you make a Base Human.txt unit and set it's max health.
Then make a base wizard.txt file and set it's max mana but also set
inherits=base_human.
Then make a blue wizard.txt file and set inherits=base_wizard.
The Blue Wizard will now have the max health of a human and the max mana
of a wizard because it inherits from base wizard which in turn inherits
from base human.
If you set more flags on the base human but then set the max_health flag
on the base wizard then the value on the base wizard would override the
one set on the base human.
This concept is pretty much the same as the Default unit flags.txt file
except that you can have inheritance several levels deep and you get to
define what inherits from what.
And finally at the end of the list of flags you can put this line:
|script_flags
This indicates you are done with the previous flags list and are now
specifying script flags instead.
This is where all the new flags scripters create will go.
Currently there are none, but I really hope they will catch on and
scripters will start exposing them from their scripts.
I've added 2 new files for scripters to use, but I'll discuss those more
in another email.
Ian Reed
email number 2:
Greetings scripters!
I've added 2 new files for you to use in your script folders.
As mentioned in a previous email the focus here is to allow you to
provide map creators with easy to use script flags rather than the old
event syntax.
Examples of the new files are located in the Data for TB\Scripts\Ian
Reed\Non script files folder.
They are called: Script Flag Definitions.txt and Event subscriptions.txt.
These file names are looked for specifically by the engine so be sure to
leave the naming the same or the engine will think it's a javascript file.
Put copies of these files in your own scripts folder and edit them as
needed.
A quick description of Script Flag Definitions.txt:
There are a couple comments in the file that I'll repeat here.
// each line has the flag name followed by the type. Valid types are
string, bool, int, float, percent, keys, function, and enum followed by
a pipe and list of enums separated by commas.
// You can optionally have a list of file types that the flag can be
used in, separated by commas. If left off the flag is valid in all files.
Down the road the valid files might not be optional, I recommend
specifying them as it will give map creators a friendly error when they
accidentally use a script flag in the wrong file.
Let me comment on each type:
string, used for textual data, can have spaces in it, if you want to do
completely custom flag parsing this is a good one to use.
bool, as with normal flags just specifying the name of the flag sets it
to true.
You can also do flag_name false which sets it to false, since that is
basically the default this is only helpful in inheritance scenarios.
int, whole numbers, negative numbers are supported.
float, decimal numbers, negative numbers are supported.
percent, expects this format: flag_name 52%, when you get the value the
52 will be 0.52. Using the percent sign makes it more obvious to map
creators about what this number means.
keys, uses the same format as the Keys.config flags, such as quest_menu
control q. There is a special javascript function that lets you check
if the specified keys were pressed. I still need to include this in TB
but it already exists in the RPG, so remind me, smile.
function, This expects this format: flag_name function_name {}, note
that this is similar to the last part of the old event syntax. There is
also a javascript function for calling these functions that I still need
to put into TB.
enum, this works just like string except if the map creator uses any
value you did not provide as an option they receive an error.
In the definitions file it looks like this: flag_name
enum|option1,option2,option3
So you might be wondering how you access these script flags from
javascript, good question!
Each object that supports script flags has a new dictionary on it called
ScriptFlags.
Here's an example of me getting the announce_name script flag off of a
unit in my testing.js file included with the game:
function announce_message(args) {
if (args.unit) {
if (args.unit.ScriptFlags.get("announce_name")) {
say(args.unit.FriendlyName);
}
}
say(args.message);
}
So again that was var val = unit.ScriptFlags.get("announce_name");
Note that val would be null if the script flag was not specified, false
if it was specifically specified with a value of false, and true otherwise.
Javascript treats null and false as falsy values so it works either way
in an if statement.
Now on to Event Subscriptions.txt.
This is a simple format where you specify the name of the event followed
by the function name and any arguments you want to pass in a JSON object.
For example:
after_map_load announce_message { message: "after_map_load" }
I actually recommend doing something more like this:
after_map_load ir_handle_after_map_load {}
This gives me a single ir_handle_after_map_load function that I can use
to do anything and everything I want to do after a map is loaded.
Everything I do should really be based on what script flags are set by
the map creators, so if they did not set any script flags that should
affect this behavior then I should do nothing in the function.
Note that I prefixed the function name with my initials.
This is because all the scripts exist in the global namespace and a
second function with the same name will override the first, so it's
safer for everyone if I prefix with my initials.
So for example I might have:
function ir_handle_after_map_load(args) {
var map = args.map;
var placeRandomUnits = map.ScriptFlags.get("place_random_units");
if (placeRandomUnits) {
// use the placeRandomUnits variable to decide which units to
randomly place in which area.
}
}
You can add the load_scripts=ian_reed flag to your map pack settings
file to load my test scripts.
They basically announce every time an event occurs so you can verify the
events are working and see when they occur.
Note that this behavior of doing something even though the map creator
didn't set a script flag is bad practice, but people should not be
loading my scripts anyway since there is nothing useful in them.
So, do as I say, not as I do, smile.
Well, I think that about covers it.
I think that the ability to hook up to all the events globally and to
create your own script flags really allows you to make a nicer
experience for the map creators.
I'm interested to hear your thoughts on the pros and cons of this method
compared with the previous way of doing things.
Thanks for all your help!
Ian Reed
On 8/28/2013 4:54 PM, Craig Brett wrote:
Hi Ian,
Ah, that's ok, that was an easy fix. Everything works again! I kind of
like this, actually, it kind of leaves more control with the map creater.
Is there a up to date change log anywhere where I can find all the new
goodies since about v20? I get the feeling I've probably missed other
little bits. The only one I distinctly remember is auto-updating,
which is cool!
Craig
On 28/08/2013 21:42, Ian Reed wrote:
Hi Craig,
This is my fault for sure.
I made a breaking change requiring map packs using scripts to set a
load_scripts=craig_brett where Craig Brett is the name of the folder
inside the scripts folder they want to use for their map packs.
You can also specify multiple folders separated by commas.
I think that adding that flag to each of your map pack settings files
will fix the issue. The change happened in dev 28, so all previous
versions worked fine without it.
Sorry about that.
Ian Reed
Other related posts:
