OrochiZEditor1.01 Build0124（支持繁体中文版1.0）

自由之民

这百八十兆设置数据解包之后加快不了多少，大头都在图形数据上。

a1256438

感謝啦~~~~~~~~~~

vbvan

原帖由 自由之民 于 2009-12-19 21:19 发表



还是希望能够编辑外部LINKDATA型数据文件。
比如说，打开外部LINKDATA-65.bak，编辑，并保存在原文件，而不进行导入操作。
比较习惯在内存里调试：
http://game.ali213.net/thread-3009724-1-1.html

呜，还有一个事情，视图中 ...

无双的数据文件通常都没有文件头，仅能通过大小或者一些有限的特征进行判断。
当存放在LINKDATA中时，修改器可以通过序号判断。而单独文件则不容易管理。

浅井市

原帖由 自由之民 于 2009-12-19 21:22 发表
这百八十兆设置数据解包之后加快不了多少，大头都在图形数据上。

解包总是会耗点内存的
就像压缩的蓝色NTFS

自由之民

原帖由 vbvan 于 2009-12-19 21:33 发表


无双的数据文件通常都没有文件头，仅能通过大小或者一些有限的特征进行判断。
当存放在LINKDATA中时，修改器可以通过序号判断。而单独文件则不容易管理。 ...

那么，比如说，进入NPC修改这个专项，再从右键菜单命令导入外部数据，进行数据匹配、编辑，再导出为外部数据呢？
现在的主要问题是，菜单的导入LINKDATA命令会强制扩容，如果不希望扩容就没办法了。
或者，能不能在保存LINKDATA修改的时候，才进行扩容判断呢？同时，允许将当前视图导出，而不经过LINKDATA文件的操作？

自由之民

原帖由 浅井市 于 2009-12-19 21:34 发表

解包总是会耗点内存的
就像压缩的蓝色NTFS

唉……说到心坎里去了……俺现在就是内存富余，磁盘不足啊~~~~~~~
VCVCVCVCVCVC

千人斩竞争

單獨文件的文件名不就是序號麼..
算了反正自己用自己的工具改也不是什麼難事.. 不支持也無所謂.. 反正所謂高人吃幾百年老本還是高人

vbvan

原帖由 千人斩竞争 于 2009-12-19 21:40 发表
單獨文件的文件名不就是序號麼..
算了反正自己用自己的工具改也不是什麼難事.. 不支持也無所謂.. 反正所謂高人吃幾百年老本還是高人

文件名中的序号如何存放是没有规律的，你可以用123.dat，也可以用FOO_123.orz

PS：如果你喜欢“高人”这种虚名，那送给你好了

自由之民

原帖由 vbvan 于 2009-12-19 21:52 发表

文件名中的序号如何存放是没有规律的，你可以用123.dat，也可以用FOO_123.orz

那……人工判断行不？
假定使用者知道自己要编辑的数据类型是什么，导入到内存或者文件的时候和原数据比一下尺寸就行？
功能要是能够像#150说的那样就好了……

千人斩竞争

我的序號指的是5d9a70處call的第二傳入值.. 另findfirstfile可以用<num>.*這種通配吧..
沒啥, 我們都不是靠這吃飯的. 對於無雙或許有空會試試弄個大眾能用的data編輯器吧. 至於我那小東西, tech show only, 您看不上眼也是正常..

vbvan

原帖由 千人斩竞争 于 2009-12-19 22:02 发表
我的序號指的是5d9a70處call的第二傳入值.. 另findfirstfile可以用.*這種通配吧..
沒啥, 我們都不是靠這吃飯的. 對於無雙或許有空會試試弄個大眾能用的data編輯器吧. 至於我那小東西, tech show only, 您看不上眼也 ...

珍惜生命，远离怨念

vbvan

原帖由 自由之民 于 2009-12-19 21:57 发表



那……人工判断行不？
假定使用者知道自己要编辑的数据类型是什么，导入到内存或者文件的时候和原数据比一下尺寸就行？
功能要是能够像#150说的那样就好了…… ...

加个选项允许导入时直接到修改器内存，导出时直接从修改器内存，不经过LINKDATA？

浅井市

原帖由 千人斩竞争 于 2009-12-19 22:02 发表
我的序號指的是5d9a70處call的第二傳入值.. 另findfirstfile可以用.*這種通配吧..
沒啥, 我們都不是靠這吃飯的. 對於無雙或許有空會試試弄個大眾能用的data編輯器吧. 至於我那小東西, tech show only, 您看不上眼也 ...

嘛，你的修改器对于我们做程序的，是很好用，用得上
但对于绝大部分小白，真的只能望而却步，而偏偏绝大部分玩游戏的都是这种人……

浅井市

原帖由 vbvan 于 2009-12-19 22:12 发表


加个选项允许导入时直接到修改器内存，导出时直接从修改器内存，不经过LINKDATA？

他的意思应该是索引重定向

自由之民

原帖由 vbvan 于 2009-12-19 22:12 发表

加个选项允许导入时直接到修改器内存，导出时直接从修改器内存，不经过LINKDATA？

是的，这样就好。

原帖由 浅井市 于 2009-12-19 22:13 发表

他的意思应该是索引重定向

不是。真不好意思。
就像刚才提过的，还用65.bak举例来说明：

之前RPGViewer解包的LINKDATA1-66.out，它和用这个修改器的导出LINKDATA功能备份出的65.bak一样。
然后进行过一些修改。

现在我想要用这个修改器继续编辑，于是，需要在LINKDATA编辑的NPC这一专项中，能够打开那个文件；
编辑之后，还希望保存成外部的数据。

整个过程中，仅仅是和LINKDATA的数据进行可能的对比，而不进行任何LINKDATA的改写。
整个编辑过程，LINKDATA只是蓝本，所有操作都在内存中进行，ORZEditor相当于是表格编辑器。

archer1986

这个不顶不是人啊~~~

浅井市

原帖由 自由之民 于 2009-12-19 22:31 发表



是的，这样就好。




不是。真不好意思。
就像刚才提过的，还用65.bak举例来说明：

之前RPGViewer解包的LINKDATA1-66.out，它和用这个修改器的导出LINKDATA功能备份出的65.bak一样。
然后进行过一些修改。

现在 ...

那你需要的只是一个框架
或者说模板或范本
这样你照这格式填就可以了
自己做个Excel试试？
WinHex也有模板的功能

另外，被UPX过的程序和没被UPX过的程序
消耗的CPU和内存是无法比的……
更不用说LZMA算法了……
所以被压缩一定是很悲剧的……（除了节约体积）

萌のたま

VAN大更新了，凸一下

rock106

van大的修改器絶對要支持!

自由之民

原帖由 浅井市 于 2009-12-19 23:28 发表

那你需要的只是一个框架
或者说模板或范本
这样你照这格式填就可以了
自己做个Excel试试？
WinHex也有模板的功能

另外，被UPX过的程序和没被UPX过的程序
消耗的CPU和内存是无法比的……
更不用说LZMA算法了……
所以被 ...

唉……作为一个用户，我只希望有一个方便的程序来帮助我编辑数据。
事实证明，Excel并不能满足我的需要。