DTAS Gametype?

[Harper [Jgkdo]]

I assume it is hard to figure out what to do with a file called "README"

Well to sum up the content:
As you might know the last common class used by bots and players is PlayerReplicationInfo (that's why its used very extensivly as a common base for all classes derived from it).
After that common base class Bots and Players uses different branches ending in INFc_BotReplicationInfo and INFc_PlayerReplicationInfo for Infiltration. dtasPlayerReplicationInfo extends INFc_PlayerReplicationInfo and the same needs to be done for bots which would result in redundant code. But the really bad thing about it are the casts and cast checks I need to do in a lot of places to ensure proper access to the values (either Player or Bot)
This is the one place multi inheritance would become really handy.

But enough complaining, I already decided before releasing 1.37 that I would reintegrate bot support if anyone ask for it. Maybe it won't be that bad coding after all. (if you hear screams its me )

@Lich: It is not hard to remove information (enemy casualties)from a scoreboard. The problem with EAS is that all information is lost during "round" changes because EAS restarts the map after each round to reset all stuff, that's why adding information is a bit harder. It would require saving to an ini in a similar way it is done by TeamStay and SSK.TeamBalance. When I have time I will look into it, but right now dtas has priority.

 

[Turin_Turambar]

Bot support can be useful in SG server where there are some bots 'playing' dtas if the players are less than six. Also with the new mutator BotDirector it could be possible to cap with bot aid!

 

[Harper [Jgkdo]]

Here is the new version. Bots should be able to do all the cool stuff again

ChangeLog:
(InfilDTAS 1.38)
- (bugfix) reintegrated bot support
- (bugfix) bShowFlagIcons didn't toggle anything, fixed

 

[- Lich -]

Ok, this window reseting to non broken state has to be looked at. (was found in 1.37, if it is fixed now... nevermind)
At the moment a reset window gets reset with trigger toggle, so you can go to a window that was broken before, and 'get rid' of the glass by using the grab key. Second there is no breaking glass or sound neither when shooting a new window, nor when using the grab key.
Yeah, this is only a very minor thingy.

[OT again, sry]
On scoreboard change for EAS: Good that you think about making it. The 'points' for accomplishing an objective are not so important. Although it would be nice to take the number of completed objectives into account on who wins the match before it comes to number of used reinforcements. This info can be transfered to next round like the time and number of used reinforcements (I hope).[/OT]

 

[Harper [Jgkdo]]

*me confused*
What windows? Usually only doors should be reset. If you mean that windows gets repaired too, well at least I have an answer to my question what other movers are "fixed" .
The reason for changing the state to 'triggler toggle' is that this is the common state used by doors and when a door is blown up with door breaching charges it becomes state 'Mover' which is what I use to identify them (together with some other minor checks). It appears that "breached" doors share this state with some other movers like windows.

So my current problem is that I don't have a proper filter to distingish between those broken doors and other stateless movers like broken windows.
Any ideas?

 

[Olethros]

How 'bout even more bot support? The experimental stuff from INFGPS v1.20 never worked properly, so I rewrote it. Now they'll actually try to cap on their own as well as defend. (Attacking bots ordered to "Attack" will try to cap the flag while defending bots ordered to "Defend" will defend it.)

Just look for "*Olethros*" in the comment to find the additions/changes. Of course, it is completely up to you wether you want to incorporate this or not.

 

[Turin_Turambar]

woot!!!

You are the man Olethros. And Harper, and everyone.

 

[Harper [Jgkdo]]

Of course I integrated it, works well BTW

Here is the new version, make sure to read the README.TXT (you can even keep the candy hidden in there ) to find out how to use the bots properly.

@Olethros: I moved the ini setting for bListFlag to the DTAS class so all ini settings are accessible from one ini section and removed the ini setting for iWPNumber (the default of 15 should be fine). Maybe you can add a "mutate utcaddwp" to add a new waypoint at the first free spot and a mutate utcclearwpByName with a string match to remove it again. That would minimize collision between different mutators which set up ut compass waypoints.

ChangeLog:
(InfilDTAS 1.39)
- (feature) bots behave smarter (thx to Olethros)

 

[zeep]

Amazing!! Now offline matches will be so much more intense. I wish i had more to say than just this. Oh wait,

*offers lamb to Olethros & Harper*

 

[ant75]

So my current problem is that I don't have a proper filter to distingish between those broken doors and other stateless movers like broken windows.
Any ideas?

This may be a stupid suggestion (forgive me for knowing nothing at all about coding), but instead of reseting all movers that are in "trigger toggle" state, maybe the mutator should check for movers that are set to "triggertoggle" AND that also have bUseTriggered set to "true" (as most movers other than doors usually have it set to false). On the other hand, having windows reseted is not a bad thing afterall, provided that they are still destroyable.

 

[Harper [Jgkdo]]

Windows are not in state 'TriggerToggle', so the check for normal doors doesn't effect them.
The reason they are reset is because I need another check to identify doors destroyed by door breaching charges. After such a charge hit a door, it becomes *very* similar to destroyed windows. So fixing these doors will also fix the windows.

I am currently pursuing an idea of creating a list of doors (Movers in state 'TriggerToggle') in the beginning of a map and reset them at the end of each round.
But I am not sure that I can do the same for windows, because I can't reset the "breaking glass" effect (it self destructs once it is activated) which is connected to destroying a window. So even if I properly reset most of the important window variables the glass will simply disappear once you shoot at it again.

 

[- Lich -]

Ok, following thing occured while playing offline:

First I changed the .ini settings to 1 attacker/defender player per team (more useful for offlineplay vs bots, at least on some maps). Then I played some rounds, everything was fine. When I restarted INF later there was something gone wrong. Although the .ini settings are the same, now the last attacker is killed when he is the only survivor. I am using version 1.39, but this problem maybe related to 1.38 (didn't play this version twice).

 

[Harper [Jgkdo]]

My guess is that you didn't use the new ini.

Every new version has a different section in the ini.
For example dtas 1.39 has section [InfilDTAS_1_39.DTAS] and 1.38 has [InfilDTAS_1_38.DTAS].
You have to copy over the new ini or using a faster, better and cleaner way just rename the old sections to match the new version.
I know this is painful, but changing the mutator name with every version is the only way to eliminate version mismatches.

 

[- Lich -]

FORGET IT. Fault was on my side, maybe what you said (although I am still wondering why I was abled to play DTAS without any DTAS in the mutatorlist...), maybe something else.

 

[{GD}Odie3]

@ Olethros/Harper [Jgkdo]

Does this mean you do not need INFBotDirector Mutator with DTAS .39?

 

[Olethros]

The new bot support in DTAS doesn't need INFBotDirector to work or anything like that. But BD can be useful if you want to micro-manage them to do more than just rush headlong for the flag.

 

[{GD}Odie3]

Yep, KW (or was it Crac) figured that out. Both BotDir and DTAS 1.39 are on GD DTAS SG Style Server

 

[keihaswarrior]

This is really cool now. I can tell the bots to 'Defend' and they will run back and camp at the flag!

One small problem I had with bot director: When I point them around, they follow my orders very well. Unfortunately, when I try to get one bot to follow another, it doesn't seem to work. I try to organize them into teams, but instead of supporting the other bot, they just run off. It would be nice if the 'Supporting' command you gave them carried a little more weight so you could order a team of 4 bots around by simply telling the leader where to go.

Oh, and the enemy target trace command is cool "Engage at 12 o'clock" hehe

 

[Harper [Jgkdo]]

Here is a new version for you. Consider the new (optional) feature of a delayed kill display experimental. I wasn't very comfortable with implementing it, but I am curious to see if it affects gameplay (in a positive or negative way)

For any other changes, here is the changelog:
(InfilDTAS 1.41)
- (change) teamkillers are now ranked down on the scoreboard
- (bugfix) red/blue team header in scoreboard
- (bugfix) adjusted enemy ping and name display

(InfilDTAS 1.40)
- (change) restricted mover reset to doors only (hopefully)
- (feature) added an optional *cough* kill coloumn (toggle with bShowKills)
- (feature) darkened server info screen (F2)

 

[FieldMedic]

I made some offline tests , and had fun with the new bot support.
Good job on that part.

And during those tests i found this version of DTAS to be very stable and did not encountered any bugs yet.

Very enjoyable release, thanks.

EDIT : instaposted by a new version of DTAS , i was only reporting about the 1.39 one