Editing, Expanding and Modifying Domination

[OrdeaL 10]

Thanks Nutta! :)

[KC Grimes 79]

Has anyone been able to add Norrin's latest revive scripts with the backpack respawn support? When I tried, everything including Ctrl Home except Ctrl End worked.

[CarlGustaffa 4]

Anyone have an idea how to use custom compositions in Domination? I.e. if I want to replace d_firebase, which now only points somewhere in the config using a string reference. I've tried something like:

d_mortarbase = loadFile "x_server\x_f\compositions\Mortar_Station_TK.sqf";

and replace d_firebase with d_mortarbase but (as expected I must say, since it's a script not a pointer) it doesn't work. Just not sure how to wrap my head around it.

I guess I have to modify x_server\x_f\fn_objectMapper.sqf, but I'm not sure what to do. Tried a little, but not really getting anywhere.

Never mind, figured it out.

d_mortarbase = call compile preprocessFileLineNumbers "x_server\x_f\compositions\Mortar_Station_TK.sqf"; //Argh, damn forum and its inserted spaces...

seems to do the trick.

Edited August 16, 2010 by CarlGustaffa

[Tankbuster 1746]

Can anyone confirm that in TT versions, there are no vehicle service factories?

[Murklor 10]

The general idea is to create a list of main targets that instead of being fully random, picks a random place that is more than x km away and less than y km away. The point is to create a list of targets that is more friendly to driving vehicles on, instead of having to constantly rely on lifting.

But isnt a mathematical solution to this overly complicated for a fairly minor gain?

I mean, take a small example. We have 3 towns in a row, where town2 is in the middle. Rather than randomizing between the 3 we already know that town2 is a better choice if you're at 1 or 3, etc. So we have just a large array between current town and related (ie nearby) towns:

dom_towns = [[town1,town2],[town2,town1,town3],[town3,town2]]

To determine the first objective: Randomize between [0][0]-[MAX][0]

To determine the next objective: Randomize between [CURRENT][0]-[CURRENT][MAX] and then delete the current town from the array (inside relations too).

If a town has no relations (for example if town2 was the first captured, then its relations are removed from both town1 and town3), either pick a new on random or pick the closest.

It wont be perfect as it would be a hybrid of randomization and determined AAS-like sequences (depending on how you create the town list in the first place), but should minimize math :)

[Tankbuster 1746]

Can anyone confirm that in TT versions, there are no vehicle service factories?

Confirmed. :)

d_aircraft_facs =
#ifdef __DEFAULT__
if (__OAVer) then {
[[[7731.88,1694.06,0],333],[[7970.34,1810.31,0],244],[[7857.73,1745.96,0],244]]
} else {
[[[4329.36,10899.2,0],60],[[4397.26,10690.8,0],148],[[4932.19,9773.54,0],325]]
};
#endif
#ifdef __EVERON__
[[[4814.13,11092.8,0],0],[[4841.15,11948,0],0],[[4814.62,11361.6,0],0]];
#endif
#ifdef __TT__
[];
#endif

[CarlGustaffa 4]

@Murklor: Not sure I follow. Seems like a lot of manual labor setting up the relational dom_towns array in the first place. As my targets are quite huge in area (compared to original) I end up with overlapping targets many places. This is not a problem as I check against a minimum distance preventing that possibility (you can get the overlapping target after completion of one further away though). It has to be automatic; put in the targets to d_target_names and the math should do the rest - no manual labor.

If your suggestion does that, then I'm just failing to see it.

[Tankbuster 1746]

The problem with nearby targets, we found, is that the players move on from the old to the new target and attack it before it's fully spawned, and that leads to lag and server problems.

[Murklor 10]

@Murklor: Not sure I follow. Seems like a lot of manual labor setting up the relational dom_towns array in the first place. As my targets are quite huge in area (compared to original) I end up with overlapping targets many places. This is not a problem as I check against a minimum distance preventing that possibility (you can get the overlapping target after completion of one further away though). It has to be automatic; put in the targets to d_target_names and the math should do the rest - no manual labor.

If your suggestion does that, then I'm just failing to see it.

Large zones and overlapping would easily be solved by considering which secondary zones relate to what primary zone, then check against the distance when randomizing a new one (when relation fail to find a town), cant be too close unless its the last one left. It would be a little manual work creating the array, yes, but its really just a matter of slapping down named markers to designate a zone and filling it in.

Sure the disadvantage is that its not fully random - if you just want gigantic zones not focused on terrain features (ie towns or similar), then your method may be better. But if you want say a domination "mission" with 5 specific towns in close sequence, then spread out either to option A or option B on random and continue with another 5 specific towns in sequence based on what random option was made, it can do it. Plus, this could be flexible zones rather than large random min-max distance based. How about an utterly huge one (tank battle), followed by a small one (capture the mountain pass or something) followed by taking the nearby town?

