IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
> Analysis of Rcbot2, suggestions and improvements to Cheeseh and partners (and others V.I.Ps forum-members: genmac, madmax2, Emotional, Septien etc.), Observations, suggestions, request improvements and others...
Brief Survey
Do you think that the observations and ideas of this topic are important (partially or fully)? So, do you think that these ideas and observations (partially or fully) deserve consideration in the continuing process of Rcbot2 improvements?
Yes [ 2 ] ** [100.00%]
No [ 0 ] ** [0.00%]
Total Votes: 2
Guests cannot vote 
YuriFR
post Jan 22 2014, 04:55 PM
Post #1


Advanced Member
***

Group: Members
Posts: 51
Joined: 7-January 14
Member No.: 2,318



Analysis of Rcbot2 v.0.76, suggestions and improvements to Cheeseh and partners (and others V.I.Ps forum-members: genmac, madmax2, Emotional, Septien etc.)

I leave a reproduction of this topic attached (format .zip)


INTRODUCTION AND INSTRUCTIONS:

• This post this was very extensive, partly because I have difficulties with writing in English (and perhaps why my writing seems wordy, at first sight). I use Google Translator, without which it would be impossible for me to communicate with anyone on this forum.
Google Translator, however, is not perfect ... !

I ASK PATIENCE TO ALL READERS. I ASK APOLOGIES IN ADVANCE FOR MY ERRORS: in spelling, wrong emphases, misuse of idioms, misinterpretation of the meaning of sentences, confusion between cultured and popular standard, among others.

When I use the term "Rcbot" or "Rcbot system" or "Rcbot2", i'm always referring to the same program (same software structure), irrespective of versions (1 or 2 etc..).
The technical term "AI" refers to "Artificial Intelligence".
The term "bot" refers to soldiers controlled by artificial intelligence of Rcbot system (or other system like Sturmbot).

This topic relates SPECIFICALLY to Rcbot system for Day of Defeat: Source. This post is a DETAILED REPORT of the results of the tests that I undertook with bots of Rcbot2 v.0.76 for Dod:Source. I'm a HARDCORE fan of Day of Defeat series and I made sure (i've certified) of the quality of Sturmbot-system for Dod-Classic and i approved him. I also enjoyed the Rcbot system, which surprised me POSITIVELY. I envision one VERY PROMISING FUTURE FOR RCBOT SYSTEM. Largely for this reason, I intend to contribute to Rcbot, (the best I can), for your development. Despite my many limitations!
• Whenever possible, i made observations about Rcbot, with references to Sturmbot. My intention is NOT simply compare the two systems. Not interest (me and here) know which system is better and which is worse, in an absolute sense, the goal is other: is to show (at who does not know) as Sturmbot works in the context of each of the reported observations to Rcbot, in order to stimulate the emergence of new ideas and solutions to Rcbot, based on a pre-existing (and solid) system; i.e: a system for bots who already proven/consolidated itself. Thus i intend that Sturmbot can serve as a "system-support" for the evolution of Rcbot, going forward: for each observation about Rcbot, the Sturmbot shows a possible solution, or implemented resource, or a different idea that was successful, or unprecedented things, much them yet nonexistent in Rcbot.
• It is NOT my goal criticize negatively the Rcbot system. On the contrary: I want the Rcbot IMPROVE EVEN MORE BECAUSE HE SHOWS THAT IS A VERY GOOD SYSTEM, AND SHOWS A VERY PROMISING FUTURE.
• This topic also seeks to satisfy a suggestion (perhaps a kind of "request") of mr. Cheeseh, in this post: http://rcbot.bots-united.com/forums/index.php?showtopic=1709 ; namely: try the latest version of Rcbot2 (version 0.76) for Dod: S, and make general comments about the program / system (observe what can be improved, what is more important etc..).
• I created this topic, and i made this post with the intention of continuing another post (link: http://rcbot.bots-united.com/forums/index.php?showtopic=1709 ). This topic will be better understood from reading the other post, quoted above. This present topic does not delete the comments, suggestions, ideas etc.. of the same previous post. On the contrary: this post complements the other (and maybe reevaluates some observations made in that previous other post).
• I invested a lot of time to write it (over 2 days). First, in my native language, then translate it into English. No details spared. I suggest you take a time to yourself, to be able to read it all at once, without interruption. And... please: read carefully (one sub-topic is always related to another sub-topic or sub-thread).

• This topic (and this post) is the result of tests that I did with Rcbot2 v.0.76 for Dod:S. on my computer. I stayed also for 2 days, focused in it, making these tests, and jotting down notes about the observations. The software ran relatively well: there were no lags at various maps. In larger maps, and with the total amount of bots (all of them with very high settings for skills), there were some lags and the game became slower. I tried to establish a certain amount of bots that not disturb much the performance of my PC, from this amount of bots i started the tests, only varying the skill level of the bots. I post just below a summary of the specifications that i used for the testings:
The number of bots was between 24 (good performance) to 32 (lowest performance), in total. On my system, I set the amount 24 bots in total, for longer time (like a “default” to tests).
In general, i established higher rates for the skills, for example: "visionticks_clients = 28 | visionticks = 75 | pathticks = 172". I modified these numbers down as well, but no modification changed the content of the comments/observations I have made here in this post.
The skills "braveness | aimskill | sensitivity" were also modified several times, without significantly modify the content of comments posted below.
I established more stable values for the following skills, staying around on the following numbers, along all the test battery: "rcbot_defrate = 0.13 | rcbot_skill = 0.94 | rcbot_anglespeed = 0.68"



SUMMARIZED INDEX OF SUBTOPICS:

1. Bot “perception” of firearms and explosive devices
1.1. The perceive of the origin of the gunshots
1.2. The perceive the “bullet impact” hitting the environment.
1.3. Expositions of bots, unnecessarily, to enemy gunfires
1.4. Negligent behavior even when bots anticipate the bullets impacts, at distance

2. Perception of noise from the enemies, and reactions

3. Perception of risk during the paths / routes

4. Improvement of some movements of bots in Rcbot
4.1. Prone and crawling
4.2. Simultaneous movements: opening fire, taking cover, responding fires
4.3. About “go in crouch” and “go to run” and improvements
4.4. Bots and walking crouching
4.5. About tactic movement "shoot firearm and evading to the side"
4.6. Changing main weapons to guns found on the ground
4.7. About interruption of walk to engage the enemies, and return to old path
4.8. Adoption the resource "always vocal response to the commander"

5. About close-combat (“hand-to-hand”)

6. Throwing grenades and responses to them
6.1. Warning and speed of run-escape of grenades
6.2. Frequency, timing, accuracy and stances to throw hand-grenades

7. Deploying Snipers and automatic machine-guns
7.1. Insignificant and significant places and (preserve) randomness
7.2. Postures/stances to deploy weapon: exposing the body
7.3. Small bugs on mechanism "deploy guns", bad choices and exposing the body
7.4. Deploying Snipers and MG, fixed position on the ground
7.5. Important problem with the perception of the enemy, (on surround area), while deployed

8. Brief note on "form(ing)-squad"

9. Latest considerations


-------------


1. Perception of risk in the environment (firearms and explosive devices)

1.1. Bots are still not able to properly perceive the origin of the shots of firearms (and explosions) "BY SOUND" that gunshots produce, regardless if the projectile hits a building/obstacle or if goes skyward. That is, the bots are still unable to use the DATA "(sound) of gunshots and explosions" to locate the position of the enemy who is carrying out these gunshots and throwing these bombs. Because from this, with this failure, the bots are not yet able to calculate the risks they are exposed to every moment of your route or every moment of confrontation. Consequently, the bots are not enabled to use this perception as a relevant data/information on which to base their conduct of reaction to the event (and so, acting reasonably and take corresponding measures to the characteristics of the attack from the enemy: direction and number of attacks). As an example of reaction, the bots could: pointing in the correct direction of the enemy and retaliate the fire immediately, or crouch/prone, taking covers, throw hands grenade, inform around squads about the impending danger, make a quick withdrawal to behind friend lines to rally forces, flank the enemy position, drastically change of course or path (look for a way to facilitate the response to fire or circumvent/avoid confrontation with the opponent in question) etc. . etc. The Sturmbot is able to detect the sound of gunshots (and voices), but needed further optimize these resources.
In Rcbot2 I spotted only THREE exceptions to this observation " 1.1 ", and that will make the bots react to shooting of firearms (and bomb blasts) of the enemy:
a) in the case of directly seeing the enemy firing (and see the grenade or other bombs dropped on the floor near them), and ...
b) in the case of seeing a partner being slaughtered specifically for enemy Snipers (perhaps also by an enemy machine-gun, now i can not remember...), and ...
c) in the case of bot being hit directly by a non-lethal fire-shot, and survive.

