New DTAS

[ant75]

I would pick option 1 of course.

edit : ok i could live with option 2, but it'd be pretty useless.

 

[Crowze]

Harper, that's the beauty of it. Attackers would still be able to cap as normal with 2 or more people, but the spec could cap on his own. This gives the other attackers more possibility of setting up defensive positions further away from the objective to cover. If defenders take out the spec, game proceeds as normal DTAS. But if the spec finds himself on his own, he could still win by capping the objective - which would probably be the preferred option, depending on his loadout.

EDIT: In order of preference: 1, 2, 4. The others I equally dislike.

 

[Midwinter]

I don't think a kills statistic makes anything to improve the game, but being optional is a good idea as well. So I would stick either with 1 or with 4.

 

[- Lich -]

Well, due to the fact that DTAS in the last week felt a little TDMish, I would say use option 4, with online servers kills deactivated.

 

[Nukeproof]

More ideas on SPEC-DTAS:

First it would rather be called "Rescue" or "Escape" and the background is to escort the SPEC to an extractionpoint

Attackers:

- per 3 or 4 players, 1 SPEC is assigned (-> so you are able to form multiple small teams, which aproach independently)
- SPECs could get improved vest like III or IV (in tradeoff of stamina)
- the extraction point (brown) and the position of all SPECs (green) is shown in the compass to all attackers
- Capture Radius is tiny (i.e 1m no blindcap), capture time is short (2-5s)
- only a SPEC can capture (even alone)

Defenders:

- only position of extractionpoint (Flag) is given
- they spawn closer to flag than attackers but don't set the flag semselves (thereby have some distance to flag as well)


Round ends when:

Defenders win:
- all Specs are dead
- roundtime ends

Attackers win:
- SPEC captures flag (=has been safely escorted and extracted)
- all defenders dead
- Bonus points are given for every additional SPEC surviving



I'm quite aware that's not really DTAS anymore. It'll probably cost quite some efforts before we even know wether it works... Gameplay might be more vulnareable to lamers but it might (hopefully) encourage teamplay even more.

 

[Harper [Jgkdo]]

DTAS already has two gamemodes, DTAS itself and FOX. The reason for including foxhunt was that it doesn't interfere (at least not much) with DTAS.
A new gamemode would be hard to seperate from the real DTAS and will most likely cause new bugs. And to put it nicely it would look aesthetical unpleasent

The best solution IMO would be to make a new mutator that implements this new gamemode. But right now I am coding DTAS and not interested in writing another gamemode.
If anyone else wants to start writing this, feel free to ask questions or use the DTAS code as a foundation for the new gamemode if you want to

Since most of you seems to dislike I plead the DTAS server admins to disable bShowKills on the servers?
My oppinion towards it is similar to Lich's. It is a nice option for offline play, but it is disliked by many DTAS players so disabling it online is a good idea.

 

[Turin_Turambar]

Option 1 for me, waiter.

 

[Crowze]

How about hardcoding it so the kills show up in offline games but not in online? I might have a go at adding the specialist option .

 

[LongJohn]

Scoreboard: Definitely - show all kills (server decides)

Other options are elitist paternalism (like all hardcoded settings)

My server is my castle

 

[zeep]

Great. Now that we got kills out of the way, any news on the lag issue? Not to be nagging or anything but a few nights ago we were with 12 people and even then it was lagging pretty bad. Not to the point that it makes you disconnect but certainly capping full auto to something slower. I also saw the hillbug a few times. But maybe you've disabled always relevant to cope with lag.

I grew up with DTAS on JgKdo so don't take my bitching the wrong way. I just want JgKdo to have great games

/forgive hyjack

 

[ant75]

I think dtas as it is now is close to perfection . But if you're really looking to improve gameplay, the next thing to improve would be randomteamspawn imo. I find annoying that the flag almost always spawns in one end of the map, and i think it would be more fun if it would more often spawn in the central parts of a map (for larger maps especially).
If i'm not mistaken, rts works like this : it chooses a random location to spawn the first team, and then tries to spawn the other team at the farther spawn location available (i know it's not that simple, but i'm trying to be short here). Maybe if spawn location for the defending team would always be the one that is chosen first (ie really randomly), the flag would be placed in more diverse areas.
I hope what i'm saying is not utter nonsense.

 

[Cleeus[JgKdo]]

RTS is one big mess of an algorithm - whith an emphasis on mess

 

[Lt.]

I would fiddle around with the [InfilDTAS_1_49.K_INF_RandomTeamSpawn] settings, but I know it would be too hard to alter a setting, observe, alter again, observe the spawn again, etc.

is there an explanation of how to set up RTSMapConfigs, CubeXYX, etc. somewhere?

 

[Harper [Jgkdo]]

Great. Now that we got kills out of the way, any news on the lag issue? Not to be nagging or anything but a few nights ago we were with 12 people and even then it was lagging pretty bad.

