Warning: Long post incoming, explaining the most advanced Scripting Technique in existence of ZH.


This is a summary how multiplayer-syncing in Generals works and about the hard-to-understand way behaves.

Also this post will teach you how to use this new knowledge to your advantage in order to create far more powerful multiplayer maps. You will learn how to individually show different briefings and different timers to different players and how to individually move the camera to a different spot for each or any player at the same time. And you will learn what can absolutely not be done separately for each player.



What most people know: In Singleplayer Mission Maps (no start positions) and in singleplayer compstomp maps you can use to transfer stuff to the human player without any trouble.

But if you use in Multiplayer while another human player is present, the map will trigger a mismatch and the match will force-end (Like this: Mismatch Picture ).

But why is that?

The explanation is simple.

As a reminder:
player0 is the player in the first lobby slot.
player1 is the player in the second lobby slot, etc.

But is the human player sitting in front of the computer the code is being executed on. And that's why this will cause trouble in multiplayer maps when more than one human player is present.

Example to make it easier to understand:

You are playing online 1vs1 against a human player. In your map you have a script:

*** IF ***
True.
*** THEN ***
Unit 'Bulldozer' is transferred to the command of Player '<Local Player>'

The game will mismatch.


Both players will individually see that the "Bulldozer" was transfered to them. Theoretically the "Bulldozer" is now being owned by two human players at the same time, with both players having full control over it. But the game engine does not support that. There may only be one owner. And the game does not know whos game-data is valid and who is the rightful owner of the unit. Thus the match mismatches.


This is also being abused by assheads online to force-end a match they are losing. Of course they do not use a script, as they can't modify the map on-the-go. So instead they use a game-trainer/cheat-engine. For example they use a cheap cheat tool that increases their money. And their money does increase. But only on their computer. Again, the online-engine does not know who to trust and force-ends the game with a mismatch warning. But don't worry, Gentool blocks people from starting their game if they have a trainer installed, otherwise I wouldn't be teaching you how to mismatch your game :D



Now you know why the game mismatches. But how could you possibly use that to an advantage in order to make better maps?


The answer is actually quite simple: Not all script actions will trigger that Mismatch Warning! And that changes everything, because some of these actions you will absolutely love to use in a local-player-dependant way and I will teach you how and why.


Example:

We have a 4-human-players-multiplayer-mission-map with 5 start positions. The first 4 lobby slots are for 4 human players. The last lobby slot is for a computer player (same as in many AOD maps), let's say teamSkirmishGLA.

Every Human-Player has a different thing to do in the map. Human-Player 1 must kill a dozer. Human-Player 2 must kill some tanks. Human-Player 3 must snipe some people and Human-Player 4 must prevent the others from doing any of that.

How do you explain that ingame? You would need 4 different briefings, explaining the mission to one player after the other sequentially. Every player will learn about their mission... but also they will learn about 3 missions that they aren't supposed to do by themselves, reducing the amount of valuable information to a mere 25% and also making the intro very confusing. It also greatly reduces the re-playability of the map, because all players will know exactly what each player's job is and the map will round-about always be the same for everybody. That's not good (at times).

Let's see how to script it in a way that a mission is only explained to the player that is supposed to do that exact mission.

First we will need a support-script to spawn and transfer four support units, one for each human player (use units that will not attack each other or spawn the units at different waypoints):

*** IF ***
True.
*** THEN ***
Spawn Unit 'player0unit' of type 'ChinaCommandCenter' on Team 'teamSkirmishGLA' at waypoint Waypoint 'some place far off the map'
Spawn Unit 'player1unit' of type 'ChinaCommandCenter' on Team 'teamSkirmishGLA' at waypoint Waypoint 'some place far off the map'
Spawn Unit 'player2unit' of type 'ChinaCommandCenter' on Team 'teamSkirmishGLA' at waypoint Waypoint 'some place far off the map'
Spawn Unit 'player3unit' of type 'ChinaCommandCenter' on Team 'teamSkirmishGLA' at waypoint Waypoint 'some place far off the map'
[???] Unit 'player0unit' is transferred to the command of Player 'player0'
[???] Unit 'player1unit' is transferred to the command of Player 'player1'
[???] Unit 'player2unit' is transferred to the command of Player 'player2'
[???] Unit 'player3unit' is transferred to the command of Player 'player3'

