AlliedModders - Sven Co-op 5.0 gamedata thread

AlliedModders (https://forums.alliedmods.net/index.php)

- Code Snippets/Tutorials (https://forums.alliedmods.net/forumdisplay.php?f=83)

- - Sven Co-op 5.0 gamedata thread (https://forums.alliedmods.net/showthread.php?t=289003)

Sven Co-op 5.0 gamedata thread

For SC 5.0 to be supported properly in AMXX, I think it would be a good idea to create a thread (just like this one) where we gather all game data, and once enough is gathered, update AMXX with all our findings. This includes private data offsets, network messages information, hamdata, useful signatures for Okapi/Orpheu, etc...

I had some fun today in IDA and successfully pulled out a lot of useful information regarding CItemInventory. My main goal for this update is to find ways to control the new item inventory system through AMXX plugins.
What I have currently are some private data offsets of CItemInventory (item_inventory) and I've analyzed two messages that come with it, InvAdd and InvRemove.

~~I didn't have real names for these offsets so I named them myself following the naming convention that Valve mostly uses.~~
Updated, uses real names now - everything that's exposed to AngelScript. Every offset is byte-aligned, so divide then by 4 for use in some natives, like get_pdata_int().

Spoiler

What these do can be found in: https://sites.google.com/site/svenma...item_inventory

InvAdd arguments go as:

Code:

Long (item_inventory index)

Byte (m_fHolderCanDrop)

Byte (m_fHolderKeepOnRespawn)

Byte (m_flWeight & 0xFF)

Byte ((m_flWeight >> 8) & 0xFF)

Byte ((m_flWeight >> 16) & 0xFF)

Byte ((m_flWeight >> 24)

String (m_pszItemName)

String (m_pszDisplayName)

String (m_pszDescription)

String (pev->model)

and InvRemove:

Code:

Long (item_inventory index)

Byte (true on respawn, false otherwise)

Also, there seems to be this kind of structure:

Code:

InventoryList

{

        CItemInventory* pItem;

        InventoryList* pNext;

}

and there seems to be a pointer to it (InventoryList*) at CBaseMonster + 320(80). This would be useful for finding out what items a player has in their inventory.

Your turn now!

Re: Sven Co-op 5.0 gamedata thread

Support for SvenCoop should be completely dropped. It seems they're going out of their way to make amx incompatible with their game.

Re: Sven Co-op 5.0 gamedata thread

Quote:

Originally Posted by PartialCloning (Post 2461474)

Support for SvenCoop should be completely dropped. It seems they're going out of their way to make amx incompatible with their game.

I don't blame them, and I believe they are really trying hard not to. But you can't really improve much unless you drop some backwards compatibility.
Though just them giving us gamedata would mean they greatly support AMXX.

Re: Sven Co-op 5.0 gamedata thread

Don't bother, Arks offered his help on this matter, they didn't even bother to answer him, why should we bother ?

Re: Sven Co-op 5.0 gamedata thread

Quote:

Originally Posted by PartialCloning (Post 2461474)

Support for SvenCoop should be completely dropped.

#triggered

Re: Sven Co-op 5.0 gamedata thread

Quote:

Originally Posted by KliPPy (Post 2461472)

I didn't have real names for these offsets so I named them myself following the naming convention that Valve mostly uses.

I've got you covered on that: http://samvanheer.github.io/SC_Angel...mInventory.htm

Scroll down to the properties; m_pHolder is the first item_inventory property.
Assuming they kept the AS API up to date with changes to the entity, this should be everything you need.
See http://samvanheer.github.io/SC_Angel...BaseEntity.htm for CBaseEntity properties so you can filter out the stuff that isn't part of item_inventory.

Also related to inventory:
http://samvanheer.github.io/SC_Angel...ntoryRules.htm
http://samvanheer.github.io/SC_Angel...entoryList.htm
http://samvanheer.github.io/SC_Angel...entoryMisc.htm

See https://github.com/SamVanheer/SC_Ang...mmits/gh-pages for the changes made to the API since the last version i uploaded. Apparently all they did is remove features, no surprise there.

There is a way to get the Angelscript engine pointer; with some tricks you can extract all of the data from it and get the offsets for every member variable, the address of every method, function and global. You can also use it to add new API functionality, though you'll need to use some serious C++ magic to get strings to work since they get their memory from the server library's heap.

Quote:

Originally Posted by PartialCloning (Post 2461474)

Support for SvenCoop should be completely dropped. It seems they're going out of their way to make amx incompatible with their game.

They don't understand what kind of effect their changes have on AMX, and they don't test thoroughly enough to spot any mistakes. I'd organize public tests to find this stuff but they won't go there.
Releasing early and often would definitely help to catch compatibility issues, having at least one person doing AMX compat testing on their internal branch would help catch these problems.

Quote:

Originally Posted by KliPPy (Post 2461476)

I'll quote them directly on this:

Quote:

[4/02/2016 23:28:24] AdamR: Debugging info isn't really meant to be given out for closed source projects.
[4/02/2016 23:28:48] AdamR: That's pretty much an invitation to reverse engineer and modify the executable.

Not that that will stop anyone from reverse engineering their code. With enough time and effort you can get anything you want out of their game libraries because they added some debug info to their Linux libraries.

Quote:

Originally Posted by Depresie (Post 2461478)

Don't bother, Arks offered his help on this matter, they didn't even bother to answer him, why should we bother ?

Trying and getting no help is better than doing nothing and then being accused of lying when you say they wouldn't help. Arkshine contacted me and i gave him the official response, i also directed him to Sniper but he apparently never replied.

I'm not going to say they don't care, i think it's more likely that they think they know what's best. Whether that's actually true or not remains to be seen. I wouldn't hold my breath if i were you.

Re: Sven Co-op 5.0 gamedata thread

Quote:

Originally Posted by Solokiller (Post 2463077)

Found out your documentation just after I posted this, but I felt too lazy to update variable names. :mrgreen:
Thanks anyway.

Quote:

Originally Posted by Solokiller (Post 2463077)

There is a way to get the Angelscript engine pointer; with some tricks you can extract all of the data from it and get the offsets for every member variable, the address of every method, function and global. You can also use it to add new API functionality, though you'll need to use some serious C++ magic to get strings to work since they get their memory from the server library's heap.

Months ago I thought about getting the engine pointer and making an AMXX module that will allow other modules and AMXX plugins to extend AS, and possibly communicate with each other. However, I was lazy.
What I didn't know is that I could dump all that info from the engine itself. I guess I'll take a look at the AS API documentation.

Re: Sven Co-op 5.0 gamedata thread

Well, you can't use its API to get that information. That's why i said you'll need to use some tricks; you'll have to get the library version used by SC (printed in the console on startup) and cast to the implementations of every interface to get to its data. It's not impossible, but unless you match up the right versions it will crash.

Getting the engine is a bit of work too, you'll need to create an entity that has a pointer to a function.
trigger_script has one, and i've got the source code for that entity if you need it. You'll be able to use that to find the offset (CTriggerScript is 228 bytes on Linux, the function is the last member, so + 224 from 'this').
Then you just cast edict_t::pvPrivateData to a byte pointer, offset to that function pointer, and dereference it to get the script function contained in it. (it's actually a pointer to a wrapper, the wrapper's layout is vtable then asIScriptFunction*)
Then you grab the engine pointer using asIScriptFunction::GetEngine.

Do be aware that if they find out you're hacking into their code like this, they will likely take some form of action.
Whether it involves shifting the trigger_script members around or changing how it stores the function entirely, i wouldn't put it past them to shoot themselves in the foot just to stop this.
If they won't share the information willingly, they won't allow you to get it through other means either.

That said, if they go through with Sniper's idea to reload Angelscript if a host error occurs, then you can just replace the Angelscript library that they'll be adding to do this. Implement asIScriptEngine and pass all methods through to the real engine.
Then you're basically given the address/offset and name of every API member on a silver platter. This also has the advantage of working for the client side when client side scripting is added, since they'll probably make that use the same code.

Re: Sven Co-op 5.0 gamedata thread

Just found out that I can grab all data from IDA, by looking at CASDocumentation::RegisterObjectProperty() calls, where I can grab everything that's exposed to AS. Main post updated. :mrgreen:

P.S. Should I feel dirty?

Re: Sven Co-op 5.0 gamedata thread

That works too i guess :P Completely missed that as an option.