Traits triggers modding

[Alkrinos]

Hello fellow modders!

I'm humbly asking for your help with some problems i have related to traits modding for Attila (or Rome, as the system is fairly the same).



Indeed i've already modified the traits triggers by editing the chances of occurrence in the trigger_effects table of the DB and it seems to work quite well.

Lately i've been trying to add some new triggers to gain a trait for characters, that when i discovered the export_triggers.lua script.

That's why i've been asking myself the following questions:

• Do the values of trigger_effects table overwrite the ones defined in the lua script ? If so, how does it work? What happend if there is a conflict between the value defind in the script and the one defined in the db?

• What is the purpose of the id field of the trigger_effects table? Is it meant to link the db to the triggers defined in the script ?

• What are the correct steps to add a new trigger for a trait ? Do i have to simply define it in the lua script or should i add it to the trigger_effects table too? Is there any extra steps?

So far i've been unable to figure out the answers by myself, that's why i'm asking for some help.

Thank you for your futur answers

[SharpEyed]

hmm scripting, the place I should work on.
some time

Well I'll try my best to help.

1st, did you look here? http://www.twcenter.net/forums/showt...Game-Functions (I didn't read all of them sorry But I looked to the places you mentioned)

2nd, those id's not seem related with scripts at all.
Those are just put there to keep them in order, so they won't mess up with each other.
And ID's not only exist on that table, there are a lot places they appear.

3rd, well this is the hardest question.
But it seems like this: "If this happens, then this triggers" , if doesn't happen = it won't trigger.
Condition.

So if you add new trait/s to the db table of traits, I don't think you will have to add them into script as well.
But then they will have the chance to appear any time, without any condition.

[Alkrinos]

Hi SharpEyed,

thank you for your kind answer, sadly i don't think that you got what my problem really is.

hmm scripting, the place I should work on.

1st, did you look here? http://www.twcenter.net/forums/showt...Game-Functions (I didn't read all of them sorry But I looked to the places you mentioned)

I already found this topic, well the thing is: this has nothing to do with my questions. In fact these are resources to help you write new lua script, and i have no real problem with that.

2nd, those id's not seem related with scripts at all.
Those are just put there to keep them in order, so they won't mess up with each other.
And ID's not only exist on that table, there are a lot places they appear.

I think you missunderstood what i was talking about.
You are surely talking about PFM UI row numbers.
I, on the other hand, am talking about the id column which is quite rare, in fact even if i didn't checked all the DB tables i'm fairly sure this id column is pretty unique to trigger_effects.
Moreover i'd like to stress the fact that thess ids are not incrementals at all so i'm quite sure they are acting as foreign keys to associate the db to the script or something like that, but i could be wrong, maybe they are just useless or serve another purpose.

3rd, well this is the hardest question.
But it seems like this: "If this happens, then this triggers" , if doesn't happen = it won't trigger.
Condition.

Yes exactly.
The script export_triggers.lua is basicaly a lot of functions implementations that return a boolean depending on conditions, then it calls these functions with tests (if statements) to determine if the following events should trigger or not a trait point gain for example.
Well, again, i have not problem at all with that being myself a dev, the issue is not understanding or editing lua scripts.

So if you add new trait/s to the db table of traits, I don't think you will have to add them into script as well.
But then they will have the chance to appear any time, without any condition.

I don't think so because first it means that the function related to the trigger has to be defined in the script (which is not a problem if you are using a trigger that already exist like att_trig_faction_leader_age_old_player_only_not_horde
for instance ), 2nd if the event occurs you have to define in the function what will happend (like gaining x point in y trait with z% chance).
Well this is only speculative as maybe a new script can be generated by the game depending on the trigger_effects tablecontent , but i'm quite sure that's not the case.


Ok so now i'll try to be more clear and specific on what my problem really is:

Let's take for example the trait healthy (att_trait_all_physical_all_healthy)

One of the trigger to gain point in the trait healthy for you agent is to be in a region with low squalor.

So let's see how it looks in the db (trigger_effects table) :

3347 |

att_trig_agent_in_region_low_squalor |

att_trait_all_physical_all_healthy |