Now come the trigger scripts that differ between the four Human Players:

*** IF ***
Unit 'player0unit' is owned by Player '<Local Player>'
*** THEN ***
Show military briefing String: 'Hi, your mission is to kill the Dozer.' for  5000  milliseconds.

*** IF ***
Unit 'player1unit' is owned by Player '<Local Player>'
*** THEN ***
Show military briefing String: 'Hi, your mission is to kill the Tanks.' for  5000  milliseconds.

*** IF ***
Unit 'player2unit' is owned by Player '<Local Player>'
*** THEN ***
Show military briefing String: 'Hi, your mission is to snipe the people.' for  5000  milliseconds.

*** IF ***
Unit 'player3unit' is owned by Player '<Local Player>'
*** THEN ***
Show military briefing String: 'Hi, your mission is to defend the Dozer, the Tanks and the People.' for  5000  milliseconds.

Yes, it is that simple.

Depending on which lobby slot you are in, you will only see one of these four briefings.


This can also be combined with any other ***IF*** condition (a timer/counter, a trigger area etc.).



The only thing you absolutely positively need to make sure when using this method:
Do NEVER run an Action that will actually trigger a mismatch warning that force-ends the match. For example, you will never be able to share Ownership of a unit between multiple players, even with this method! You can only do cosmetic/visual things with these local-player-dependant scripts!


Things that do not cause a mismatch when made Local-Player-Dependant
- Display of Counter / Timer (ONLY DISPLAY!!!))
- Display of military Briefings
- Movement of Camera
- (untested) Radar Events
- (untested) Highlighting of Units

Things that will definitely mismatch a game if made Local-Player-Dependant:
- "Play Sound 'XYZ'" (for some weird reason. So you can !!!!NOT!!!! play sound effects via scripts in individualized intros). Instead do this:
http://www.cnclabs.com/forums/cnc_postsm148375_The-logic-behind--Local-Player--explained-and-how-to-use-it-in-Multiplayer.aspx#post148375 
- Movement of any unit
- Cashflow
- Triggering any other script that contains any of these actions (logically)
- (untested) mere ownership of a unit (without the unit being used or moved in any other way, probably not a good idea!!)


Generally speaking:
Always keep local-player-dependant scripts and non-local-player-dependant scripts STRICTLY seperated. If you mix them up your map will be very unstable and bugs will be hard to find.



That is all for now.


If anything is too confusing or hard to understand, please feel free to ask.

Edited by user 7 years ago | Reason: Not specified

I just tested some scripts with one of my friends and the following scripts dont cause mismatches:

-Flashing units.
-Radar events.
-Disable/Enable Letterbox mode.
-Disable/Enable User Input.
-Disable/Enable Draw-icon UI.
-Disable/Enable EVA.
-Disable/Enable Occlusion.
-Disable/Enable Particle Cap.
-Set max FPS.

All these can be done for different players and will not cause mismatches.

Speech and sound effects don't give a mismatch if you only play it for player0, but any other and there will be a mismatch. (Odd...)

Alternatively to creating a script that spawns and transfers units to all playerX (where X is the number of the player), you can create players in the player list named "playerX" then place an object for each player and in Object Properties change the team to "teamplayerX" then make sure to name the units like, for example the way I^love^mixery did, to playerXhelper, so you can use them in the scripts later. Doing this will also remove all the [???] from the scripts that use playerX.

This topic needs to be pinned btw.

---

So individual sounds for player0 do work with this method but if you use it for any other player# a mismatch will be triggered? Are you sure about that?

Thanks for the tests btw. Feel free to do more😁

That's nice scripting logic!
Playing individual sounds for each player would mean that we can overcome the hardcoded super weapon voice events (add new ones to SpecialPowers with no-voice Enums) using scripting (useful for mods). Would be a pity if it causes mismatch.

