Hm, and what's the problem to expand the whole scripts recursively? I.e. scripts = expand(scripts)? All the code is in lists, that are easily changable.
I'm not at a computer where I can actually write or test code atm so I'm just stuck looking enviously at all this and thinking of in how many ways I could use it
Anyway, quick suggestion and something that I think should somehow be incorporated into the autoloot as well: encumbrance/weight.
If an npc simply always picks the best armor value, you'll get toons who are all running around in full plate eventually which, if you use infantry units like I do, is not necessarily something you want. Either way, even if you don't give a toss about turning them into slow moving turds, it would still be usefull to be able to directly access an item's weight and since you're doing this anyway, might as well get all the info we can get
But this is all seriously cool stuff which would allow(among about a million things) for more advanced formation options to be coded, where you can class units into more than just 'infantry' and 'ranged' but could use weapon dmg and armor value and such to make more intelligent classifications.
Hm, and what's the problem to expand the whole scripts recursively? I.e. scripts = expand(scripts)? All the code is in lists, that are easily changable.
Um, dude, i could just misunderstood because of my english, you know.
Let me try to explain how i see it.
some_python_function generates a list (for example, [ (assign, ":somevar", 12), another_python_function(":somevar"), (eq, ":somevar", 6) ])
and another_python_function is
def expand( target_list ):
temp_list = [] #we can't just insert items in for-in cycle
for record in target_list:
if isinstance(record, list): #functions must generate lists: first, it's standart to use tuples for operations, second, it's modifiable
temp_list.extend( expand(record) )
else:
temp_list.append( record )
target_list.__init__( temp_list ) #replace data with a new one
return target_list
def expand_s( target_scripts_list ):
for script in target_scripts_list: #for each script
expand(script[1])
expand_s( scripts )
That's for scripts, you can write expand_s alternative to match game_menus syntax, for example.
Ok, sorry for the skepticism. That works in theory, only difference is that you need to make all your python wrappers return a class that is descended from list, just so you can distinguish your code chunks from actual lists, so you know which ones to expand and which ones to leave alone.
I'd be careful about wrapping modsys in python functions like that. Since basically everything is unrolled, you need to watch for code explosions in recursive calls.
I'll give that a shot this evening! That will mean that I can wrapper multiple python functions with a single MS script, and not confuse other MS coders with "low level" python functions.
In my initial instance, I have basically 3 different python functions that generate lists of MS tuples, and what I want is to wrapper all three of those lists as a single body to an initialization script to be called by the MS code. And it would appear that your technique will allow me to do so.
Otherwise I had to wrapper each and every python function in an MS script wrapper, which would lead to the likelihood of another programmer accidentally thinking that they could call any one of those in isolation (that they were meant to be called from MS code) - and they're not.
find out on forums.taleworlds.com/index.php/topic,35044.105.html
I use XP, and I m not sure if it will work on windows 7, but I try to change every line that call python on the build_module.bat, like:
Code:
python process_init.py
to
Code:
"c:\python24\python" process_init.py
and it works.
Btw, thanks for necro this thread. Nice and full of useful info discuss among great modders up there.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.