This problem can't be solved by DTAS. It is a general problem happening with some EAS maps. We ran a cpulog on JgKdo for the last couple of days and have a pretty good picture about the ok maps (even with 16) and the ones consuming all cpu time even with 10 players. Currently we pursue the idea of DM conversions of EAS maps to see if there is any improvment.

it chooses a random location to spawn the first team, and then tries to spawn the other team at the farther spawn location available (i know it's not that simple, but i'm trying to be short here).

Actually it is
All the calculations done are very complicated but your explanation is pretty accurate.
Understanding and improving RTS is already on my todo list and I will get to it as soon as I have fully understood Khutans code. Placing the defending team first would require some communication between the two mutators but won't be a problem. It takes away some of the randomicity of RTS but there is still enough left.

I might have a go at adding the specialist option.

Good luck
Curious, what exactly do you want to do? Integrate it into DTAS, use DTAS as a base of development or starting from scratch?

is there an explanation of how to set up RTSMapConfigs, CubeXYX, etc. somewhere?

I changed the meaining of the settings in a recent version of DTAS (you won't miss anything since the RTSMapConfig array did absolutly nothing prior to the change). Now you can use it to disable certain pathnodes from a specific map. It is a first step towards identifying and removing bad nodes from maps (Andes falling to death, spawning outside some maps and so on). In a future version I will give players the option to identify there starting point and report it back here so we can finally get rid of all really bad spawnpoints.
On the other settings:
SPPCollisions (I think room for the player to spawn)
PercentageOfNearPoints (after the first team spawns RTS calculates how far every valid spawnpoint is away from this point and will use only points that are not "near" for example with PoNP=80 the enemy will spawn in the remaining 20%
Cube? (the map is divided into cubes of the given size. I havent figured out why exactly this is done but I am sure I will find out sooner or later. All I can say is that they are used together with the navigation points to calculate the spawnpoint)
bEveryRound (toggles map or round based spawn change)
for the other values, no idea right know. I will include these in the readme in some of the next versions.

 

[Crowze]

I think integrating it into DTAS will be possible, but I'll be basing it of your lastest, if you don't mind of course . Good luck with the RTS mess... when I first integrated it into DTAS and I saw the code, I thought 'no way am I going to touch this' .

 

[Harper [Jgkdo]]

Basing sounds good
I am quite reluctant about an integration. We would end with two conflicting gamemodes in one mutator and nobody will know what gamemode is running when joining a DTAS server.

And yes the RTS code looks scary, it is really brilliant but nontheless it freaks the hell out of me

 

[zeep]

RTS: Can't Khutan be reached for some assistance? May save you some work Harper. Also, wouldn't it be better to just open a map, correct the pathnodes, possibly add more to specific locations and eventually release a new (dtas) version? I'm just thinking out loud.

Specialist mut: Good luck Crowze

 

[Harper [Jgkdo]]

Too late, I already started hacking the RTS code
I am pretty sure I understand what Khutan is doing and I will try out some things myself in one of the next versions (though with 1.50 I want to be on the safe side and not changing any functionality of RTS)

Changing maps won't be necessary. I already added an interface admins can use to block certain nodes and I will even add map based exceptions to th RTS code (mainly because it is RTS sole purpose to provide random valid spawnpoints)
But maybe even this won't be needed. Maybe I can change the algorithm used to determine a valid spawnpoint and make it work without any exceptions.

 

[ant75]

Idea : if you can select nodes and block them, would it also be possible to select other nodes so that they have a greater chance of being used for spawn ? For example, tigerhunt is very fun when the flag is inside a house, so it'd be cool if we could decide that 1 out of 10-15 rounds the defending team would spawn into either one of the houses.

 

[Harper [Jgkdo]]

1.50 released

I still haven't deactivated bShowKills for online play (though I set it to false as a recommend default value). The main reason for doing it is that I didn't want to take the right to decide away from the serveradmins, but I still hope you (serveradmins) will consider using the defaults I propose.

About the changes to RTS, I haven't changed any functionality yet, just adding some debug options usable by players and admins. If there is any map you don't use because RTS may select bad spawns, there is now the possibilty to fix this. Here is the needed information from the README:
mutate RTSMySpawn - displays information about your current spawnpoint (admins will see spawns of both teams)
NOTE: if anyhting bad happens to any member of your team due to a bad spawnpoint, use this command and relay the information to a server admin or post it in the Inf Forum "New DTAS" thread

If you want to experiment a bit with other RTS settings, here are a short description about their function:
RTS ini settings
================

integer values:
StartPointSpacing: room between two players when spawning
LineWidth: players are placed along a line, this sets how man players spawn at each point of it
CubeXYZ: the size of the cubes the map is divided into (don't change this)

boolean values:
bEveryRound: toggles between round based spawn point change and map based changes

float values:
SPPCollisionRadius: radius for the collsion cylinder used for room testing before spawning
SPPCollisionHeight: height for the collsion cylinder used for room testing before spawning
MinThreshHold: minimal distance between both teams when spawning
PercentageOfNearPoints: how many points are considered "near". The enemy team won't spawn at "near" points