Print

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

[expwnent]

Are you still having problems with the unit death event? I was reading back and you said it was missing some. I haven't touched it in a long time so it's probably still broken but it might have magically fixed itself with some DF change. edit: It's a pretty cheap test so you can probably afford to check it every frame without slowing FPS too much.

I haven't checked in awhile, but I am not sure if it's that it isn't triggering, or that the last attacker doesn't include death by bleeding or something. I should do some more thorough tests to see the efficiency.

The event checker looked right to me when I looked at it. I hope it's right because if it's not I have no idea what's wrong.

Chaining: Suppose you want to shoot a magic bolt that splits at the target and bounces around. A spell that immediately bounces around seems fairly straightforward but if you need the bolt to actually hit the target in order to bounce you might have to use item-trigger or projectile-trigger in a tricky way. It's a weird case. I don't actually need it so if it's not possible don't worry about it.

That is a good idea, right now chaining just works by replicating the spell and messing with the source and target id's. It would be cool if it relied on actually hitting the first target. I would have to think of a clever way to handle that. I think it would involve projectile-trigger and some trickyness, but I think it could be done.

It's an interesting puzzle. I'd register a callback for that type of material hitting a target. Check whether the item is the specific one that matters, and if so, do some sort of "proxy recasting" where the original caster recasts the spell but from the location of the target toward some new target. Decrement some variable to make sure it doesn't last forever of course. Something like that should work. Could even support bounded exponential growth, hehe. You'd have to be careful not to 'leak' memory by having one-use callbacks on item-trigger or projectile-trigger that you really only want once because they'd get called forever until you exit the game even if they don't do anything.

Come to think of it, I don't think there's currently a way to UNregister anything in any of the *-trigger scripts. It's not a problem for 90% of the cases because the number of triggers is constant but in order to support something like this it should allow it. I'm not sure what the right answer is. I think the best way would be to allow the script you call a way of returning a value to the caller indicating whether or not you want to unregister. By default it would stay registered but if you have a lot of dynamically registering things it'd be better this way.

But then again, everything that fits in the category of "instance of this particular spell that I want to bounce around a few times" could fit in one giant callback and then there wouldn't be a problem. I guess in this case we still don't need it. Maybe there is a case where we do need it. I'm not sure.

There was a createitem script which overlaps with modtools/create-item. I think the only difference was yours includes an optional duration.

Yes, that is basically the only difference between the two, it might be worth it to just include the optional duration in the modtools version, and then I can scrap my version.

That sounds good.

I was having difficulties with the . convention. Sometimes it would work fine, othertimes it would not. Is that because for something like asdf.end, end is a special function in lua, and so it gets upset?

You only have to use it when you're using Lua keywords as table elements. Otherwise it's fine.

Yes, they are all three very similar, propel works just on units, falling is just items falling from the sky, and projectile is items moving from one x,y,z to another. The reason they are three separate scripts now is because they started as three separate spells that I expanded on (cyclone, blizzard, and multi-shot respectively). Falling and projectile could easily be combined, it might be nice to keep propel separate though so people know that one is for items and one is for units.

I like your idea of having the item one work on pre-existing items, and simply creating items if need be. That simplifies the code greatly, and allows for using actual ammunition on a unit to perform a special shot. I will look into it.

propel-unit and propel-item seem reasonable with lots of options for each. Falling is more or less the same as projectile, right?

I don't know why I never tried that, its much simpler. Is there any drawback to using the createCallback though?

Not really. From a design perspective if you only do something once it's better to just manually inline it than to make a subroutine that does it. You also did some weirdness like

Code: [Select]

function callback(arg1,arg2)
 return function(notActuallyUsed) return foo(arg1,arg2) end
end

The dfhack.timeout callback doesn't set any arguments when it calls so it'll just always be null there.

On a side note, add-syndrome is currently able to remove a syndrome based on the SYN_NAME, would it be possible to have to remove syndromes based on SYN_CLASS too? That way you could remove multiple syndromes all with different names, with the same command.

That seems reasonable.

That would be very awesome if you could do that, also because it would allow me to store the different text files that the classes and civilization scripts use in a persistent table, which would mean they wouldn't have to be read each time you want to do an action with them.