1 |

2 |

Which means that the trigger att_trig_agent_in_region_low_squalor has 2% of chance to increase the trait healthy by one point each turn the conditions are met.

Now let's take a look at the lua script and more precisely at the function related to this particular trigger:

--[[ att_trig_agent_in_region_low_squalor ]]--

function att_trig_agent_in_region_low_squalor_impl (context)
return char_is_agent(context:character()) and context:character():has_region() and context:character():region():squalor() < 30 and context:character():model():turn_number() > 5
end

events.CharacterTurnStart[#events.CharacterTurnStart+1] =
function (context)
if att_trig_agent_in_region_low_squalor_impl(context) then
effect.trait("att_trait_all_physical_all_healthy", "agent", 1, 2, context)
return true
end
return false
end

The first function ( att_trig_agent_in_region_low_squalor_impl ) check if the caracter has been in a region with less than 30 squalor for more than 5 turns and return true or false according to these factors.

The second one calls the previous during a test, each turn, and if it's true then call a method that has 2% chance to add 1 point to the healthy trait of your agent.

And here is my real problem:

effect.trait("att_trait_all_physical_all_healthy", "agent", 1, 2, context)

these values passed as parameters to the method trait (%=2 and number of point = 1) are hardcoded and i can't imagine how the values in the trigger_effects table are supposed to overwrite them.
If it used variables instead of hardcoded integers it would be totally clear but like this i just don't get how this is supposed to interact.. That's why i was thinking the id column of the trigger_effects table plays a role in that.

Maybe i'm looking at it the wrong way but it completely screws my brain.

I know Hellbent and Dresden worked on something similar with Rome 2 (http://www.twcenter.net/forums/showt...DLC-Compatible) maybe they can enlighten me.

I'm sorry if i don't express myself clearly but as you could easily see: English is not my mother tongue..

I'd like to thank in advance all the people that will take the time to read my question and try to answer it.

[SharpEyed]

Hi SharpEyed,

thank you for your kind answer, sadly i don't think that you got what my problem really is.

Hello, well maybe or maybe not but I tried my best.

You are surely talking about PFM UI row numbers.

No, I'm not.

I, on the other hand, am talking about the id column which is quite rare, in fact even if i didn't checked all the DB tables i'm fairly sure this id column is pretty unique to trigger_effects.
Moreover i'd like to stress the fact that thess ids are not incrementals at all so i'm quite sure they are acting as foreign keys to associate the db to the script or something like that, but i could be wrong, maybe they are just useless or serve another purpose.

How they are not incremental? they start from 0 and goes up to 4 thousands.

And no they are not unique to trigger_effects table, but I just can't find other tables to show you now..
Thou "ministerial_positions_to_effects_tables" and "ministerial_positions_to_effects_tables" have "ui_id" one

Also "building_units_allowed_tables" has something called "key" , which is just a random number that doesnt effect anything at all, just dont get the same one. Would give you error anyway.

- - -

About the rest, well you got my head confused too :/
So I don't wanna say anything wrong, as I'm not a pro after all, hope some experienced modders help.
Then I would say, try to pm few of them by giving the link of this thread.

But till then, why not give a try yourself?
Add a new trait, and give a chance of %100, without touching the script file.
Then end the turn and see.

[OpusDei]

The lua script will be ovewrited (the programmers say this themselves in their own notes in the scripts about the entries). The triggers you created are ignored because they can not be compiled

DB records have to exist to be able to refer to in the lua scripts and startpos. Startpos also overwrites lua scripts btw.

Greetz
T.

[Alkrinos]

Thank you for your answer OpusDei. It really helps!

The lua script will be ovewrited (the programmers say this themselves in their own notes in the scripts about the entries).

Where did you find these notes, i can't find anything in the code comments beside really *professional* comments like "Automatically generated via export from old_tw_game", "Automatically generated via export from random_dev_workstation_path" and stuff like that. I'm very interested to learn more about it!

The triggers you created are ignored because they can not be compiled

I didn't mention anything about that. That's not a problem i have so don't worry.

DB records have to exist to be able to refer to in the lua scripts and startpos. Startpos also overwrites lua scripts btw.

Ok! That's what i deduced but i'm glad someone can finally confirm that, Thanks.

Now what i really want to understand is how it works: where and how the overwriting happens.
Especially how db and script interact with each other, i'm pretty sure it uses the id of the record as i mentioned before or some sort of references but well i can't figure it out.
If you have any more detailed informations on that, i'll gladly hear them!

Every record has a unique key for indexing, lookup, combined keys/queriing, that is called ID in the database.

I'm quite familiar with relational and object databases as i work with them every day, so as i explained in my previous post how ids and keys are working is not really a secret for me.
The thing is i don't get at all how CA managed the Ids of the trigger_effects table, they seem completely random and i don't understand the logic behind it.
Usually you use incremental ids for your records, here they are just random and the range is so huge i can't believe it's due to deleted records.

So now that you confirmed that db overwrite scripts and you told me triggers have to be declared in both db and script to work properly, my problem is to know how to choose my new trigger_effects record id.
Indeed, as i don't know how they are generated and managed nor how it interacts with the script and the rest of the db tables i'm wondering if i can just choose it arbitrarily ( watching for duplicated values, of course) and if there is any side tables to update.

I'm pretty sure the game engine is ORM-based but i'm lacking the knowledges about the engine to properly understand how it works (and i'm pretty sure CA didn't released any detailed documentation about its game engine ) but maybe veteran modders have some insights to share.

[OpusDei]

Every record has a unique key for indexing, lookup, combined keys/queriing, that is called ID in the database.

[OpusDei]

I understand. There is a part we don't have acces to. Because I am a professional database designer (oracle/~sql and unix script programmer) I know how the relative database is build up and what needs to be in there and what needs to exist to be able to be called upon in scripts. The language that is used in these luascripts however is different, interpunction/synopsis so it takes me a lot of time to read the referrals and to make new subroutines. The new sort of triggers that are being used in Atilla are called 'CALLBACKS'. Instead of making new subroutines the whole time, one can be used with different variables and thereby saving of lot op programminglines (also for compiling). So if you want to make a new small behaviour/subroutine you use a new callback to call upon a functionblock. The checks to the new triggers (very smart) are called "Watches" (to watch out for a certain amount or situation to occur and than activate the CALLBACKS you made, with ofcourse standard looping (until do, for next, etc) functionality. The problem herewith is that you (at least I don't!) have the synopsis of this programminglanguage. But maybe you do, since I read you said having experienced with luascripting before.\

And you are right first the DB is read and then in the end userscripts (so these values are dominant as also the startposdb entries and scripts under World_CIA and CIA entries. The way that keys/records/combined keys are lookup up is part of the inaccessible gameengine, but that should not be a problem.

Triggers are NOT defined in the DB, they don't exist there. Triggering is part of the programming (loops, booleans, status quo's that trigger events). The DB is just full of records and entities! Triggers are defined in export_triggers (where u can make new ones) and referred to and at from the scritping, like in every programminglanguage depending on the variables you yourself set in the first definition section of a script.

It is not easy to make a new script because of all of this, much work! But you may be able to changes existing scripts or add new subroutines to them.

Sorry for my english

Greetz
T.

Ps.
The way the Database is being presented with ID's does not tell you what the Keys (or combined keys) are in the rows, every entitiy or combination of entities can be used as unique identifiers to be queried on as in every relation database. So a first row of ID's from 1 to 1000 tells you nothing except if it does..when it's the unique recordidentifier, key to that record. It's not random, this is just what you seem to see in the moddingtool you use.

[Alkrinos]

Hello OpusDei

I understand. There is a part we don't have acces to. Because I am a professional database designer (oracle/~sql and unix script programmer) I know how the relative database is build up and what needs to be in there and what needs to exist to be able to be called upon in scripts. The language that is used in these luascripts however is different, interpunction/synopsis so it takes me a lot of time to read the referrals and to make new subroutines. The new sort of triggers that are being used in Atilla are called 'CALLBACKS'. Instead of making new subroutines the whole time, one can be used with different variables and thereby saving of lot op programminglines (also for compiling). So if you want to make a new small behaviour/subroutine you use a new callback to call upon a functionblock. The checks to the new triggers (very smart) are called "Watches" (to watch out for a certain amount or situation to occur and than activate the CALLBACKS you made, with ofcourse standard looping (until do, for next, etc) functionality. The problem herewith is that you (at least I don't!) have the synopsis of this programminglanguage. But maybe you do, since I read you said having experienced with luascripting before.