1.2. Bots are also not able to perceive the enemy's projectile hitting the walls, floor, ceiling, and other structures (glass, objects etc.) near them, and so are unable to use this event (" ballistic impacts on the surrounding") as a relevant "data to compute" (information) in their structure of "reflection/reasoning " (part of the AI responsible for formulation of plausible "lines of responses" to the threat in the environment). I better explain: bots do not understand that ricochets or explosions surrounding them (or around the area a partner next to him) indicate that he is under direct sight (or under close indirect threat), and is therefore exposing themselves unnecessarily. As the ballistic event is not perceived, or computed, the bots no takes sensible attitude for self-defense/protection or counter- attack measures. This failure of perception also includes the circumstances in which the bots can see the indirect ballistic impacts with much anticipation (eg: see a partner be slaughtered in front him, or see, by far, the ricochets in the buildings). The Sturmbot could also provide bots with a feature of "perception of ballistic impacts", but that did not work 100 % (similar to the case in item "1.1").

Due to the items "1.1" and "1.2", the behavior of the bots falls short in terms of prudence and caution. The 3 exceptions of the item "1.1" also apply to this item "1.2".

1.3. Does not always happen, but the next event is frequent: the bots that are exposing themselves unnecessarily to enemy gunfire and have not yet located them (as described in previous items), stand still with his back (or side) to the source of the gunshots (or explosions) without any sketch of reaction. Remain for a while as if they were "unconcerned" with the risk of being hit anytime. A minimally reasonable behavior for this circunstance would be: once the shots are perceived, bots must crouch, or go in prone position, or retreat/evade, or just rotate the body in contrary direction to the ballistic impacts on the structures surrounding, aiming to find the source of gunshot (the enemy) and act against him. The Sturmbot always had this same flaw/defect, which was never fully corrected by Johan Linde. And this characteristic has always irritated me (one of the few very negative critical points of the Sturmbot system). The exceptions "b)" and "c)" in the item "1.1" also apply to this occurrence.

1.4. Bots step into places or regions that are suffering intense ballistic impacts by guns and explosions, carelessly/rashly. Many go inside this way, and die, and are followed by many others (all ignoring the death of the previous waves just ahead). The bots that enter these territories tend to always repeat the same pattern of "negligent behavior". The Sturmbot was a little different, it enabled them bots with a kind of "sense of caution" (self-preservation or self-defense): at the sight the bullets impacts in buildings, in real time the bots stopped walking, "thinkin", and look for rework their routes and actions measures. When resuming the walk and observe the resurgence of gunshots (reaching the environment), they stopped again to reassess the degree of danger. However, the attitudes they took soon after were not perfect, and many bots after their stops did not change theirs routes (or measures of action) and continued on the same path until to get shot of firearms and die ...

2. Perception of risk in the environment (noise from the enemies: footsteps of soldiers, voice commands, doors opening or closing, falling of objects or soldiers, cries, explosions, "fight melee" nearby, etc; & visible lighted lanterns)

The bots yet not react appropriately to these environmental variables listed above (especially the sounds). Even when they occur in quiet places (away from the "hot" combat sites). The most recommended conduct for the bot that passes through an empty and silent region will be: when they hear these sounds nearby, coming from another bot (or human player) belonging to the opposing army, the bot should abandon its route temporarily and go to the site, with caution, to verify and take offensive measures. Based on these noises, the bot does not need deviating too much from its normal path, no need to travel long distances in order to search for the presence of nearby enemies. But the bot should be able to do a quick search and short within a radius of action/intervention that is plausible for him (that makes real sense). What I mean is: introduce a little bit of variables "curiosity" and "conduct patrol" into Artificial Intelligence of Rc bots. The Sturmbot possessed this ability, but there was a limitation: only a noise very close can able to arouse the attention of the bot (equivalent to 1 or 3 meters at most). And yet nevertheless, the bot didn't use much effort to "hunt down" the opponent that made the noise. This would probably be improved by Johand Linde, but it was not ... ...

3. Perception of risk in the environment: during the paths/route between waypoints.

In the Sturmbot there are many kinds of waypoints, in this post interested two types: a) "precision waypoints" and b) "common waypoints". The diference between them is that the former establishes the obligation of the contact between the bot and a specific waypoint, and the second is more flexible, allowing a significant degree of deviation in the path between a waypoint and another waypoint, but without exaggeration. The first was more used to force a bot to go through a very narrow path and avoid problems (such as: climbing a narrow staircase, pass through a tight alley, walking near slopes and abysses etc.), the second was widely used (as standard) throughout the extent of the map. I think it worked that way... What I want with it all ...? See below:
If Rcbot2 works also using "Common waypoints" (non-precision) as "default", you can add for bots, in the script, self-defense behaviors during the travel between "common waypoints". For example, I will use the following assumption: from a point 'A' to another point 'B', the bots crossing an open plaza and ample space (eg: the main square of the map "dod_anzio"). Rather than always follow the path straight 'A' --> 'B', bots can make small deviations, sub-routes through obstacles and things that provide coverages (protection) during movement of bot progression (between 'A' and 'B'). Or, in the absence of elements which provide protection, the bots would make like rats do (in real life: avoid open spaces): walk along walls (protecting theirs "side back"/shoulders) until when it is no longer more possible (eg: point where the end of wall forms an oblique or right angle, in relation to destination point 'B'). If you decide to implement this feature, you can make it work as "default", for cases in which the bots walk through wide open spaces (which in theory: expose the bots to enemy gunfires). And do make this as optional (or random) when the bots roam tight hallways, alleys, or relatively enclosed spaces.

4. Improvement of some movements of bots in Rcbot.