Rough Draft. Way harder to write than it looks.

I mainly work with with targeted interactions, even my interactions that are self targeted use the USAGE_HINT:ATTACK so that the combat log isn't spammed with Urist McDwarf casts Stone Skin when he is off growing plants, and is only triggered in combat. With the wrapper script this is as easy as changing !TARGET to !SOURCE. I suppose I could see it being useful to have the ability for interaction-trigger to work on a no-target system, it would definitely be useful for a multi-target system, although the wrapper script can also handle that too.

I just rewrote the whole thing in a much cleaner way but it's about the same level of functionality (except now I'm sure it works). It may or may not work correctly on self interactions. I couldn't come up with a good clean test case for that.

[Roses]

Chaining: Suppose you want to shoot a magic bolt that splits at the target and bounces around. A spell that immediately bounces around seems fairly straightforward but if you need the bolt to actually hit the target in order to bounce you might have to use item-trigger or projectile-trigger in a tricky way. It's a weird case. I don't actually need it so if it's not possible don't worry about it.

That is a good idea, right now chaining just works by replicating the spell and messing with the source and target id's. It would be cool if it relied on actually hitting the first target. I would have to think of a clever way to handle that. I think it would involve projectile-trigger and some trickyness, but I think it could be done.

It's an interesting puzzle. I'd register a callback for that type of material hitting a target. Check whether the item is the specific one that matters, and if so, do some sort of "proxy recasting" where the original caster recasts the spell but from the location of the target toward some new target. Decrement some variable to make sure it doesn't last forever of course. Something like that should work. Could even support bounded exponential growth, hehe. You'd have to be careful not to 'leak' memory by having one-use callbacks on item-trigger or projectile-trigger that you really only want once because they'd get called forever until you exit the game even if they don't do anything.

Come to think of it, I don't think there's currently a way to UNregister anything in any of the *-trigger scripts. It's not a problem for 90% of the cases because the number of triggers is constant but in order to support something like this it should allow it. I'm not sure what the right answer is. I think the best way would be to allow the script you call a way of returning a value to the caller indicating whether or not you want to unregister. By default it would stay registered but if you have a lot of dynamically registering things it'd be better this way.

But then again, everything that fits in the category of "instance of this particular spell that I want to bounce around a few times" could fit in one giant callback and then there wouldn't be a problem. I guess in this case we still don't need it. Maybe there is a case where we do need it. I'm not sure.

Hmm, I'm not sure if there would be a case where it would be necessary. Although it would probably be much more elegant than I giant callback.

I was having difficulties with the . convention. Sometimes it would work fine, othertimes it would not. Is that because for something like asdf.end, end is a special function in lua, and so it gets upset?

You only have to use it when you're using Lua keywords as table elements. Otherwise it's fine.

That would explain it. I'll make sure to take note of that.

Yes, they are all three very similar, propel works just on units, falling is just items falling from the sky, and projectile is items moving from one x,y,z to another. The reason they are three separate scripts now is because they started as three separate spells that I expanded on (cyclone, blizzard, and multi-shot respectively). Falling and projectile could easily be combined, it might be nice to keep propel separate though so people know that one is for items and one is for units.

I like your idea of having the item one work on pre-existing items, and simply creating items if need be. That simplifies the code greatly, and allows for using actual ammunition on a unit to perform a special shot. I will look into it.

propel-unit and propel-item seem reasonable with lots of options for each. Falling is more or less the same as projectile, right?

Yeah, the only difference is that there are different flags that need to be set depending on if an item is in free fall or was fired/thrown as a projectile. But they can still easily be in the same script.

I don't know why I never tried that, its much simpler. Is there any drawback to using the createCallback though?

Not really. From a design perspective if you only do something once it's better to just manually inline it than to make a subroutine that does it. You also did some weirdness like

Code: [Select]

function callback(arg1,arg2)
 return function(notActuallyUsed) return foo(arg1,arg2) end
end

The dfhack.timeout callback doesn't set any arguments when it calls so it'll just always be null there.

That is that way because the call back function required it to be, something about needing a function without any arguments or something. Not really sure, but it was a rather poor work around that I just googled.

