Print

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

[Roses]

Sorry for my horrible update schedule. I am done with the Event system (it's actually working pretty neat, can have buildings change by season/month/week, random weather occur based on season, run scripts based on wealth/population/deaths/progress triggers/and many more. A complete list will be included in the ReadMe) and am now starting on the Civilization System (I want to get both working before a proper release since they tie into each other a lot).

Now previously I had each entity get it's own unique civilization that was tracked independently of the others, but I am now wondering if it would be better to have all of the same entities get grouped together. Does anyone know how the game itself treats entities? For instance if there are three MOUNTAIN entities and two EVIL entities, can MOUNTAIN A be at war with EVIL A but not EVIL B? If MOUNTAIN A is at war will MOUNTAIN B and MOUNTAIN C be too? I know resources (i.e. available weapons, materials, animals, etc...) are stored on a per-entity basis, but are they actually just shared in the game? If someone from MOUNTAIN A learns to tame a specific creature, will MOUNTAIN B and MOUNTAIN C have access to them as well?

The whole reason for asking is because there are certain things that would be made much easier if I just treated all of the MOUNTAIN entities as a single civilization. It's not impossible to make each entity unique and independent, but it will complicate some things.

[vjmdhzgr]

The way you asked that question is a bit confusing, but I think I know what you mean. Once a world is generated civilizations are separate from the entity file. They are all their own individual civilization that tames their own creatures, has its own entity positions (in vanilla they can actually vary between civilizations. Humans don't start out with law givers they make them at some point, and I think there can be some varying names) and any editing of the entity files does not affect them. Which is why I've been trying to always use entity to refer to the files and civilization for civilizations.

Now just in case my current interpretation is wrong and my initial one is actually correct, then having multiple MOUNTAIN entities is duplicating raws which is not a viable option for a mod that makes any sense.

[Dirst]

The way you asked that question is a bit confusing, but I think I know what you mean. Once a world is generated civilizations are separate from the entity file. They are all their own individual civilization that tames their own creatures, has its own entity positions (in vanilla they can actually vary between civilizations. Humans don't start out with law givers they make them at some point, and I think there can be some varying names) and any editing of the entity files does not affect them. Which is why I've been trying to always use entity to refer to the files and civilization for civilizations.

Now just in case my current interpretation is wrong and my initial one is actually correct, then having multiple MOUNTAIN entities is duplicating raws which is not a viable option for a mod that makes any sense.

I can confirm that civilizations have distinct identities beyond the entity definition, much the same way units have distinct identities beyond their creature definition.

[Roses]

Yes, I agree the wording with entities, civilizations, and Civilizations (from my system) is confusing to discuss. I will refer to them as entities (the things in the raw files), civilizations (the civilizations in game), and Civilizations (which are assigned through my system). The way the "Civilization System" currently works is this,

Create a seperate file with

Code: [Select]

[CIVILIZATION:MOUNTAIN]
...
...
...I then assign that Civilization to all populations from the matching entity, but each civilization gets it's own unique Civilization. This is done by basically making several copies of the same Civilization and applying them across each civilization . This means that each civilization advances separately from the others. But I could change it so that each civilization that belongs to a given entity all belong to the same Civilization, so that if you give one them access to steel, they all get it.

Honestly I thought the first one was the best way to do it, but you really only interact with a single civilization of an entity while playing fort mode (and my systems are all designed around fort mode). I don't know, I suppose I can add the option for both, but it's a lot more coding. I'm guessing the feature really won't be used by many people other than myself for my mod, and I only generate one civilization (with a high number of different populations) of each entity so that isn't a big deal for me.

I guess the question becomes, how often do you interact with different civilizations of the same entity in fort mode?

[Dirst]

Maybe use the word Nation instead of doubling up on Civilization?

[Roses]

Hmm, that's a good idea. But the question remains, should each civ have its own nation, or should each civ that belongs to a single entity be apart of the same nation? I keep going back and forth in my head. But I think I'm going to make it joined nations instead of individual nations.

[vjmdhzgr]

I like the idea of different civilizations having varying levels of technology so there's more to distinguish them, but I don't really care too much either way, and the mod you're planning already seem to be a lot of work so I'd go with what's easiest.

Also Dirst there's a bit of a difference between the relation of entities and civilizations and creatures and units. Civilizations are completely separate from the entity after world generation, but most ways you can edit a creature after world generation will still affect any units. Though I think the ways that don't will just cause crashes rather than do nothing, which is still an effect I suppose.

[Roses]

Well I have really been failing at my updates this summer, but here finally is another one. It includes a ReadMe for all three systems (Class, Civilization, and Event) as well as examples for both Class and Event Systems. The Civilization System doesn't include an example yet because I'm not sure how well it actually works. That is to say, it works without errors or things like that, but all it currently does is add and remove access to materials and items to entities, and I'm not sure if that is actually respected in game or not. So if someone would like to play around with it and let me know, I won't have a chance to fully test it out for awhile.

Up next is the wrapper script. Probably one of the most complex scripts for DF there is, it is currently usable, but can be greatly improved and (hopefully) simplified a bit. This next update should be faster than the others since it doesn't involve an entire system, although technically the wrapper script and functions is as large as one of the systems.

EDIT: I also updated the third post to include information about all three currently included systems.

EDIT2: Just noticed a fairly large issue with how I was reading in certain information from external files. I have just now uploaded a fixed version.

[Roses]

Alright, I am wrapping up the wrapper script (pardon the pun). I have added the ability to target units based off of their pathfinding and station. Both for required and immune. This allows for targeting units that are fleeing and other such things.

Before I finalize the script, are there any other targeting features that people would like to see as options the current list is

Code: [Select]

creature class
syndrome class
syndrome name
race
caste
body part
flag (i.e. skeleton, ambusher_hidden, etc...)
token (i.e. MEGABEAST, FLIER, etc...)
noble position
profession
skill level
attribute level
traits
speed
age
entity
pathfinding
stationI am also planning on adding targeting configuration for a units inventory, but if there is anything else people would like to see just let me know and I will see if I can add it in.

[Roses]

So I know I haven't been updating this as much as I said I would, or as I would have liked. But I am nearing a new release for the improved wrapper system. And then I plan on working on the detailed unit viewer gui along with an in-game bestiary. This bestiary will tell you all the relevant information about the creatures of the world AND it will have pictures! See below for a proof of concept. Note that I am actually hoping on tying this in with Japa's Dwarf Portrait project so that by default you get a portrait like he has, and then if you have external images you would like to show instead those are overlayed. If/when Japa includes wounds on his paper doll models those could be included in the detailed unit viewer as well.

Spoiler (click to show/hide)

[Mr. Orange]

Just want to say that it's awesome what you're doing Roses. Looking forward to the new stuff!

[Roses]

I wanted to apologize for my lack of updates and my general absence from the boards lately. I have been dealing a lot with familial and personal issues this summer and have not gotten to invest as much time as I would like in this endeavor. That being said, I will be pushing my next update to github this weekend, and that is the wrapper script update. I am hoping that the update will make it more intuitive and easier to use as it provides a lot of targeting and logic options that are not available in DF or DFHack.

That being said, I am apologizing again for my limited appearance in the last few months. I know several people have messaged me and I am only now just responding. I am hoping to be more involved in the community moving forward so I hope those that were interested in my work here will keep posting and messaging me. I have thought a lot recently about what I would like to see from a mod and how the main reason I started writing all of these scripts is so I could create the mod that I have always wanted. I think that is closer than ever now, but unfortunately there are still several things that are missing from a scripting stand point before I would feel comfortable releasing a mod of my own. That being said I feel like over the course of the next month I will have a fairly decent chunk of time to put towards coding and I hope that I will be able to push the rest of my planned DFHack scripts and systems through so that I will finally be able to show case the power of these scripts.

I won't lie, the fact that very few people, if any, use these scripts I write has made it difficult to continue working, but I know that that is largely my fault in making the whole system more complicated and harder to understand. I am hoping that in the next month or so I will be able to tie everything together and show the community the power of the things I have envisioned. Again, sorry for my absence, and I hope I can make it up to you all in the coming weeks!

[Meph]

I won't lie, the fact that very few people, if any, use these scripts I write has made it difficult to continue working, but I know that that is largely my fault in making the whole system more complicated and harder to understand.

Its not a fault to be a perfectionist.

It would help a lot of you make small examples and release them as small mods, to show what people can do. The scripts are of course arcane if no one has used them yet.

I'd certainly still be interested... there are more races to be made with unique playstyles.

[Putnam]

I use the class system in Fortbent, and that's hopefully going to be the most extreme use case around (or else I'd feel real bad for whoever outdoes me), so that's an example of what it can do.

[Roses]

The first pass as the wrapper script is now up. Hopefully it is more streamlined and easier to use. Below you will find a brief walkthrough. I will be creating a more in depth one soon that will include all of the options and what they do.

The wrapper script is, as it sounds, a script that wraps around your other scripts in order to provide much more complex options than can currently be found in game. The reason for it's development is two fold;
1. It allows any script writer to provide complex targeting options for their scripts without the need to write all of the code themselves.
2. It allows modders to create more meaningful interactions with custom targeting options and unit based outcomes.

The way the script works is as follows;
Starting with a standard script which adds 500 skill experience to the masonry skill to unit 0

Code: [Select]

modtools/skill-change -skill MASONRY -mode add -granularity experience -unit 0 -value 500
We can then place this script inside of the wrapper script, at the very basic level you will have

Code: [Select]

wrapper -sourceUnit 0 -checkUnit -script [ modtools/skill-change -skill MASONRY -mode add -granularity experience -unit SOURCE_UNIT_ID -value 500 ]
As it stands this gives us no extra advantages, however we can now begin adding in the options. The full list of targeting options are as follows

Code: [Select]

'requiredClass',
 'requiredCreature',
 'requiredSyndrome',
 'requiredToken',
 'requiredNoble',
 'requiredProfession',
 'requiredEntity',
 'immuneClass',
 'immuneCreature',
 'immuneSyndrome',
 'immuneToken',
 'immuneNoble',
 'immuneProfession',
 'immuneEntity',
 'maxAttribute',
 'minAttribute',
 'gtAttribute',
 'ltAttribute',
 'maxSkill',
 'minSkill',
 'gtSkill',
 'ltSkill',
 'maxTrait',
 'minTrait',
 'gtTrait',
 'ltTrait',
 'maxAge',
 'minAge',
 'gtAge',
 'ltAge',
 'maxSpeed',
 'minSpeed',
 'gtSpeed',
 'ltSpeed',
So if you wanted your script to only add experience to the unit if they were between masonry levels 1 and 5 you could add

Code: [Select]

wrapper -sourceUnit 0 -checkUnit -minSkill MASONRY:1 -maxSkill MASONRY:5 -script [ modtools/skill-change -skill MASONRY -mode add -granularity experience -unit SOURCE_UNIT_ID -value 500 ]
You can add as many or as few of the targeting options as you want into a single wrapper. But you aren't just limited for checking a single unit. Say you wanted to add the experience to all of your units within a given distance of the source unit

Code: [Select]

wrapper -sourceUnit 0 -checkUnit -radius [ 10 10 2 ] -script [ modtools/skill-change -skill MASONRY -mode add -granularity experience -unit SOURCE_UNIT_ID -value 500 ]
Only 5 units in the radius?

Code: [Select]

wrapper -sourceUnit 0 -checkUnit -radius [ 10 10 2 ] -maxTargets 5 -script [ modtools/skill-change -skill MASONRY -mode add -granularity experience -unit SOURCE_UNIT_ID -value 500 ]
Only friendly units in the radius?

Code: [Select]

wrapper -sourceUnit 0 -checkUnit Friendly -radius [ 10 10 2 ] -script [ modtools/skill-change -skill MASONRY -mode add -granularity experience -unit SOURCE_UNIT_ID -value 500 ]
In addition to the many many different targeting options you can come up with, you can also alter the actual scripts being run. For example, say you wanted to add masonry experience to a unit, but you wanted to do it based on how much strength that unit has? It's simple!

Code: [Select]

wrapper -sourceUnit 0 -checkUnit -value [ source.attribute.strength ] -script [ modtools/skill-change -skill MASONRY -mode add -granularity experience -unit SOURCE_UNIT_ID -value VALUE_1 ]
Average of their strength and toughness?

Code: [Select]

wrapper -sourceUnit 0 -checkUnit -value [ (source.attribute.strength+source.attribute.toughness)/2 ] -script [ modtools/skill-change -skill MASONRY -mode add -granularity experience -unit SOURCE_UNIT_ID -value VALUE_1 ]
And so on, and so on...

Now, because of the large number of different options I am sure you are bound to find some problems, whether it be that it's not doing anything or it's crashing. There is the option to add -verbose into your wrapper script, this will give you a little bit more information on what is going on.

Lastly, if you look at the script you will see several options that I haven't touched on here. For now consider those options not working (most of them are, but there are still some bugs). Currently the wrapper script only supports checking for units and their relations to other units. The next step will be checking locations, items, projectiles, and more. With these additional checks you will be able to;
1. Have a script that only targets tiles with trees around a unit
2. Have a script that only targets items, or weapons, or silver weapons, or silver short swords
3. Have a script to target corpses
4. Have a script to target projectiles
etc...

Any questions please let me know. And if the targeting options aren't working please let me know that as well. I did test nearly all of them in the arena.