And you are right first the DB is read and then in the end userscripts (so these values are dominant as also the startposdb entries and scripts under World_CIA and CIA entries. The way that keys/records/combined keys are lookup up is part of the inaccessible gameengine, but that should not be a problem.

Being myself an IT engineer too i completely understand this kind of programming paradigm and the use of stuff like generic routines, but good job your post could help people that are not used to it.
Well my real problem is the part of the game engine we can't have access too, i don't like to work on something when i can't control everything and prevent side effects. (Even if i was too impatient and i finally decided to edit the lua script to fix so typos)

Triggers are NOT defined in the DB, they don't exist there. Triggering is part of the programming (loops, booleans, status quo's that trigger events). The DB is just full of records and entities! Triggers are defined in export_triggers (where u can make new ones) and referred to and at from the scritping, like in every programminglanguage depending on the variables you yourself set in the first definition section of a script.

It is not easy to make a new script because of all of this, much work! But you may be able to changes existing scripts or add new subroutines to them.

I already got that too, well maybe it's my fault i should have insisted on the fact that i have programming and DB knowledges. Again i'm quite sure it will help some other people reading this topic so thanks.

The way the Database is being presented with ID's does not tell you what the Keys (or combined keys) are in the rows, every entitiy or combination of entities can be used as unique identifiers to be queried on as in every relation database.