I mainly work with with targeted interactions, even my interactions that are self targeted use the USAGE_HINT:ATTACK so that the combat log isn't spammed with Urist McDwarf casts Stone Skin when he is off growing plants, and is only triggered in combat. With the wrapper script this is as easy as changing !TARGET to !SOURCE. I suppose I could see it being useful to have the ability for interaction-trigger to work on a no-target system, it would definitely be useful for a multi-target system, although the wrapper script can also handle that too.

I just rewrote the whole thing in a much cleaner way but it's about the same level of functionality (except now I'm sure it works). It may or may not work correctly on self interactions. I couldn't come up with a good clean test case for that.

Awesome, I will hopefully have some extra time soon to finish up a couple of the things on my to-do list and start testing things out.

[Roses]

So I am back to work on the unit viewer this week. I have started with the detailed syndrome viewer portion. Below is what I have so far

Spoiler (click to show/hide)

Green means that that time has passed, red means it is still coming.

The question is, what do people think is the best way to portray this information? Instead of red/green should I just subtract the value so you can see how many ticks are left? Should I get rid of ticks and use minutes/hours? Should there be more information? Any thoughts or suggestions would be very nice to have.

[hanspeter]

Seeing syndromes in numbers by default feels a little cheat-y, I think it would be better to make it optional.

Maybe use red and green - / + as percentage of time until end.

At the beginning: /----------
After 20 percent of duration: ++/--------
After 80 percent of duration: ++++++++/--

[Roses]

Civilizations and You!

Today I will be talking about the Civilization system (Note: Everything talked about here-in is for NPC entities, not your fort)

Have you ever thought to yourself, "Man, these goblins are just no challenge no that I have my full steel clad army", or "I wish the game could change while I play"? If so, then this is for you!

The Civilization system allows you to customize the advancement of any entity you would like, and have them advance during game play!
Types of advancement include:

• Add/Remove Available Inorganics (Metals/Stones/Gems)
• Add/Remove Available Organics (Leather/Wood/Cloth/Silk/Plants)
• Add/Remove Available Creatures (Pets/Minions/Pack Animals/Mounts/Wagon Pullers)
• Add/Remove Available Items (Weapons/Armor/Toys/Tools/etc...)
• Add/Remove Available Refuse (Bones/Shell/Ivory/Pearl/Horn)
• Add/Remove Noble Positions (DO NOT REMOVE THEM! IT WILL CAUSE THE GAME TO CRASH)

All of these will effect the the various stuff that an entity would bring for trade AND for attacks. You can even add Adamantine and other SPECIAL materials, so be careful!

Advancement is handled separately for each instance of an entity. That means that if you have 3 different Human entities placed, each one will be treated as it's own unique Civilization, but they will all follow the same advancement system.
Methods of advancement include:

• Time Based (Daily/Weekly/Monthly/Seasonly/Yearly) - as a probability of triggering at each selected timescale
• Kill Based - triggers when they kill a certain number of your units
• Invasion Based - triggers after they commit a certain number of invasions with your fort
• Trade Based - triggers after they commit a certain number of trades with your fort
• Counter Based - for the advanced users that use my counters script

All of the non-Time Based methods check for advancement at the start of every new season. Advancements can occur as many times as you would like. Each Civilization "level" counts as one advancement.

All of this means that you can have a lot of customization in your game! So let's start by going over what you will need.

• Dwarf Fortress
• DFHack
• My Script Collection

The files in my script collection that are related to the Civilization System:

• hack/lua/civilizations/establish-civ.lua
• hack/lua/civilizations/read-file.lua
• hack/scripts/civilizations/level-up.lua
• hack/scripts/civilizations/noble-change.lua
• hack/scripts/civilizations/resource-change.lua
• hack/scripts/base/civilizations.lua
• raw/objects/civilizations.txt

So now that we know what it does, and we know what we need. How do we get started? Well for virtually everything you want to do, the only file you will need to modify is the civilization.txt file.

So let's take a look at civilization.txt

Code: [Select]

[CIV:PLAINS]
#Base Tokens
[NAME:humans from the north]
[LEVELS:1]
[LEVEL_METHOD:YEARLY:100]
#Level Tokens
[LEVEL:0]
 [LEVEL_NAME:started in the stone age]