4.1. Sometimes I saw the bots of Rcbot go in prone in combat. Initially liked it because it could be intended to protect himself. However, often the bots crawling sideways for no apparent logical reason to do this - i got to witness a scene in which a bot crawling sideways in the absence of any enemy in evidence at the site (a battle had occurred there earlier, but no bot opponent still there). I think the bots should be able to crawl, as I have already explained in this and in the other posts (see below), but must do so with some rationale and purpose (at least I was not able to clearly understand the specific reasons justifying this attitude of "creeping sideways"). Sturmbot bots are also able to crawl (can crawl in certain situations, including, for several meters without getting up). But do this following a more rational purpose (such as: suppressive-fire protection, search for take cover against intense gunfire, escape from grenades, attempts to flank the opponent, attempt to kill an enemy that is very close, and also in prone, using the bayonet or knife etc. etc.), as I detailed in the other posts (check on link: http://rcbot.bots-united.com/forums/index.php?showtopic=1709 ).

4.2. The bots in Rcbot, when they are surprised by many distant enemies, in front of them, also should be able to open fire and simultaneously run in the direction of obstacles on the way, with the goal of establishing good shooting positions and get enough coverage and protection (eg: behind concrete blocks on the streets or low walls of stone, behind sandbags, go to corners of walls, behind czech-hedgehog, behind cars or armored vehicles, behind an open window etc. etc.). Once the bot to gain good coverage, he can continue and keep your gunshots (alternating between the following movements: gunshooting, escape/evade of fire-retaliation: crouch or go in prone behind coverage, and return to shoot against enemies... and so on ... repeating the process). The tactics described above no need always be activated, either will become very predictable, but should be widely used from time to time, occasionally/periodically, providing a more richer combat experience, more actual or verisimilar, and much more varied. I'm sure that these resources will be nice and very cool in Rcbot2! Sturmbot was able to provide to bots some rational use of coverages, in combat situations.

4.3. I feel missed of some movements in the Rcbot 2, more present in bots of Sturmbot (and more present in real life and in game between humans), both movements: “go in crouch” and “go to run”. The Rcbot is able to make bots crouch, and more rarely: make the bots go to run. I think the frequency of use of these movements should be increased in Rcbot, at least a little more. Many, many times the bots of Sturmbot go in crouch in order to get more accurate gunshots and minor setbacks (recoil), mainly (but not exclusively) when the bots used sub-machine guns (eg: MP40, STG44, Thompson, BAR). Bots (Sturmbot) also crouched with rifles to gunshoot, but less frequently than bots with sub-machine guns. Alternatively, bots of Sturmbot (regardless of his class), were also go in prone aiming to improve the chance to hit and reduce as much as possible the gun's recoil.

In Sturmbot , the movement "run" was set to execute through specific waypoints along the routes, the only exception to this rule is the perception of grenades on the ground around and consequent leakage "racing" (see sub-topic below). I always considered this particular feature of Sturmbot a little bit restrictive: I think the movement of running might be sometimes employed in certain specific situations of much danger, regardless of whether "run waypoints", such as: emergency withdrawal straight-line ("fall back"), escapes of very intense gunfire going in the lateral direction (right or left), escape quickly of the area controlled by some Sniper, crossing an area that is in the perpendicular under heavy fire of machine-gun/MGs (eg: the area to cross forms a letter "T" in relation to MG: bots go through the upper extension of the "T", which is under control of the machine gun positioned at the bottom of the "T"; i do not mean that the bot should run in straight-line toward the machine-gun…!). Perhaps, more other situations may be thought for use of "run movement" to Rcbot. Another point is which the Rcbot should improve the "speed of run" and "time of run", when the bots are running: i think that the bots are performing very short runs and with a "speed racing" perhaps below the maximum (compared to observed in Sturmbot: in there it was satisfactory).

4.4. In Sturmbot is relatively more common to see certain situations where the bots walk crouching. In Rcbot it is also possible, but so far i've only seen the bots walk crouching for a very few meters and only in situations where they were ambushed, without possibility of withdrawal (eg: grouped, defending a last flag of opponent's attack). I think that more situations ("walk crouching") can be added in Rcbot... would be nice!

4.5. The bots in Rcbot should use with more accurately the resource "shoot firearm and evading to the side" (gunshot, and flee of fire-response, going to right or left side / flank). I've seen the bots Rcbot perform this procedure, however, the bots just take a few steps towards the lateral and could to protect yourself more, with (a little bit) longer steps. If i'm not mistaken, the bots of Sturmbot walk sideways by a slightly greater extent. Another thing: the Rcbot-bots when in combat, could also have the ability to switch between shooting positions ("standing", "crouching", "in prone"), once in a while, with the intent to hinder the accuracy of the opponent's gunshots and minimize yourself damage. In turn, I think this option can only is valid if the shift of position does not significantly impair the accuracy of the shots of the bot itself.

4.6. The bots in the Sturmbot (only last version 1.7) could change their main weapons for other weapons that were (thrown) on the floor (friendly or enemy weapons). The bots did this change once in a while. I did not know identify the reasons for this changes, beyond the possible motive "run out of ammo". This aspect ("change weapons") can also be thought to Rcbot. However, I think the frequency of exchanges of weapons should be less (in Rcbot) than the existing frequency in Sturmbot (the frequency of changes was exaggerated).

