Home » MODDING HQ 1.13 » v1.13 Coding Talk » Tactical AI: architectural redesign
Re: Tactical AI: architectural redesign[message #318221] Mon, 29 April 2013 22:53 Go to previous messageGo to next message
IoP

 
Messages:17
Registered:March 2012
https://o84.nor.fi/~jikuja/ja2/remove_unused_includes_v1.diff

New version. Tested with VS2010 and all combinations(=12) of EN/DE, Rel/Debug, JA2/UB/demos. Please test with older VS before merging

Diff only removes unused #includes. More work needed if we want to remove repeated #includes.

[Updated on: Mon, 29 April 2013 22:54] by Moderator

Re: Tactical AI: architectural redesign[message #318267] Tue, 30 April 2013 17:39 Go to previous messageGo to next message
RoWa21

 
Messages:2049
Registered:October 2005
Location: Austria
feynman
I've got the ClimbPlan working now. The code was partly broken in the legacy implementation - in green mode, militia would never climb, although the intention was clearly there (it would probably have worked with the A* shortest path algorithm, but that wasn't used, and the other one doesn't set MAPELEMENT_EXT_CLIMBPOINT). And not only does my implementation fix it, but it also should give a speedup in finding the climb spots - the old code looked at each and every tile grid in a certain area (20x20=400 tiles), whereas I only look at the climb spots defined by the buildings, and there aren't soooo many in each map. Yay.


Sounds good Smile
Do you work in your local SVN Source trunk and update the main source trunk with features from time to time?


Re: Tactical AI: architectural redesign[message #318269] Tue, 30 April 2013 18:31 Go to previous messageGo to next message
feynman

 
Messages:38
Registered:October 2010
@Durak: The current code contains an AI_ACTION_JUMP_WINDOW, added by Flugente. I don't know if enemies actually do that, but if not, it doesn't seem to be a problem with the AI. Anyways, green militia AI doesn't do it, so I haven't looked at it in detail yet.

@IoP: Thank you so very much... that should make things considerably easier on my part.
What do you mean with "remove repeated #includes"? If "A.cpp" includes "B.h" & "C.h", but "B.h" already includes "C.h", that is OK (it would be bad style to do otherwise, actually - if B.h no longer requires C.h, no dependent code should break if B.h removes C.h from its includes; and avoiding double inclusion is exactly what include guards are for). Or did you mean something else?

@RoWa21: I've added my local svn working copy to a local mercurial repository, so that I can mess things up and revert them without you having to clean up my mess Wink (and I don't have to fix all the Visual Studio project files every time I add a new header/compilation unit, which I'm doing a lot in this early phase)
Of course, I merge that with the public svn regularly. I also am nearly done with the "green AI militia stuff" (i.e., what was formerly DecideActionGreen, when called for an NPC that is part of the militia, plus some "related" functions), the only thing missing is the "scan horizon" stuff (currently there are versions with and without gun readied; I want to make a more generic version also allowing the use of binoculars - do NPCs currently use them?). When this is done, I will make a commit (I'd say one or two days for the ScanHorizon plan, two days documentation, and testing on the weekend, so with any luck I'll commit late sunday)


On the functional side of things...
A part of the climbing code was broken, so I fixed it. Now it is *really* broken. Well, sort of. Because my plans *work*. If you create a "ClimbPlan", the guy climbs, if it is possible at all. The old code was more like, 'let's try... and most likely fail'. Which lead the developers to increase the probability to 'try' climbing, to, like, 70% for "ONGUARD" militia guys in each decision making cycle, and still gaining a negligible posterior probability of climbing (btw, adding what is supposed to be a boolean value, albeit stored in an integer type, to a probability valiu is so that I am once more astounded that the code did work, ever). I *will not* estimate this posterior probability, so here we have one case of 'non-optional legacy behavior change' - I'll just compute a new climbing probability that 'feels right' and doesn't clutter everyone near buildings (which happens if all the guys climb up and down all the time).

However, I didn't find a map on which the militia was hand-placed, so they get created 'randomly', and default behavior seems not to be "ONGUARD", but "STATIONARY", which makes them do nothing (except changing direction on occasion). I'm not sure if this is intended, and at first didn't know how to deal with it. If you want to place your militia manually in game (via talk command), this makes sense, otherwise it doesn't (IMO). I think 'default behavior' should be "ONGUARD", with a small random chance of being on patrol duty.

But... enforcing a reassignment of orders would break maps where the militia is placed and assigned specific orders by the map designer (and militiamen placed in game via talk would walk around afterwards). So I decided to add, for the semi-legacy militia plan factory, a configuration option 'OverrideOrders'. If set, new orders will be assigned when the militia first creates a plan, with most of them being ONGUARD and some on FARPATROL. This doesn't work sector-wise for now, but adding such a feature would be trivial (the real work would be to provide the list where which behavior is desired; I don't think this is needed, because a campaign either sets initial militia position or not, 'only on some sectors' doesn't seem to be so desirable).
Re: Tactical AI: architectural redesign[message #318297] Tue, 30 April 2013 23:39 Go to previous message
Durak

 
Messages:58
Registered:April 2010
feynman
However, I didn't find a map on which the militia was hand-placed, so they get created 'randomly',...



I don't know if this information is helpful, but upon loading a sector where militia soldiers are stationed, they use the same "spawn" points as enemies. (= not randomly placed on the map)
Previous Topic: (More) questions regarding coding style and cosmetic changes
Next Topic: I'm putting an end to save-file compatibility breaks, if noone minds...
Goto Forum:
  


Current Time: Sat Jan 20 01:12:20 EET 2018

Total time taken to generate the page: 0.01800 seconds