#Resource Tokens
## Creature Tokens
 [LEVEL_REMOVE:CREATURE:PET:ALL:ALL]
 [LEVEL_REMOVE:CREATURE:WAGON:ALL:ALL]
 [LEVEL_REMOVE:CREATURE:MOUNT:ALL:ALL]
 [LEVEL_REMOVE:CREATURE:PACK:ALL:ALL]
 [LEVEL_REMOVE:CREATURE:MINION:ALL:ALL]
 [LEVEL_REMOVE:CREATURE:EXOTIC:ALL:ALL]
 [LEVEL_REMOVE:CREATURE:FISH:ALL:ALL]
 [LEVEL_REMOVE:CREATURE:EGG:ALL:ALL]
## Item Tokens
 [LEVEL_REMOVE:ITEM:WEAPON:ALL]
 [LEVEL_REMOVE:ITEM:SHIELD:ALL]
 [LEVEL_REMOVE:ITEM:AMMO:ALL]
 [LEVEL_REMOVE:ITEM:HELM:ALL]
 [LEVEL_REMOVE:ITEM:ARMOR:ALL]
 [LEVEL_REMOVE:ITEM:PANTS:ALL]
 [LEVEL_REMOVE:ITEM:SHOES:ALL]
 [LEVEL_REMOVE:ITEM:GLOVES:ALL]
 [LEVEL_REMOVE:ITEM:TRAP:ALL]
 [LEVEL_REMOVE:ITEM:SIEGE:ALL]
 [LEVEL_REMOVE:ITEM:TOY:ALL]
 [LEVEL_REMOVE:ITEM:INSTRUMENT:ALL]
 [LEVEL_REMOVE:ITEM:TOOL:ALL]
## Inorganic Tokens
 [LEVEL_REMOVE:INORGANIC:METAL:ALL]
 [LEVEL_REMOVE:INORGANIC:STONE:ALL]
 [LEVEL_REMOVE:INORGANIC:GEM:ALL]
## Organic Tokens
 [LEVEL_REMOVE:ORGANIC:LEATHER:ALL:ALL]
 [LEVEL_REMOVE:ORGANIC:FIBER:ALL:ALL]
 [LEVEL_REMOVE:ORGANIC:SILK:ALL:ALL]
 [LEVEL_REMOVE:ORGANIC:WOOL:ALL:ALL]
 [LEVEL_REMOVE:ORGANIC:WOOD:ALL:ALL]
 [LEVEL_REMOVE:ORGANIC:PLANT:ALL:ALL]
 [LEVEL_REMOVE:ORGANIC:SEED:ALL:ALL]
## Refuse Tokens
 [LEVEL_REMOVE:REFUSE:BONE:ALL:ALL]
 [LEVEL_REMOVE:REFUSE:SHELL:ALL:ALL]
 [LEVEL_REMOVE:REFUSE:PEARL:ALL:ALL]
 [LEVEL_REMOVE:REFUSE:IVORY:ALL:ALL]
 [LEVEL_REMOVE:REFUSE:HORN:ALL:ALL]
## Misc Tokens
 [LEVEL_REMOVE:MISC:BOOZE:ALL:ALL]
 [LEVEL_REMOVE:MISC:CHEESE:ALL:ALL]
 [LEVEL_REMOVE:MISC:POWDER:ALL:ALL]
 [LEVEL_REMOVE:MISC:EXTRACT:ALL:ALL]
 [LEVEL_REMOVE:MISC:MEAT:ALL:ALL]
 [LEVEL_REMOVE:MISC:GLASS:ALL:ALL]
# Expanded Level Tokens
[LEVEL:1]
 [LEVEL_NAME:entered the copper age]
 [LEVEL_CHANGE_METHOD:YEARLY:50]
# Noble Tokens
 [LEVEL_ADD_POSITION:MONARCH2]
