Midna

Its added, but I cant reproduce the crash so we'll have to wait and see what happens.

I'll edit this post once I know more,

Thanks once again.

Edit: Stable so far(12h uptime)

Edit2: Almost 48hr now, still no related crash.

Edit3: Confirmed stable.

ps im only using mmaps in arena and bg's. only offmesh I use is in Blade Edge Arena.

Yes it is included, but ill do a full re-patch/compile just incase.

Could this be caused by a similair problem?

http://pastebin.com/n2nyyW8p

t = 0x4280003a <Address 0x4280003a out of bounds>

The crash itself seems very similair.

Its also caused by offmeshes as the XYZ provided in the crashdump is near the rope in Blades Edge Arena.

It seems to work

I really appreciate the work you put into this and thanks alot for the help.

-Midna

Hello, I got mmaps working on OregonCore(2.4.3) using the mmaps_rewrite repo, But I'm having problems with offmeshes, I've looked at the fixes Posted before(page 38 post #936) but they are already included.

After walking across an offmesh a few times I get this crash:

http://pastebin.com/wrPCDnrK

I managed to reproduce it on local and it seems to be fairly deep in the detour code:

const unsigned char* t = &tile->detailTris[(pd->triBase+j)*4];

const float* v[3];

for (int k = 0; k < 3; ++k)

{

if (t[k] < poly->vertCount)

v[k] = &tile->verts[poly->verts[t[k]]*3];

else

v[k] = &tile->detailVerts[(pd->vertBase+(t[k]-poly->vertCount))*3];

}

In this code taken from DetourNavMeshQuesy.cpp 't' seems to be invalid at the time of the crash. simply returning a DT_FAILURE when this is the case will cause the pet to get stuck.

Is this something related to Oregon Core/backport?

Any suggestions are welcome.

-Midna

I've yet to see something that changes backpeddling speed . But yes then it should be noticable.

I just got a bit worried as it disapeared without a notice or smt

This patch is for oregon, but it should mostly be thesame.

The server sends movement info in the wrong order.

@@ -374,9 +374,9 @@ void Object::_BuildMovementUpdate(ByteBu

// Unit speeds

*data << ((Unit*)this)->GetSpeed(MOVE_WALK);

*data << ((Unit*)this)->GetSpeed(MOVE_RUN);

+ *data << ((Unit*)this)->GetSpeed(MOVE_RUN_BACK);

+ *data << ((Unit*)this)->GetSpeed(MOVE_SWIM);

*data << ((Unit*)this)->GetSpeed(MOVE_SWIM_BACK);

- *data << ((Unit*)this)->GetSpeed(MOVE_SWIM);

- *data << ((Unit*)this)->GetSpeed(MOVE_RUN_BACK);

*data << ((Unit*)this)->GetSpeed(MOVE_FLIGHT);

*data << ((Unit*)this)->GetSpeed(MOVE_FLIGHT_BACK);

*data << ((Unit*)this)->GetSpeed(MOVE_TURN_RATE);

This will also weird bug where you have to set backpeddling speed in "MOVE_SWIM_BACK" instead of "MOVE_RUN_BACK" and vice versa

@@ -62,9 +62,9 @@ float baseMoveSpeed[MAX_MOVE_TYPE] =

{

2.5f, // MOVE_WALK

7.0f, // MOVE_RUN

- 2.5f, // MOVE_RUN_BACK

+ 4.5f, // MOVE_RUN_BACK

4.722222f, // MOVE_SWIM

- 4.5f, // MOVE_SWIM_BACK

+ 2.5f, // MOVE_SWIM_BACK

3.141594f, // MOVE_TURN_RATE

7.0f, // MOVE_FLIGHT

4.5f, // MOVE_FLIGHT_BACK

This is not noticable client side, I found it while coding related stuff.

There might be more code related to this in mangos, not sure you guys are gonna have to check for urself.

-Midna

What happaned to the mmaps branch on mangos-one?

Looking at my schedule, I'd say that mangos-one should see the feature branch with mmaps arrive on Wednesday evening

<3 Awesome work dude.

Ok, I might have found an easier way to find out the adresses, with a program called TrainerSpy.

It hooks the WinAPI WriteProcessMemory call, and you can get the modified adresses this way.

The problem however, some hacks seem to have some kind of protection against this, in the way that they spam useless(?) WriteProcessMemory calls.

So The program works, but its a bit shitty to find out which adresses are the ones your looking for.

Another problem is, the program cant hook the api on 64-bit systems. I used VMware to get around this.

Heres the program:

http://www.mediafire.com/?4z6gm3fycggqs7l

If your interested in this project, please help me find the right addresses and ill try to find the correct non-eddited value's and start filling the warden database.

This might also help you guys here with 3.3.5a just though i'd share this.

This little tool helped me create 3 checks for 2.4.3(More to come).

Ok, I got the TOM_RUS version working on Oregoncore(2.4.3), post is on thier forum.

However, I've only got one MEM_CHECK so far:

INSERT INTO `warden_data_result` (`id`, `check`, `data`, `str`, `address`, `length`, `result`, `comment`) VALUES
(803, 243, '', '', 4840352, 2, '558B', NULL);

This is for the Lua protection disabler posted earlier.

The provided PAGE_CHECKS/DRIVER_CHECKS seem to work fine afaik, no false positives yet.

Right now i'm interrested in how to get the adresses for the most populair hacks on 2.4.3 like wowemuhacker and similair hacks, I don't have enough experience to dissemble them myself so basicly im asking if somome is interested in doing this, already has the addresses, or could explain me where I should look, I got a bit of experience with dissambling.

-Midna

Of course the checks are different, the invalid packets might be a problem though unless someone knows how they are supposed to be for 2.4.3?

If you want the right checks, your gonna have to find them yourself, find out what address a cheat modifies, and add a check for that.