Hi Ian,
Wow, you've been busy!
I think when I get used to this, it will be very cool. The map creators
guide is updated too, right?
So is 10 the parser version of all the files that use this new format?
Can inheritance determine points that are removed? Likfe for instance, if I
wanted one unit to have health points, but an inherited unit has unhealthy
for instance?. What about skills, can they add or subtract from units? Or
is that beyond what the purpose of the inheritance flag was intended? I am
just trying to get my mind around this. I like it, I just want to understand
it, grin.
So, a lot of my older maps use craig's scripts. If I just load scripts for
craig's stuff that should work on those older map packs?
al
-----Original Message-----
From: ian-reeds-games-bounce@xxxxxxxxxxxxx
[mailto:ian-reeds-games-bounce@xxxxxxxxxxxxx] On Behalf Of Ian Reed
Sent: Monday, August 26, 2013 5:39 AM
To: ian-reeds-games@xxxxxxxxxxxxx
Subject: [ian-reeds-games] TB 1.13 dev 28
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