I'm not really sure i got what you are trying to tell me here.
Do you mean that this id row is not necessarily the primary key of the table ? Well to me it was pretty obvious that it was, but i'm completely wrong. I'm just wondering why this table have an id row of all tables if it's just useless and not a key.

So a first row of ID's from 1 to 1000 tells you nothing except if it does..when it's the unique recordidentifier, key to that record. It's not random, this is just what you seem to see in the moddingtool you use.

I just don't get your point here, could you rephrase it (sorry my english sucks)
If you are telling me that it's not because there is an id field that this mandatorily means it's a unique record identifier i agree but once again it would be completely stupid to even create this field in the table then.
Once again let me stress the fact i'm not talking about the PFM's UI row number but the id field of the table.
Maybe you are telling me that this field exists for all tables but for some reason it appears on the trigger_effects table and not on the other one?
Do you mean that in fact it's just useless and i can ignore it as it has nothing to do with some kind of unique row identifier the game engine use for lookup?

Sorry for my english

Don't be sorry! Mine is far worst and i'm pretty sure that's the main problem here hahaha
Really appreciate your efforts to help me btw.

[OpusDei]

The hardcoded part of the Database Engine (assembly) generates ID's for internal reference ;-). If you look carefully you will find these ID's not to be sequential numbers. So these ID's do have a function, the RDB would not work without it! It's just not the key to the records we use and need.. These keys, referral and combined are defined as keys in the database.

So the real referral is the att_trigger_. If you want to find the reference in the luascript you search for the Name, that is the unique recordidentifier.

Example charactartraits:

--[[ att_trig_agent_character_created_less_than_three_traits ]]--


function att_trig_agent_character_created_less_than_three_traits_impl (context)
return char_is_agent(context:character()) and context:character():number_of_traits() <3
end

The unique identifier here is "att_trig_agent_character_created_less_than_three_traits", which has a one byte internal reference in the hardcoded DB, but is referred to under the same name for the DB programming:

trigger_effects_tables
Sort alphabetically and you will find the first row to obtain the unique (textual) record identifier as referred to in the script.

I said unique record identifier, but really it is not, it is a part of a combined key, there can be lots of "att_trig_agent_etc" the combination with the trait makes it unique. Like in zipcode and number of your house. Here you can see the level of normalisation that is used in the RDBMS, it's level 3.

Greetz