[NAME_MALE:great king:great kings]
[NAME_FEMALE:great queen:great queens]
[NUMBER:1]
[SPOUSE_MALE:great king consort:great kings consort]
[SPOUSE_FEMALE:great queen consort:great queens consort]
[SUCCESSION:BY_HEIR]
[RESPONSIBILITY:LAW_MAKING]
[RESPONSIBILITY:RECEIVE_DIPLOMATS]
[RESPONSIBILITY:MILITARY_GOALS]
[PRECEDENCE:1]
[SPECIAL_BURIAL]
[RULES_FROM_LOCATION]
[MENIAL_WORK_EXEMPTION]
[MENIAL_WORK_EXEMPTION_SPOUSE]
[SLEEP_PRETENSION]
[PUNISHMENT_EXEMPTION]
[FLASHES]
[BRAG_ON_KILL]
[CHAT_WORTHY]
[DO_NOT_CULL]
[KILL_QUEST]
[EXPORTED_IN_LEGENDS]
[DETERMINES_COIN_DESIGN]
[COLOR:5:0:1]
[ACCOUNT_EXEMPT]
[DUTY_BOUND]
[DEMAND_MAX:20]
[MANDATE_MAX:10]
[REQUIRED_BOXES:20]
[REQUIRED_CABINETS:10]
[REQUIRED_RACKS:10]
[REQUIRED_STANDS:10]
[REQUIRED_OFFICE:20000]
[REQUIRED_BEDROOM:20000]
[REQUIRED_DINING:20000]
[REQUIRED_TOMB:20000]That includes all of the currently supported tokens for each civilization. Note that the X in [CIV:X] must be the same as the entity you are interested in modifying (i.e. PLAINS in Vanilla DF is Humans) Let's talk about what they do.

Base Tokens
These tokens are mandatory for each civilization and should only occur once.

• [NAME] - What the civilization is called, not currently used for anything. This will make an appearance in the upcoming Journal project
• [LEVELS] - Number of levels that your civilization has
• [LEVEL_METHOD] - The method for leveling that the civilization starts with. Valid entries include:
  • DAILY/WEEKLY/MONTHLY/SEASON/YEARLY - The number then specifies the probability for it to occur at each timestep
  • KILLS - The number is the number of kills needed
  • INVASION - The number is the number of invasions needed
  • TRADE - The number is the number of trades needed
  • COUNTER:X, where X is the name of the counter to check - The number is the number of the counter needed

Level Tokens:
These are the tokens that defined each level

• [LEVEL] - The start of the level declaration, the number specifies the level
• [LEVEL_NAME] - The name of the level, currently appears in an in-game announcment, "Entity 1 has X", where X is the entered text
• [LEVEL_CHANGE_METHOD] - This allows the method of leveling to change as the civilization advances, valid tokens are the same as [LEVEL_METHOD]

Resource Tokens
These are the tokens that will handle all of the adding and removing of availability to specific things. The basic syntax is [LEVEL_ADD] and [LEVEL_REMOVE]. I will split these into their various sub-types
-Creature Tokens
To add/remove creatures we start with the basic syntax [LEVEL_ADD]/[LEVEL_REMOVE] and add to it.

• [LEVEL_ADD:CREATURE:type] - valid types include
  • PET:creature:caste - adds creature to the available pets of an entity
  • WAGON:creature:caste - adds creature to the available wagon pullers of an entity
  • MOUNT:creature:caste - adds creature to the available mounts of an entity
  • PACK:creature:caste - adds creature to the available pack animals of an entity
  • MINION:creature:caste - adds creature to the available minions of an entity
  • EXOTIC:creature:caste - adds creature to the available exotic pets of an entity
  • FISH:creature:caste - adds creature to the available fish of an entity
  • EGG:creature:caste - adds creature to the available egg producers of an entity
• [LEVEL_REMOVE:CREATURE] - all of the same tokens as for [LEVEL_ADD] are valid for [LEVEL_REMOVE]

There is the special token ALL for both creature and class. For example creature:ALL would add all the castes of a particular creature, ALL:caste would add the caste of all the creatures in game, and ALL:ALL would add all the creatures and all their castes.

Item Tokens
To add/remove items you follow a similar method to the creatures. Start with [LEVEL_ADD]/[LEVEL_REMOVE] and add to it

