Modding Q&A [For Quick Questions and Answers]

[Caba`drin]

Okay edited :p
you mean i should change the 0.4 by the hit_agent trigger?

The first change would be to change the trigger's call interval from 0.4 to ti_on_agent_hit , but doing that results in other changes, that are shown in the alternatives Somebody and I posted above.

The alternative I put up replaces the entire trigger. And the one Somebody put up replaces the conditions and consequences blocks, keeping the beginning parts I posted.

 

[Sayd Ûthman]

i hate the triggers, they are too hard to me 

 

[Caba`drin]

i hate the triggers, they are too hard to me

I tried to include some explanation for the bits in my post above....for whatever that's worth.

 

[Sayd Ûthman]

after numberous reading, i think somebody's code is better for me because it uses inventory slots.and by the way, it is possible to make everybody who have a spear in inventory wield it at the beggining of the battle?
thank' s a lot

EDIT: a little mistake in both codes, you should remove the comma at the end.

 

[Ritter Dummbatz]

it is possible to make everybody who have a spear in inventory wield it at the beggining of the battle?

You already make use of operations that can do exactly that.
May be after midnight things seem to be not that obvious.

 

[Sayd Ûthman]

?? where ?

 

[Ritter Dummbatz]

Wherever it is after midnight. 

agent_get_item_slot can be used to check what item the agent uses. If it is not a spear make him switching weapons.

 

[Sayd Ûthman]

Okkkaaay 

 

[Sayd Ûthman]

SomeBody i don't know what is happen, but your code makes all items broke (even bows and crossbows)

 

[Somebody]

Don't blame me, I didn't write it. You can get rid of the conditional block before the is_between if you only want those weapons to break. If that's the case, then there's no need to multiply and divide - simply change the random chance parameters. Otherwise, use item_get_type and check if it's a polearm before proceeding.

 

[Sayd Ûthman]

I'm not blaming you^^ so even if i didn't understand all you've said i am now trying removing some things i don't need. by the way, what this does:

(assign, ":end", ek_head),

 

[Somebody]

It breaks out of the loop after finding the first matching weapon.

 

[Lumos]

Does the opcode "party_is_active" fail if a party is disabled?

Another one: How does the AI decide what to lay siege to?

 

[Ritter Dummbatz]

I noticed that you asked 'how' and I answere with 'where' and I also might be wrong but I think the decision is made inside
'npc_decision_checklist_party_ai ' and parties available are counted and may be the strength of castle defenses...not sure about the last one. But the answere should be inside this script or in the area around this one.

 

[Ritter Dummbatz]

Sorry for the double post but the previous one was an answere and here comes my question.

Is there anything special about team slots in singleplayer like a limit on how many slots can be given or something?

At first it worked fine for me but lately after adding a few more slots it doesn't initate with the value defined in module_constants but seems to have a value equally to the number of troops of that team. I double and triple checked my code but if I would have found something I wouldn't be posting.

Do you know more?

 

[Caba`drin]

You can only set team slots for teams 0-7. ...not sure if you were doing otherwise.
Also, remember the module_constants definition doesn't initialize the VALUE of the slot, it just tells the compiler what words are associated with what slot number. The slot value will be initialized at 0 and re-set every mission, like agent slots.

I've not run into problems with numbers of slots though...I've used from 0 into 100 something in PBOD with motomataru's formations.

 

[Lumos]

I noticed that you asked 'how' and I answere with 'where' and I also might be wrong but I think the decision is made inside
'npc_decision_checklist_party_ai ' and parties available are counted and may be the strength of castle defenses...not sure about the last one. But the answere should be inside this script or in the area around this one.

Thanks a lot. I'll check it out. We might soon have enemy lords laying siege to our Outposts, and building their own!

 

[Raegenhere]

hmm... i am just wondering, is it possible to assemble multimesh-items without renaming them in open brf (mesh, mesh.1 and so on)?

For example:
weapon 1 uses the meshes grip_a and blade_a
weapon 2 uses the meshes grip_b and blade_a
weapon 3 uses the meshes grip_a and blade_b
weapon 4 uses the meshes grip_b and blade_b

tried assigning a second mesh using morgh's tools, but no luck so far.

The nice thing about this would be that it keeps the number of meshes low.
Or is it even a big deal to have many meshes in brf files, in terms of performance?

 

[Ritter Dummbatz]

the module_constants definition doesn't initialize the VALUE of the slot

Thanks a lot. Since it worked for me that way so far so I never noticed. I know wonder why it's not set to 0 and instead contains the troop number...anyway.

I am now a bit confused about the numbers that as you say 'tells the compiler what words are associated with what slot number'
I didn't care about the order as there are many slots are out of that order.

For example under troop slots you'll find.

slot_troop_love_interest_3    = 37
slot_lady_no_messages          = 37

So how does the compiler make a difference between those two? My brain alone is currently not enough to get it.

 

[Caba`drin]

For example under troop slots you'll find.

slot_troop_love_interest_3    = 37
slot_lady_no_messages          = 37

So how does the compiler make a difference between those two? My brain alone is currently not enough to get it.

The compiler doesn't differentiate between the two, because it doesn't need to in this case:
slot_troop_love_interest_3 is only used for lord troops.
slot_lady_no_messages is only used for lady troops.
Thus, there is no overlap. But in both cases, troop.variable37 contains the data the game is looking for.

If a troop needed to store both a third love interest and a message status, then they would be assigned different slot numbers. Like 37 and 38 or some such.

Spoiler: my slot explanation from my syntax thread, for what its worth

Slots are essentially ways to have variables arrayed by an object (party, troop, agent, team, faction, scene, item, player, scene prop, or party template).  Each party, troop, agent, item etc has a number of "slots" (variables) assigned to it. That variable has a common name "slot_item_SLOTNAME" for each version of the object is assigned to (items in this case), which is useful, but stores unique information for each object. Where it looks like a "constant" is the fact that the engine turns the name of the arrayed variable (the slot) into a number in module_constants (slot_item_base_price = 53).  This means that the engine looks at the 53rd slot-variable associated with a given item to find that item's base price.

So, when you see operations using slots such as (item_get_slot, ":base_price", ":item_id", slot_item_base_price),
you can see that you need to specify exactly which item you want to get the base price for. But, since the variable is arrayed, you could embed that in a try_for_* loop and iterate through many ":item_id"s to do things to the base price of every item, say.

You can access the price for a specific item with the item_get_slot operation, change it via item_set_slot, and test for equality with item_slot_eq and the like.

If you know C-like programming languages, slots work a lot like this:
slot_troop_spouse
spouse[troop1] = spousename
spouse[troop2] = spousename
spouse[trp_player] = spousename
which the engine reads as troop_variable_30[troop1], troop_variable30[trp_player] etc since slot_troop_spouse is set as slot 30 in constants.

slot_item_base_price
baseprice[item1] = priceA
baseprice[item2] = priceB
baseprice[item3] = priceC
and the engine reads that as item_variable_53[item1], item_variable_53[item2] etc...since it is set as 53 in constants

This is a work in progress. Addenda, suggestions, corrections, and similar are welcome.