4.7. I did some testing in Rcbot in order to verify the operation of the resource "bots interrupt your journey when they spot an enemy out of him, engages the enemy to kill him, and returns to his old route". Based on the results I got, my opinion is that this feature MUST BE MUCH IMPROVED. Why i think so? Because many times I teased bots, exposing myself to them and then i hiding (and evading your gunshots), aiming to lure them out of their routes. In fact, i noticed that the bots deviate from their routes to kill me, but deviate VERY LITTLE and DESIST QUICKLY OF ENGAGEMENT. The Sturmbot promotes a longer engagement than Rcbot, and yet I felt that the time and distance were still insufficient (and implausible in relation to the behavior of a soldier in a real situation, or to a human playing Dod : Source in internet) . In my opinion , a bot should be PERSISTENT DURING ENGAGEMENT out off course; obviously to a certain limit. It is not necessary, nor desirable, program the bots to undertake a long and relentless persecution, or an engagement that scroll across the map. But the bot should be able to abandon their old route PERSISTENTLY, once noting the threat of an enemy outside them, and pursue it in several situations: climbing and descending stairs, entering homes and buildings, jump into holes in the walls of buildings, etc. . - to kill the enemy, within a reasonable radius of action, a distance equivalent to several meters in all directions (you must stipulate an amount for it, maybe 10%, 20% of the map? I don't know...). If the bot follow the entire extension/range determined, and he can not kill the enemy, he returns by the same path toward its old route. This is the core of idea. It is important that, during this return, the bot look back with some frequency, in order to defend its backs.
One important detail: bots of Sturmbot only engage the enemy off course, if the enemy is seen evading (hiding, or going around a corner), ie: 1°, the bot sees the enemy off course, shortly after (2°) the bot shoot against him (but misses the shot or: enemy survives), and 3°: the enemy does not fight back (do not "shot/fire respond") and evade the site. More or less like this, only with these 3 conditions that the bot starts the procedure of "engagement off course".

4.8. According to my other posts (i will not detail here)*: insofar as it is being added new voice commands (among bots) in Rcbot, and corresponding behaviors, remember to also add the corresponding gestures, and a verbal response of bots at command-voice of commander: "Yes, sir" for if so (and "yes gesture" with head) and "No, sir" to if not (and "negative gesture" with head). I'm basing myself once again on the legacy left by Sturmbot. Although this seems a silly detail, even throwaway, he CONTRIBUTES GREATLY TO THE ATMOSPHERE of the game Day of Defeat. Although it not seems, at first, the lack of response cries impoverishes the experience of the game, and its lack is felt.
* Link to the same old posts: http://rcbot.bots-united.com/forums/index.php?showtopic=1709 .

5. Fight "body-to -body"/"hand-to-hand" (close combats).

As I realized , the bots Rcbot are actually able to use "spade tools" or knives to attack the opponent in hand-to-hand fight (skirmish within walking distance) instead of conventional firearms. However, the bots only shifted the conventional gun for shovel or knife, when their main (and secondary) weapons were fully discharged. This phenomenon is logically correct and should be maintained!, but there is a problem regarding this issue (close combats): i witnessed a curious scene in which two opponents Rc-bots suddenly collided among themselves in the doorway of a room, as they were too close one to other (touching each other), the bots found some trouble hitting gunshots at very close range. They stood looking at one another, and firing unreliably, once in a while, until a bot finally managed to kill the other. In Sturmbot this does not occur: as soon as that two opponents have collided across a short distance ( 1-2 meters at most, or less than 1 meter: contact "body- to-body"), they immediately change their main guns (fire-weapons) to knives or shovels, the bot that is faster in this change, gain an advantage, and probably be able to strike the opponent and wins. This feature can be adopted in Rcbot, it will solve the double-problem of aiming and hit the gunshot for very short distances and, at the same time, turn the close-combats coolest!, interesting and realistic (eg: i refreshment our memory, using the "fight scene" with knives between a German and an American soldiers in the movie "Saving Private Ryan").

6. Throwing grenades (and explosive devices) and response to grenades thrown by the opponent.

6.1. “Rc”-bots are able to realize the grenades the enemy on the ground, thrown against them, and notify their partners around. Bots of Rcbots are also able to escape. However, they do not take a quick and satisfactory (effective) reaction against the threat posed by grenades. Example: escape running as much they can, all the way out of the "area impact" of these explosives. I saw the bots evade of local, moving relatively slow for that situation (maybe a little faster than usual, but not running enough!). With this behavior Rc-bots conveyed an unrealistic impression: as if they were not "impressed" with the inherent risk of death by grenades (note that in real wars, the soldiers has a big fear of being maimed or killed by hand-grenades - a similar reaction happens even with human players, in war games for PC: all of them try avoid the grenades, the maximum possible...). The reaction to hand-grenades, by the bots of Sturmbot, are more consistent (and quick) than reactions in Rcbot: they run with maximum speed, all of them disperse, and go in prone behind obstacles, such as: sand bags, entries, holes on walls, shell-holes in streets, or even in ground (but far enough from the grenade). In Sturmbot can occur some bot not see the grenade on the ground and die because of this (plausible act that can happen in real life too), but if a bot on Sturmbot perceived the grenade he will flee and alert her to any other bots in the surroundings, with frantic gestures and cries (saying: "Grenade!"). The other bots, warned, will also try to escape of the grenade just as the first bot he saw. In my opinion, the Rcbot should adopt the same behavior / reaction used by Sturmbot. A strong argument for adopting this change: I witnessed bots in Rcbot die because not ran enough (far away from hand-grenades) and because the bots coming from back not heard the cries warning ("Grenade!").

6.2. The bots of Rcbot throw grenades, but I noticed they are more biased in throw explosives by their firearms, instead of using the classical hand-grenades. My opinion is that this feature must be reversed. Another thing that can be changed (increased) is the frequency and accuracy of throwing the hand grenades: the bots must throw hand grenades a little bit more often, when appropriate (see explanation below), and with better "hit rates" for hand-grenades: make it a bit more accurate. Bots of Sturmbot can serve as an example again. They threw their grenades based on a very sophisticated "timing" ("sense of opportunity"). They were able to understand various combat-situations, and respond to them with the racional use of hand grenades, such as: clustering of enemy troops, heavy shootouts (during a medium period), if the friend team is suffering a fire-suppression, on cases of deadlock / standstill in the lines of contact between armies (no faction move for advance or indentation), in cases of numeric disadvantage against the enemy, bot get ambushed/cornered alone, several unsuccessful attempts to kill someone with firearms, presence of machine-gun nest, sighting an inaccessible Sniper, defending the last flag, support the withdrawal in an emergency case etc. .. All these situations are conducive to the use of hand-grenades. It's amazing, in Sturmbot: every time I thought " this situation (fighting) asks hand-grenades" opponent bots threw their grenades on me and my team! However, the Sturmbot does not employ the philosophy "always the same solution for to the same problem", and the measures-actions of bots varied (perhaps with the use of probabilistic ... i dont know...). Thus, the context of the fight became more realistic: more unpredictable (and therefore more dangerous) - what's good!
Another feature that i not have observed in Rcbot (not sure if there is or not...), but there is in Sturmbot, is the ability of a bot efficiently launch a hand-grenade into any of adoptable possible positions: "standing", "crouching" and "prone". The Rcbot could also implement this feature, if not have in there.

7. Deploying snipers and automatic machine guns (MGs, .30, .50 etc. )

7.1. Bots of Rcbot2 are able to deploy snipers and machine-guns (the Sturmbot also had the same feature). Often the chosen location is good and is sufficient to cover fire and help curb the advance of enemy troops. But sometimes the bot that controls the machine-gun or Sniper insists deploy your weapon on totally insignificant places. An example: bot deploys the weapon in 1st barricade of sandbags (or: Sniper on the near building) nearest the spawn area of your own team, when his army is fully advanced, taking the offensive (therefore, have an advantage and is attacker), and about to conquer the last enemy flag. It is assumed that at this circunstances an MG or Sniper would be more required in the middle of the map (to keep the territory achieved) or at the end of the map (to support completion of the battle: fire-support), but not on start of the map, because it makes no sense... Obviously, a Mg or Sniper can deploy weapons in the first sandbag (or first window, or first building), near the spawn area of the team, but only when it is appropriate, as in the case of the friend team being at a disadvantage (the offensive belongs to enemy army), maybe having only one flag to defend... .
If, however, this feature is improved in Rcbot, the (cap)ability of the bot (MG or Sniper) choose more or less randomly, the deployment point, it should be preserved. Unless this random choice consider PRIMARILY the datas "where is the front-line, more or less, in the present instant" and "where is the flags are being disputed/quarreled" and "where fighting is concentrated". I particularly love and enjoyed this feature (randomness in choice of deployment point) because it makes the game less predictable. I think until this feature must also be improved with time.

7.2. Sometimes the bot that controls the MG or Sniper, (Sniper especially!), when fixing a position, let your own body very exposed to enemies, and so it becomes easy target. This aspect is less common in MG-bots because they crouch a bit at the time of deploying, but is very often and common on the Sniper cases. The Snipers have the (bad) habit of staying in the "standing" posture, at time to fix position, rather than crouch or in prone positions. I think the Snipers can use the "standing posture" when strictly necessary to kill an enemy, but should always stay crouched or prone when these two positions do not disturb your sight.

7.3. There are some small implementation bugs that must be fixed. I will cite a fact: MG-bot goes to the point of deployment to fixed position, and the choice of posture in the waypoint is established as "prone". To meet the specification, and fix the mg-gun, he stay in prone and not can see beyond a salience or corner that is capping his vision, however it remains fixed and the tip of his head is exposed to enemies. He does not see the enemy and can not fire his weapon against him, but the enemy sees the tip of his head - he is then shot down, despite owning a powerfull Machine-Gun MG... Another example occurs when the MG-bot lies behind a sandbag and decides to implement the gun right there on the ground: so, the sandbag impairs vision of MG-bot preventing him from realizing the enemies. There are other examples, such as the Snipers (can happen with MGs too...) who choose fixed position in buildings (eg: towers) with more of one chance of implementation (different angles of vision). In this cases is common that the Sniper select the worst possible direction in these buildings, getting their back to the movement of enemy troops - ignoring the risk of being killed by a shot hiting their back. Apart from the risk of dying, by doing this, the Sniper does not contribute to the team, and misses opportunities for intervention.

7.4. I felt missed of firearms-implementations (MG and Sniper) on the ground (in "prone" stances), at the same time: FIXED AND RANDOM; and not only on sandbags, or windows, holes, towers etc. With this option (more implementations in prone), I think the game would be even more unpredictable and Snipers and MGs would surprise us with a much higher frequency. At this point the Sturmbot is very similar to the Rcbot: by default, the MG-bots and Snipers do not establish fixed points on the ground for a long time, but are able to go in prone when they see the presence of enemies at distance, in order to kill opponents with accuracy. In both bot-systems, shortly after eliminated the threat, the MG-bots stand up again and continue the route/travel. Personally, I think implementations on the ground, both FIXED AND TEMPORARY, should exist in Rcbot2 for both classes "MG" and "Sniper" (maybe extend the option for Bazooka / Panzerschreck).

7.5. There is an important problem with the implementation of fixed MGs (not sure if the same happens with the Sniper class) in Rcbot that DESERVES TO BE CORRECTED. This problem is closely connected with the discussion of the items "1.1", "1.2" and "2". This is a nonexistent problem in Sturmbot.
I'll use a real example that happened to me in testing: after I see an MG-bot (enemy) fixed in a window on the top floor of a house, I managed to escape from their radius of action (mg-gun), and i walked around the buildings for the purpose of reach the 2 story house. I climbed the stairs and positioned myself just behind the MG-bot, but I did not kill him. I chose to do a test: i approached him to touch my weapon on his back, but he did not retaliate me, he continued in the window watching the movement on the outside. Then I pulled away again and ran toward him touching my gun back into his shoulder, again he did not come out of its fixed mg-position. I pulled back a little, again, and i started jumping, gave several jumps, but the bot did not move, ie : not "listened" my noises and failed to notice my presence there, right behind him. So, i chose to employ another test: i open fire on wall close him (his right side), but without hit the MG-bot, and he did not leave the fixed position to react against me (in a real combat situation or PC games between humans, anyone would have heard the shots and perceived ballistic impacts, not counting the previous sound of my footsteps coming up the stairs, approaching, or heels that i perform behind the enemy). I could only move the bot from there and force him to react against me, when I approached him again, put the gun in his back and walked towards his right side until I touch the wall where he was positioned. Once I touched the window, i immediately noticed that the bot finally dropped the fixed position, and turned his body toward me with some speed and killed me.

This example illustrates the IMPORTANCE OF ADOPTING the features discussed in the previous items, particularly the items "1.1", "1.2" and "2" !!

8. Brief note on forming squad

I am aware that mr. Cheeseh is working with the forming of squads to Rcbot2 (Dod: S), from the knowledge of this function in Rcbot1.
I think, and i suggest, that the formation of the squad on Rcbot2 should be FLEXIBLE and not rigid. In Sturmbot is flexible. I explain better: the formation of squads should not restrict the independence/freedom of bots that are following the bot-leader (or human-leader), like it is in Sturmbot. The bots should still retain some ability to autonomous choices (and make some decisions for themselves), according as development of the combat situation. Moreover, the bot can make the decision to leave the squad immediately when they notice that their squad is being huge decimated, or is in big danger, through the fault of the "decisions" of the bot-leader/human-leader. This is my opinion.


9. Latest considerations.

I reiterate the suggestions I made in the previous posts: study the entire system-Sturmbot, adopt the existing features in it, and go slowly perfecting each resources. Start by installing the Dod-Classic with the last version of Sturmbot (version 1.7), then analyze the behavior of bots in several different combat situations, and several maps. Reserve you the changelog-history of Sturmbot for reference. Make notes.

There are still many VERY GOOD features in Sturmbot that are missing in Rcbot2, to Dod:Source. Personally, I think ALL of them should be considered: implemented gradually, one by one, in Rcbot-system. After this: improving each one resources, also gradually, to a satisfactory point. For more information, please, i ask to all to reread my last considerations in the post: http://rcbot.bots-united.com/forums/index.php?showtopic=1709 .

I have in mind that the Rcbot2 to DoD:S. already made TREMENDOUS PROGRESS.
All my comments are intended to assist in the development of Rcbot2 for years to come.
With these analysis and suggestions, i hope, i intend to contribute to the development of Rcbot-system (Dod:S), including the first full-version of the program (non-beta version). I ask all developers (mr. Cheeseh and partners) to consider these my posts for the future, with attention, even after the release of a non-beta versions (in the case of not yet being possible to implement all these ideas described above).


If i happen to remember more things, i return to post to this topic.



THANK YOU VERY MUCH !



I leave a reproduction of this topic attached (format .zip)

-------------------------------------------------------------------------------------------------------------------------------Attached File  Topics___rcbot.zip ( 27.58k ) Number of downloads: 401
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
genmac
post Jan 23 2014, 09:33 AM
Post #2


RCBot Guru
*****

Group: Waypointers
Posts: 571
Joined: 11-November 11
Member No.: 2,098



that's one epic post! probably the longest post ever written on the entire Bots United forum. I'm sure Cheeseh will read it thoroughly while making his lovely baby go to sleep well unless he himself goes to sleep to hihi!

Anyway a great post and all I can say is...just play online hehe.
Bots are bots, fun to have but don't ask too much. Probably in the near or far future we'll soon have super human like bots that can navigate in real time no wpts needed like RACC. Check out bots on COD-black ops 2 and COD-ghost ...their ok but nothing new really that all the bots in hl/hl2 mods can do or even better. CSGO bots? well only improvement or upgrade they have is a built-in FFA feature and no more dumb nade throwing.

Sturmbot...I have like 3-4 versions installed on 3-4 seperate dod folders starting on beta 1.3b and so on. I love that bot too bad Jowo died too early, bot authors should stay away on asian beaches hehe.
The last final version is almost perfect and I sometimes make them sprint a lot on some custom wpts I made way back. I'm sure Cheeseh can implement or try copy some of it features.

As for now Cheeseh should concentrate as well on making the bot more dedicated server friendly so admins wont have a hard time running it.
Add map specific bot profiles, better automated cvars for dedis, better sourcemod compatability, no use of sv_Cheats and so on.

I want to write a super long one but I guess this is enough or I might as well write a new story line for hl3 LOL!
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
madmax2
post Jan 23 2014, 10:33 PM
Post #3


RCBot Guru
*****

Group: Waypointers
Posts: 956
Joined: 2-March 12
From: USA, WA state
Member No.: 2,162



QUOTE
that's one epic post! probably the longest post ever written on the entire Bots United forum. I'm sure Cheeseh will read it thoroughly while making his lovely baby go to sleep well unless he himself goes to sleep to hihi!


Genmac, you kill me sometimes...laugh.gif...

Hi YuriFR,

You make many valid points, much of it I can agree with, we all want to see the bots continue to develop and improve. And i'm sure much of what you say will be heard and considered for addition to rcbot. I will try to comment on few of your concerns, but will do so in more than one post, as I am pressed for time right now and may want to check some of your observations before I comment...

I'll start near the end of your post...

8. Forming Squads...
Just a small request (@ cheeseh), I play with smaller player loads, usually 7vs7 or less. If bots are going to be forming their own squads, I would like the option to limit the number of bots per squad, as low as 2 per squad, or at least a disable option... ok, done with that...

7.5 is a good point, bots are not always aware of what is happening behind them, even when getting shot from behind (this happens to some of us players too). The mg being deployed in a window may be part of the problem here, even if he did hear you approach, how would he know if you were friend or foe (perhaps bots could detect friend or foe from the map locations of friendly bots?)? He would have to undeploy every time he heard something behind, and to deploy again leaves him vulnerable from outside the window too. Maybe a better solution for the mg, once squads are working, would be to have one bot watching the mg's back from time to time, on random occasions? But all rcbots should and do hear, but i'm not sure if they are hearing from behind very well. If a player is going to melee kill an mg from behind, i don't think there is much the mg can do from the deployed position. I don't want to see them constantly deploying & undeploying. We should try this on snipers or other camping bots to see what happens, they may react differently?

7.4 proneing is adjustable now. many rcbot users were complaining that the bots proned to much, so cheeseh made a fix for this. try lowering braveness if you want them to prone more...

7.3 I'm certain a few of the problems you cited were waypoint related or caused.

QUOTE
In this cases is common that the Sniper select the worst possible direction in these buildings, getting their back to the movement of enemy troops - ignoring the risk of being killed by a shot hiting their back.


I suspect this is partly the case here. each sniper/mg/defend wpt should be team tagged, unless it is a neutral position. I have seen rcw's that don't have team tags on window positions that should be tagged. Thus either side will use that position. Also lack of area tags could put the bots in this situation too.

I'm not sure how the bots see their environment, can they actually see the sandbags or corner of the building? If they lose sight of the targets by proneing or other means, they should respond to that somehow, aquire a new waypoint position, but they are also trying to keep behind cover, it seems like a difficult balancing act to me. I've seen what you are talking about, but am not sure what the solution would be? I think some of the problem is wpt placement and some is the maps or source engine itself. I've tried to shoot around corners or through cracks between sandbags & walls and my bullets are blocked by the invisible edges of the sandbag or other obstacles, this is a mapping or engine flaw that will cause problems for the bots too, I would think...

QUOTE
Another example occurs when the MG-bot lies behind a sandbag and decides to implement the gun right there on the ground: so, the sandbag impairs vision of MG-bot preventing him from realizing the enemies.


This could be wpt placement or radius (not pulling all the way up to the sandbag to deploy), or they are simply under heavy fire and may be proneing just before they get on the sandbag wpt, to protect themselves. This is what I have seen the most, if they were to continue and attempt to deploy on the sandbag, they likely would get slaughtered anyways.

7.2 this is a good point, it would be nice to see snipers & other classes crouch more when under fire (but not to much proneing). Proneing takes longer to deploy/undeploy, and bots often get hung up on the terrain if they try to crawl to another wpt. I remember sturmbots doing this very well, it would make rcbots appear more human-like.

Note to cheeseh, when any bot goes to a prone/defend wpt, which rarely happens for some odd reason, they still don't stay in the prone position, but i think it's because they won't camp on prone/defend wpts, they just move through them. Can anyone else confirm this, or not?

And btw, mg's (snipers too, i think?) will occasionally go to defend wpts, which is ok cause they usually don't stay to long (i actually saw an mg deploy on a defend only window wpt a couple times!). this could partly be due to a lack of a mg or sniper wpt in that flag/area, so they try to use the defend wpt instead?

7.1 I have seen this to, it is most noticeable in mg's and to a lesser degree snipers, often hang back at the first flag positions and don't advance fast enough. It is actually better than it used to be with earlier rcbot2 versions, i see it less now. I think the bots ai should consider advancing the mg's/snipers when their team has capture 2 flags ahead, maybe sometimes even 1 flag ahead? This would work for linear maps like flash or avalanche, but maybe not for non-linear maps like churchyard? I'm not sure if rcbot has any territorial awareness yet?

Like I said in your first topic, I have seen bots, say several allied bots run right by their first flag that was captured by the axis, in an attempt to reach a goal on the far side of the map. Allied bots lose a lot on dod_vigilance because of this, trying to cap a harder 2 man cap in the middle of the map, instead of recapping an easy one man cap right in front of thier spawn, and on thier way to that 2 man cap. I think bots should capture/defend flags more sequentially than they do now, or at least put a much higher priority on recapping their first flags and close by single man caps. I think this is just as important as the mg's moving forward, a territorial awareness issue...

Thats enough for now, but one more thing to mention... wink.gif

max

YuriFR,

Just a friendly reminder...
I should of said this the very first time you multi posted topics, please don't multi post the same topic to get attention. Your topic/posts are seen or will be seen, there isn't that much activity here that they will be missed. If you really feel the need to get attention to your topic, just "bump" it back to the front page with another post in it.
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
Emotional
post Jan 28 2014, 06:22 PM
Post #4


RCBot Fan
****

Group: Members
Posts: 101
Joined: 5-March 13
Member No.: 2,260



at first glance a good post
but now I don't thnink to

most of what I read, known without this post, I see little info, what I don't know.
Some notice:

QUOTE
4.6. The bots in the Sturmbot (only last version 1.7) could change their main weapons for other weapons that were (thrown) on the floor (friendly or enemy weapons). The bots did this change once in a while. I did not know identify the reasons for this changes, beyond the possible motive "run out of ammo". This aspect ("change weapons") can also be thought to Rcbot.

on dod_colmar, sometimes support class bots can take other weapons, provided that
1) it's a too support weapon (allies can take stg44, axis - BAR)
2) it lays near the bomb site
I thnk, this is due to bomb planting (when bot planting bomb site, its angle of view may be forwarded in some other side and he can accidentally take weapon)