• [LEVEL_ADD:ITEM:type:subtype] - valid types include
  • WEAPON
  • SHIELD
  • AMMO
  • HELM
  • ARMOR
  • PANTS
  • SHOES
  • GLOVES
  • TRAP
  • SIEGE
  • TOY
  • INSTRUMENT
  • TOOL
• [LEVEL_REMOVE:ITEM:type:subtype] - the same as available for [LEVEL_ADD:ITEM]

There is a special token ALL for the subtype. WEAPON:ALL will add all weapons to a given entity

Inorganic Tokens
To add/remove inorganic materials you follow a similar method to the creatures. Start with [LEVEL_ADD]/[LEVEL_REMOVE] and add to it

• [LEVEL_ADD:INORGANIC:type:subtype] - valid types include
  • METAL
  • STONE
  • GEM
• [LEVEL_REMOVE:INORGANIC:type:subtype] - the same as available for [LEVEL_ADD:INORGANIC]

There is a special token ALL for the subtype. METAL:ALL will add all inorganics with the tag [IS_METAL] to the entity

Organic Tokens
To add/remove organic materials you follow a similar method to the creatures. Start with [LEVEL_ADD]/[LEVEL_REMOVE] and add to it

• [LEVEL_ADD:ORGANIC:type] - valid types include
  • LEATHER:creature:material
  • FIBER:plant:material
  • SILK:creature:material
  • WOOL:creature:material
  • WOOD:plant:material
  • PLANT:plant:material
  • SEED:plant:material
• [LEVEL_REMOVE:ORGANIC:type] - the same as available for [LEVEL_ADD:ORGANIC]

Organic tokens work a little differently than the other tokens. Some come from creatures and some come from plants. The first token (creature/plant) will either be something like SHEEP if it is a creature or MUSHROOM_HELMET_PLUMP if it is a plant. The second token (material) is the name you have given to the material in the raw. For vanilla it is just things like LEATHER, SEED, SILK, etc... but it doesn't have to be. You might have a mod that has TOUGH_LEATHER as the defined material.

There is a special token ALL:ALL for the creature:material pair. LEATHER:ALL:ALL will add all organics with the tag [LEATHER] to the entity

Refuse Tokens
Refuse tokens function the same as organic tokens, just with different types.

• [LEVEL_ADD:REFUSE:type] - valid types include
  • BONE:creature:material
  • HORN:creature:material
  • SHELL:creature:material
  • PEARL:creature:material
  • IVORY:creature:material
• [LEVEL_REMOVE:REFUSE:type] - the same as available for [LEVEL_ADD:REFUSE]

Refuse tokens work just like organic tokens, but take different materials (and all come from creatures).

There is a special token ALL:ALL for the creature:material pair. BONE:ALL:ALL will add all materials with the tag [BONE] to the entity.

Misc Tokens
Misc tokens work just like organic and refuse tokens

• [LEVEL_ADD:MISC:type] - valid types include
  • CHEESE:creature:material
  • BOOZE:plant:material
  • POWDER:creature:material
  • EXTRACT:creature:material
  • MEAT:creature:material
• [LEVEL_REMOVE:ORGANIC:type] - the same as available for [LEVEL_ADD:MISC]

Misc tokens are tricky because they don't always have to be from one source. But the same premise applies no matter where they are from.

Noble Tokens
Adding nobles requires a little bit more work than adding resources, but is just as straightforward as in the raws. To add a noble all you need to do is place
[LEVEL_ADD_POSITION:X], where X is some name you choose (e.g. MONARCH). Then everything after that, until a new [LEVEL_ADD_POSITION:X], or a non-position raws token will be attributed to the position. In our example above,

Code: [Select]

