PYTHON SCRIPT/SCHEME EXCHANGE
- Thread starter maw
- Start date
Users who are viewing this thread
Golcondio said:
Why a massively complicated bunch of scripts like this? Try copying and adjusting the Native looting mechanisms to use player party prisoners. That would allow you to do everything in just one small script, removes the need for custom item identification or imod scripts, removes the need for extra troop types, and even solves the problem of inappropriate imods.
Also, Amman de Stazia, what you're suggesting doesn't work. troop_add_item ignores the list of imodbits, something which I've frequently exploited for Craftmod.
Sedentarily,
Winter
Golcondio
Sergeant at Arms
Why? Because I'm new at scripting (when I say new, I mean "never written a line of code before"), so my aim was to make it work, not finesse...Winter said:
I actually TRIED using the looting mechanisms but I can't manage to understand how I'm supposed to use operations like
Code:
change_screen_loot
Code:
troop_loot_troopGolcondio said:
My point isn't about urging you to finesse, it's about pointing you to a solution that will work without the in-built flaws of your current script. It's not a bad piece of code at all -- it would've been very functional in the last M&B version -- but with 0.808's looting functionality, it overlooks features that would really simplify the whole thing.
I believe that looting requires you to be in an encounter for it to work, and possibly even requires being called from a game menu, so it would indeed fail when used in a trigger. Instead I'd test it by: 1) starting an encounter with a dummy party or using a variable condition, which 2) dumps the player to a menu that redirects to the loot screen, and finally 3) leave_encounter and change_screen_return.
Also, just a note, in your item scripts you can actually use item entries and imods directly. You don't have to use their numbers. For example, (is_between,":range","itm_horse_meat","itm_practice_sword"), works equally well as (is_between,":range",1,2),. You can also address imods directly by using the constants defined in header_item_modifiers. For example, instead of (assign,reg(5),16),#hardened armor you can use (assign,reg(5),imod_hardened),#hardened armor
Sunderedly,
Winter
Golcondio
Sergeant at Arms
Thanks! knowing this beforehand would have saved me a lot of crosschecking, but I still learned something...Winter said:
I'll try the encounter thing, which means: Back To Coding!!! (I actually spent more time in the past weeks coding and browsing the forum for answers than playing...)
Amman d Stazia
Master Knight
Winter said:
(troop_add_item, "trp_player","itm_steel_bolts",0)
change zero to some other numbers.... go on
the number references an imodbit. If you cross-check the list of modifiers (complete) with the list of modifiers applicable to that item, you can select from the correct spread of numbers, thus adding an item with a modifier.
locomotively
Amman
Amman de Stazia said:(troop_add_item, "trp_player","itm_steel_bolts",0)
change zero to some other numbers.... go on
the number references an imodbit. If you cross-check the list of modifiers (complete) with the list of modifiers applicable to that item, you can select from the correct spread of numbers, thus adding an item with a modifier.
locomotively
Amman
I know what it does, man. The entirety of Craftmod's crafting system is built around that single operation. As I said, putting random numbers in that field gets you ragged bolts, rusty bows, swaybacked armour and lame weapons, because troop_add_item ignores the item's list of imodbits.
Doing it your way would mean having to build massive additional scripts that manually distinguish allowed imodbits for each item or range of items. I did that for Craftmod only because I had to do it anyway for correct material imods. Here it's a bass-ackwards solution to a very simple problem.
Besides, all you did was mention the item's imodbit list, as if that could be directly accessed in a condition or as if troop_add_item disallowed incompatible imods. Neither of which is possible, and expecting Golcondio to just figure out what you meant when it was unclear even to me is quite simply silly.
Scoldingly,
Winter
Amman d Stazia
Master Knight
well, winter, I don't know why you have such trouble figuring it out - you are the über expert after all...
Golcondio has already listed that imod number 14, for example, equals sturdy. So obviously he KNOWS which number causes which modifier.
To then create a custom group, or spread, using only modifiers which are logically applicable to all items, would be a matter of deciding which ones to choose: Hmmmn, rusty? No, not for clothing, rusty linen shirts sounds strange... Old? Yes. Poor? yes.
So a new group is created with four or five universal modifiers.
In the way that imodbits scimitar = imodbits sword+ imodbit watered steel
you can tack the custom group onto exisiting armour/clothes etc groups if it contains extra modifiers, thus ensuring that Golcondio's script will never pull an invalid one.
Alternatively, only include universal modifiers which are already included in the native scripts: so, no old spears or poor hauberks.
If you do the latter, you don't even NEED to create a custom group: but having them in a group would make referencing easier, because you'd only have to look at the group and not cross-check all the different possibilities.
please remember that it is not only the perfect script which works: There are many ways to cause the same event, some take more time than others to type, some are more flexible. Not everyone is a python perfectionist like you are.
Golcondio has already listed that imod number 14, for example, equals sturdy. So obviously he KNOWS which number causes which modifier.
To then create a custom group, or spread, using only modifiers which are logically applicable to all items, would be a matter of deciding which ones to choose: Hmmmn, rusty? No, not for clothing, rusty linen shirts sounds strange... Old? Yes. Poor? yes.
So a new group is created with four or five universal modifiers.
In the way that imodbits scimitar = imodbits sword+ imodbit watered steel
you can tack the custom group onto exisiting armour/clothes etc groups if it contains extra modifiers, thus ensuring that Golcondio's script will never pull an invalid one.
Alternatively, only include universal modifiers which are already included in the native scripts: so, no old spears or poor hauberks.
If you do the latter, you don't even NEED to create a custom group: but having them in a group would make referencing easier, because you'd only have to look at the group and not cross-check all the different possibilities.
please remember that it is not only the perfect script which works: There are many ways to cause the same event, some take more time than others to type, some are more flexible. Not everyone is a python perfectionist like you are.
Manitas
Grandmaster Knight
Let's say you have a group of items, which come in 3 varieties, inferior, basic and superior, each being a separate item entry, ordered in this fashion in module_items.
Lets say the constant "the_items_begin" contains the ID of the first of them.
Now, if for the item ":item" you do:
(val_sub,":item",the_items_begin),
(assign,":quality",":item"),
(val_mod,":quality",3)
Then you can tell that when quality is 0, then the item is inferior, 1 is basic and 2 is superior.
Now add 1 to the ID if you want to upgrade an item, subtract 1 to degrade.
If you want to standardize an item, add 2 minus ":quality" to its ID.
If you want to randomize quality of many standardized items, then iterate over them adding a random number from the set (-1, 0, 1) to every one of them.
What I mean is that the functionality can be achieved in much simpler and more flexible way - in the above method you can have a separate mesh for each variety, as many variety names as there are items times three, and you can fine tune all the parameters, and don't have to rely on horrendous method of price calculation that comes with imods.
I mean, there are many great things about M&B, but imodbit system is not one of them.
Why argue over them, or even notice them, why not let them go on well deserved retirement.
Lets say the constant "the_items_begin" contains the ID of the first of them.
Now, if for the item ":item" you do:
(val_sub,":item",the_items_begin),
(assign,":quality",":item"),
(val_mod,":quality",3)
Then you can tell that when quality is 0, then the item is inferior, 1 is basic and 2 is superior.
Now add 1 to the ID if you want to upgrade an item, subtract 1 to degrade.
If you want to standardize an item, add 2 minus ":quality" to its ID.
If you want to randomize quality of many standardized items, then iterate over them adding a random number from the set (-1, 0, 1) to every one of them.
What I mean is that the functionality can be achieved in much simpler and more flexible way - in the above method you can have a separate mesh for each variety, as many variety names as there are items times three, and you can fine tune all the parameters, and don't have to rely on horrendous method of price calculation that comes with imods.
I mean, there are many great things about M&B, but imodbit system is not one of them.
Why argue over them, or even notice them, why not let them go on well deserved retirement.
Amman d Stazia
Master Knight
that's actually pretty cool, because in addition it lets you do things like take your weapon to the smith and have it improved. The only script needed would be to (quality+1) on the weapon currently equipped. Right?
Here's another way of working inside the imodbit system:
[assign,reg(10),imod_tattered],
[assign,reg(11),imod_reinforced],
[assign,reg(12),imod_thick],
[assign,reg(13),imod_ragged],
(store_random_in_range,reg(0),reg(10),reg(14)), (troop_remove_item,0,"itm_padded_cloth"),(troop_add_item,"trp_marnid","itm_padded_cloth",reg(0)),
you can use ANY imod here, which is 'applicable' to the item in question.
Not sure what is and isn't?
in module_items, add this (or a similar line)
imodbits_cloth = imodbit_tattered | imodbit_ragged | imodbit_sturdy | imodbit_crude | imodbit_thick | imodbit_reinforced | imodbit_hardened | imodbits_ai
imodbits_ai = imodbit_heavy | imodbit_hardened | imodbit_battered | imodbit_crude
in imodbits_ai you can throw all the modifiers you want: these will then apply to cloth too. The 4 I've chosen can apply to any item, even arrows at a stretch.
Here's another way of working inside the imodbit system:
[assign,reg(10),imod_tattered],
[assign,reg(11),imod_reinforced],
[assign,reg(12),imod_thick],
[assign,reg(13),imod_ragged],
(store_random_in_range,reg(0),reg(10),reg(14)), (troop_remove_item,0,"itm_padded_cloth"),(troop_add_item,"trp_marnid","itm_padded_cloth",reg(0)),
you can use ANY imod here, which is 'applicable' to the item in question.
Not sure what is and isn't?
in module_items, add this (or a similar line)
imodbits_cloth = imodbit_tattered | imodbit_ragged | imodbit_sturdy | imodbit_crude | imodbit_thick | imodbit_reinforced | imodbit_hardened | imodbits_ai
imodbits_ai = imodbit_heavy | imodbit_hardened | imodbit_battered | imodbit_crude
in imodbits_ai you can throw all the modifiers you want: these will then apply to cloth too. The 4 I've chosen can apply to any item, even arrows at a stretch.
Amman de Stazia said:
. . . That code, it doesn't mean what you think it means. store_random_in_range will use the content of those registers, not their ID numbers. So what will happen is that you're starting a bad range from the number 12 (imod_tattered) to whatever garbage value is left in reg14. You'll most probably end up with an assertion error for trying to add illegal imods.
Clarificationally,
Winter
Highlander
Marquis
You could use
(store_random_in_range,reg(1),10,14)
(troop_remove_item,0,"itm_padded_cloth"),(troop_add_item,"trp_marnid","itm_padded_cloth",reg(reg(1))),
I'm not 100% sure, but if I remember correct, I've successfully used something like that before. Just try it.
(store_random_in_range,reg(1),10,14)
(troop_remove_item,0,"itm_padded_cloth"),(troop_add_item,"trp_marnid","itm_padded_cloth",reg(reg(1))),
I'm not 100% sure, but if I remember correct, I've successfully used something like that before. Just try it.
Highlander said:
I'm afraid that doesn't work either, for two reasons.
1) You can't use register or variable values as regnumbers. Otherwise we wouldn't need dummy troops for arrays.
2) The imods in question are not in an unbroken block. Storing a random in range from 10 to 14 will get you a random choice of: imod_watered_steel, imod_heavy, imod_tattered or imod_ragged. Unfortunately it's impossible to change the order in header_item_modifiers because they're only constants and therefore aren't scanned like tuples.
That's all, must run now.
Celeritously,
Winter
Hellequin
Sergeant at Arms
The approach I used for this (Schattenlander has weapons risk decaying in quality after use, though the probabilities are currently tuned too high) is pretty simple...
A specific script takes in an item and its imod. From the item's position in a (sorted) module_items file, it can tell what kind of item it is - is this a horse, a sword, a shield, etc. Most imods (such as, say, Tattered) only decay to one other imod anyway - Tattered is only ever applied to cloth armour, which has a specified next step down. So I don't even look at the results of the item-classification part, the script can say straight off that down from Tattered gets you Ragged (or whatever it is, I forget the progression). In a few instances a single imod can have multiple interpretations - Rusty means a different thing for armour than for axes, for example, and decays differently. So in those cases, the script checks the classification results and can unequivocally say that since it's a rusty weapon it should decay to X.
Making a version which did the same thing the other direction would be much the same affair. I believe Craftmod does it similarly as well.
The big gotcha is that you need to carefully sort the items list so that you can identify everything, and I also chose to do a lot of rationalizing of the imod progression so that there were fewer different "spectrums" to follow up and down.
Manitas has a good point except that imods have the advantage of a great deal of user-visible content in a relatively compact manner. To simply replicate Native's level of detail using that scheme would multiply the number of items five- to seven-fold. Construction of items (all items) using an adjective plus a noun, or indeed simply from two strings if you chose to break the standard grammar, is an extremely powerful tool. Right now it's an extremely powerful tool with strong limitations. Someday, however, Armagan may be good enough to give us the ability to define our own imod lists and their effects. At which point, look out, it's a whole 'nother ball game.
(Here's a thought - just use the same format as module_items objects for the newly defined modifiers. That is, a now-nonexistent module_item_modifiers.py would contain tupes identical to item tuples, which are added to the items in-game once an imod has been assigned. The name portion gets added on the front of the item's name (rendering the header_item_modifiers.csv file obsolete). The numerical values such as speed, weight, or damage get added to the item's stats, and default to zero [no change] where not specified. The mesh field would be unused in most cases, although the possibility exists to define a mesh here which will also be drawn every time the imod is present (perhaps a sickly green aura); mostly, meshes would continue to be associated with the item, and be able to include alternates associated with specific imods, just as now.)
A specific script takes in an item and its imod. From the item's position in a (sorted) module_items file, it can tell what kind of item it is - is this a horse, a sword, a shield, etc. Most imods (such as, say, Tattered) only decay to one other imod anyway - Tattered is only ever applied to cloth armour, which has a specified next step down. So I don't even look at the results of the item-classification part, the script can say straight off that down from Tattered gets you Ragged (or whatever it is, I forget the progression). In a few instances a single imod can have multiple interpretations - Rusty means a different thing for armour than for axes, for example, and decays differently. So in those cases, the script checks the classification results and can unequivocally say that since it's a rusty weapon it should decay to X.
Making a version which did the same thing the other direction would be much the same affair. I believe Craftmod does it similarly as well.
The big gotcha is that you need to carefully sort the items list so that you can identify everything, and I also chose to do a lot of rationalizing of the imod progression so that there were fewer different "spectrums" to follow up and down.
Manitas has a good point except that imods have the advantage of a great deal of user-visible content in a relatively compact manner. To simply replicate Native's level of detail using that scheme would multiply the number of items five- to seven-fold. Construction of items (all items) using an adjective plus a noun, or indeed simply from two strings if you chose to break the standard grammar, is an extremely powerful tool. Right now it's an extremely powerful tool with strong limitations. Someday, however, Armagan may be good enough to give us the ability to define our own imod lists and their effects. At which point, look out, it's a whole 'nother ball game.
(Here's a thought - just use the same format as module_items objects for the newly defined modifiers. That is, a now-nonexistent module_item_modifiers.py would contain tupes identical to item tuples, which are added to the items in-game once an imod has been assigned. The name portion gets added on the front of the item's name (rendering the header_item_modifiers.csv file obsolete). The numerical values such as speed, weight, or damage get added to the item's stats, and default to zero [no change] where not specified. The mesh field would be unused in most cases, although the possibility exists to define a mesh here which will also be drawn every time the imod is present (perhaps a sickly green aura); mostly, meshes would continue to be associated with the item, and be able to include alternates associated with specific imods, just as now.)
Hellequin said:
Yeah, that's pretty much how it works. My point has always been, though, that it's a big pain in the arse and very heavy-duty for a script that really doesn't need it at all.
It'd be easy if items had their own slots -- just give each item a little array of applicable imods starting with slot 1, and then put the number of imods that ended up applicable into slot 0. Or, if you wanted to do it wastefully but more simply, just a yes/no value for each imod slot, since they're only constants that could be used as slot numbers.
Who knows, maybe next version.
Murkily,
Winter
Hellequin
Sergeant at Arms
Or, since item slots (once they exist) will be in strong demand for other stuff, if imods end up being entities give 'em slots too. Then you can encode which items this is legit for in whatever manner you like, without using up storage space which the items themselves would probably have better uses for.
KON_Air
Master Knight
Almost random starting character
About half an hour of Copy/Pasting
Edit; Durr... forgot about that fact
ehe, fixed the code
Code:
#THE RANDOM CHARACTER
("start_xplrar",[(eq, "$clss_chc", 24),
(store_random_in_range, "$strdice", 0, 6),
(store_random_in_range, "$agidice", 0, 6),
(store_random_in_range, "$intdice", 0, 6),
(store_random_in_range, "$chrdice", 0, 6),
(store_random_in_range, "$skl1dice", 0, 4),
(store_random_in_range, "$skl2dice", 0, 3),
(store_random_in_range, "$skl3dice", 0, 3),
(store_random_in_range, "$skl4dice", 0, 2),
(store_random_in_range, "$goldice", 100, 1200),
(store_random_in_range, "$itmdice", 0, 6),
(store_random_in_range, "$wpndice", 0, 7),
],"Accept.",[
(troop_raise_attribute, "trp_player",ca_strength,"$strdice"),
(troop_raise_attribute, "trp_player",ca_agility,"$agidice"),
(troop_raise_attribute, "trp_player",ca_intelligence,"$intdice"),
(troop_raise_attribute, "trp_player",ca_charisma,"$chrdice"),
#skills c/p from somewhere else so value/dice added later
(troop_raise_skill, "trp_player","skl_trade","$skl4dice"),
(troop_raise_skill, "trp_player","skl_leadership","$skl1dice"),
(troop_raise_skill, "trp_player","skl_prisoner_management","$skl1dice"),
(troop_raise_skill, "trp_player","skl_engineer","$skl2dice"),
(troop_raise_skill, "trp_player","skl_first_aid","$skl2dice"),
(troop_raise_skill, "trp_player","skl_surgery","$skl3dice"),
(troop_raise_skill, "trp_player","skl_wound_treatment","$skl3dice"),
(troop_raise_skill, "trp_player","skl_inventory_management","$skl1dice"),
(troop_raise_skill, "trp_player","skl_spotting","$skl2dice"),
(troop_raise_skill, "trp_player","skl_pathfinding","$skl2dice"),
(troop_raise_skill, "trp_player","skl_tactics","$skl3dice"),
(troop_raise_skill, "trp_player","skl_tracking","$skl3dice"),
(troop_raise_skill, "trp_player","skl_trainer","$skl2dice"),
(troop_raise_skill, "trp_player","skl_horse_archery","$skl3dice"),
(troop_raise_skill, "trp_player","skl_riding","$skl1dice"),
(troop_raise_skill, "trp_player","skl_athletics","$skl4dice"),
(troop_raise_skill, "trp_player","skl_shield","$skl2dice"),
(troop_raise_skill, "trp_player","skl_weapon_master","$skl2dice"),
(troop_raise_skill, "trp_player","skl_power_draw","$skl4dice"),
(troop_raise_skill, "trp_player","skl_power_throw","$skl4dice"),
(troop_raise_skill, "trp_player","skl_power_strike","$skl4dice"),
(troop_raise_skill, "trp_player","skl_ironflesh","$skl1dice"),
#itm dice all copy pasted from other classes :P
(try_begin),
(eq, "$itmdice",0),
(eq, "$character_gender",1),
(troop_add_item, "trp_player","itm_dress",imod_sturdy),
(troop_add_item, "trp_player","itm_wimple_with_veil",imod_sturdy),
(troop_add_item, "trp_player","itm_woolen_hose",0),
(else_try),
(eq, "$itmdice",0),
(troop_add_item, "trp_player","itm_ragged_outfit",imod_sturdy),
(troop_add_item, "trp_player","itm_ankle_boots",0),
(else_try),
(eq, "$itmdice",1),
(eq, "$character_gender",1),
(troop_add_item, "trp_player","itm_lady_dress_ruby",imod_sturdy),
(troop_add_item, "trp_player","itm_turret_hat_ruby",imod_sturdy),
(troop_add_item, "trp_player","itm_woolen_hose",0),
(else_try),
(eq, "$itmdice",1),
(troop_add_item, "trp_player","itm_nobleman_outfit",imod_sturdy),
(troop_add_item, "trp_player","itm_woolen_hose",0),
(else_try),
(eq, "$itmdice",2),
(eq, "$character_gender",1),
(troop_add_item, "trp_player","itm_peasant_dress",imod_sturdy),
(troop_add_item, "trp_player","itm_wimple_a",imod_sturdy),
(troop_add_item, "trp_player","itm_woolen_hose",0),
(else_try),
(eq, "$itmdice",2),
(troop_add_item, "trp_player","itm_straw_hat",imod_sturdy),
(troop_add_item, "trp_player","itm_linen_tunic",imod_sturdy),
(troop_add_item, "trp_player","itm_woolen_hose",0),
(else_try),
(eq, "$itmdice",3),
(troop_add_item, "trp_player","itm_wine",0),
(troop_add_item, "trp_player","itm_bread",0),
(troop_add_item, "trp_player","itm_robe",0),
(troop_add_item, "trp_player","itm_black_hood",0),
(else_try),
(eq, "$itmdice",4),
(troop_add_item, "trp_player","itm_tabard",imod_sturdy),
(troop_add_item, "trp_player","itm_leather_boots",0),
(else_try),
(eq, "$itmdice",5),
(troop_add_item, "trp_player","itm_leather_armor",0),
(troop_add_item, "trp_player","itm_skullcap",0),
(troop_add_item, "trp_player","itm_ankle_boots",0),
(try_end),
#All Hail Might Apple acting as a seperator
(troop_add_item, "trp_player","itm_apples",0),
#The only part I wrote;
(try_begin),
(eq, "$wpndice", 0),
(troop_raise_proficiency, "trp_player",0,35),
(troop_add_item, "trp_player","itm_sword_medieval_a",0),
(troop_add_item, "trp_player","itm_round_shield",0),
(else_try),
(eq, "$wpndice", 1),
(troop_raise_proficiency, "trp_player",1,35),
(troop_add_item, "trp_player","itm_axe",0),
(troop_add_item, "trp_player","itm_round_shield",0),
(else_try),
(eq, "$wpndice", 2),
(troop_raise_proficiency, "trp_player",2,35),
(troop_add_item, "trp_player","itm_spear",0),
(troop_add_item, "trp_player","itm_round_shield",0),
(else_try),
(eq, "$wpndice", 3),
(troop_raise_proficiency, "trp_player",3,35),
(troop_add_item, "trp_player","itm_hunting_bow",0),
(troop_add_item, "trp_player","itm_arrows",0),
(else_try),
(eq, "$wpndice", 4),
(troop_raise_proficiency, "trp_player",4,35),
(troop_add_item, "trp_player","itm_hunting_crossbow",0),
(troop_add_item, "trp_player","itm_bolts",0),
(else_try),
(eq, "$wpndice", 5),
(troop_raise_proficiency, "trp_player",5,35),
(troop_add_item, "trp_player","itm_throwing_daggers",0),
(troop_add_item, "trp_player","itm_dagger",0),
(troop_add_item, "trp_player","itm_round_shield",0),
(else_try),
(eq, "$wpndice", 6),
(troop_raise_proficiency, "trp_player",6,50),
(troop_add_item, "trp_player","itm_dagger",0),
(troop_add_item, "trp_player","itm_flintlock_pistol",0),
(troop_add_item, "trp_player","itm_cartridges",0),
(try_end),
(troop_add_gold, "trp_player", "$goldice"),
(change_screen_return, 0),
]),About half an hour of Copy/Pasting
Edit; Durr... forgot about that fact
Code:
store_random_in_range = 2136 # gets random number in range [range_low,range_high] excluding range_high
# (store_random_in_range,<destination>,<range_low>,<range_high>),ehe, fixed the code
eljeffe418
Sergeant
Modified source code to make it so lords can capture each other. I think it was originally in the source but the variable to see if they can be captured wasn't declared, I think. There's already a string for the lord getting captured. I changed it so that it's based on difference of renown.
grailknighthero
Sergeant Knight
eljeffe418 said:
Ive seen the variable. It is the chance for escape and right now it is set at 100%. There is a note for it that later it will be set to 80%.
