OSP Code Optimisation Autoloot improved-source Updated on 3-25, 2009

Users who are viewing this thread

rubik

Squire
Original autoloot thread by fisheye:

I had adjusted autoloot. Reorganized how NPCs will choose their loots, they will accord to the performance instead of the price.
source:

Updated on 3-25, 2009:
Minor fix on judgement of Two-handed/One-handed weapons.
10:41:46 pm
Minor fix on judgement of Two-handed/One-handed weapons again.

Updated on 3-24, 2009:
Create a independent classified for Two-handed/One-handed weapons. They didn't subordinate to Two-handed weapons any more.
Well, I also did some necessary additions in module_dialogs.py and module_strings.py this time.
Now,The archive only contains 5 files, we need not to change module_items.py and process_items.py any more, so there is no need to include them. module_dialogs.py, module_game_menus.py and module_strings.py are the same as fisheye's. The most great changes by me is in module_scripts.py, in addition module_constants.py contains some slots definitions by me.


I used some actual PYTHON code. Such as:

def set_item_difficulty():
item_difficulty = [] # create an empty list: item_difficulty
for i_item in xrange(len(items)): # do a loop in the list items
item_difficulty.append((item_set_slot, i_item, slot_item_difficulty, get_difficulty(items[i_item][6]))) # append Module System sentences to the list
return item_difficulty[:] # return the whole list with all Module System sentences above

# the function get_difficulty is already defined in header_items.py, I just call it here.

It was used to set items' difficulties. Then we can use (item_get_slot,<destination>, <item_id>, slot_item_difficulty) to get items' difficulties easily.
Of course we also need to add some code to call this PYTHON function.

First we need to add the flowing script to call it.
("init_item_difficulties", set_item_difficulty()),

Then add the flowing to the script of game_start to call the script of init_item_difficulties.
(call_script, "script_init_item_difficulties"),
I almost forget that, you must define slot_item_difficulty in module_constants.py before you use it.

Well, I will start a new topic to discuss how to use some simple PYTHON functions in MNB Module System later, I think it will be a great help to your MOD development.
 
Last edited by a moderator:
Ooooo this is brilliant. Best code I've seen since M&B got released.

I had a good look at it.

It totally works.

Rubik is not actually calling a python script at execute time, that would be impossible. He is using a brilliant trick where he uses an inline call to python code to auto-generate a large amount of static game scripts (one line for each item) which sets the item slot to the appropriate value. These game scripts are then compiled into the .txt files and executed at game start.

With this code you can set item slots to anything computable at compile-time, e.g., whether it is a polearm or a lance, whether it starts with an "a", whether it is unique, anything static.

It is vastly improved. I'm stunned.
 
!@$!@#$!@  Wow!

You Can Do This?!

Sweeeeeet!  Seriously - I never imagined you could set an object's slot value from the module system!!!  That's HUGE!

Thanks Rubik!

This gets my vote for most kick-ass code snippet so far in 2009 ...that I've seen (I'm still new around here :razz: )

This opens up a lot of possibilities - not just the difficulty can be set in a slot, but the flags indicating whether an item is usable on horse back or not, or whether shields are disallowed, which means whole new choices can be given to the player in terms of how they want their companions to choose stuff -

Like don't choose stuff incompatible with being on a horse, .... or don't choose stuff that's incompatible with a shield, etc...

Oooooo!!!
 
Not just the traditional fields in the items are available. You can now add your own optional fields to the end of an item tuple (e.g. "color", or "unique_flavor_text", or "special_skill_bonuses") and extract them from an item slot. Blows my mind.
 
Updated on 3-24, 2009:
Create a independent classified for Two-handed/One-handed weapons. They didn't subordinate to Two-handed weapons any more.
Well, I also did some necessary additions in module_dialogs.py and module_strings.py this time.

Some key code snippet:
Code:
    if items[i_item][4] & itc_bastardsword == itc_bastardsword:
      item_base_score.append((item_set_slot, i_item, slot_two_handed_one_handed, 1))
 
bah I'm gone from the forum for a week cause my computer is fried and someone writes the most brilliant piece of code in a long time.. :wink:

Nice work Rubik, this certainly has a lot of potential and is very helpful for any number of recently discussed topics, such as a proper way to determine unit strength based on armor lvl and weapon damage and such.

You, sir, deserve a medal.
 
I think I did something wrong on how to judge whether a weapon is two-handed/one-handed or not.

It should be as following:
Code:
    if items[i_item][3] & itp_type_two_handed_wpn == itp_type_two_handed_wpn and items[i_item][3] & itp_two_handed == 0:
not:
Code:
    if items[i_item][4] & itc_bastardsword == itc_bastardsword:
 
Still I did something wrong on judgement of Two-handed/One-handed weapons. :sad:

if items[i_item][4] & itc_bastardsword == itc_bastardsword:
if items[i_item][3] & itp_type_two_handed_wpn == itp_type_two_handed_wpn and items[i_item][3] & itp_two_handed == 0:

It should be ok this time:
Code:
if items[i_item][3] & ibf_item_type_mask == itp_type_two_handed_wpn and items[i_item][3] & itp_two_handed == 0:
I have tested this and found no problem.

PS: new game required.
 
Rubik,

Would you be able to include 'just' the code, since I did lot of modifications in my python files (most of the ones you uploaded) and since I'm kind of new to this I don't really know how to find the code in the files you included (if I miss anything or whatever).

That would be fantastic :smile:
 
Mr. Roy,

Download a copy of "Beyond Compare 3.0".  It will let you see exactly what's changed between any two text files - with very easy to use filtering so you can ignore meaningless differences, and just see the important parts.

You can use that to compare the kit Rubik has so kindly published to your own code, and then (within BC3.0) you can selectively copy into your code those parts which are new, specific to the autoloot.

Learning to use such a tool is quite easy, and its perhaps the best single tool a programmer of any kind might come by (well, that and perhaps version control system).

At any rate, it will make extracting the necessary parts trivial.
 
yeah, Mordachai is absolutely right, I use a program called "Compare It" but its the exact same concept and makes integrating all these different kits very easy.  One thing I would recommend is to compare it to the original un-edited module system so you can see exactly what changed.  My program can sometimes get a little confused when comparing it to my source code, etc.
 
don't know how i missed this.... absolutely brilliant work, rubik.  thank you very much for this, and for teaching an old dog a new trick.

regards,
ta
 
Back
Top Bottom