[LEVEL_ADD_POSITION:MONARCH2]
[NAME_MALE:great king:great kings]
[NAME_FEMALE:great queen:great queens]
[NUMBER:1]
[SPOUSE_MALE:great king consort:great kings consort]
[SPOUSE_FEMALE:great queen consort:great queens consort]
[SUCCESSION:BY_HEIR]
[RESPONSIBILITY:LAW_MAKING]
[RESPONSIBILITY:RECEIVE_DIPLOMATS]
[RESPONSIBILITY:MILITARY_GOALS]
[PRECEDENCE:1]
[SPECIAL_BURIAL]
[RULES_FROM_LOCATION]
[MENIAL_WORK_EXEMPTION]
[MENIAL_WORK_EXEMPTION_SPOUSE]
[SLEEP_PRETENSION]
[PUNISHMENT_EXEMPTION]
[FLASHES]
[BRAG_ON_KILL]
[CHAT_WORTHY]
[DO_NOT_CULL]
[KILL_QUEST]
[EXPORTED_IN_LEGENDS]
[DETERMINES_COIN_DESIGN]
[COLOR:5:0:1]
[ACCOUNT_EXEMPT]
[DUTY_BOUND]
[DEMAND_MAX:20]
[MANDATE_MAX:10]
[REQUIRED_BOXES:20]
[REQUIRED_CABINETS:10]
[REQUIRED_RACKS:10]
[REQUIRED_STANDS:10]
[REQUIRED_OFFICE:20000]
[REQUIRED_BEDROOM:20000]
[REQUIRED_DINING:20000]
[REQUIRED_TOMB:20000]I just copied the MOUNTAIN entities MONARCH and made one that requires more things. Simple enough.

And there you have it, that is all that is needed to start making your game evolve and change while you play! Please post your custom civilizations here so that others can see all the fun things you can do!

Addendum 1: Custom Levels
You can custom level a civilization through a reaction/interaction/command line by using

Code: [Select]

civilizations/level-up CIV_IDThe counters system also allows for a much more rigorous custom leveling structure. Especially when combined with [LEVEL_CHANGE_METHOD].

[Roses]

Figured it was about time to write a Civilizations System tutorial. You can find it above this post, and I will link to it on the main page. Please ask any questions or give any feedback you might have so I can make it more clear and easy to understand.

Seeing syndromes in numbers by default feels a little cheat-y, I think it would be better to make it optional.

Maybe use red and green - / + as percentage of time until end.

At the beginning: /----------
After 20 percent of duration: ++/--------
After 80 percent of duration: ++++++++/--

That is a possibility. Right now the first screen just shows what syndromes you have and doesn't give any information about the syndromes themselves. To see this screen you have to hit shift-S.

[expwnent]

Interesting. That has a lot of potential.

[Putnam]

If I have class A that autoupgrades into class B and class A has:

BONUS_PHYS:AGILITY:1000
BONUS_SKILL:SITUATIONAL_AWARENESS:2

and class B has:

BONUS_PHYS:AGILITY:2000
BONUS_SKILL:SITUATIONAL_AWARENESS:3

Would the upgraded unit have 3000 bonus agility or 2000? Similarly, would they have 3 bonus observation or 5?

[Roses]

The upgraded unit would have 2000 bonus agility and 3 bonus observation. I went back and forth on that a lot, but I decided that I wanted to make it so that if you changed classes you would lose the benefit of the first class and gain the benefit of the second class. Similarly, the levels are not additive. If you have 1000:2000:3000 for a 2 Level class, at level 0 you have a bonus of 1000, at level 1 you have a bonus of 2000, and at level 2 you have a bonus of 3000 (i.e. not 1000, 3000, 6000).

While on the topic of the class system, two quick things:

1. I changed spells slightly so that you can now automatically learn them at each level. This is done by taking out the AUTO from where the level would normally go, and placing an extra optional tag [SPELL_AUTO_LEARN] in the spell. This means that you can have a creature with say, 10 levels, and at each level it could automatically learn a spell. Costs and requirements are still in effect (if you have them) so the creature may fail to learn the spell at the point of level up, but you can manually teach them the spell just like normal later. I have left in the option for keeping it how it is now, so that there is backwards compatibility.

2. I have added a [REQUIRED_CREATURE] tag as an option, which functions like [REQUIRED_CREATURE:creature:caste] and [SPELL_REQUIRED_CREATURE:creature:caste]. With ALL as a special argument for both creature and caste (e.g. ALL:MALE, DWARF:ALL).

Concerning the wrapper script, I have a couple updates there as well

1. I have overhauled the -value argument, you can now input equations instead of singular values! It works by inputting

Code: [Select]