In general, I don't like this post.

Yuri, you you demand too much from Cheeseh. You required so much changes, that I doubt that Cheeseh really will enhance all. Programming - long and hard work, understand? I would be focused on small but really needed changes.
I can noted some needed changes:
-voice communication bots system - get used to it from old GoldSource games
-separation level of difficulty on the teams - on some maps just can not win for one or both teams (due either to features of map or with its size)
-improved teamwork - bots can use one of wpts according to the class and support each other - if enemy machinegunner kill teammate, sniper or bazookaman biggrin.gif go kill machinegunner.
-maybe some bug fixes in behavior of bots



Cheeseh

if you read it, please, not to try do all, what Yuri wrote. We know, that you have real life, that you can not leave. Some big and great projects collapsed because their creators set so much goals and can't reach no one. Believe me - if you will only support rcbot for DoD:S on DoD:S updates - for more of us it will be enough. I'll waiting bots for DoD:S from 2006 year - and I would not want to with this project something happened. You have not big developers team, you have not 2 mln. $, you have not 24 free hours for rcbots - and I think it's imprudently by Yuri - require a lot of work from you. Do, as you can do, in any case we will respect your work. If we can help you anything - just write.

And yes, little request:

[edited]no request[edited]
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
YuriFR
post Jan 29 2014, 01:35 AM
Post #5


