Welcome to Open Carnage

A resource for gamers and technology enthusiasts, with unique means of rewarding content creation and support. Have a wander to see why we're worth the time!

IceCrow14

Universal AI synchronization

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
		
		end
	end

-- 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

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.