Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[MagmaMcFry]

That actually sounds really hard to add to Blast

Actually it's really easy, so long as you forget the task of adding calls to #REGISTER_OBJECT to every raw object

Spoiler: Warning, warning... very poor code (click to show/hide)

Code: [Select]

# {ADD_TAGS;ITEM:EXAMPLE;[EXAMPLE][TAGS]}
my %ADD_TAGS = (); # not {}
$TEMPLATES{'ADD_TAGS'} = sub {
my ($object, $tags) = @_;
my $oldtags = $ADD_TAGS{$object};
$ADD_TAGS{$object} = $oldtags . $tags;
return "";
};

# {#REGISTER_OBJECT;ITEM:EXAMPLE}
$TEMPLATES{'#REGISTER_OBJECT'} = sub {
my ($object) = @_;
my $tags = $ADD_TAGS{$object};
return $tags;
};

DIsorganized tag additions are kinda what I wanted to discourage, since that could possibly introduce all kinds of problems from leaving castes selected or somesuch, and it leaves little room for quality checks, because once a tag is added like this, it can't be removed anymore.

Your soulution sounds workable, but one addition should be made, the ability for an addon to override a vanilla file.
The best way to do this (that I can think of) would be a special kind of addon, eg you would have normal addons and overide addons, overide addons would be merged with the base before parsing and otherwise ignored. This would allow you to make advanced edits to a base without needing to distribute everything. For example my saurian mod removes the playable race tag from the dwaves and doubles the value of all metals, as of now there is no way for blast to change that short of a new base. With override addons I could just override the two files in question and leave the rest up to the default base.

As for material templates, there are some other tags that may be useful, namely UNDIGGABLE as well as things like tempature info.

See, this is the kind of problem that can be solved with templates too. I'd add a base config option that specifies whether or not stone is diggable, and the civ-playable entities could base the existence of their [CIV_CONTROLLABLE] on this value. I don't really see why you want to increase the value of metals, since those saurians are after all in the same world as the dwarves, and the trade system is enough to ensure that metals would have the same market value everywhere.

I didn't think about the incompatability problem with tech classes, Maybe the ability to remove specific reactions/buildings from a tech class? The alloy furnace is the simplest case, some of the reactions BD adds are in direct conflict with vanilla ones.
The ability to override/remove a specific reaction would also be invaluable for addons to other blast mods, say you want to add a bugfix to said steampunk mod you could remove just the bugged reaction and register the fixed replacement in its place. With such abilitys you could just post a small patch, much easier than having to distribute a whole new copy of the mod (if the mod is large, like say Masterwork).

That sort of stuff would probably be best left to the mod or add-on in question, but I'd suppose that posting larger diffs isn't really worth it, and smaller diffs can just be applied manually. I'll think about it, but it isn't really important now.

[Putnam]

These dictionaries and tech class things are perfect for materials plus...

later, though

[milo christiansen]

I have made three VERY useful templates:

Code: [Select]

{!TEMPLATE;@REACTION;id;class;
[REACTION:%id]
{TECH_CLASS;REACTION;%id;%class}
}

{!TEMPLATE;@BUILDING_WORKSHOP;id;class;
[BUILDING_WORKSHOP:%id]
{TECH_CLASS;BUILDING;%id;%class}
}

{!TEMPLATE;@BUILDING_FURNACE;id;class;
[BUILDING_FURNACE:%id]
{TECH_CLASS;BUILDING;%id;%class}
}
These are to be used in the place of the vanilla tags of the same name.
Better Dorfs uses these templates for all reactions and workshops. Builtin versions of these templates as well as templates for all item headers and anything else that can be registered would make blast code "flow" better.

One "bug" I found is that %token_SOME_TEXT will not work but SOME_TEXT_%token will. May I suggest %{token} or %(token) as an optional replacement syntax?

I have finally given up on having the ability to overide vanilla things from an addon and just made Better Dorfs into a base. Not as easy to install maybe but it works

Better Dorfs is MUCH nicer to work with now that porting is finished, not only can you fix bugs in half the time (due to less duplicate code) but a simple edit of the config file is all you need to go from ready to play dwarves to ready to play saurians.

I need to play a test game or two but affter that look for version 1.0!

