Tired of having to choose between dumb and slow bots and aimbot-wielding maniacs when not enough human opponents are around?
"Smarter Bots" applies small modifications to the generic bot AI that removes or reduces the influence of difficulty level on bot skills. Their aim is unaffected, so if godlike aiming scares you, you can scale their accuracy using the difficulty levels as usual. However, many other aspects, such as movement speeds, translocator usage or general jumping and dodging on the lowest levels, have been greatly improved by mostly or entirely decoupling them from the game difficulty level.
Download Link
[Mutator/ServerActor] Smarter Bots
-
Cat1981England
- Posts: 2326
- Joined: Mon 23. Aug 2010, 16:35
Re: [Mutator/ServerActor] Smarter Bots
Thanks for this 
Now on the server, feedback welcome, particularly about the bots aim which is currently set to "Adept".
Now on the server, feedback welcome, particularly about the bots aim which is currently set to "Adept".
The Universal Declaration of Human Rights, Article 1:
All human beings are born free and equal in dignity and rights. They are endowed with reason and conscience and should act towards one another in a spirit of brotherhood.
All human beings are born free and equal in dignity and rights. They are endowed with reason and conscience and should act towards one another in a spirit of brotherhood.
Re: [Mutator/ServerActor] Smarter Bots
Nice, you would have thought this decoupling would have been the default.
Re: [Mutator/ServerActor] Smarter Bots
Only now catching up to this, and, first off, props for re-sparking the conversation about making bots better for ONS; it's definitely a subject where seasoned players usually do have concrete thoughts in mind to suggest as improvements, but one that all too often peters out as little more than a community wishlist compilation because nobody actually rolls up their sleeves to set things in motion.
In practical terms now, as far as the decoupling from the GameDifficulty prop of bots' non-aiming/peripheral behavioural traits goes, I'll simply echo Daly in that this makes so much sense it might as well have always been a standard feature. Beyond this change though, there might be a few other, more ONS-specific ideas that could also be worth exploring while this brew's still being stirred, so here's a few additional proposals for your consideration.
- I believe this one has already been brought up elsewhere, but for emphasis' sake, it might bear repeating: there's an old mod called LinkMeDammit!, made by the Omnis' Kamek back in 2010, that significantly increases the bots' tendency to link up to human players, whether the latter are on foot with their linkguns out or inside a damaged vehicle, that very much aligns with this project's general goals and could well be incorporated into it so that online matches with smaller crowds can offer a less diminished experience to a more crowded server situation.
- In that same thread Crusha also broached the idea of getting bots to report on the positions of important enemy vehicles once they're sighted. Implementing this would improve upon their strategic usefulness by a good amount, thereby helping humans make more informed calls about where they should move to next and what they should expect; seeing as such info is very crucial in any ONS game, this is something still worth looking into IMO. As for deciding which vehicles should be deemed "important" enough to report on their whereabouts (and, optionally, the state of their health, if significantly damaged?), perhaps that could be based on a simple, general whitelist of known "heavy hitters", or a list of "map-specific top-5" compound entries. Either way, this would be adding much needed freshness to low-pop matches.
- In the same vein to the previous suggestion above, and for similarly strategic reasons, slightly expanding the granularity of players' command abilities to include a specific node attack directive for each/all bot(s) could also be explored - although, I'm not entirely sure this could be achieved merely through a bot subclass, rather than requiring additions to PlayerController too, but, either way, this would give human players a lot more control of their team's realtime attack efforts (well, as long as different human players wouldn't keep spamming antithetical orders one after another anyway).
- Similar to the incorporation of existing work with the LinkMeDammit pack, efforts to improve support for human players was also made in the direction of vehicle seat ejection with regard to bot passengers filling up all available spots. While this first approach has been focused at individual custom vehicle classes, perhaps a more holistic approach could be attempted with this mod?
- Lastly, while not ONS specific, this one's something of an old pet peeve of mine when it comes to the intersection of bots' annoying auto-/insta-aiming and the scarcity of redeemers in maps; I'd greatly appreciate a server-wide, toggleable switch for permitting them or altogether proscribing the shooting down of guided warheads (unless, perhaps, they're headed right for the bot and have been sighted for more than a second?).
Alright, that's all that comes to mind on this right now. Do lemme know if I'm going too "pie in the sky" with these though, cause I got the sense that, with at least one or two of these, I may be. Keep up the good work.
In practical terms now, as far as the decoupling from the GameDifficulty prop of bots' non-aiming/peripheral behavioural traits goes, I'll simply echo Daly in that this makes so much sense it might as well have always been a standard feature. Beyond this change though, there might be a few other, more ONS-specific ideas that could also be worth exploring while this brew's still being stirred, so here's a few additional proposals for your consideration.
- I believe this one has already been brought up elsewhere, but for emphasis' sake, it might bear repeating: there's an old mod called LinkMeDammit!, made by the Omnis' Kamek back in 2010, that significantly increases the bots' tendency to link up to human players, whether the latter are on foot with their linkguns out or inside a damaged vehicle, that very much aligns with this project's general goals and could well be incorporated into it so that online matches with smaller crowds can offer a less diminished experience to a more crowded server situation.
- In that same thread Crusha also broached the idea of getting bots to report on the positions of important enemy vehicles once they're sighted. Implementing this would improve upon their strategic usefulness by a good amount, thereby helping humans make more informed calls about where they should move to next and what they should expect; seeing as such info is very crucial in any ONS game, this is something still worth looking into IMO. As for deciding which vehicles should be deemed "important" enough to report on their whereabouts (and, optionally, the state of their health, if significantly damaged?), perhaps that could be based on a simple, general whitelist of known "heavy hitters", or a list of "map-specific top-5" compound entries. Either way, this would be adding much needed freshness to low-pop matches.
- In the same vein to the previous suggestion above, and for similarly strategic reasons, slightly expanding the granularity of players' command abilities to include a specific node attack directive for each/all bot(s) could also be explored - although, I'm not entirely sure this could be achieved merely through a bot subclass, rather than requiring additions to PlayerController too, but, either way, this would give human players a lot more control of their team's realtime attack efforts (well, as long as different human players wouldn't keep spamming antithetical orders one after another anyway).
- Similar to the incorporation of existing work with the LinkMeDammit pack, efforts to improve support for human players was also made in the direction of vehicle seat ejection with regard to bot passengers filling up all available spots. While this first approach has been focused at individual custom vehicle classes, perhaps a more holistic approach could be attempted with this mod?
- Lastly, while not ONS specific, this one's something of an old pet peeve of mine when it comes to the intersection of bots' annoying auto-/insta-aiming and the scarcity of redeemers in maps; I'd greatly appreciate a server-wide, toggleable switch for permitting them or altogether proscribing the shooting down of guided warheads (unless, perhaps, they're headed right for the bot and have been sighted for more than a second?).
Alright, that's all that comes to mind on this right now. Do lemme know if I'm going too "pie in the sky" with these though, cause I got the sense that, with at least one or two of these, I may be. Keep up the good work.
Eyes in the skies.
Re: [Mutator/ServerActor] Smarter Bots
The LinkMeDammit download fell victim to GameFront's stupid 30 inactivity take down policy once again. Why do people trust this kind of service for small mod releases? If anyone can provide a link to the latest version, I'd be happy to see if that can be integrated into Smarter Bots.
The idea of more specific location names isn't that new either. Not only did Crusha suggest it in the LinkMe thread, but I also even messed with generating such location descriptions way earlier for "Wormbot" and "Tournament". The questions here, as you pointed out, would be "What's an important vehicle?" and also "When should an update about the location be issued?" - and in which language? Keep in mind that both vehicle and location names may be localized. The first idea would have been a simple chat message, but a more complex localized message may be much more friendly towards non-English speakers. The question here would be, how to get more than one location-defining object across the network easily for generating the message.
More customized bot commands can be extremely tricky. Even properly integrating the standard commands into Jailbreak's customized AI strategies proved difficult. And we had full access to the entire AI there. Not only would we have to replace the command menu, but possibly also the TeamAI (might be possible) and possibly the SquadAI as well. (Would conflict with artillery turret support, but I guess I could merge those two.)
Also, some basic AI stuff is integrated into weapons and vehicles. One of these is whether humans can enter bot-filled vehicles or not. Unfortunately there are not that many places to hook into that behavior. One might be the PlayerController, but that is already taken by Anti TCC or UTComp or whatever else servers may be running. The next one might be the gametype, but do we really want to subclass ONSOnslaughtGame itself? Might be quite messy. Beyond that I think the individual vehicles are pretty much the only thing left for implementing bot kick-out.
Similar things go for bots aiming at Redeemers and SPMA cameras - the projectiles themselves instruct bots to do so.
[edit]
While I did not find a working link to LinkMeDammit, I may have found extracted source code for it. I just don't know if that's already the final version, as it doesn't include any version information.
The idea of more specific location names isn't that new either. Not only did Crusha suggest it in the LinkMe thread, but I also even messed with generating such location descriptions way earlier for "Wormbot" and "Tournament". The questions here, as you pointed out, would be "What's an important vehicle?" and also "When should an update about the location be issued?" - and in which language? Keep in mind that both vehicle and location names may be localized. The first idea would have been a simple chat message, but a more complex localized message may be much more friendly towards non-English speakers. The question here would be, how to get more than one location-defining object across the network easily for generating the message.
More customized bot commands can be extremely tricky. Even properly integrating the standard commands into Jailbreak's customized AI strategies proved difficult. And we had full access to the entire AI there. Not only would we have to replace the command menu, but possibly also the TeamAI (might be possible) and possibly the SquadAI as well. (Would conflict with artillery turret support, but I guess I could merge those two.)
Also, some basic AI stuff is integrated into weapons and vehicles. One of these is whether humans can enter bot-filled vehicles or not. Unfortunately there are not that many places to hook into that behavior. One might be the PlayerController, but that is already taken by Anti TCC or UTComp or whatever else servers may be running. The next one might be the gametype, but do we really want to subclass ONSOnslaughtGame itself? Might be quite messy. Beyond that I think the individual vehicles are pretty much the only thing left for implementing bot kick-out.
Similar things go for bots aiming at Redeemers and SPMA cameras - the projectiles themselves instruct bots to do so.
[edit]
While I did not find a working link to LinkMeDammit, I may have found extracted source code for it. I just don't know if that's already the final version, as it doesn't include any version information.
Re: [Mutator/ServerActor] Smarter Bots
Been stitching this together for about a week now, so there's a chance it might be too late for some of the suggestions made below with regard to specific aspects of this mod that are (were at the time?) under active development. Apologies if so, but it's the best I can do these days. Oh, and it's a bit long too, but what else is new, right? Anywho, on with it...
Still, since the matter's already raised, I think it's also apropos to emphasize that the chronically ephemeral n' volatile (and therefore unfortunate) online storage preferences exhibited among a majority of UT community members, creative or otherwise, has after so many years compounded the problem of historic preservation of a vast amount of UT mod work, that would otherwise be interesting to study and perhaps even build further upon, to such a point that perusing almost any project thread from over 3-4 years ago, even on Epic's own official msg. board, most often resembles a cemetery of dead links and pics that offers very little insight into the progress being made back then or what it all ultimately amounted to. Pretty sad state of affairs all in all, and kinda makes one wish people back then had been just a tiny bit more mindful 'bout where exactly they were uploading their hard work when sharing it via pics n' other files.
It's also part of the reason why I've never allowed my predominantly ONS-focused UT2004 cache to be emptied (easy to do via UT2004.ini) and why I bother to take multi-tiered backups on a routine, bi-monthly schedule, all to ensure there'll always be at least one source around to re-offer (arcane?) old content, if that ever becomes necessary for any reason among any community I frequent. I just hope there's enough others of the same mentality still around to keep most of the worthwhile stuff available, but with eminent resource repositories like UT-files significantly scaling down their archives' size over the recent years, I can't say I'm too optimistic about UT modded content's survival outlook in the long run that these days :/.
Anyway, sorry for the impromptu rant there, the preservation issue has been on my mind for quite awhile now, as you might be able to tell, and this is the first opportunity to publicly bring it up I've found in years.
As far as determining a vehicle's importance goes, a solution that seems to require a minimal amount of in-match resource consumption might be to just pre-feed a (30-ish item long) hierarchical list via the package's/ServerActor's .ini file, which some assisting actor could copy and whittle down to one containing only the present vehicles, as referenced by all the map's vec factories, all before an imminent match begins (or the current round, if a randomizer actor is detected). After that, a bot would check any sighted vehicle's class against this updated list and only bother to report its location if the spotted mechanized enemy lies, say, above the 50th/75th threat percentile. Additionally, bots can be told to report only on hostile vecs above a fixed amount of spots, like the 6-7 top threats, if the dynamic list is still longer than, say, 20ish in-match vecs, as the case can often be in some TMU maps. As for the original ordered list in the .ini, this could be defined by each server's staff and/or community, based on what they know to be most prevalent (and deadly) aggressors in their maps' roster, therefore the most useful to inform about.
Another related, but IMO equally crucial, question here would be, what kind of event would constitute a bot legitimately becoming aware of an enemy vehicle? Are we talking about line of sight to the target in question, while also factoring in local fog parameters, or is a nearby flying projectile/weaponfire or explosion/emitter caused by those known to originate from a valid threat also a valid alternative for positive ID-ing, as it naturally goes with human players? What about uniquely distinct vehicle audio cues, like their horn sounds? Are we, furthermore, also willing to abide by the wid[-er/-est] FOV angle/X-ray/extra-sensory awareness that bots of the highest difficulty settings infamously enjoy? When first suggesting this expansion here, vehicle spotting by bots seemed like a pretty straightforward idea, I gotta confess, but the farther one might go trying to better flesh it out it, the more complex it appears to get. Hopefully not prohibitively complex though, because even opting for a bare-bones kind of "direct n' proximal identification" functionality, this still stands to be useful enough to players, so the potential benefits from adding it are undeniably there.
In terms of when an update should be issued and the related subject of preventing reporting redundancy now, as a first, commonsense starting point, one might intuitively note that multiple bots transmitting a barrage of reports on a vehicular enemy threat's whereabouts, say, every other second, would become annoying (and resource-taxing) pretty quickly. On the other hand, however, personal ingame experience suggests that, when it comes to top threats, it's not unusual for people to update on such vehicles' movements in intervals shorter than even 10secs (because that can significantly factor into overall strategic decisions), so perhaps a sensible minimal period value for preventing newer reports on the same vec might lie somewhere 'round 6-7secs?
Additionally, it seems equally logical that a report flood-preventing restriction would need to be applied to all team bots with respect to any specific threat, and in order to coordinate n' enforce this in a top-down manner there'd probably need to exist a centralized reference resource per team. Such a resource could probably be managed by a specialized actor that would maintain a team's master reports table, where time and parent vehicle factory would be recorded for each report/entry. The reason I'm suggesting parent vehicle factory be used here, instead of simply going with vehicle class, is to avoid false negative scenarios, where bots might find themselves blocked from warning about a second high threat moving closer because a report about the first one of the same class was recently issued, but hasn't expired yet - this can happen more often in the randomizer kind of edits, with Arena matches being the obvious, worst case sub-scenario. To my mind, and to sum up here, the bots' enemy vehicle spotting feature will likely prove as helpful and beneficial to human players as the degree to which it manages to adequately meet standards concerning all three issues of usefulness (i.e. report freshness), non-redundancy and thoroughness.
Lastly, regarding possible multilingual support and server network resource optimization, as far as the former is concerned, I can't say I find myself as compelled by this goal as you appear to be, given the point in this game's life we're at, the minimal amount of people still playing (and therefore equal amount of impact this extra might have, weighted against the effort to implement it), and how even most non-native English speakers still playing it are more or less familiar by now with most (English) terms and messages the game (and, equally importantly, any custom content creator) uses to relay info. Granted, bots' retail voice/text responses have had multilingual support baked in via .int files and forethought in their Uscript code, and that's probably what's informing your mindset and standards here. As far as anything beyond that is concerned, however - specific map locations (via volumes or objective descriptions), mod weapons and vehicles, HUD messages or frag descriptions - experience, and almost the entire history of this game's modding scene, has proven multilingual creations to be the exception, rather than the rule. Basically, it might prove a waste of time after a substantial amount of effort, is my concern (and warning) here, but I won't go as far as to advise against it, if you feel strongly about adding multi-language support in.
With regard to the optimal way of relaying the sighting info now, text messages would seem a sensible (and reliable) way to do it, although it might prove a bit limiting in the direction of multilang support due to contextual params in strings not allowing for all the kind of text substitutions this might require. OTOH, relaying messages via other channels/functionality and having them processed n' appear on clients' lang-localized end would allow for the info to be compressed far more - a set of (X, Y, Z, vectype) is cheaper to broadcast than a ~50-char string (dunno if the engine would allow it to make it across losslessly though) - but might consume a few more resources to assemble and display per event, not to mention the entire burden of having to provide accurate translations for all necessary adjacency/directional/relational terms, as discussed above. Beyond that though, I'm not confident I'm experienced enough with this particular subsystem of the game so as to be able to offer any more helpful thoughts, so I'll just end it here n' wait to see where you go with it.
Edit: Ah, what the hell, screw it, it's not like this is ever likely to come up again anytime soon. Improving ONS by overhauling entire parts of its asset toolkit (towards a direction of more flexibility and mobility, for one thing) has been one of my longstanding aspirations and a message I've tried to evangelize ever since I began looking under this game's hood more than six years ago, which would indeed require (finally) subclassing ONSOnslaughtGame. Practically speaking, however, the chances of something like that happening at this point in UT2004's life are infinitesimally slim, not to mention such an undertaking would have to gather enough interest so as to become the collective effort of a number of devoted people designing, developing, playtesting and debugging together, so yeah, "quite messy" would certainly be one accurate way to describe it, should that ever take off. Since none of that can just casually arise from the discussion of a much more focused and realistic-scoped project, such as the current one, though, that's as far as I think it makes sense to go on this tangent. Guess that's the long way of saying, "careful what you presume to be a rhetorical question"
.
Still, perhaps this doesn't necessarily have to be regarded as an arrangement beyond bypassing. I mean, couldn't the SmarterBots' subclass at an early point in its Tick function check whether the current target is a redeemer projectile or remotely guided pawn/warhead (or child thereof, for custom variants) and, based on a newly added relevant variable, just reset the target to None (and something similar for focus) if said var's value corresponds to a server preference for not shooting such projectiles/pawns? Understandably, this might put different parts of the game's code in a kind of war with each other, whereupon during every tick under such a scenario a flying deemer in proximity of such bots would re-declare itself a valid target to them, only for the SmarterBot code in each one to then immediately trash those assignments in the same tick (or early in the next one).
As with all wars there'd be some fallout and that here would probably translate into an uptick in server CPU consumption during such events, but when trying to ballpark that additional processing cost in average/worst cases, it didn't seem to be a very heavy one. Specifically, one can consider that this would only be applied to a) only bots without any current target, b) only bots not currently shooting or occupied with something else, c) bots of a GameDifficulty setting above 2.0 (obviously applies to CEONSS), d) a limited number of enemy bots rather than always all of them (each team has a max of 6 in most ONSPlus servers, so that could be an average of 2-3 and a worst case of 5 for a few ticks), and e) only for the time a flying deemer projectile/pawn is in direct LOS with any SmarterBot AI player, which in most cases rarely exceeds 6-7secs. All told, the extra CPU cycles owed to this back-n-forth and, at worst, once per redeemer shot (120secs apart for pickups; admittedly, more frequent for custom content, like Arbalests) doesn't seem too onerous for servers employing capable n' up-to-date hardware, such as CEONSS; even if it proved to be so, however, it'd be a feature that admins would be able to turn off very easily. As for bots possibly "locking up" during a transient redeemer's flight as a side-effect of all this, well, the remainder of their logic would still be running after their initial target gets forcibly scrapped, so as long as they decided on a new course of action, I presume this shouldn't affect 'em any longer.
Anyway, it's possible I'm overlooking something that could seriously throw off these estimates, so please consider all the above as more of an exploration than a thesis of definitive feasibility.
Hmm, guess this got a bit longer, and delayed, than originally expected, but I do hope some of it can still prove useful, or at least serve as food for thought for further development, anyway. As ever, keep up the good work, Wormbo.
Glad to see you were provided with a number of fresh download sources, so not much else needs doing 'bout providing that particular file.Wormbo wrote:The LinkMeDammit download fell victim to GameFront's stupid 30 inactivity take down policy once again. Why do people trust this kind of service for small mod releases? If anyone can provide a link to the latest version, I'd be happy to see if that can be integrated into Smarter Bots.
[...]
[edit]
While I did not find a working link to LinkMeDammit, I may have found extracted source code for it. I just don't know if that's already the final version, as it doesn't include any version information.
Still, since the matter's already raised, I think it's also apropos to emphasize that the chronically ephemeral n' volatile (and therefore unfortunate) online storage preferences exhibited among a majority of UT community members, creative or otherwise, has after so many years compounded the problem of historic preservation of a vast amount of UT mod work, that would otherwise be interesting to study and perhaps even build further upon, to such a point that perusing almost any project thread from over 3-4 years ago, even on Epic's own official msg. board, most often resembles a cemetery of dead links and pics that offers very little insight into the progress being made back then or what it all ultimately amounted to. Pretty sad state of affairs all in all, and kinda makes one wish people back then had been just a tiny bit more mindful 'bout where exactly they were uploading their hard work when sharing it via pics n' other files.
It's also part of the reason why I've never allowed my predominantly ONS-focused UT2004 cache to be emptied (easy to do via UT2004.ini) and why I bother to take multi-tiered backups on a routine, bi-monthly schedule, all to ensure there'll always be at least one source around to re-offer (arcane?) old content, if that ever becomes necessary for any reason among any community I frequent. I just hope there's enough others of the same mentality still around to keep most of the worthwhile stuff available, but with eminent resource repositories like UT-files significantly scaling down their archives' size over the recent years, I can't say I'm too optimistic about UT modded content's survival outlook in the long run that these days :/.
Anyway, sorry for the impromptu rant there, the preservation issue has been on my mind for quite awhile now, as you might be able to tell, and this is the first opportunity to publicly bring it up I've found in years.
Agreed, some of those subjects, while certainly not unsolvable, do pose interesting challenges, and since the topic was rekindled, I gotta confess I too have been toying in my mind with various approaches to that end on occasion, plus a few other related questions.Wormbo wrote:[...]The questions here [regarding bots reporting vehicles' locations], as you pointed out, would be "What's an important vehicle?" and also "When should an update about the location be issued?" - and in which language? Keep in mind that both vehicle and location names may be localized. The first idea would have been a simple chat message, but a more complex localized message may be much more friendly towards non-English speakers. The question here would be, how to get more than one location-defining object across the network easily for generating the message.[...]
As far as determining a vehicle's importance goes, a solution that seems to require a minimal amount of in-match resource consumption might be to just pre-feed a (30-ish item long) hierarchical list via the package's/ServerActor's .ini file, which some assisting actor could copy and whittle down to one containing only the present vehicles, as referenced by all the map's vec factories, all before an imminent match begins (or the current round, if a randomizer actor is detected). After that, a bot would check any sighted vehicle's class against this updated list and only bother to report its location if the spotted mechanized enemy lies, say, above the 50th/75th threat percentile. Additionally, bots can be told to report only on hostile vecs above a fixed amount of spots, like the 6-7 top threats, if the dynamic list is still longer than, say, 20ish in-match vecs, as the case can often be in some TMU maps. As for the original ordered list in the .ini, this could be defined by each server's staff and/or community, based on what they know to be most prevalent (and deadly) aggressors in their maps' roster, therefore the most useful to inform about.
Another related, but IMO equally crucial, question here would be, what kind of event would constitute a bot legitimately becoming aware of an enemy vehicle? Are we talking about line of sight to the target in question, while also factoring in local fog parameters, or is a nearby flying projectile/weaponfire or explosion/emitter caused by those known to originate from a valid threat also a valid alternative for positive ID-ing, as it naturally goes with human players? What about uniquely distinct vehicle audio cues, like their horn sounds? Are we, furthermore, also willing to abide by the wid[-er/-est] FOV angle/X-ray/extra-sensory awareness that bots of the highest difficulty settings infamously enjoy? When first suggesting this expansion here, vehicle spotting by bots seemed like a pretty straightforward idea, I gotta confess, but the farther one might go trying to better flesh it out it, the more complex it appears to get. Hopefully not prohibitively complex though, because even opting for a bare-bones kind of "direct n' proximal identification" functionality, this still stands to be useful enough to players, so the potential benefits from adding it are undeniably there.
In terms of when an update should be issued and the related subject of preventing reporting redundancy now, as a first, commonsense starting point, one might intuitively note that multiple bots transmitting a barrage of reports on a vehicular enemy threat's whereabouts, say, every other second, would become annoying (and resource-taxing) pretty quickly. On the other hand, however, personal ingame experience suggests that, when it comes to top threats, it's not unusual for people to update on such vehicles' movements in intervals shorter than even 10secs (because that can significantly factor into overall strategic decisions), so perhaps a sensible minimal period value for preventing newer reports on the same vec might lie somewhere 'round 6-7secs?
Additionally, it seems equally logical that a report flood-preventing restriction would need to be applied to all team bots with respect to any specific threat, and in order to coordinate n' enforce this in a top-down manner there'd probably need to exist a centralized reference resource per team. Such a resource could probably be managed by a specialized actor that would maintain a team's master reports table, where time and parent vehicle factory would be recorded for each report/entry. The reason I'm suggesting parent vehicle factory be used here, instead of simply going with vehicle class, is to avoid false negative scenarios, where bots might find themselves blocked from warning about a second high threat moving closer because a report about the first one of the same class was recently issued, but hasn't expired yet - this can happen more often in the randomizer kind of edits, with Arena matches being the obvious, worst case sub-scenario. To my mind, and to sum up here, the bots' enemy vehicle spotting feature will likely prove as helpful and beneficial to human players as the degree to which it manages to adequately meet standards concerning all three issues of usefulness (i.e. report freshness), non-redundancy and thoroughness.
Lastly, regarding possible multilingual support and server network resource optimization, as far as the former is concerned, I can't say I find myself as compelled by this goal as you appear to be, given the point in this game's life we're at, the minimal amount of people still playing (and therefore equal amount of impact this extra might have, weighted against the effort to implement it), and how even most non-native English speakers still playing it are more or less familiar by now with most (English) terms and messages the game (and, equally importantly, any custom content creator) uses to relay info. Granted, bots' retail voice/text responses have had multilingual support baked in via .int files and forethought in their Uscript code, and that's probably what's informing your mindset and standards here. As far as anything beyond that is concerned, however - specific map locations (via volumes or objective descriptions), mod weapons and vehicles, HUD messages or frag descriptions - experience, and almost the entire history of this game's modding scene, has proven multilingual creations to be the exception, rather than the rule. Basically, it might prove a waste of time after a substantial amount of effort, is my concern (and warning) here, but I won't go as far as to advise against it, if you feel strongly about adding multi-language support in.
With regard to the optimal way of relaying the sighting info now, text messages would seem a sensible (and reliable) way to do it, although it might prove a bit limiting in the direction of multilang support due to contextual params in strings not allowing for all the kind of text substitutions this might require. OTOH, relaying messages via other channels/functionality and having them processed n' appear on clients' lang-localized end would allow for the info to be compressed far more - a set of (X, Y, Z, vectype) is cheaper to broadcast than a ~50-char string (dunno if the engine would allow it to make it across losslessly though) - but might consume a few more resources to assemble and display per event, not to mention the entire burden of having to provide accurate translations for all necessary adjacency/directional/relational terms, as discussed above. Beyond that though, I'm not confident I'm experienced enough with this particular subsystem of the game so as to be able to offer any more helpful thoughts, so I'll just end it here n' wait to see where you go with it.
Ugh, trust me, you don't want my honest answer to that.Wormbo wrote:[...]The next [possible place to hook into AI stuff] might be the gametype, but do we really want to subclass ONSOnslaughtGame itself? Might be quite messy.[...]
Edit: Ah, what the hell, screw it, it's not like this is ever likely to come up again anytime soon. Improving ONS by overhauling entire parts of its asset toolkit (towards a direction of more flexibility and mobility, for one thing) has been one of my longstanding aspirations and a message I've tried to evangelize ever since I began looking under this game's hood more than six years ago, which would indeed require (finally) subclassing ONSOnslaughtGame. Practically speaking, however, the chances of something like that happening at this point in UT2004's life are infinitesimally slim, not to mention such an undertaking would have to gather enough interest so as to become the collective effort of a number of devoted people designing, developing, playtesting and debugging together, so yeah, "quite messy" would certainly be one accurate way to describe it, should that ever take off. Since none of that can just casually arise from the discussion of a much more focused and realistic-scoped project, such as the current one, though, that's as far as I think it makes sense to go on this tangent. Guess that's the long way of saying, "careful what you presume to be a rhetorical question"
.Looking at the relevant bit of code, it seems the devs went with an "opt in" mentality here, where specific projectiles would self-declare as valid candidates for enemy bot targeting, rather than having that part of the bots' logic centrally placed in the Bot class and then allowing specific projectiles to "opt out" of being auto-targeted via, say, a specific property setting that bots would check for; guess this must've saved more on server CPU/bandwidth resources on aggregate or something to a similar effect for them to have implemented it so.Wormbo wrote:[...]Similar things go for bots aiming at Redeemers and SPMA cameras - the projectiles themselves instruct bots to do so.[...]
Still, perhaps this doesn't necessarily have to be regarded as an arrangement beyond bypassing. I mean, couldn't the SmarterBots' subclass at an early point in its Tick function check whether the current target is a redeemer projectile or remotely guided pawn/warhead (or child thereof, for custom variants) and, based on a newly added relevant variable, just reset the target to None (and something similar for focus) if said var's value corresponds to a server preference for not shooting such projectiles/pawns? Understandably, this might put different parts of the game's code in a kind of war with each other, whereupon during every tick under such a scenario a flying deemer in proximity of such bots would re-declare itself a valid target to them, only for the SmarterBot code in each one to then immediately trash those assignments in the same tick (or early in the next one).
As with all wars there'd be some fallout and that here would probably translate into an uptick in server CPU consumption during such events, but when trying to ballpark that additional processing cost in average/worst cases, it didn't seem to be a very heavy one. Specifically, one can consider that this would only be applied to a) only bots without any current target, b) only bots not currently shooting or occupied with something else, c) bots of a GameDifficulty setting above 2.0 (obviously applies to CEONSS), d) a limited number of enemy bots rather than always all of them (each team has a max of 6 in most ONSPlus servers, so that could be an average of 2-3 and a worst case of 5 for a few ticks), and e) only for the time a flying deemer projectile/pawn is in direct LOS with any SmarterBot AI player, which in most cases rarely exceeds 6-7secs. All told, the extra CPU cycles owed to this back-n-forth and, at worst, once per redeemer shot (120secs apart for pickups; admittedly, more frequent for custom content, like Arbalests) doesn't seem too onerous for servers employing capable n' up-to-date hardware, such as CEONSS; even if it proved to be so, however, it'd be a feature that admins would be able to turn off very easily. As for bots possibly "locking up" during a transient redeemer's flight as a side-effect of all this, well, the remainder of their logic would still be running after their initial target gets forcibly scrapped, so as long as they decided on a new course of action, I presume this shouldn't affect 'em any longer.
Anyway, it's possible I'm overlooking something that could seriously throw off these estimates, so please consider all the above as more of an exploration than a thesis of definitive feasibility.
Hmm, guess this got a bit longer, and delayed, than originally expected, but I do hope some of it can still prove useful, or at least serve as food for thought for further development, anyway. As ever, keep up the good work, Wormbo.
Eyes in the skies.