-value "1200*self:willpower/target:willpower-target:toughness/10" This basically says exactly what you would think it would say. This allows for much more detailed work with strengths and weaknesses applied to each attribute.

2. To go along with that overhaul I am looking at ways to have multiple values, so that if you want to change the number for multiple things in a script, you are able to. I just need to find a classy way to go about it.

3. I have added a sort of, reverse silence tag. Currently the silence tag works by checking the source unit for syndrome classes, and if it finds one then it tells the script not to run because they are "silenced". The new tag (which I still need a proper name for) does the opposite, it checks for a syndrome class and if it DOESN'T find it, then it tells the script not to run.

These updates should be out sometime "soon". As always keep up the comments and suggestions. They really help me figure out what everyone else would like.

[Putnam]

The upgraded unit would have 2000 bonus agility and 3 bonus observation. I went back and forth on that a lot, but I decided that I wanted to make it so that if you changed classes you would lose the benefit of the first class and gain the benefit of the second class. Similarly, the levels are not additive. If you have 1000:2000:3000 for a 2 Level class, at level 0 you have a bonus of 1000, at level 1 you have a bonus of 2000, and at level 2 you have a bonus of 3000 (i.e. not 1000, 3000, 6000).

Does this apply for spells as well? If I have class A that autoupgrades into class B, and A has an AUTO spell, will it be lost when it upgrades to B?

[Roses]

The upgraded unit would have 2000 bonus agility and 3 bonus observation. I went back and forth on that a lot, but I decided that I wanted to make it so that if you changed classes you would lose the benefit of the first class and gain the benefit of the second class. Similarly, the levels are not additive. If you have 1000:2000:3000 for a 2 Level class, at level 0 you have a bonus of 1000, at level 1 you have a bonus of 2000, and at level 2 you have a bonus of 3000 (i.e. not 1000, 3000, 6000).

Does this apply for spells as well? If I have class A that autoupgrades into class B, and A has an AUTO spell, will it be lost when it upgrades to B?

Nope, spells are currently unique. There is no current easy way to unlearn a spell (except for the instance where a spell is marked as an upgrade to another spell). I will most likely add an ability to unlearn spells based on class at a later time, but that will be an addition, not a change of the core functionality. For now, spells are kept along classes, unless removed externally through modtools/add-syndrome -remove

EDIT: And that is why you don't try to respond on your phone. Fixed spelling mistakes.

[Putnam]

Good, heh. I've been relying on that. Course, it wouldn't be too hard of an edit--only 120 things at the very most I need to edit, which isn't at all the worst I've had to deal with (I.E friggin 144 UNIQUE things consistently GOD never again and if I had to rework how the transformation worked that would be 2160 holy shit)

[Putnam]

Anyway, is there a reason for every single variable in your code being global?

(struggling to find out exactly how your scripts check a unit's classes--looks like persistent storage, but the variable names are throwing me off)

EDIT: It's by class number? Oh...

Also, i,x? usually k,v is used.

EDIT 2: Wait, no, it's with a persistent configuration at unit_id..'_current_class'? The "curpers" thing confused me.

[expwnent]

Thoughts: global variables are secretly just global for each script. Scripts cannot share variables (that would be a nightmare to organize). In general functions should contain local variables. If you need something to persist across multiple calls of a script that's what globals are for.

[Roses]

Anyway, is there a reason for every single variable in your code being global?

(struggling to find out exactly how your scripts check a unit's classes--looks like persistent storage, but the variable names are throwing me off)

EDIT: It's by class number? Oh...

Also, i,x? usually k,v is used.

EDIT 2: Wait, no, it's with a persistent configuration at unit_id..'_current_class'? The "curpers" thing confused me.

No, I should really change most of them to local variables. I was used to writing in a language where local is the default and you have to specify global. I always forget when I write that it's the other way around.

I prefer using i,x - j,y - k,z for my pair configurations, just a matter of preference I suppose.

Classes are stored in two ways. Both are persistent storage.
1. unit_id..'current_class' - this stores the information of what the current class is, how much experience you have obtained in the current class, total experience over all classes, and skill experience
2. unit_id..CLASS_NAME - this stores total experience and level for the specific class

curpers, pers, and nexpers are just referring to the persistent variable being checked at the moment.