Mugen 1.0 亲地址

原文地址:https://tieba.baidu.com/p/4347428396?share=9105&fr=share&sfc=qqfriend


Mugen 1.0 下,相较winmugen来说确实有很多不同了。
不同属性值的距离上发生了微妙的变化,但最主要的是,存放 “主程序的文件夹地址指针” 的 内存位置 发生了变化。即:
winmugen 上为 :4B5B4C
Mugen 1.0 上为 :52B40C


---------------------------------------
与此同时,winmugen上 4B5B4C内存放的值,直接指向 Mugen文件夹的绝对路径。
而 Mugen 1.0 并不是,Mugen1.0 在 52B40C内存放的值,指向的是 Mugen1.0文件夹绝对路径的上方 距离200(16进制)的 位置。
我说的很抽象,看图吧

image.png



在 winmugen下:
主程序文件夹 的内存地址 距离 P1人物数据地址指针 的 内存距离 为 B754.
即:

4B5B4C处的值 + B754(十六进制) = P1人物数据地址指针の内存位置
--------------

Mugen 1.0 下:

主程序文件夹 的内存地址 距离 P1人物数据地址指针 的 内存距离 为 11034.
可能是 程序员觉得不好记,于是就改成了 11234 (记忆时,可记成 10000 + 1234)。
让 52B40C记录的指针 向上移动了 200(16进制)个内存单元。
也就是说:
52B40C处的值 + 11234(十六进制) = P1人物数据地址指针の内存位置


52B40C处的值 + 11238(十六进制) = P2人物数据地址指针の内存位置
-----------


请注意:
P2人物数据地址指针 - P1人物数据地址指针 = 9224(10进制)


还记得 之前我讲 winmugen内 直死的时候说道的 P1和P2的距离是多少吗?
对了,在winmugen下,P1和 P2相距 13832 个 单位。
ti呵呵eba.ba呵呵idu.c呵呵om/p/43呵呵22274250
该帖有论述。(去掉”呵呵“)


现在Mugen 1.0 内, 两个人物 相距 为 9224 个单位了。缩短了



--------------------------------------


得到P1人物数据地址 后,进入观察,于是我得到:


--------------------------------------------
---------------------------------------------------
------------------------------------------

人物数据篇:

“以 life为 0点 开始”

-440 --- 重定向点 (最最关键的点,P1人物数据指针 直接指向该处)
-436 --- Player ID
-432 --- 在Player列表中的序号
-428 --- teamside (P侧)
...
-412 --- (可能是)ishelper
-408 ~ -360 --- 人物显示名 (老版是 -320)【人物名最长30(hex) = 48个字符】

;---- 以下 const 相关数据
-356 --- const(data.life) 
-352 --- const(data.power)
-348 --- const(data.attack)

-336 --- const(Data.AirJuggle)
-332 --- const(Size.Attack.Dist(Size.Proj.Attack.Dist))
-328 --- const(Size.Proj.Attack.Dist)
-324 --- const(Data.Defence)
....
;----


-8 --- PlayerEnableSet

0 --- life 
4 --- lifemax
8 --- 血条显示上,life的当前值
12 --- 血条显示上,life前几帧残留值(延迟效果)

2708 --- Stateno
2712 --- Prevstateno

2716 --- Persistent 【假设 为 1 - 512 】
3256 --- Hitpausetime (与win上 hitpausetime到life的距离相同)【根据上面有: 541 】
3272 --- Alive
;(注意 它与hitpausetime之间的距离变了 增加了4个单位)【根据上面有:557】
; Alive 距离 “重定向点”的16进制距离为 E80,不再是winMugen上的 E24了。



很显然,如果是 读取 null来进行 超即死等操作时,null的个数 应该是 557 - 560。
(winmugen下是 553 - 556)


这个557 是 3272(alive) - 2716(persisent) + 1 = 557 这样计算得到的。

现在,我并没有把 persistent 真正作为 固定点 1 - 512 来进行罗列,而是以life为0进行罗列的。
所以难免会让 作者们感到生疏。
所以 这个帖子只是一个 半成品。


这个半成品,以后兴许会完善,也可能不会。

补充:

Y = 主程序地址(52B40C)


Y + 10EA8 : gametime
Y + 11430 : player数量开始
Y + 11434 : player数量结束
Y + 11658 : assertspecialintro
Y + 116E4 : roundno
Y + 116E8 : 胜利数1P
Y + 116EC : 胜利数2P
Y + 11710 : roundstate
Y + 11714 : 胜利方
Y + 11718 : 试合结束方式

X = 人物头地址

X + E54 : time
X + E58 : type 
X + E5C : movetype 
X + E64 : ctrl
X + E9C - F88 : var(0) - var(59)
X + F8C - 1028 : fvar(0) - fvar(39)
X + 1474 : helper,id
X + 1478 : parent,id
X + 147C : parent指针
X + 1480 : root指针
X + 1484 : playertype


Author:yui
Date:2016.02.10

暂无评论
根据相关规定,发布评论前必须绑定手机前往绑定
你,确定要这么做吗?
正在处理中...