[MagmaMcFry]

I have made three VERY useful templates:

Code: [Select]

{!TEMPLATE;@REACTION;id;class;
[REACTION:%id]
{TECH_CLASS;REACTION;%id;%class}
}

{!TEMPLATE;@BUILDING_WORKSHOP;id;class;
[BUILDING_WORKSHOP:%id]
{TECH_CLASS;BUILDING;%id;%class}
}

{!TEMPLATE;@BUILDING_FURNACE;id;class;
[BUILDING_FURNACE:%id]
{TECH_CLASS;BUILDING;%id;%class}
}
These are to be used in the place of the vanilla tags of the same name.
Better Dorfs uses these templates for all reactions and workshops. Builtin versions of these templates as well as templates for all item headers and anything else that can be registered would make blast code "flow" better.

Those look useful, but they can't completely replace the TECH_CLASS code, so they would introduce a new kind of syntax which would be used in parallel with the other syntax and therefore hurt legibility. They're fine for any code which only has to be understood by the author, but the default base has to stay legible. We should make a repository of Perl/Blast snippets that are useful to work with, but not clean enough (or usable in vanilla enough) for the default base.

One "bug" I found is that %token_SOME_TEXT will not work but SOME_TEXT_%token will. May I suggest %{token} or %(token) as an optional replacement syntax?

I forgot to add that. It's in now (but only on Github yet), the syntax is %{token}. Just replace your BlastTemplates.pm with this version.

Better Dorfs is MUCH nicer to work with now that porting is finished, not only can you fix bugs in half the time (due to less duplicate code) but a simple edit of the config file is all you need to go from ready to play dwarves to ready to play saurians.

This is exactly why I made Blast. It works! *happy dance*

[milo christiansen]

One problem: Blast needs perl and most windows users do not have perl. To that end I have started porting Blast to Go.

GoBlast will have two modes: Blast compatible, and simple.
The main issue is that GoBlast will not be as easy to customise, and so it will be mostly for mod authors to distribute not for general use.

So far simple mode works and all the builtin Blast templates are avalible (not the ones in the standered base).
I am using GoBlast to install/configure Better Dorfs so if you want to see it in action look at that.

[milo christiansen]

All done! GoBlast v1.1 (which is fully Blast compatible) will ship with the next version of Better Dorfs.

One template I added to GoBlast that I would like to see added to Blast:

{REGISTER_REACTION_PRODUCT;<INORGANIC>;<CLASS>;<MAT>}
        Adds a [MATERIAL_REACTION_PRODUCT:<CLASS>:<MAT>] tag to the definition of <INORGANIC>. For this to work, <INORGANIC> must be registered as a SHARED_INORGANIC. If this template call is the first to define this reaction product, then the given <MAT> is the one used in the finished raws.

[MagmaMcFry]

{REGISTER_REACTION_PRODUCT} is now on Github. Sorry if this didn't happen earlier, but I seem to have run out of spare time at the moment.

About the GoBlast thing: I guess it works fine for your mod, but it's kinda... overengineered? Now you have an own program that is compatible with only your own mod and the default base. I'm still trying to add a tiny integrated Perl version for Windows, and when I finally manage to do that, your program will be quite obsolete.

[milo christiansen]

Hey man I needed a project :p

GoBlast is/was basicly just for my mod, it was made with my needs in mind and any extra fetures (like full Blast compatibility) were added because I needed something to do
An integrated perl version sounds wonderful!

One thing GoBlast does that I really like is allow partial bases, it simply overwrites existing files instead of deleting everything. This causes a few problems (ok a lot of problems) but it allows me to distribute just the changed files instead of the whole raw folder (3 1.6K binaries make up for that :p).

One thing: Blast should ignore the raw/graphics folder. Everyone has their own setup for graphics so making it part of the base is anoying.

And some more templates:

{SHARED_MATERIAL_TEMPLATE;<NAME>;<DEFINITION>}
   An alias for SHARED_INORGANIC; use for material templates.