Yes.

---

For anybody who still cares, this is how you play sounds for only one player:




Any other solution will cause a desync. Of course you can fancy things up a little but this is the basic solution.

mixery, you're a genius

here's one way to fancy things up

---

Found a (normally impossible) way to control CommandButton availability differently between human players. It is normally impossible because the CommandButton scripts have no "for player X" insert field, so if both players are the same faction, both players will be able to build X even if only one of them has fulfilled the prerequisites. And if you cheat your way around this using LocalPlayer by removing or adding command-buttons for only one LocalPlayer, the game will be thrown off-sync and eventually mismatch, making this impossible even with all the tricks above.

But wait! There still is a way to fix that behaviour:
With this script you can only build neutrone shells if you own an InternetCenter, the script is fully in sync and will not cause a mismatch. Note the different slot numbers. Basically, the command button is made off-limits instead of being removed.

Take a look at the slot numbers in these scripts:

(active, run every frame, don't deactivate upon success)

Limitation: The imaginary slots (16 in the example above) may only be the slots 15, 16, 17 and 18. Slots higher than that will still cause a mismatch! So you are limited to 4 command buttons per faction per building.

Explanation why this works:
So player0 owns an InternetCenter.
player1 doesn't.

For player0 the upgrade is in slot 6.
For player1 the upgrade is in slot 16, which means that, for player1 only, it is technically there, but off-limits and not clickable or keyboard-shortcut-able, but the machine of player1 still accepts the fact that somehow player0 clicked the upgrade (because, technically, the command button is there, the game doesn't understand it's off-limits). AI behaviour not tested.

This allows you to fully and completely customize the entire building and unit tech-tree of maps without .ini file! Things like "you need 5 propaganda centers and exactly 57 dozers to build a nuke are now easily do-able with this. And the best thing, you only need one script for all 8 player slots!

One tiny detail to keep in mind:

There, however, is one tiny glitch:
In order to update command button positions, the object needs to be re-selected. That means: If one player has the requirements to "see" the command button, and, while having the object selected, loses the requirements, the command button will still be there and click-able until the object is re-selected. It is the same the other way around, the button is not there until the object was re-selected.

If you, absolutely positively, need to fix that tiny bug, this would be the way to force-deselect everything, but will require some more work to check if the condition changed:

How did you even come up with that?! 😮 😮 😮

---

Not sure if that question was rhetorical or not, but anyway:

I usually narrow a problem down by factual approach. I knew why the game was desynced and searched for a way around it. So, similar to the sound solution above, I had to find a way to "fake" something not being there even though it is there. Having to find a way to hide the button without actually disabling it was the only logical conclusion.

Of course I didn't know whether it would crash or not, so I simply tested it. And it worked. So yea, a mix of narrowing down and trial and error. You can pretty much fix anything that is fixable by following these steps, given that you know the tools and their limits.

Yo, concerning sound mismatches:

I just realized it doesn't even have to be the same sound used in the workaround, which makes things A LOT easier.




So for player1 it will play AirRaidSiren and for everybody else it would play BlackLotusVoiceCashComplete, but it has been muted permanently for every player, so no hassle with the need to un-mute sound effects, as you can just use any unneeded sound as a placeholder (aka muted sound file).


100% confirmed and mismatch free.

I don't know how much this really matters, but there is a very specific situation where you will get a mismatch if you move a commandbutton.

The stealth general's arms dealer has terrorist bikes in slot 15 for the AI to use. So if you change that slot locally the game could mismatch when the stealth AI builds terrorist bikes.


I actually suspect I could bypass gentool (if I wanted to).

I discovered a method years ago to create a mismatch button in-game. According to gentool's documentation it would not detect it as an invalid game install.

I've debated on trying to contact gentool's dev but I honestly doubt anyone else will ever figure out how to do it.

---

Small addition by Newgate:

There is a sound script action that doesn't cause mismatches at all, but it limits you to speech files: