Damn, if I had the time to check this code out...
Lumos said:Damn, if I had the time to check this code out...
othr said:There is just one issue I noticed. Cavalry units will wait for their dehorsed friends before making another charge, I think it would be best if they didn't, they're very vulnerable to ranged fire when they're just standing there waiting for their buddies on foot to join up.
sphere said:I'm still relative new to using this mod, so the following may not be accurate. Please be tolerant, and just take those that may be useful Using warband 1127, btw. Note this is the version BEFORE the last update. Please ignore all the points which are no longer applicable.
sphere said:1) relation with the original Hold command (holding F1-F1, move to target, then release). intuitively, I'll expect the formations to be centered horizontally and have front touching the spot marked. This is not always the case.
sphere said:2) Facing is also a problem. As there is a lack of rotating formations atm (unless I miss out some features), keeping the default idea of autorotating to face the nearest concentration of enemies will be good.
sphere said:4) Separate formation position templates from assignment template. Position will define position "slots" like ranks, staggered ranks (where a ranks positions are aligned with gaps of the rank in front, like the default Hold position in game has with "Stand Closer" issued), shieldwall, square, wedge, loose (where rest of "formation" just follow the leader losely without any fixed formation) and of course no formations. assignment templates will decide how to assign troops to that formation (and also how to "repair" damaged formations when troops die). E.g. maybe for just ranks, we could have:
a) 3 ranks: infantry in first line, archer in second line, mounted archers in third, cavalry divided into two blocks at either side (not mixed with the center ranks) (If only we have kneel animation and make the first line kneel with shields up....)
or
b) 2 ranks, first rank with alternating infantry and archers, second rank with alternating cavalry and mounted archers
sphere said:6) Regarding "Shield wall", is it a formation where those units with the biggest/baddest shield will go to first row and set their individual ai to actually hold the shield (i.e. agent performing shieldwall duty are automatically set to not put down the shield like fire range weapons or use two handed weapons unless otherwise commanded or shieldwall is changed to some other formation). If it isn't, maybe it should be???
sphere said:Not directly related to above, but... (please ignore useless stuff, and just hoping something could be helpful)
motomataru said:Prob 2: I noticed a variant of this problem with my new AI. Basically, the troops get their formation data from the team leader (partly because faction data is NOT attached to most troops -- even faction troops). When the leader dies, the troops can't determine which faction they belong to, hence can't pick a formation. Initially, I thought, "No problem. Leaderless troops shouldn't perform functions that require orders from a leader." But it does look funny to see a formation go kaplooey in the middle of a battle when the leader is killed. Suggestions?
I don;t understand the "faction" part exactly, do you mean this:
* formation related data are stored in faction data, and only team leader records the faction id?
* is it possible to propagate this data to all formation members during formation forming/reforming?
* if it is the lack of leader problem, can a new leader be elected by the first agent that detects leader is gone? (e.g. once agent detects leader killed, store the agent's id in global data, then read back the id (to cater for race-condition), and if the id is the agent's id, the agent is now the new leader and will do initiate the formation reforming and reading/generating all the formation data again.
motomataru said:othr said:There is just one issue I noticed. Cavalry units will wait for their dehorsed friends before making another charge, I think it would be best if they didn't, they're very vulnerable to ranged fire when they're just standing there waiting for their buddies on foot to join up.
You know, at some point unmounted cavalry will join infantry. Or at least it was when I was still using agent_get_class instead of agent_get_division. But I did notice the other day that unmounted Vaegir vets remained with cavalry. Argh.
(try_for_agents, ":agent"),
(agent_is_human, ":agent"),
(agent_is_alive, ":agent"),
(try_begin),
(agent_get_group, ":agent_group", ":agent"),
(eq, ":agent_group", 2), # 2 is cavalry
(agent_get_horse, ":agent_horse", ":agent"),
(le, ":agent_horse", 0), # lacking horse
(agent_set_group, ":agent", 0), # 0 is infantry
(try_end),
(try_end),
othr said:I wrote this little thing, I have no idea if this is the way this should be done but it does seem to get the job done when it comes to reassigning dehorsed cavalry to the infantry group. I plugged this into a lance breaking trigger, it can go pretty much anywhere I guess.
Code:(try_for_agents, ":agent"), (agent_is_human, ":agent"), (agent_is_alive, ":agent"), (try_begin), (agent_get_group, ":agent_group", ":agent"), (eq, ":agent_group", 2), # 2 is cavalry (agent_get_horse, ":agent_horse", ":agent"), (le, ":agent_horse", 0), # lacking horse (agent_set_group, ":agent", 0), # 0 is infantry (try_end), (try_end),
sphere said:My suspicions comes from the observation that formations_mission_templates_mb.py contains the obsoleted game constants:
sphere said:EDIT: btw, after I upgraded it to the latest version for modmerger (0.2.1), would you like me to post it back to you to maintain, or do you mind if I just upload it somewhere and stick a link as a sort of mini-port branch off your main work?
sphere said:EDIT2: ok, just took 2 min to adapt formAI after the experience with the main mod, integrated and builds without a problem, then I took my little beginner testing squad of 29 men (From earlier save game) and engaged some vaegir deserters (skirmishers i think)...
They did not approach like the usual mad charge. The deserters (seems all archers) form a nice llittle line at the far end o the map and don't move. I tot their AI got stuck or something and rode closer... then those sneaky b***** started concentrated arrowfire on my hero..... horse went out and before I knew it ... I realised that helmets are important even during testing... you should never ride horses or autobikes without one...
Now, please tell me, is that expected or just a stroke of luck that the enemy AI got stuck and don't move??? LOL
othr said:Have you considered using a subversion server for your code Motomataru? Google code offers free subversion repositories, I'm old fashioned... I like to merge the code myself and subversion would make it really easy
motomataru said:Just updated the code with many of your suggestions from the last couple weeks. Sorry to miss the boat, sphere...
Sorry, I changed the naming convention. Extensions ending in _mb are Mount&Blade 1.011 alternative scripts, and it's the non-extended ones that are for Warband.
That's why above I say I've realized that the various versions could probably be handled by the modmerger from a single file. Like a WB codeblock and a M&B codeblock. Do you have a suggestion for how to proceed for that?
sphere said:hmm, then I means i may have been messing around with mixed version source? (I actually used _wb versions for the other files). wondered why it still seem to work... LOL... think I'll do another merge from scratch leaving out the wb files for now.
sphere said:BTW, I was thinking maybe I can try to keep a variables in an option file somewhere (probably modmerger_options.py for the latest version) for user to set (e.g. "version" : 1127), so when writing your own injection code, you could do things like check if the game is warband (probably when "version" > 1011) or if it is the latest warband that some code supports (e.g. if only supported after 1125, then check for "version" >= 1125). That way, even the "wb" version of the file can be placed into same file, and the merging instructions could just try to check for version and use older merging method if version is older, use latest version if version is correct or absent (if no version, assume latest), or if version is way older than what you support, choose to print an error message or something.
sphere said:So is this the right idea?:, if version is 1011 (any range?), use the _wb versions of the files where they exists? Other-wise use the latest one ( just 1127, or can we put "version" > 1011 or "version" not specified). Which means that if version < 1011, we can choose not to do anything.
sphere said:EDIT: Note sure if I am right about this observation, since I haven't looked into the code for details:
it seems that after advance forward command is issued, the center of the formation is not updated. So when I use the hold F1-F1 (Hold Position) key to set the position flag some distance away, instead of formation going there, it forms up at some displaced position.
sphere said:EDIT2: ok, this is the combined pack, which does Warband and Vanilla injecting in the same source files (yeah, no more manual file renaming, score 1 for lazy mod users!).
BTW, doesn't the module system have a version number stored in a global or constant somewhere? That would be more reliable than the end-modder figuring it out...
othr said:I have a quick question! I have some troops in the mod whose main purpose is to toss javelins and other sharp objects at the enemy. They are treated as 'archers' however their range is rather short, is there any way I can make factions with this type of troop advance closer with the javeliniers? Right now they think they're archers and stop advancing while still way too far away.
(team_get_leader, ":fleader", ":team_no"),
(agent_get_troop_id, ":fleader_troop", ":fleader"),
(store_troop_faction, ":ffaction", ":fleader_troop"),
(else_try),
(assign, ":shot_distance", AI_firing_distance),
(try_begin),
(eq, ":ffaction", "fac_kingdom_2"), # this is the javelin heavy faction
(assign, ":shot_distance", 2500),
(try_end),
othr said:Then they won't all have javelins, hrm.
othr said:What does this constant control AI_firing_distance?
othr said:I added this in team_field_ranged_tactics which may or may not make them behave the way I want:
This piece to obtain the faction:
Code:(team_get_leader, ":fleader", ":team_no"), (agent_get_troop_id, ":fleader_troop", ":fleader"), (store_troop_faction, ":ffaction", ":fleader_troop"),
then later on:
Code:(else_try), (assign, ":shot_distance", AI_firing_distance), (try_begin), (eq, ":ffaction", "fac_kingdom_2"), # this is the javelin heavy faction (assign, ":shot_distance", 2500), (try_end),
It seems like it did the trick but there is lots of code to read to understand what this did exactly.