Advanced Member
***

Group: Members
Posts: 51
Joined: 7-January 14
Member No.: 2,318



Hello! Mr. Emotional!

Unlike you, I liked your post: contributes to the debate, even with disagreements. Not only so, but also because your answer will allow me to make some clarifications I left to do before (because the post would be even longer):

1 -
QUOTE(Emotional @ Jan 28 2014, 04:22 PM) *

Yuri, you you demand too much from Cheeseh. You required so much changes, that I doubt that Cheeseh really will enhance all. Programming - long and hard work, understand? (...

a) This comment shows maybe I expressed myself badly, or i was misunderstood. I'm not "demanding" anything of mr. Cheeseh ... he has ALL THE POWER, and I none. He can ignore me or accept my ideas (like yours). Will only depend on HIM. I do not have the ability to program bots, otherwise I'd do a system of bots for me. I can only hope from mr. Cheeseh some charity and benevolence, to hear me and agree me. I can't do much beyond these hope/expectation. I want to stress here that mr. Cheeseh is the "head" (the "owner") of Rcbot2 for DoD:Source, it is the developer and possibly the only one who understands the entire operation of Rcbot-system, it is up to me just the job to point to something, or beg for something.

b.) Perhaps i made a serious lack: I should have added the following line to the topic I created, "This analysis that i promoted in this post MUST be understood in the context of long-term of development (years). Even in order to meet the demand of gamers for Dod: Source when the system (game) becomes obsolete, off-line, and is completely abandoned (without support) for 'Valve' / steam. It is just a kind of 'a package of suggested lines of development', based a system that has proven functionality, the Sturmbot".


