Sikovit
Retired
Thanks!
Needed this. (:
Needed this. (:
What do you mean? CMRs still work the same way as they always have... Offsets have just changed a little bit since this thread was made.I am currently working on a new CMR that will work with TU16, as I am new to CMR Modding I may need some help along the way. Would anyone be willing to help me out with this? If so Add me on Skype: Phunctional
Just out of curiosity, is there a new version from the ones I posted on the last page? Or does the latest struct still work? If not I can update it.What do you mean? CMRs still work the same way as they always have... Offsets have just changed a little bit since this thread was made.
Honestly i'm not really sure how to use the offsets you posted, I tried to calculate their location in a cmr_save but none of it seemed to match up consistently. The values that you posted do work though and they have helped a lot. Perhaps i'm just a noob.Just out of curiosity, is there a new version from the ones I posted on the last page? Or does the latest struct still work? If not I can update it.
I'm guessing you'd take the version from the header, and then after that, for instance, the integer after the header would be the first enumerator, and then the second integer would be the second enumerator, and so on.Honestly i'm not really sure how to use the offsets you posted, I tried to calculate their location in a cmr_save but none of it seemed to match up consistently. The values that you posted do work though and they have helped a lot. Perhaps i'm just a noob.
To him I was only meaning to understand what he was talking about by a CMR that works on TU16 because the structure is still the same as the last TU.
Thank you, I was definitely doing it wrong.I'm guessing you'd take the version from the header, and then after that, for instance, the integer after the header would be the first enumerator, and then the second integer would be the second enumerator, and so on.
Let me just give you an example.But wouldn't that mean that I would do something like 42+8 in hex to get the offset? That gives me 4A.
enum primaryWeapon
{
ar = 1,
smg = 10,
lmg = 100
};
void readFile()
{
//TODO: Open the file.
theFileIO.Seek(0x42);
primaryWeapon thePW = theFileIO.ReadInt();
//If the integer is 1, then thePW is an assault rifle, if the integer is 10, then thePW is a sub-machine gun.
I figured it out in my last post and edited it. What you are showing doesn't really seem right to me, at least not for a CMR since in a cmr_save file the version number is here:Let me just give you an example.
Code:enum primaryWeapon { ar = 1, smg = 10, lmg = 100 }; void readFile() { //TODO: Open the file. theFileIO.Seek(0x42); primaryWeapon thePW = theFileIO.ReadInt(); //If the integer is 1, then thePW is an assault rifle, if the integer is 10, then thePW is a sub-machine gun.
That would be correct. I was thinking wrong. Though I'm not sure if the header ends at the version number.I figured it out in my last post and edited it. What you are showing doesn't really seem right to me, at least not for a CMR since in a cmr_save file the version number is here:So then I take the offset for the version number and add whatever offset he says to use in struct s0 to that to find the offset in the file. But what if I want to use an offset from say struct s3? Would I just add 86+1859(s0)+14(s1)+128(s2)+whatever offset i want to use from s3?
That might be the case but I still find it odd that mine is exactly 10 bytes after. Especially consider that all 10 of those bytes are 00s.That would be correct. I was thinking wrong. Though I'm not sure if the header ends at the version number.
The header contains all the data about the rest of the actual data below. The header may of changed lengths, or what he said is wrong.Failed to quote your posted before you edited it, but:
Yes but the offset for my version number is 0x56. I'm not really understanding this idea of a header... he said the FIRST 42 BYTES are the header so wouldn't that mean that the correct offset for the version number should be 0x46? Mine is 10 bytes after that...
Ah, alright. Thank you.The header contains all the data about the rest of the actual data below. The header may of changed lengths, or what he said is wrong.
Looking at his structure though, you can find the end of the header by locating the "recipeName" value and subtracting 0xF3.Ah, alright. Thank you.
I'll look at that next time i'm on Ghosts and see if that matches up properly then get back to you. Thanks again for the help though, hate to ask such dumb questions.Looking at his structure though, you can find the end of the header by locating the "recipeName" value and subtracting 0xF3.
There does seem to be something different in the new file but i'm not sure what yet. There is a new version in the CMR files, it now lists the version as 59 and the file is 1971 bytes instead of only 1945 (a difference of 26).Just out of curiosity, is there a new version from the ones I posted on the last page? Or does the latest struct still work? If not I can update it.
There does seem to be something different in the new file but i'm not sure what yet. There is a new version in the CMR files, it now lists the version as 59 and the file is 1971 bytes instead of only 1945 (a difference of 26).
In version 58 there is a 01 at 0x18F in the gametype I was looking at, but on version 59 that same 01 is moved all the way down to 0x1A9. That's exactly 26 bytes down although they're all just 0s.
Whatever they added is somewhere between 0x7F and 0x1A9.
That's probably it.It may be the esports change they made. You can now rename the teams.