{IF;<VALUE_1>;<VALUE_2>;<IF_PRERAWS>;<ELSE_PRERAWS>}
   If <VALUE_1> equals <VALUE_2> (case doesn't count), then <IF_PRERAWS> are parse and returned.
   Else, <ELSE_PRERAWS> are parsed and returned. This is very useful for checking parameters in user templates.

IF is a little "iffy" I can think of some good uses for it but they are all things that could be done in other ways.

[MagmaMcFry]

Aw yeah, I did it! I found a Perl code distributable generator (PAR::Packer for those interested), finally got it to work, and was able to compile a Perl program that can run any other given Perl program (as long as it doesn't include any standard library modules that Blast doesn't need too). It got larger than I expected (~4.3 MB), but that's because I had to switch to Strawberry Perl due to compatibility and copyright issues with ActivePerl. But hey, that's still heaps better than the full 90 MB Perl download. Expect a new release soonish!

Edit: The raw/graphics issue is also going to be addressed, I'll allow add-ons to define their own graphics.

[milo christiansen]

Cool!

I think I'll keep using GoBlast for Better Dorfs, if only for the simple mode, but I may port some of the BD industrys as blast addons.

Now you just need some one to port Masterwork :p

[MagmaMcFry]

Cool!

I think I'll keep using GoBlast for Better Dorfs, if only for the simple mode, but I may port some of the BD industrys as blast addons.

Now you just need some one to port Masterwork :p

Oh god, Masterwork. I had a look at it and it could have gone wonderfully with Blast, but it's kinda too late for that now. If someone ever ports Masterwork to Blast, it's quite certainly not going to be me.

[MagmaMcFry]

New release, this time with a miniature Perl build included, so you don't need to have Perl installed. To run Blast with this build, use blast.cmd instead of blast.pl. I tested this on my Windows version, but I don't know whether it works on every Windows yet. Needs some testing.

Also, I added the IF template suggested by milo, and two more templates IF_LIKE and IFVAR_LIKE, who treat the second argument as a regular expression to be matched to the first.

[milo christiansen]

IF_LIKE looks very usefull.

I want to look into embeding perl in a go program, if I can (it is possible, I just don't know how hard it will be) then GoBlast will become much easier to keep compatible.

Maybe I can get the file size down (and I can cross-compile binarys for every os/arch DF supports)

Would it be possible to make the Blast directory structure configurable?
More importantly could addons be allowed to overide vanilla files?
One of the things that is stopping Better Dorfs from becoming a Blast addon is the lack of a way to replace the entity files, most of the other stuff can be worked around somehow.

[MagmaMcFry]

I want to look into embeding perl in a go program, if I can (it is possible, I just don't know how hard it will be) then GoBlast will become much easier to keep compatible.

Maybe I can get the file size down (and I can cross-compile binarys for every os/arch DF supports)

Google says that https://github.com/bradfitz/campher is what you are looking for, and it looks really easy to use.

Would it be possible to make the Blast directory structure configurable?
More importantly could addons be allowed to overide vanilla files?
One of the things that is stopping Better Dorfs from becoming a Blast addon is the lack of a way to replace the entity files, most of the other stuff can be worked around somehow.

I'm still not that enthusiastic about overriding base files, but could you work with a {!DISABLE_VANILLA_FEATURE;<FEATURE>} template, and what features would you want disabled?

EDIT: Also, how would you like your directory structure to be configurable?

[milo christiansen]

It depends on how fine grained the control for disabling vanilla stuff is. Mostly I just override reactions and permited items, but I also need config conditionals (IF_VAR;@CONFIG_XYZ) to allow removing entire entitys and replacing one set of items with another.

I really can't think of a good solution to my problem other than writing a new base.

As for dir structure configurability I want two things; the ability to specify that the base/some addons should not have there/its namespace appended to the file names, and the ability to set the path to the base dir and output dir as well as specifying one or more addon dirs.

I think the way to go would be for me to add the capabilitys I want to GoBlast and then write up docs and present them here, if you like them you can add the capabilitys to blast or suggest changes for me to add before submiting them for review again. That way you can see the changes in action (I'll provide a demo) before you make up your mind.

Thanks for the link, I'll go check it out now

EDIT: That is exactly what I needed! My quick search didn't turn anything up so I thought I would need to make my own bindings. So long as everything compiles fine I should be able to add support for reading Blast native templates.
FULL compatibility is now in sight!