Zandronum

ACS DOM is what it sounds like: the domination gamemode in an ACS version.
I tried to do this once before, but it didn't work because the compiler I was using wasn't built to do what I had in mind, so I started over with the good old ACC.
The purpose of this system is to break the boundiaries of what the built-in domination gamemode can do, while also eliminating the need for the SECTINFO lump. the system only requires a sector tag, a function call and preferably a little fade color script from the mapper. Note though, that this system is only built to support two teams, and a third team will do absolutely nothing, and neither will any number of additional teams. Therefore the current version is the "rvb version", which is the "red versus blue".

This is what my testing map looks like, simply because screenshots are required:

Spoiler: 289x170 (Open)

Now, this isn't particularly useful unless I explain how this works.

Spoiler: Gameplay (Open)

Ok, like in domination you need to stand in the domination point area, which will usually be indicated with a colored sector fade.
The difference is that this system uses a "Balance of Power" system, which means that a number keeps track of how many players from each team occupies the point, and updates with the difference. this means that three red players "dominates" one blue player. This means that the red team takes control over the point, and the BoP changes in their favor with a certain time interval until it reaches a maximum control cap.
If one team takes over a point and changes it so the BoP falls one point in their favor and leaves, then the other team can take it that much quicker. If they instead wait for it to reach the max cap, then a blue player would need more time to take over the domination point.

The reason it is constructed like this is because my experience with domination has been chaotic, basically players speedrunning to the domination points and playing fragfest on the way. With the hold system, I expect players to behave differently.

Spoiler: Mapping with the system (Open)

This is the script content of my test map:

Code: Select all

#include "zcommon.acs"
#import "ACS_DOM.acs"

script 1 open {
DOM_INIT(1, 1, 35, -16, 16, -16, TEAM_RED, 4, "Red Base"); //Red base
	DOM_INIT(3, 1, 35, 16, 16, -16, TEAM_BLUE, 4, "Blue Base"); //Blue base
	DOM_INIT(2, 1, 35, 0, 16, -16, 255, 4, "Middle Point"); //Neutral middle point
}

script 4 (int DOM_ID) {
	switch(DOM_POINT_CURRENTTEAM[DOM_ID]) {
		case TEAM_BLUE:
			Sector_SetFade(DOM_POINT_SECTORTAG[DOM_ID], 0, 0, 255);
			break;
		case TEAM_RED:
			Sector_SetFade(DOM_POINT_SECTORTAG[DOM_ID], 255, 0, 0);
			break;
		case 255:
			Sector_SetFade(DOM_POINT_SECTORTAG[DOM_ID], 255, 255, 255);
			break;
	}
}

It really isn't that complicated. Script 4 can be stolen directly, and it will set the fade of whichever sector(s) the domination point covers.

The function to be called is built like this:
DOM_INIT(int SecTag, int PointsGiven, int RestartTime, int BoP, int BMC, int RMC, int CurTeam, int FSN, str Name)

The parameters are like these:

• SecTag: The sector tag for the domination point sector(s).
• PointsGiven: The number of points given to the holding team.
• RestartTime: This determines how often the script restarts. This both determines how often the script checks the number of players from each team, but also how often points are given. The number of players from each team is calculated before the points are given.
• BoP: Balance of Power, it is a number indicating how much control one team or the other has.
• BMC: Blue Max Control, blue team will not be able to raise their BoP in this point over this limit.
• RMC: Like BMC, but for the red team.
• CurTeam: The team initially holding the domination point. This should usually correspond to the BoP you specify. This works with the constants "TEAM_RED" and "TEAM_BLUE". If you want it to be neutral, use the number 255.
• FSN: Fancyness Script Number. I couldn't come up with a better name, but it should be clear what this does. It is the script called when the point changes hands, which means one can do more than change the fade color of a few sectors.
• Name: The name of the domination point. This isn't currently used, but add it so you won't need to update your map.

Furthermore, the system uses the world variables 255 through 247, inclusive. This is how the DOM_INIT function works and it can't really be argued with.
The script numbers used are 900 trough 903, inclusive. If this is an issue, let me know and the next versions will use different numbers.
The system also required players to have the TIDs 900 and 901. This is already handled automatically by the library.

Download link:
Download from TSPG

An important technical note, for both mappers, scripters and server hosts:
Any modified version of this library can be used for the same maps as long as it carries the same characteristics, given that the person making the maps don't add in the library in his distribution (please don't, add a text file specifying library file name). Any library defining DOM_INIT should work, though I recommend using the same variable names and such as are already present in the current library for both consistency and to avoid things breaking for mappers changing libraries around for testing.

So other than that, please try this out if you are a mapper and if you aren't, well just give some maps a spin, eh? And make sure to leave your thoughts here, otherwise improvements can not happen. ;)

Spoiler: Current to-do list (Open)

• Create a system for visual representation of BoP for holding players
• Create a visual overview of points and holders.
• Possibly a system for more than two teams if such is desired.
• A "vanilla style" domination point script I suppose, would be best done elsehow though.
• A charge-up style domination point script.
• Player max altitude for capture? (Would require a large rework)

Ok I'll test this; if it doesn't suck, extend for 4 teams.

Use actors instead of sectors for domination points.

@Combinebobnt
Thank you for testing, please make sure to leave any questions here.
As for four teams, that depends on interest, really. If there is no interest, then I see no reason to make it.

@Monsterovich
You just commanded me like your little minion to scrap all my work and start over to create an entirely different system. Just what is your explanation for this? Why should I do that?
Just telling me to do something should be obviously... ineffective in terms of you getting your will. You have to make an actual point in order for it to be a logical decision to do as you say.

Lollipop wrote: Why should I do that?

Because actors are the best way, you don't even need to open your maps in the map editor. Just put these points through the cvars by using map coordinates that works on any map. This would be cool. Also, you can't mix your domination points with 3d floors in the same sector without issues. Plus you can easily allow to hold points instead of instantly capturing them that's very simple with actor position calculations, otherwise you have to add conditional actors like "Actor hits floor" that increases mapper's work.

Thank you for making your point.
I do not see why the first point makes sense, as a gamemode would normally have their maps made specifically for that gamemode anyway, as to which the mapper would obviously add in the minimal code required.
As for the 3D floors, that is a valid point, although I have never seen much use of 3D floors in competetive maps for some reason in the first place, even for gamemodes where this is not an issue. I do not expect this to prove problematic for anyone. If it does I could see if there was a way to create a height boundiary for the sectorpoints.

Now, I am not even sure how to implement this without making it cumbersome to use. The best way in my opinion would to know what teams the players are in and where they are on the map, stored in arrays, and then checking their proximity to the actor point. The problem is that I would have to block the map out in approximate areas, as to avoid checking the distance from every player to every point, resulting in playercount*pointcount loop cycles quite often, which could be a potential performance problem. Now, for such approximations, the mapper would have to go in and work those areas out, and then the whole point is gone.

Right now it just counts things in a sector, which by far outperforms what you are proposing.

Anyway, updating the first post with a bit more information.