To make sense of that garble-guck, There's a trigger volume for the tens place, a trigger volume for the singles place, and 9 vehicles for each one (veh_1-veh_9, and for the tens-place, veh_10-veh_90)

The Server Script;

Section 1 places a named biped in if the score is high enough. A score of 46 will spawn veh_10, veh_20, veh_30 and veh_40.

Section 2 chops off the tens place of the score based on what we just placed. If we placed veh_10-veh_40, it would chop off 10 points 4 times, bringing our SCORE to 6.

Section 3 places a named vehicle into the singles area if the score is high enough. An original score of 46 turns into 6, and so will place veh_1 - veh_6. Then it sleeps long enough for clients to sync the score, before moving all vehicles to a restarting location while we wait for a while to resync the score.

So, if the score is 46, we have 4 vehicles (10-40) inside the tens-place Trigger Volume, and we have 6 vehicles (1-6) inside the single-place Trigger Volume.

On the client side, we pick up the server is about to sync us the score, give it some time to calculate that score, and then do a read for what is where. If there's a veh_10 inside the volume, we add 10 to the score, if there's a veh_20, we add another 10 (20 total). So if 46 was our server score, veh_10 - veh_40 are there, as are veh_1 - veh_6. We add 10 for each of the tens-place vehicles (total of 40), and 1 for each of the singles place (total of 6).

When it's all said and done, we added 10 4 times for the 4 vehicles, and 1 6 times for the 6 vehicles, giving us 46.

In the meantime, between syncs we use a simple tracker for keeping all players that are ingame updated. Each kill adds 1 to REALSCORE, which is handled in the AI's individual script (because yes, all 8 of my AI are running their own respawning scripts, it's not handled by a single central script).

So for the most part, the players are updated point by point, and get a full sync every so often, or optionally you can set the full-sync to also occur when a player joins or exits;

(script continuous check_for_sync)

(set #newPLAYERS (list_count (players)) )

(if (!= #newPLAYERS #oldPLAYERS) (set CHANGE_BOOLEAN true) )

(set #oldPLAYERS #newPLAYERS)

(sleep 5)

)

(script continuous SYNC_OVERRIDE

(sleep 9000) ;; 5 minutes real-time

(set CHANGE_BOOLEAN true)

)

You would edit the SYNC script to add (sleep_until (= CHANGE_BOOLEAN true) ), and then at the end of each pass where you start resetting the bipeds adding a (set CHANGE_BOOLEAN false) command to reset itself. And by doing that, every time a player joins or leaves the syncing script will run, letting any new players get the updated score. Every 5 minutes, the script is also ran regardless, making sure all players are on the same page.

Mind you, I'd probably have to adjust the sleep times a lot to take into account network lag. On a LAN this would run flawlessly, Lag takes it's toll on anything that runs on a clock. However, by using a same-starting point (when the vehicle is placed), the time should match up. If my lag is 4 seconds, and it takes .5 seconds to run a code, I should recieve the next part of the code 4.5 seconds after the first part started, exactly when I should anyway.

/copypaste

I could have improves on the lagtime slightly, but end result is syncing AI in a stock Halo PC server, without any add-ons, that has the same apparent lagtime as a dial-up game. For Halo's netcode, not too bad. Also, the above is an extremely crude and inefficient counting system, I could easily change it to a bit system as opposed to a ten point counting system and achieve significantly higher data limits or use significantly less objects.

Edit:

Found the scripts that actually synced the AI, the above is just syncing the scores;

(global short bip1_health 1)(global short bip2_health 1)(global short bip3_health 1)(global short bip4_health 1)(global short bip5_health 1)(global short bip6_health 1)(global short bip7_health 1)(global short bip8_health 1)

By linking the "Body" node to the "Body" node of the other model, they orient properly.

Here's a breakdown; The V1-8 are vehicles with the model/animations of the biped. The S1-8 are the bipeds that are the actual AI. This is the host script, the clients had no scripts running at all.

The Vehicles have no collision as this would block shots towards the AI. They're basically markers for the players to know where the bipeds are, when you're shooting the AI you're hitting an invisible biped.

Once the biped dies, the script destroys the vehicle and recreates everything. Here's ALL the bugs that I know of;

Converted server map ran an exception. CE map has no issues, therefore I blame Harbinger for a poor conversion. "Dummy" vehicles occasionally show up on client side after an AI is killed. Instead of disappearing when dead, the vehicle-marker just stays there frozen in place. This is caused by the sudden delete/respawn of the vehicles server side. This can be fixed by including a client-side script to delete all the vehicles every x minutes. Even if it deletes some of the "real" vehicles, they'll be instantly recreated for the client by the server pushing the info. LAG. The lead on the AI is two-fold, because of standard network lag, and script lag. Specifically, the time between attach/detach and sending that data over the server. You have to aim in front of the vehicle even on LAN because the vehicle is always a few steps behind.

This can be helped by removing the (sleep) commands from AI1-AI8, and also by removing the (sleep_until) commands from those and re-writing the AI_health scripts to pause the respawning instead. So instead of checking for health, it's just always running and is stopped by the health script.

EDIT: forgot to clarify that the "dummy" vehicle problem is an occasional thing, I'd say 1 of 10 AI that's killed gets frozen. Mind you, the AI still respawns and still has it's new vehicle-marker, there's just another instance of the marker frozen where the old AI died.Edited by DeadHamster on Dec 14, 2017 at 08:17 AM