2 -
QUOTE(Emotional @ Jan 28 2014, 04:22 PM) *

Cheeseh
if you read it, please, not to try do all, what Yuri wrote. [(...)] Some big and great projects collapsed because their creators set so much goals and can't reach no one. Believe me - if you will only support rcbot for DoD:S on DoD:S updates - for more of us it will be enough. I'll waiting bots for DoD:S from 2006 year - and I would not want to with this project something happened. [(...)] and I think it's imprudently by Yuri - require a lot of work from you.

c) Here, I largely agree with you, mr. Emotional: big projects actually collapse because of the difficulty of prioritizing goals. I also agree that the Rcbot is ALREADY A GREAT SYSTEM FOR BOTS (I was clear about this in the post!). And I also do not want the Rcbot2 to fail, this desire is not unique you. Contrariwise, I reiterate: I cheer for the Rcbot CONTINUE BECAUSE THERE IS NO MORE ANOTHER BOT-SYSTEM, SO GOOD, FOR DOD:S. [And I'll have to use him, going forward, even when Dod: Source is no longer supported by the "Valve"/Steam...]

d) I do not want to contribute to hinder the development of the Rcbot2. If I'm actually doing it, with these posts, (if I have this power), then I will ask everyone to ignore, flatly, my posts! And forget me. I'll be sad and feel very very frustrated by not being able to show to other people what I would like to show, but I will not die because of these feelings ... What I purported to show (again)**: is, yes, possible to implement the features that Sturmbot implemented, successfully. Or: at least it is possible to implement similar features, on Rcbot. These resources will help make the Rcbot2 even better than it already is! And at a later stage, much more later (keep in mind: "long-term"): enhance the functioning of these resources within the Rcbot. That's it.

e) I disagree with mr. Emotional, on relation at the point of trying to convince mr . Cheeseh to disregard that my observations are merely suggestions of goals, or lines of development, for the future (long term!), perhaps inducing mr. Cheeseh to think that these are "impositions" for concrete measures to be implemented on an urgent time. Not so !!! I do not have this "big influence" or power...
Another thing: is not eliminating the proposition (suggestions) of goals, that will solve the presumed risk of collapse of the projects: the solution is a matter of establishing a hierarchy of goals, well organized (well structured), to the short, medium and long term, considering the ideas I made (based on Sturmbot), and based on some agreement (consensus of users and agreement/acceptance of mr. Cheeseh) about these suggestions. But remember this: keeping the goals "in the context of long-term", to Rcbot2.

f) It is certainly much (and hard) work do all things that have been proposed, again I agree with mr. Emotional. However i think that: the goals should be assumed to be "ideal one, a possibility to be achieved in the long term", and, in principle, they should NOT MANDATORY be met. Can serve as a "north" **. However, the goals are not impossible, because Johan "Jowo" Linde (with about 15-17 years old) also made much progress with Sturmbot, and made this ​​practically alone, like mr. Cheeseh! The Sturmbot NOT collapsed, in any way, and obtained success in implementing many important and complex features, also hard to perform, as I mentioned before. Sturmbot only stopped because the developer "Jowo" died. A good organization/management of time and resources, perhaps allowed to Johan Linde achieve high levels of complexity with Sturmbot ... perhaps this is the "key" of the relatively rapid evolution of Sturmbot.
I'm just wondering, I'm not sure ... !

** {[I clearly explicited these things in the begining of post, on the need to contextualize the subject based on the query from another previous post, in which I developed the idea of ​​informing, (everything at once), the mr. Cheeseh on the existence and quality of another system of bots to Day of Defeat series, the Sturmbot. Link: http://rcbot.bots-united.com/forums/index.php?showtopic=1709 ]}


3-
QUOTE(Emotional @ Jan 28 2014, 04:22 PM) *

We know , that you [Cheeseh] have real life, that you can not leave [(...)] you have not 24 hours for free rcbots - and I think it's imprudently by Yuri - require a lot of work from you. (...

g) I chose not to comment on that part, but I couldn't help do it ... sounded too ironic: i also have personal lives. And I do not have 24 free-hours to the Rcbot, or for Dod:Source, or this forum... Still, my desire to contribute something to the Rcbot was so strong, I invested 2 days for tests and 2 days to write the original post (because I do not speak or write in English). If Rcbot not interested me very I would not be writing... Perhaps the only difference between me and mr. Cheeseh, on this point, is that he has a baby to care for, if I 'm not mistaken ... [incidentally, I take the time for wishes you good luck mr.Cheeseh, and her baby - i have no children, but I love my nephews!].
I have not been "imprudently" because there is no any "imprudence" in trying to encourage an environment of ideas and discussions about the Rcbot (and Sturmbot). Finally, i do not coerce mr. Cheeseh to hard-work in a certain direction.


Everything I wrote in this response, mr . Emotional, was nothing personal. smile.gif
I hope you understand that. I'm just taking the opportunity to clarify more precisely what goes through my head. Ok?!


Thank you and apologize for any misunderstanding ! smile.gif


[my apologies: using google translator...]


Postscript: I'll wait for a higher volume of contributions for this post, by the continuation of incomplete reasoning of "madmax2", and perhaps by direct participation of mr. Cheeseh here. With this I return to post. Thanks! smile.gif
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
genmac
post Jan 29 2014, 12:37 PM
Post #6


RCBot Guru
*****

Group: Waypointers
Posts: 571
Joined: 11-November 11
Member No.: 2,098



Kinda related hehe...
http://forums.bots-united.com/showthread.p...65925#post65925
I just made a new video with good old sturmbot check it out!

User is offlineProfile CardPM
Go to the top of the page
+Quote Post
Cheeseh
post Jan 30 2014, 05:01 PM
Post #7


Admin
*****

Group: Admin
Posts: 3,055
Joined: 11-September 03
From: uk
Member No.: 1



This is my quick reply, it's the only time I've had to read quickly and reply to such a thread, it's the Chinese new year, so have some spare time. The baby is sleeping through all the fireworks and we're just waiting till they subside before sleep!


1 Perception of risk in the environment (firearms and explosive devices)

1.1 Bots only listen to other players footsteps by occasionally looking in the direction of the footsteps but they don’t currently go out of their way. It is an addition for the future.

1.2. Same as 1.1

1.3. Could add simple system to retreat and wait, flank etc. This is currently not implemented, although there is a waypoint belief system that allows bots to know about danger. If there is more danger they will slow down or prone. That’s all at the moment.

1.4. Same as 1.3

2. Same as 1.1

3. Perception of risk in the environment: during the paths/route between waypoints.

A waypoint belief system exists but depends on each bot’s “braveness”. Low braveness will cause bots to avoid high danger areas. Naturally waypointers should be able to add waypoints along walls etc that will automatically create belief values for bots to either use more often or avoid. In the next version this will be a little more sensitive, double the sensitivity in fact, so you might see more bots taking more paths

Improvement of some movements of bots in Rcbot.

4.1. The bot is most likely proning because of a task such as a sniping or machine gunning task which has a prone waypoint. For the next version bots will learn better when to prone and not.

4.2. At the moment bots don’t take cover unless they are under fire. They don’t go out of their way to attack. An addition to the next version is to take cover under sandbags and reappear to shoot enemies when under fire. This requires appropriate waypointing.

4.3. - 4.4 Crouching is part of waypointing or defending tasks only in Rcbot.

4.5. Shooting positions, stand, crouch and prone are independent of each other right now depending on the bot class. Note that it’s rather complicated when taking into consideration a machine gunner that requires proning to fire accurately and reload, where as an assault class doesn’t have to worry about this. Bots fire, take cover to reload and return to fire again which I believe is good enough for a simple bot. However there is a possibility of adding a new waypoint type to allow sidestep coverage.

4.6. This is a new feature added to the next version, they will also give ammo if someone calls and shout for ammo if they need it.

4.7. This is an added feature in rcbot but bots only remember their previous enemy, it depends on whether the enemy is worth attacking or not, sometimes attacking the flag is higher priority, or closer, visible enemies. Although it can be improved.

4.8. This is a feature which is added in the next version.

5. The melee weapon is not a priority weapon although I would like to add the feature to edit weapon priorities in the future.

6. Throwing grenades (and explosive devices) and response to grenades thrown by the opponent.

6.1. This will be investigated and debugged for the future.

6.2. This will be investigated and debugged for the future.

7. Deploying snipers and automatic machine guns (MGs, .30, .50 etc. )

7.1. The placement of snipers and machine gunners deploying their weapons is based on the waypoints. Some choose whether to defend or attack. The bots choose which flag to defend or attack based on a waypoint belief system that is updated and saved after every map. If you think it is an insignificant position, it is actually because the bots believe it is actually a dangerous location in comparison to the other flag points. These waypoints must have the appropriate areas that match the flag that it is either defending or attacking. Squads should reduce this as they will stick together and the leader will be forced to move to the front line.

7.2. Waypointing the sniper waypoint as crouch or prone would be better to solve this.

7.3. I’m afraid this is just an engine problem with tracelines (lines to test if bots can see something which is only ONE line) hitting off walls even when you can see a head. Try this with a real player, can you see their head? Can you shoot it? How much is visible?

7.4. These exist already. You will have snipers moving towards a sniper point for example, if he is not at a sniper point and sees an enemy he will stop and use his sniper rifle until the threat is over (temporary). When he reaches the sniper spot he is fixed.

7.5. Before bots used to look around at noises when they were sniping or machine gunning, but really, i found it to be more realistic for bots to just keep looking forward because it ruined their perception of what they were supposed to be doing and basically made them more vulnerable to the other side.

refer to madmax2 posts for some of these points, as they are also quite valid.



------------------
I have since added a few additions yet to be released, be patient

Bot squads. Bots can use 'stick together' radio command to get other bots to join them. They follow the squad leaders commands. Leaders can give 'hold position' command which makes members go for the nearest defensive waypoint related to their class at the leaders closest flag.
Bots will use the area clear command
Squad leaders will use the hold position command after they capture a point. This causes bots to do the above behavior,
Squad leaders will use the gogogo command after they have spent some time defending, this causes members to move out of defending and go to attack
Bots will ask for ammo and give ammo when they hear the voice command.
Bots will pick up weapons.
Bots will crouch at sandbags and stand to shoot enemies if waypointed correctly.
Bots learn how to prone better each map, but the progress is not saved

I made a video on youtube ,In the video you'll notice the radio commands being used such as 'stick together' 'go go go' 'yes sir' 'hold this position' etc. you'll see a bot near the end doing a shoot and crouch, but you'll notice it backfires on the rocketeer at the end!

video here : http://youtu.be/arB94uKbKwA
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
Cheeseh
post Feb 2 2014, 04:07 PM
Post #8


Admin
*****

Group: Admin
Posts: 3,055
Joined: 11-September 03
From: uk
Member No.: 1



If you;d like to try a debug DLL on what I'm working on, have a look

this is a debug dll. to run this you must put -allowdebug into the command line. Also the file is much larger because its a debug DLL. It might be able to give you a crash log if it crashes.

http://sourceforge.net/p/rcbot2/code/HEAD/....dll?format=raw

there are more additions including
CODE

improved combat behavior
added some improved behaviours for machine gunners
machine gunners deploy machine gun at cover points
bots crouch and pull out to shoot the enemy at crouch cover points
improved bots listening behaviour in DOD:S
new cvar rcbot_listen_dist (make larger for bots to hear further)
fixed sniper bug
dod bots pick up weapons if out of ammo
bot squads : disable by using rcbot_bots_form_squads 0
bots use need ammo voice command
bots give ammo to players who use the need ammo voice command
bots use area-clear radio command
fixed possible crash
bots pick up weapons in dod:s
altered waypoint belief system
added some new squad leader voice commands after capturing and defending
bots in squads do their own thing if the squad leader is idle, but do not go too far from the leader
bots are a little more aware of their environment, investigating enemies etc

for bot listening to work, dod_stats must be working
User is offlineProfile CardPM
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



- Lo-Fi Version Time is now: 28th March 2024 - 09:57 PM