@Tankbuster

IMO this is more a flaw in the overall design than the fact the town is closer. Free paradrops and flags in captured zones make half the team reach the next zone in like less than a minute. If I where to re-design something about Domination, it would surely be that! Remove all paradrop flags completely, make only the C130 able to paradrop people (ie HALO jumps from it).

Plus, I think there is one critical part of the enemy forces that is missing: Ground reinforcements. IMO there is no need to create EVERYONE at the same time and just have them stand or prance about in the zone lika idiots. Seems like this is done because you can paradrop smack on top of them and just snipe everyone. Imagine if you could have intermittent BATTLES when 4 tanks and 30+ infantry units roll into a zone to reinforce it?

Edited August 17, 2010 by Murklor

[CarlGustaffa 4]

Yeah, I've already removed parajumping into the next target. There is combat jumping available for everyone from the base, but the restriction is you can't jump too close. There is HALO jumping only for three guys, but the restriction is you can only jump from two zones and the altitude is really high - it takes a while.

The point with nearby zones is to make it possible to get to the next target by vehicle without having to spend too much time doing it (most people aren't as patient as I am wrt "dead time" :)) But nice tip btw, I'll look into not revealing the next target until it has been fully setup, but not highest on the priority list.

Btw, think I found a bug. During debugging I've set d_searchintel bits all to one (found) in init.sqf. And there is not much working. I haven't tested this in multiplayer or non debugging version yet, but:

x_server\x_airki.sqf:

#ifndef __TT__
switch (_type) do {
	case "SU": {if ((__XJIPGetVar(d_searchintel) select 2) == 1) then {d_kb_logic1 kbTell [d_kb_logic2,d_kb_topic_side,"TellAirSUAttack"]}};
	case "KA": {if ((__XJIPGetVar(d_searchintel) select 3) == 1) then {d_kb_logic1 kbTell [d_kb_logic2,d_kb_topic_side,"TellAirAttackChopperAttack"]}};
	case "MIMG": {if ((__XJIPGetVar(d_searchintel) select 4) == 1) then {d_kb_logic1 kbTell [d_kb_logic2,d_kb_topic_side,"TellAirLightAttackChopperAttack"]}};
};
#endif

Should probably read:

#ifndef __TT__
switch (_type) do {
	case "SU": {if ((__XJIPGetVar(d_searchintel) select 2) == 1) then {d_kb_logic1 kbTell [d_kb_logic2,d_kb_topic_side,"TellAirSUAttack",true]}};
	case "KA": {if ((__XJIPGetVar(d_searchintel) select 3) == 1) then {d_kb_logic1 kbTell [d_kb_logic2,d_kb_topic_side,"TellAirAttackChopperAttack",true]}};
	case "MIMG": {if ((__XJIPGetVar(d_searchintel) select 4) == 1) then {d_kb_logic1 kbTell [d_kb_logic2,d_kb_topic_side,"TellAirLightAttackChopperAttack",true]}};
};
#endif

I think I experienced the same problem for AIs artillery warning as well, but my AI artillery system is completely different, so I can't tell you where to fix. Also I get no spotting warning, no saboteur warning, basically no nothing :p

I also suggest upping the chance of getting the "governor main target secondary mission", so as to increase the chance of finding any intel. Or removing him from secondaries and making sure he is always there. Back when this was invented for Dominatrix (Arma1/ACE1) I put it on all squad leaders (but with less chance of occuring), but now it's only on this one dude that is not even present in all missions, making intel extremely hard to get. I haven't seen a single public game (not played many lately though) where any intel was ever found. It would have been worthwhile looking for it - if it worked that is :)

Think I found how to fix the problems, at least for single player testing:

Search for any use of d_searchintel where kbTell is used, and put a ",true" at the end.

Edited August 17, 2010 by CarlGustaffa

[Murklor 10]

I haven't seen a single public game (not played many lately though) where any intel was ever found. It would have been worthwhile looking for it - if it worked that is :)

Actually I saw this yesterday, someone found intel on the body of a dead guy :)

I dont really know what it did though, not much effect other than the coms saying it.

And I get the point about nearby zones, I'm not arguing that logic. Vehicles are generally used far too little in Domination, especially light vehicles (like jeeps), its infantry and helicopters all day long. I just believe your method is a bit over-complicated ;)

[CarlGustaffa 4]

I agree, on everything :p My method is overcomplicated. Simpler methods work in my head until I try to actually do it - then I end up with the same mess :D

Feel free to suggest an alternative way that works fully:

