Print

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

[Putnam]

Spiked shields are probably just flavor.

[MagmaMcFry]

Feature request, many mods add weapons, and often foreign weapons are a part of this, would it possible to do a {get "item_name" info} so that someone could see the benefits of that weapon without navigating the raw files. An example of why I bring this up, while playing DFMM, I got a drow caravan, and they brought spiked shields, and alas neither the masterwork sub-thread nor the masterwork wiki provided any help (or I am oblivious) as to the benefits and/or drawbacks of a spiked shield. If you could add in that feature, it might help take out some of the confusion when choosing whether or not to build/buy that weapon/armor from some mod or another.

So you want a method of finding specific objects in the raw files? I would think that Blast isn't really the best mechanism to do this, since Blast doesn't know what it is operating on (it doesn't even care about brackets), and it can be entirely possible that this item doesn't even exist yet while Blast is running. Tell you what, I'll write you a small standalone program that has you enter keywords, then scans the finished raws for any objects that match these keywords and prints them to terminal and to log file. Would that suffice for your purposes?

Edit: Or use this instead, it's kinda better suited for browsing.

[dimondmine2]

Thank you so much, for the link, and I would love to help this project, although I really know how I would do so, as I am not much of a modder.

[MagmaMcFry]

I added another template stage before the main parsing stage: Pretemplates, recognizable by the ! at the beginning of their name. Now all pre-templates are called before all main templates, which are in turn called before all post-templates. I also moved the TEMPLATE and GLOBAL_TEMPLATE templates over to !TEMPLATE and !GLOBAL_TEMPLATE, to allow people to write package-spanning main templates for other mods while ensuring that the template is defined before it is called.

[MagmaMcFry]

Added some time conversion templates, inspired by Hugo_The_Dwarf's Time to Ticks utility. I also added some more documentation to this topic, visible in reply #6.

[expwnent]

Posting to watch.

[milo christiansen]

How exactly did you rework these systems? If they're similar enough, I could replace the vanilla systems with what you have there.

The mods in question are all different enough from vanilla that replacing said vanilla reactions would not be a good idea. For axample the smelter mini-mod I mentioned removes all alloy reactions from the smelter and adds bar-only reactions to a new building, the Alloy Furnace.

I am trying to make a pile of mini-mods that can be installed in any combination, some replace vanilla stuff with expanded versions, some add all new industrys. The problem is that I need a way to update the entity with all the correct permitted reactions and buildings. If I was just adding stuff Blast would be just what I needed as-is, but some of the mods REPLACE vanilla stuff, but only for the dwarves.

A template to allow overriding tech classes for one entity only combined with a template for inserting tags into an existing object (in a different file) would be ideal.

Other than the problem of replacing stuff, Blast is about as good as it gets for repetative tasks.

I would try my hand at writing my own templates but Perl is not my thing, the only reason I have it installed at all is for pprof

[MagmaMcFry]

The mods in question are all different enough from vanilla that replacing said vanilla reactions would not be a good idea. For example the smelter mini-mod I mentioned removes all alloy reactions from the smelter and adds bar-only reactions to a new building, the Alloy Furnace.

I figured the ore alloy reactions were horribly broken anyway, so I planned on removing them, and replacing the bar alloy reactions with alloy reaction generator template calls. Then you could actually override the alloy reaction generator template to additionally produce different reactions with different tech classes, for example your alloy furnace reactions, if you really so desired.

A template to allow overriding tech classes for one entity only combined with a template for inserting tags into an existing object (in a different file) would be ideal.

Should be possible if you properly prepare those existing objects in those different files. I'm currently working on an ore dictionary that does just that.

[Bloax]

Have an orange good sir.

[MagmaMcFry]

Have an orange good sir.

AN OCTOPUS IN A TOP HAT GAVE ME AN ORANGE
THIS IS THE HAPPIEST DAY OF MY LIFE

In other news: 0.4.0a is out, and it brings dictionaries! Well, not exactly, they're more like a mechanism to share items and inorganic materials between add-ons, so you don't end up with 3 different variants of tungsten or 5 weapons called "trident". The sharing mechanism of inorganic materials comes with some extra features, namely the ability to register inorganic materials to reaction classes or as ores of other materials, which allows you to make sure that unobtanite is really an ore of your unobtanium, no matter which definition of INORGANIC:UNOBTANITE is used.

All vanilla items and stones/gems/metals have been made shared for your convenience, so you can easily make vanilla materials ores of your own stuff too, just in case you ever wanted to make pitchblende an ore of uranium.

[MagmaMcFry]

Added some more config options to the base: You can now disable animal people variations and/or giant animal variations from existing (erasing them completely, not just adding [DOES_NOT_EXIST]).

In other news: I need more feedback! Is anyone actually using this? Does anyone even plan to use this? I feel so lonely here in my thread... 

Seriously though, I'd really appreciate someone going ahead and writing an add-on (a new entity or some extra technology or a content pack or something, anything) for the standard base, so I can see what I need to work on next.

[milo christiansen]

Dictionaries look good, more after I get a chance to really look at them.

I plan to port my saurian mod to blast, dictionaries should provide all the stuff I need for that mod.

My mod Better Dorfs on the other hand still needs a way to overide reactions (sorry if such a thing was added, I need to sit down and read the docs)

Blast looks better and better every time a new version hits

[milo christiansen]

Quickly scanned the docs:
    Blast still needs a way to add tags to an object, something like {#REGISTER_OBJECT;RAW_ID} and {ADD_TAGS_TO_OBJECT;RAW_ID;<TAGS>}   
    A way to override tech classes is still needed

Other than those two things I can't think of anything that I really need.
The base would need to have a #REGISTER_OBJECT tag inserted into EVERY raw object, a huge task, but it would make it easy for modderes to add tags to, for example, material templates with minimum fuss.

I think I'll go get some perl docs. #REGISTER_OBJECT sounds like something I can do... A little playing with maps (or whatever perl calls hash tables) and some quick regexes and I should have something usable.

[MagmaMcFry]

Quickly scanned the docs:
    Blast still needs a way to add tags to an object, something like {#REGISTER_OBJECT;RAW_ID} and {ADD_TAGS_TO_OBJECT;RAW_ID;<TAGS>}   
    A way to override tech classes is still needed

Removing tech classes has the potential problem of making stuff incompatible. Simple case: One add-on removes the METALWORKING_ADVANCED tech class from the MOUNTAIN entity, and another add-on adds a steampunk tech tree for dwarves that registers some reactions to METALWORKING_ADVANCED. Suddenly the second mod is unplayable. This is what we need to avoid. I'd suggest that you leave the vanilla reactions there (I'll make the ore alloy reactions toggleable), and just add those alloy furnace reactions as an alternative. I could write a way to allow you to register a template to be called every time a metal alloy reaction is created, so you can generate corresponding reactions for your alloy furnace.

Other than those two things I can't think of anything that I really need.
The base would need to have a #REGISTER_OBJECT tag inserted into EVERY raw object, a huge task, but it would make it easy for modderes to add tags to, for example, material templates with minimum fuss.

I think I'll go get some perl docs. #REGISTER_OBJECT sounds like something I can do... A little playing with maps (or whatever perl calls hash tables) and some quick regexes and I should have something usable.

That actually sounds really hard to add to Blast, but there's a better way to do this. Remember that there are only really few tags that you would ever really need to add to an existing object, namely tags that refer to other objects. For material templates, this would be REACTION_CLASS and MATERIAL_REACTION_PRODUCT, and I could easily do the same thing there like I did for inorganics already.

[milo christiansen]

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

Warning, warning... very poor code follows

Code: [Select]

# {ADD_TAGS;ITEM:EXAMPLE;[EXAMPLE][TAGS]}
my %ADD_TAGS = {};
$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;
};
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.

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).