Welcome to Open Carnage

A resource for Halo 1 modding and tech, with unique means of rewarding individual content creation and support. Have a wander to see why we're worth the time! EST. 2012


Universal AI synchronization

14 posts in this topic

Members of Open Carnage never see off-site ads.

On 11/11/2018 at 8:44 AM, Devieth said:

Nice script, but that video's audio is something else...


Thanks, and about the audio... I didn't notice it until I uploaded it, lol, sorry. Windows' Game DVR doesn't provide me with the quality I'd desire but at least it's enough to show up the kind of updates I'm used to make/upload.


In other news, today I spent some time to work on SAPP and Chimera scripts again and found some awful mistakes in this script's code and reworked some stuff like... The server updaters, I forgot to add something that would update their limits (in other words, the last biped that would be updated would be the 300th, no single biped with an index higher than that would be updated anymore), got rid of a glitch that sometimes messed up some bipeds' animation playback and position updates, and also reworked the main 'Updater' function a little so it would now be able to send the current health and shield states of the bipeds.


I also found a way to manipulate the networked bipeds successfully in another script (so local duplicates wouldn't be necessary) but it is very susceptible to failure in bad connections or when a pair (or more) bipeds are very close to each other.


Out of curiosity... Does anybody know any in-game memory addresses/offsets where info about the FP model is stored?

Share this post

Link to post
Share on other sites

Hey, I am having trouble reading your script the way you wrote it (not sure how you have everything working, its just confusing to look at in general, how your matching a server bipd to something the client sees I cant warp my head around.) Anyway I'm thinking this might help you out instead of guessing the size of the object table? If not that's cool.  Also instead of calling `get_object(i)` a tone of times you could just do a `local object = get_object(i)`

	local object_table = 0x400506B4 -- 1.10 Client address (Not for use on dedicated server.)
	local object_count = read_word(object_table + 0x2E)
	local object_base = read_dword(object_table + 0x34)
	for i = 0,object_count-1 do
		local m_object = read_dword(object_base + i * 0xC + 0x8)
		local m_ObjectID = read_word(object_base + i * 12) * 0x10000 + i
		if read_word(mobject + 0xB4) == 0 then -- bipd

-- For the server (sapp) is mostly the same except for the object_table address which is:
	local object_table = read_dword(read_dword(sig_scan("8B0D????????8B513425FFFF00008D") + 2))


Share this post

Link to post
Share on other sites

Hello Devieth, sorry for the late reply, I've been very busy lately. This stuff for sure will be very useful to improve the client scripts, you may have already figured out that there's a function that iterates through all the objects using a static range, 1 to 1024 if I recall correct (I haven't touched the code in some time), each iteration being a dynamic object ID, I guess. The client script works fine using this scheme of taking the data and replicating whatever the server is doing locally with it, but for the latest method that I had been developing after this (the one that uses the real networked bipeds), getting the client to manipulate the bipeds using only their dynamic IDs was kind of... Frustrating, but that may be over, in case the object table you provided keeps the static IDs, just like SAPP's do (I might be wrong, but I've done some testing before and have found that every time a new object was spawned, its ID number was greater than the previous one's).


There's some information that you may want to know about the script if you want to know somewhat more about how it works. Basically, both the client and the server scripts have two main roles, the first one (and probably the most important) being the Rcon messages stuff; the server reads the memory, makes a new string containing the basic information of every biped, it formats this string and sends it to the clients, the client script, on the other hand is meant to 'split' the string and extract the information from it to then make a NEW local biped out of it (if it doesn't exist), there are also some specific sub-functions that basically format the strings to avoid some bugs in the case of the server, but overall the string management functions are placed in the middle, below the setup. On the other hand, there are the tag manipulation functions, I placed these at the bottom because they are used generally only on startup of the maps and aren't supposed to affect the string manipulation functions.


I'm conscious that there's a lot that can be polished in the code but unfortunately I can't do anything about it right now. Maybe in some weeks I will be able to retake this to fix the critical glitches and release a more 'readable' version. There's also more that I'd like to know about reading the game's memory, currently I just know how to read and write to it through SAPP and Chimera's integrated functions but have no idea about how to do it externally (which would be useful to debug some stuff quicker and find out more information not always available in the offsets and addresses lists). I slightly know how it works, but nevertheless I have very little experience on this so any advice from anyone would be very appreciated.

Edited by IceCrow14

Share this post

Link to post
Share on other sites

It's time for an update. After a deep re-work of both of the scripts, I've managed to increase their stability and fix most of the critical issues that I'm aware of, practically this version is ready for continued use in a dedicated server if anyone desires to do so. Also, I'm working in the addition of customization options for the client script with the purpose of disabling (or reducing the impact of) certain features in exchange for better performance. And last but not less important, the possibility to disable any of the scripts from inside the game or in specific maps is in my plans too.


Here's a video of the actual progress (I recommend turning on the subtitles, there is additional information about every clip):



aLTis and Tucker933 like this

Share this post

Link to post
Share on other sites

Much better than other implementations I've seen! Keep it up!

IceCrow14 likes this


"You fix my mistakes is what you do." - Tucker
"You're useless." - Tucker 2 minutes later

"You're sort of cool in some ways." - 002

Share this post

Link to post
Share on other sites

Posted (edited)

Good news, a new release version is here, and it comes with a lot of improvements. I'll be running low on time soon so I've decided to release the scripts the way they are right now, not lacking anything basic but with some cut features that I'd like to add later.


Here are some of the key features of this version:


- Named, and encounter-free bipeds will synchronize now
- AI actors that use the player biped tag will synchronize too
- RCon packets are compressed
- Aim velocities will be updated
- Introduced the in-game menu for the client script, which allows to change and save new values for parameters that can affect the game's performance
- Aditionally, a settings file for each script will be created in the root directory if they don't exist
- Protected maps can be "excluded" from the scripts' memory manipulation functions, so game crashes/exceptions can be prevented. This has to be done manually
- Improved compatibility with other Lua scripts

- Settings files will be created after the first execution, for example, the client's will appear when you join a dedicated server for the first time, and the server's, when you load the Lua script in SAPP.


And some usage:



Additional notes:


- I've removed the capability to disable server-side garbage collection because it is pretty stable now, however I would like to bring it back in future versions
- Other features that might come back are: Automatic g. c. of bipeds that no longer are updated by the server, manual reset and adjustable visual quality commands
- As a side effect, the scripts are a bit heavier this time. I seriously encourage anybody that uses them to play with the available settings because they start off with the "safe" configuration, not the best for optimal performance
- For the next version, features that I might introduce (finally) are AI synchronization for vehicles, usage of the automatically created server-side bipeds instead of local copies, and the previously mentioned ones

- These scripts (v.1.2) are NOT compatible with those from version 1.1.


Special thanks to anybody who has tested this, provided feedback, made suggestions and/or shared their knowledge and tools for the public. This (probably) wouldn't have been possible without them. :)



AI synchronization scripts by IceCrow14 v.1.2 (Fixed I).rar

Edited by IceCrow14
Found an issue in the client script.

Share this post

Link to post
Share on other sites

The client script gives me extremely low framerate on any server I join. I get less than 1 frame per second.


Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.