1. Rearrange the target list.

2. Adhere to minimum and maximum distance, allowing above maximum if no alternatives can be found (otherwise the list wouldn't complete).

3. No "manual work" (I have over 40 target locations).

As for the intel, it is supposed to give you early warnings about stuff that is supposed to happen. I.e. when AI sends artillery downrange adn you have that piece of intel, you'll get a warning allowing you to get away before impact. Or early warnings when attack planes and choppers are sent to the target; for vanilla everyone can just grab a Stinger and have a go, but for me with limited everything, you better get prepared.

Edited August 17, 2010 by CarlGustaffa

[Murklor 10]

Feel free to suggest an alternative way that works fully:

1. Rearrange the target list.

2. Adhere to minimum and maximum distance, allowing above maximum if no alternatives can be found (otherwise the list wouldn't complete).

3. No "manual work" (I have over 40 target locations).

Well you already know that I cannot match all those, since I already said it require some manual work. 40 locations wouldnt be that complicated though.

Maybe I'll get around to actually modifying Domination than just suggesting things some day so I can see how it works in practice, but without a dedicated server I doubt I'll ever work up the courage. The mission is extremely complicated as is, if you touch something everything breaks, lol.

[CarlGustaffa 4]

Oh yeah, been there, broke that :D

So, about the locking, did a little experiment. In init.sqf, I changed to:

[1, "d_mhqdepl", {(_this select 0) lock (_this select 1);[b]hint "Mobile HQ vehicle should be locked now!!";[/b]d_allunits_add set [count d_allunits_add, (_this select 0) getVariable "D_MHQ_Camo"]}] call XNetAddEvent;

When I test in SP, I get the new hint. In MP, the hint doesn't show. Should I replace the first 1 with a 0 and move this whole line up before the isserver check to get deployed vehicle locks back? Or should I use a separate XNetAddEvent only for the clients that only deals with the lock (similar to how client visual effects are done), and remove the lock system from the server? Or maybe just kick out the player who enters if vehicle is deployed (similar to engineer vehicle check script)? This netcode with its extreme short codes may be effecient, but it's really hard to read and understand.

[xeno 234]

This netcode with its extreme short codes may be effecient, but it's really hard to read and understand.

You can replace the event names with longer strings if you want and it helps you, doesn't matter.

How does it work:

To add an event you have to use:

[0, "eventname", {code to run}] call XNetAddEvent;

0 = the event gets registered on all clients (plus server)

1 = server only (isServer)

2 = client only

3 = dedicated server only (isDedicated)

4 = alternative client only (!isServer)

"eventname" is the name that you choose for a net event.

["eventname", parameters] call XNetCallEvent;

This will run the event where it was registered. If you have registered a 1 event type, then the event will only run on the server.

The parameters can be a single value or an array and gets transfered to the event code.

Now what's also possible is to add more than one code statement to an event:

[0, "event", {first code}] call XNetAddEvent;

[0, "event", {second code}] call XNetAddEvent;

["event", parameters] call XNetCallEvent;

Will run both code statements.

One thing more. When you execute an event with XNetCallEvent and you have registered the event on the caller client/server too the code will run there too.

It is also possible to remove an event with XNetRemoveEvent again:

"someevent" call XNetRemoveEvent; // this will remove the event someevent only where XNetRemoveEvent was executed

Examples:

Display a hint message on all clients:

[2, "d_hint", {hint format ["%1 send the following message: %2", _this select 0, _this select 1]}] call XNetAddEvent;

["d_hint", [name player, "This is a test message"]] call XNetCallEvent; // can be executed on any client or the server, the message will only show up on clients

Add an object to an array on the server:

[1, "d_add", {somearray set [count somearray, _this]} call XNetAddEvent;

["d_add", someobject] call XNetCallEvent; // again, doesn't matter where you execute it, the object will only be added to the array on the server

Xeno

Edited August 17, 2010 by Xeno

[Muzzleflash 111]

Hey Xeno

Sent you a pm some weeks ago. Is it okay if I use that script you are referring to above in other missions?

[xeno 234]

Is it okay if I use that script you are referring to above in other missions?

Sure.

The concept is from CBA, I've added the part for registering events on certain machines. It stores the events with the eventname in a locally created object so getting the event code with getVariable "eventname" is quite fast. Makes network handling totally easy (and it is using just one publicVariable for all events).

Xeno

[Murklor 10]

Oh yeah, been there, broke that :D

Well at least you get that far, lol. The very design of Domination remain a complete mystery to me.

I got home, with a simple idea: "Hey I'll just jack into the main target generation to see if I can alter the way it generate the zone!".

Change description.ext to include a "my special random 2" option for main targets. Success.

Tried finding where the mission is determining generation based on the selected d_MainTargets option. Fail.

Tried finding where actual generation of main target and "start" of the mission is. Fail.

Working backwards, tried finding where x_server\x_createmaintarget.sqf is called from. Fail.

Give up. Success!

So that's pretty much it. I managed to edit a single line in description.ext. Well, two really!

Edit: Oh wait, after another 20 minutes of scratching my head I got part of it. Dont understand why x_createnexttarget.sqf is only called when d_SidemissionsOnly == 1, otherwise I thought that was the "start"... x_setupserver.sqf doesnt seem to call it?

Blergh.

Edited August 17, 2010 by Murklor

[CarlGustaffa 4]

No need to edit description.ext. You want to replace how randomization is done. The list is targets is randomized by default in init.sqf as follows:

d_maintargets_list = (count d_target_names) call XfRandomIndexArray;

Now all you need to do is replace that function with your own, I used:

d_maintargets_list = (count d_target_names) call XfArrangeTargets;

Also, it's probably best to do it outside Domination. I made a separate mission where I just copied the needed stuff directly into the missions init.sqf (target array data and some useful functions for instant marker creation etc useful for debugging it), and made the resorting a normal script I could call up with a radio trigger. That way the mission can be left running in the background, and errors can be fixed without restarts. As long as the radio trigger executes a script using execVM, and not deals with anything precompiled stuff, editing will be a lot more flexible.

Once you're happy with how it works, then it's time to implement it in the mission you're actually working on. For this stuff, fairly easy, since you're only replacing a single function call with your own. My small problem was that I had sleeps going on in the script version, which calls to functions doesn't like. And some access to certain data needed for debugging that clients doesn't have, but I just publicvariabled that and it worked. Here is how it looked while I made the thing, well outside of Domination :p

@Xeno: Thanks for explanation. Hope I can understand it eventually :D

Edited August 17, 2010 by CarlGustaffa

[Murklor 10]

No need to edit description.ext. You want to replace how randomization is done.

Not only did I want to do that, but also how the zones are generated (as in a whole new set of data associated with them). Which is why I wanted to use the description option. Selecting a special option would launch another way of generating zones and how the AI handles them. Just need to figure out where/how it starts the main zones so I can do a simple if and execute another zone init instead. I know could replace the files, but I dont want to do that as it would break the regular mission.

[Durka-Durka 10]

Is there any reason the squads aren't grouped? I'm trying to troubleshoot why 2.28 crashes so much and one of the changes I made was grouping the units together according to their squad lable (alpha, bravo, ect)

[Tankbuster 1746]

Is there any reason the squads aren't grouped? I'm trying to troubleshoot why 2.28 crashes so much and one of the changes I made was grouping the units together according to their squad lable (alpha, bravo, ect)

Are you playing AI version? They aren't grouped in AI.

[Durka-Durka 10]

Are you playing AI version? They aren't grouped in AI.

I'm playing/modifying West_R version. They aren't grouped in that either, from what I can tell. So I went in to the editor and hit f2 for groups, then connected the lines to alpha/bravo/ect so they would be more organized in the multiplayer setup screen. Could this cause a crash to desktop?

Edited August 17, 2010 by Durka-Durka

[CarlGustaffa 4]

@Durka-Durka:

I don't know what could possibly cause a CTD, but I wouldn't touch grouped or ungrouped units for a given version. If the _R is revive, then I assume they should be grouped. I haven't messes with that version myself, but when I have played it I have had group icons to my leader - indicating I was grouped.

@Murklor:

Good idea about uniqueness to the targets. I'll keep that in mind. But I would probably just store that as a data set within target_names array (and update the target readout macro accordingly). I've already added guards and patrols to the camps, pluss a number of mortar stations (which does make a difference, even if they will not actually fire). AI arty updated to be more survivable and fun, and will cease for a number of reasons (you don't know the number of spotters though, but they only call it in now, they don't need to know - everyone reports to the spotters). For the mortar support to shut up, you need to silence every tube in the area (they are close, so they don't need the radio tower support). And the mortars will keep you moving, trust me - forget camping :D As for ourselves, we only have one set of artillery and one set of mortars (both "external support"). But I really wish we had some 60s in the game, those 80s wreck complete havoc at times...

[KC Grimes 79]

I'm playing/modifying West_R version. They aren't grouped in that either, from what I can tell. So I went in to the editor and hit f2 for groups, then connected the lines to alpha/bravo/ect so they would be more organized in the multiplayer setup screen. Could this cause a crash to desktop?

I've done this for each version, works without any flaws. The grouping doesn't effect anything other than the groups, script-wise. Other than the team thing in show status.