Jump to content

FeXoR

WFG Retired
  • Posts

    1.426
  • Joined

  • Last visited

  • Days Won

    28

Posts posted by FeXoR

  1. In the old and currently-being-worked-on designs, we don't recalculate paths for units. Once they've started to move and have picked a path, they'll carry on using that path forever, unless they crash into an obstacle and have to stop and pick a new path. That's maybe not ideal behaviour, but it works okay for now :)

    I think that's OK though I saw some talks about that in dev-chat already so it might be changed too :ok:

  2. Hmm, am getting tired again, so while I'm sure there are things I can comment on I'll leave that for tomorrow =) If I forget please add a reply so I don't miss this topic :)

    Hiho, I wanted to add that my 'story' was not that perfect since I forgot about effective arrows where not available in massive numbers. Every arrow caught by a shield where an advantage to an well formated army. If they could catch arrows more 'expensive' then the shield itself it would really be an physical advantage.

    Another thing I forgot to say clearly is the attack-move order. It's the most helpful command in modern RTS games. Just to say it directly: Attack move is IMO a player given order but is indeed inside the gray area between player and unit AI order. If stances should have an impact on it... well same pro and contras like for auto scout/search and destroy command (especially two clicks for one command doesn't sound good to me) ...and an attack move order given to a unit with stance 'hold ground' may be confusing (since the unit wouldn't attack).

    And ofc. I wanted to remind you of this topic :crazy:

    Thx in advance :)

  3. Sorry for the triple post but I saw Quantumstate already read this and forgot to add the main thing.

    It would be really nice of you to tell me what code is needed to produce a female peasant, build a farm and send that female peasant to gather from that farm (Ignoring the other starting units)

    In addition I need to know how to change the resource gathered if a gatherer has returned the resources he carried and how to garrison and drop units to/from a specified building (I think that could be explained in words).

    But until now I'm quite helpless because everything seams to depend on everything else in the common-api for me ATM(I know it might not get better by my concept :wacko:)

    Thx in advance.

  4. Here's a very rough concept of what my AI should do and perhaps makes more clear why I want it. Beware the typos... :S :

    Main aims of fbot:

    - Everything that needs resources in one queue of entity/condition pairs

    - Gather existent resources close to the deposits rather than collecting by type (A growing 'gatherRange' can do that reset when a new deposit is finished)

    - What entities are build should depend on the available resources rather then be fixed

    - Expand by territory rather than senselessly attacking

    - Add conditions to give up (e.g. no civil center and (in sum 500 resources missing to build one OR no deposit for the missing resource), has to be tweaked...)

    - Force units to return resources if enemies near and if close enough to be attacked by CC garrison if this adds damage to CC. Otherwise walk to the opposite side of the CC as the enemies are as long as some amount of hit-points. Otherwise garrison to safety.

    - Re-decide what a unit should gather when it returned resources

    - Develop an easy_ai_api (build as far as possible upon common-api-v2) that only requires fixed code (shown in a demo bot) and a custom list of entity/condition pairs (and attack conditions)

    Abbreviations:

    CC: Civil Center

    CF: Citizen Female

    CS: Citizen Soldier

    More detailed:

    ----- Cover CC/food/wood/gatherers/popcap -----

    - Civil center (CC)

    (Without CC the game will be lost so this is the first priority even if you have drop-sides for all resources and enough resources and a builder)

    (Edge case enough resources/popcap and barracks)

    (Edge case drop sides/barracks/enough resources/popcap for CS but not enough resources for CC (hard...))

    - Enough popcap to build units (If CC/enough resources for a gatherer but no gatherers/enough popcap to build gatherer -> force attack with all non-citizen soldiers)

    - Food gatherer (citizens females (CF) if non-running food source near, else if resources for farm/farm available build farm, else if running food source and enough resources for CS build CS, else if wood near and farm available prefer gather wood)

    - Wood gatherer (citizen soldiers (CS) if enough wood, else CF until enough wood)

    - Field (Still prefer non-running Gaia resources in gather range)

    - 10 CF and 10 CS

    ----- Food/wood/gatherers/popcap covered, before that don't do anything else! -----

    - Build house(if not already present)

    - Build mill

    - Build farmstead

    - Advance to T2

    - Build 2 markets

    - Build trade units (TU) for all non-food resources (5 each starting with wood if no wood in gatherRange, no wood if most of the entities in gatherRange grant wood and start with metal)

    - 20 CS

    - Add stone to be gathered (CS)

    - 30 CS

    - Build a tower in front (towards the enemy) of all markets if stone in gatherRange, else if enough metal otherwise 5 more stone trade units

    - Build temple if stone in gatherRange

    - Build barracks

    - Build temple (if not already)

    - (Maybe defensive structures right now but don't think so)

    ----- T3 -----

    - Advance to T3

    - Build a building crew (10-20)

    - Build 5 fortresses at the border to the enemy

    - Build non-preasant production buildings (for heroes, elite, siege)

    - Build a defense force garrisoning in buildings good versus siege weapons that can be garrisoned anywhere(10-20, heroes/elite(unmounted?), CS (unmounted?))

    - Build one of all non-present building types

    - Expand territory with CCs near fortresses

    - Build a hunting force of 5-10 ranged mounted citizen soldiers

    - Further expand territory with CCs near fortresses

    - Build 3 fortresses at the border to the enemy

    - Build an attack force depending on civilization (Preferring ranged mounted/siege towers, heroes, catapults and rams)

    - Further expand territory with CCs near fortresses

    - Reinforce attack force until current pop-cap

    ...

    - If popcap is reached -> Attack with all soldiers but foot citizen soldiers

    In between sometimes check if markets could be placed better and raze unneeded fortresses (IMO the number shouldn't be limited but fortresses should be balanced though they are about to be balanced already) 

  5. Academies. Rome total war have names Scriptorum something like that. but the 0 AD team dont want create more structures

    I would prefer less races with more structures (to keep the art work reasonable) to increase the length of the build-up phase in witch strategic decisions weight heavily and allow different tactics.

  6. A Roman spy would be a speculator. In Latin class we're translating Caesar's Commentaries on the Gallic Wars and it was on the vocabulary list :)

    Gallia est omnis divisa in partes tres, quarum unam incolunt Belgae, aliam Aquitani, tertiam, qui ipsorum lingua Celtae, nostra Galli appellantur... ;)

  7. I think he's talking about playing a random map

    When you go on Matches > Random Map, the default civ for all players is Hellenes. Because they don't exist anymore the civ selection dropdown contains no text. When you click start, it warns that Hellenes aren't a civilization (but it still starts the game).

    Indeed. I thought it would happen in scenarios as well. :self_hammer:

    Let's all breathe. Easily fixed. :)

    True. I just didn't find where but:

    Just figure out a new default for simulation\data\player_defaults.json.

    I'll just make it alphabetical for now. Is that okay with everyone? :)

    Yep

  8. the pop limit increase of a fortress - sure, could be added. I don't personally see much need for it as the change has already been done though + it's one of those things you quickly learn :)

    The amount of food a farm grants is shown (the right bar, hover over to see exact amount).

    Not sure what you mean by "attack bonus", it does say which units a unit is bonused against/which are bonused against it if you hover over the unit portrait with one selected (ok, it does say "counters/is countered by", but the meaning is the same). If that is what you mean :unsure:

    I think pop cap bonus sould be seen even of it's already added.

    I forgot about the resource bar, your right and it's nice and consistent.

    The quality of the attack bonus is shown, yes, but not the quantity. Is it a multiplier and if how high ('x1.8 vs. cavalry' e.g.) or a fixed amount ('+12 pierce/+8 hack vs. cavalry' e.g.)?

  9. It would be possible, but then the GUI would be more crowded/or we'd have to remove other things. I'm sure there will be GUI mods though that might do something like this :) For the main version we're not very likely to change it though as unit stats aren't something you generally need to access quickly (apart from health/loyalty, but those you get easily displayed with the colored bars for a quick check and hover over for more detail).

    I agree. I'd like to be able to see more informations though. For example the pop limit increase of a fortress (can be seen in the build menu of a worker able to build it but not in the fortress itself AFAIK). I think there are others like the attack bonus or the amount of food a farm grants. Not sure about all of this but I think they should be viewable in-game though most only by tooltips/mouse hover (how is this called :shrug:) to keep the GUI clean. 

  10. Welcome to the 0ad community :cheers:

    2. The European wars expansion pack for Cossacks had a nice little feature that helped me a lot: "Peace Time." If you chose this option, you could choose increments of time (up to one hour, if I remember correctly,) that the computer would not attack you. If it did, it would lose that unit. Likewise, if you attacked during that time, your unit was automatically destroyed. Is there any way of including this feature in 0 A.D.?

    I like the idea of a peace time. Not sure if it should be a standard option but some maps could have it. One hour seams long to me but that's details ;)

    I didn't like Cossacks though... Played it a weekend and noticed that pumping arches is the best way to go. Extremely cheep and can attack buildings... Siege weapons that could be captured together with units (mostly) unable to attack buildings and a unit AI chasing units instead of attacking targets in range made the chaos perfect. Hot discussed issues in 0ad as well ;)

  11. First of all thanks for your detailed reply. I think that perhaps it was necessary to wright everything down and I feel a bit ashamed I left it to you because I could have written the expected stance behaviour and it purpose myself though ofc. I would have had to assume more than you since I don't really know it. So perhaps it was best that way.

    Phew, that was a lot of text, hope it all makes sense. I hope I haven't left any unfinished sentences/points somewhere, if so I blame them on being tired and ask that you'll require me to explain myself tomorrow ;)

    I think it was quite understandable and I don't really mind missing ends of sentences :D ...I didn't noticed any though.

    If we're able to implement formations in a useful way though the units will fight in/as a formation and not be scattered unless the formation breaks. We'll have to see exactly how formations end up being implemented, but one thing that has been suggested is for them to work like "if you put a group of units into formation they will essentially be as one big/wide unit, moving together, taking damage together, dealing damage together, and not break up unless either the user breaks up the formation or enough of them get killed that they're too few to be a formation so they get scattered as individual units".

    If you do this I think it would be a good idea to have a button that ties the units together.rather then tying them just by selection. Afterwards the single unit cannot be selected but only the formation as the whole. Another button could split the formation into single units again. If the damage is split to all the units in a formation it will be quite overpowered because focused fire will not work against them any more (and it's unrealistic btw.). I don't mean I'm totally opposed to this idea, I just want to say that. It would be more realistic if the 'surface' of the formation would cycle injured or tired units with fresh units from the center. Dealing damage together is even more overpowered and exactly the opposite of what would happen if there where no 'together behavior' but only the shape was hold (I will assume now what that could mean because I don't know better): The units all can deal damage though the number of units at the surface (for a square only squareroot of the number of units) is quite low (and so in reality most could not attack). It seams to me (yes I am assuming again, what can I do :P) thats more like forcing the issue to be effective than realistic.

    There are 3 ways that could make formations effective witch come to my mind:

    - Treating a formation generally as one big unit as you (or Michael) suggested: Most unrealistic and overpowered but simplest to implement I think. Feels to me like forcing the issue though.

    - Keeping the units together in a well defined shape and make this as efficient as possible (e.g. cycling the outer units and heal the wounded inside): More realistic but still not effective enough. You'd still have to add damage or armor bonus (Armor would be more realistic due to shielding each other) to make up for the loss on surface and with it the loss of potential damage of melee fighters. That would be harder to implement though I think.

    - The second method with an added moral (less moral -> less damage) and stamina system: Most realistic (see below). As hard to implement as the second idea and additionally a moral system to implement.

    I think psychology was the main advantage of formations. In battle the own soldiers was surrounded by allies making them feel save. The enemy sees a big thing coming against them that laughs about (yes, assuming) ranged attack (though still they did damage but in the massive amounts of units it could not really been noticed. Neither for the allays that a friend has fallen/was injured, not to the enemy that their efforts had a result). With a veteran motivating the own troops and the troops believing (in) him because he won battles already. The enemy units (the prouder the better) feel provoked and go into melee combat. If you had a phalanx? (I think. Short sword, pilum, shield) the pilum was used to disarm the enemy shields and then mainly shielding each other and piercing through the gaps with the short sword. Spears in the second line was used against mounted enemies. Wounded soldiers was drawn from the front and replaced with fresh soldiers. That didn't only led to better performance per meter of the outline of the formation but also leaves only dead enemies on the front line - psychology again.

    When the Huns and later the Mongols came that didn't let themselves be provoked and often ambushed this strategy lost its main value. Later knights (moralized by a high social status) with heavy horse breast plates crushed the lines of the enemies though the maintenance of a knit was quite high.

    When bows got better and arrows reached a maximum momentum to break full body armors and shields the time of the knights came to an end... and so on...

    Just a little story and why I think formations had no big physical value but mainly a moral impact.

    Hmm, we're talking about the same thing with different words :P ...

    I still thing theres a difference between 'gluing' units together and making them form a nice looking shape... but ok...

    There is a "scatter" formation [...] but that could be changed to work like what you suggest, or something similar, where the units move together, but aren't set up in a predefined shape but rather just moving near each other to the same goal.

    That would be really nice!

    Hmm, partly we're getting into a philosophical discussion here :P "What is a player order, and how do you define it in a way that includes all possible situations?"...

    I totally agree :P. Though if you do it with stances you have to click 2 buttons instead of one additionally to what you said. But since stances are in, it still could be done with them. I could live with that ;)

    And here comes some deeper/better arguments for stances as a whole than above :P

    Yes, of cause you are right. I will perhaps not use them much but it has benefits and I was stubborn not to agree with that in the first place. I think I just wanted to make it crystal clear that unit stances interacting with everything (especially player given command with some exceptions like e.g.auto explore) isn't a good idea but as I get it, it's more the missing order priority system.

    Not sure exactly what you're asking for here :unsure: Are you talking about what you mentioned in the first sentence here or something else? If so I don't think it should be a part of stances at all, but rather of a more basic priorities system, something like: "a direct player order takes highest priority, even if it would be more logical from other code to attack a nearby unit it would still attack another unit further away (it's a bit hard to decide what the units should do if you've given them a direct order to attack - or for non-siege later capture - a building, but units start to attack them, should they continue to focus on the building - direct player order - or respond to the enemies - direct threat?); next comes units attacking it; later nearby enemy units, later still

    enemy units further away but still within range/LOS. Apart from that there should be another priorities system so e.g. melee never attacks ranged units (unless by direct player order), cavalry prioritizes ranged infantry, ranged infantry prioritizes enemy melee infantry. And apart from that there should be the stances which should define e.g. whether the units follow enemy units far away or not, whether they stand still even while attacked etc. In other words, even if set to aggressive units should still attack an enemy unit they have a greater chance to defeat, the stances should just define e.g. how far they pursue them/whether they attack at all.

    I'm speaking of the behavior of units in battle determined by the unit AI. First the order priority that would do best in general IMO: 1st: Player command. 2nd: Unit AI command depending on unit type, chosen stance and chosen formation: 2a: Be effective: Before starting to move check if you could attack instead. 2b: If attacking check if you could attack a more vulnerable target for your attacks instead. 2c: If you have to move, focus on a target that attacks. 2d: If no attacking target is near and you have to move focus on a target that you can catch.

    I think you want 2a and 2b swapped. But exactly this leads to the strange ineffective behavior. it's better to attack a decent target than not to deal damage at all!

    What I was asking for was a stance that does something like that. Before moving check if it can attack instead...

    There may be an other priority before 2a that handles targets to avoid. However this has to be set carefully! It only should effect siege units avoiding non-siege units and piercing units to avoid buildings and rams. If you can deal more then 1 damage per attack to a unit, attack! By the way, ranged siege units should be extremely vulnerable to any hack/crush attacks. Think of a swordsman cutting a catapults rope - the catapult is useless after that. In addition ranged siege units shouldn't have that high piercing armor - Someone has to operate on it. IMO siege engines should have to be guarded. Until now 2 catapults win against 10 citizen melee soldiers... and there's nothing planned to change that AFAIK.

    But here we got the issue by it's throat. The combinations available by unit type, stance and formation is that high that it seams impossible to implement really sensibly or a notable game play impact IMO.

    If the player gives an order to attack a unit behind a battalion of enemies it's his fault, not the programmers...

    Just to make sure I get it right: (Please tell me if I'm not):

    - Unit type handles the attack priority and the units to avoid (wich AFAIK is the same as attack priority as planned) and the targets able to attack at all (which I doubt should be (widely) used)

    - Stances handles how far units leave the position they where send by the player

    - Formations handle the shape the units are forming, stat changes (movement speed decrease, armor increase, attack increased) and the damage derivation (overpowered IMO)

    but the RAM aries dont have behavior buttons.

    Sorry, oversaw this one. Yes, indeed that's another problem... It will be fixed by order priority though.

  12. To billt79: Sorry that I tore everything apart here :blush:. Your Idea is good! It helps with finding the last peasant of an otherwise defeated enemy as well.

    And I'm probably confusing myself over all the replies so if something is unclear blame it on me and ask what I mean rather than assume I mean something weird ;)

    I have problems to get everything straight in multi reply posts, too :laugh: Sorry if I did assume something that wasn't meant, I tend to do that :pardon:

    But I fear the question I have to ask here is: Why do you want stances at all? What are you expecting from them?

    I never was thankful for stances in any game I played. If AoE II had attack-move instead of stances it would have been better IMO.

    Right now formations is more like "these units move around kinda close to each other" and doesn't provide much benefit/effect of any sort.

    I'm sorry. but it isn't like that. If the aim of the formations or it's actual state would be as you say to hold the units together as a bunch it would be a good thing because no single unit runs into the enemy and gets killed before the battle really started. That I would call it a 'glue' functionality that does not need a predefined shape at all. Warcraft 3 had it and I sometimes used it though you better turn it off if you flee. It's more like birds flying together but the shape changes. Mainly the unit closest to the target walks calm and the unit far away hastes to keep up with the others. To have such thing as an option (!) would be nice to have.

    But as is now units move to a somehow defined center (center of mass? Am I assuming something here :D ) to shape a specific form. So it seams (!) to me that its not a gameplay feature at all... it's a visual feature or a feature simulating massive troop movement as is was back then and that would be a style feature IMO. And that's where we are back to the starting post of this topic.

    Yeah, but that's not a player order ;) But rather an automatic order from the explore/search-and-destroy system :) My point was rather that player orders would not have to be taken into consideration for the auto explore/S&D system :)

    Well, I don't agree. For me there are only two options: 1: A player gave the order 2: The unit was idle and the unit AI took control over the unit.

    And since the player clicked the button its a player command from my point of view.

    I would say all player orders apart from move orders should completely ignore stances (even if they include moving to e.g. a building to garrison there).

    I think stances shouldn't interact with any player given orders. It should be an 'AI configuration' option exclusively. And in this case I ask myself: Why not make a unit AI capable of handling most situations well instead of adding multiple unit AI behaviors with each working well in less situations? That would be something like aggressive but before moving checking if any easier to reach target is present (for example the unit right next to the fleeing one). So I ask you to at least add a stance that acts as I suggested. Let the player decide what he likes most.

    That depends on how the groups/formations are implemented, currently they're explicitly tied to each other and a move order for a group of unit first means they have to form up into formation (and it would probably be a pain to have the formation system try to find out whether there are enemy units nearby and thus have the formation form up later). For most cases it should work fine though, so perhaps it would be wiser to add a "flee" command, where they would move directly to a safe spot? (Probably easiest to have the user set a spot rather than the game trying to find out where it's safe to go =) )

    Thats easy! Add a formation that applies the order to every unit separately: Something like a 'non-formation formation' :D. It's about the same as with the stances: Please, please add it and let the player decide.

    That ranged foot units are in general faster than melee foot units makes sense since they wore less armor and no shield. Still I think ranged can (but don't have to) attack close targets. I haven't fully made up my mind about that but melee units with piercing attacks or mixed pierce/hack attacks are quite useless for my gameplay already and that would reduce there power further...

    And I think it would be really nice if the player could set default stances/formations before the game as a player option.

    I just don't know how the final behavior is planned, so I cannot say much about it. I only don't see the needs for stances/formation/non-siege min. range/attack priorities/ attack boni/attack preventions. All of that can be done with unitAI, attack-move and armor/damage types IMO or has no actual gameplay value to me.

  13. Yes they are close to death, but i order to garrison into temple, but they don't go. RAM are same, they dont go into save to repair and fight even units.

    other occasionally bug are when melee units don't want attack to civ centre they marching but after they go to starting position.

    Yes, 1st and 2nd (not going into temple/save location) are because of the default aggressive stance. It's not a bug, it is meant to be like that by default (and I don't think thats a good idea). You can change the stance to defensive or passive for better behavior in this situation (but that doesn't really mean they will go there as fast as possible).

    I didn't get the last part though, sorry...

  14. all military units dont obey orders if they are under attack.

    They don't go into a save building because they are under attack?

    A ranged unit will not attack and maybe kill the melee fighter charging him?

    A melee fighter will not hit the enemy unit standing right next to him but try to reach an archer attacking him though he has to go through a battalion of enemies for that?

    When giving the retreat order a unit far away from the enemy will not backup the retreat of his battalion but charge back into the enemy?

    Sorry but I doubt that. It's not so much about not following the orders. If they would do something more effective than I have told them everything would be fine and I'd say 'Whow!, really nice!'. But its horrible inefficient. All of the units behavior. Starting with gathering: If a source runs out they don't seek the source nearest to the building they bring the resources to but nearest to them at the time the old source runs out... and wind up in enemy territory... 

  15. I'm not sure if this really counts as a bug, but Norton Antivirus' SONAR virus detection thinks that the latest pre-built SVN pryrogenesis.exe is a malicious file, and removes it when I try to run it (I do know how to ignore Norton). :D

    Anyway, the reason Norton gives for removing the file is that it made an:

    --Attempt to start a thread in a process address space--

    Don't know if most of this is due to it being an SVN file and thus new and not downloaded often, or to my having it installed in a non-standard location (C:\0ad). If the team already knows about this, I'm sorry to have been any trouble.

    I have no information for you. But I wouldn't mind if 0ad has a viral impact on the RTS community :lol:

    • Like 1
  16. There's no reason to complain about the future of a feature based on the present of another ;)

    In general I really like the idea of auto explore/search and destroy depending on stances. Perhaps I should have said that in the first place :blush:

    But only if I cannot persuade you to drop stances... And I think that is a sure thing.

    Search-and-destroy/auto-explore shouldn't need to take player orders into account as they should cancel out previous orders and later orders should cancel search-and-destroy/auto-explore.

    I think auto explore/search and destroy should be continued after units auto attacked something due to an offensive stance.

    Hmm, looking at your comment again I guess you might have been talking about stances apart from search-and-destroy/auto-explore all the time :P

    I just meant that it seams to be enough chaos with the present units behavior so it may not be wise to add a new feature for unit behavior before the present ones are under control.

    I.e. if archers would fire even if it's not 100% sure they would hit their target it's probably more likely they will actually hit something than if they're moving around to get to where they'd perfectly hit the unit they're trying to hit.

    Exactly! Units in range -> Fire! Target runs away but still a target in range -> Change target and fire! Though I don't get what that has to do with 'being exact'... It has something to do with maxing the damage output and after units focus on firing instead of running here and there than damage bonus and armor can be taken in account. If no one deals damage the unit behavior is obviously not that effective.

    Either way I'm almost starting to lean towards Michaels old pet idea of using battalions for everything =) Most of the unit behavior issues seems to stem from the the way individual units interact :P

    I don't really know what this would be... If it's similar to armies in 'The battle for middle earth' plz. don't! It reduces the damage dealt and the players influence on the units further.

    hmm i don't care if the explored will die, in EE can happens a lot of times, the Scout must be sacrificed if its killed that means the zone of map that is dangerous.

    I have no problems with a scout can be killed. I have a problem that the scout don't listen to my orders that would save him!

  17. I agree :) No reason to complicate things more than necessary imho :) Maybe we could display a dialog the first time a user clicks the explore button telling them the difference between exploring in passive/defensive/aggressive etc (though stand ground should probably not have any effect as it's usually used to have the units remain in place (though ranged units can still attack)).

    Nothing personal (indeed I like your calm comments) but "No reason to complicate things more than necessary"? :shok:

    If you insist on having stances I agree. I really think it will be really, really hard to make the units perform their work well though. There will be lots of possible combinations of stances, orders and formations and even different unit types may require different behavior to make sense (like foot melee versus mounted ranged with min. range).

    My latest comment to this issue can be read here.

  18. Bigmaster: Thanks for pointing all this out! I totally agree with you (Don't really mind the AutoQueue I think) and feel a bit alone with that.

    Some other issues I'm concerned about are unitAI/stances, formations, minimum range for non-siege units and target restrictions/priorities (planned). Until now there's no way to turn off formations or forbid the unitAI to override player commands or even a sensible stance. Some examples:

    - Player wants a combat unit to go to a destination, unit is attacked on it's way there. Result: The unit starts attacking before reaching the target as the actual default behavior.

    - Player wants to retreat multiple units scattered among an enemy base and gives a command to go to a save location. Result: All units closer to the save location will run further into the enemy base (to gather with the other units and form a formation). Even worse: If buildings and units in the enemy base are tight some or all units may not be able to get out of the enemy base in formation and thus running here and there without getting anywhere.

    - Player set the 'aggressive' (default) stance to a couple of melee units, an enemy ranged unit shows up and attacks them. Result: The melee units will go towards the ranged unit to be able to attack it and the ranged unit will run away to be able to attack the melee units (since he cannot attack from melee range). All units try to get in position to attack the enemy but they can't.

    - Player wants to garrison an attacked building, since he knows they will fight back he puts the stances to 'passive'. Result (quite often): One of the attacking units attack a unit with the garrison order. The attacked units runs away from the building he shall garrison (to avoid the enemies attacks the stance-supporting PPL might say). After a sec or so he returns to the old command (garrisoning the building) so he turns around an now walks towards the building again. Now the enemy attacks again and the unit to garrison turns around again... often until death.

    There are many other situations the units refuse to actually perform the players commands especially but not exclusively when time is of the essence like in battles.

    BTW until now the best way to move units is: Target an enemy unit and change order before the target is reached/give a garrison command and change command before target is reached/give the command to all units separately... well, have fun... :wacko:

  19. As long as it works for most maps, and then on the maps where it doesn't work we give them some defense towers, I think is more than acceptable. (y)

    I will add walls as iberian starting entities but will wait until all races walls entities are in place so I don't have to adjust things every few days...

    It would be nice if someone would add a comment when all factions have walls of the same length (and perhaps again if models are unique for all civs) as far as is planned.

  20. Depends on what you favor most: capturing or destroying.

    Will the player be able to capture garrisoned buildings? If not it's destroying anyways.

    Besides civil centers and fortresses and maybe towers the player don't have to destroy anything. It will fall apart on it's own.

    Is there a link where the capturing feature is explained in detail?

  21. The AI is a sub-section of the network synchronised gameplay simulation. The game provides a proxy representation of the state of the simulation. Direct access to the rest of the simulation is not allowed so that theAI can be safely made asynchronous. The proxy representation is a set of javascript objects, with one for every entity in the game, with appropriate properties. Diff's are sent each AI turn to keep the list up to date. This is done with the combination of AIInterface and AIProxy (simulation/components).

    The AI has the function HandleMessage(state) called each turn. state is an object with quite a few properties, see the function in base.js for more details. The thing which gives you all of the entity information is state.entities which is an object of the form {5: {id: 5, owner:1, ...} , 7:{...},...}. So state.entities[id] is an object containing all of he changes to an entity in the last turn. When an object is created then state.entities[id] will contains all of the properties for that object. The common-api applies the diffs each turn to keep all of the entities up to date for the AI.

    The AI performs actions by calling an interface called Engine.PostCommand() which sends a message to simulation/helpers/commands.js which runs the command. There are a few other Engine commands, which should be self explanatory (run a search on the AI folder to find them all). They are defined somewhere in the C++ (I can't remember exactly).

    THX! I think I will start writing the bot next week.

    As far as I get it and questions:

    - First each turn the data changed in the engine the turn before are applied to the BasiAI's data

    - BaseAI.OnUpdate() is the call for the actual custom AI script that should be overwritten in the constructor.

    - In opposite to the data update at the beginning of the turn (engine -> BaseAI) setting orders is send individually? Or did I miss a function sending a diff of orders from the BaseAI to the engine? And if it's like think doesn't it defeat the ability of the AI to be threaded (because of many interactions with the engine)?

    - What does 'settings' in the constructor contain?

     

×
×
  • Create New...