SourceMOD和Metamod:Source的讨论

金闪闪

说到SourceMOD，也要看Metamod:Source了。
后则 http://www.sourcemm.net/

两者有联系但也有区别。

大家延续Metamod的理解，应该是SourceMOD的。只是Metamod在Source升级后一直没新版本发布，才被SourceMOD的光环替代。

现在两者都有了。大家可以参考有关介绍。:D

monkie

Post by 金闪闪
说到SourceMOD，也要看Metamod:Source了。
后则 http://www.sourcemm.net/

两者有联系但也有区别。

大家延续Metamod的理解，应该是SourceMOD的。只是Metamod在Source升级后一直没新版本发布，才被SourceMOD的光环替代。

现在两者都有了。大家可以参考有关介绍。:D

提醒大家一点，
Metamod: Source 对应 支持HL1引擎的 Metamod（Metamod-P）；
SourceMod 对应 支持HL1引擎的 AMX Mod X（AMX）。

目前Mani Admin Plugin在Source引擎服务器中也起着AMX Mod X式的作用，所以才有SourceMOD的fans期待未来SourceMOD会比Mani Admin Plugin做得更好。以当前Mani最新版本1.2 Beta R来看，执行效率仍有不尽如人意之处，SourceMOD似乎正在这方面赶超Mani。

还有，闪闪，貌似现在Source引擎上Metamod: Source和SourceMOD也都是Bailopan主持的Allied Mods在做，通盘一家了，SourceMOD应该是可以有所期待的。

jop

Mani 只是一个 Metamod: Source 的插件多功能集，且非开放型设计，用户没有可2次开发型
与 SourceMod （== hl2的 amxx版）也是Metamod: Source 的插件，但是针对2次开发使用的，无法比较。

就暂时使用 SourceMod 来看，语言定义/规则比较严谨，它的 SourcePawn 初次使用比 amxx 难一点，但它的 extension 模块开发比 amxx 的 module 简单。加上整体功能丰富，用户可简易使用/可开发的，肯定会被接受，只是现在功能有待完善。就现在 CSS 受欢迎的程度而言，无法预知未来。

monkie

Post by jop
Mani 只是一个 Metamod: Source 的插件多功能集，且非开放型设计，用户没有可2次开发型
与 SourceMod （== hl2的 amxx版）也是Metamod: Source 的插件，但是针对2次开发使用的，无法比较。

就暂时使用 SourceMod 来看，语言定义/规则比较严谨，它的 SourcePawn 初次使用比 amxx 难一点，但它的 extension 模块开发比 amxx 的 module 简单。加上整体功能丰富，用户可简易使用/可开发的，肯定会被接受，只是现在功能有待完善。就现在 CSS 受欢迎的程度而言，无法预知未来。

感谢兄台补充;)

就是否为开放型设计而言，以Mani为一家封闭之作，SourceMOD遵从GPL来看，无疑后者占优；从能否作二次开发来看，也是后者更胜一筹。Bail是个强人，做Source引擎服务器的管理员们大可期待SourceMOD的到来……

金闪闪

Metamod:Source的主文件就是一个server.dll文件。:D

从某种意义上说，类似以前的liblist.gam中替代mp.dll文件。
这种替代后，在一定程度上会导致系统的不稳定。

SourceMOD是AMXX的延续，至少他们的开发者是同一个人。

由于Source Engine本身具备了METAMOD的管理功能，大家还是把重点放在SourceMOD上。

我看beta版本中的script范例，基本和SmallC一样，理解上大家没有难处。:)

jop

Post by 金闪闪
Metamod:Source的主文件就是一个server.dll文件。:D

从某种意义上说，类似以前的liblist.gam中替代mp.dll文件。
这种替代后，在一定程度上会导致系统的不稳定。

SourceMOD是AMXX的延续，至少他们的开发者是同一个人。

由于Source Engine本身具备了METAMOD的管理功能，大家还是把重点放在SourceMOD上。

我看beta版本中的script范例，基本和SmallC一样，理解上大家没有难处。:)

言下之意，服务器不需要加载 Metamod:Source?

如果是：需要更正一些说明
1：Metamod:Source 的主文件虽然是一个server.dll，但并不是代替原有的server.dll
只是因为hl2最先加载server.dll文件名的dll，不像hl1可以指定加载文件的名字，所以需要使用这个名字。另外因为 hook 的需要两个文件会被先后依次加载 (hl2 engine>加载Metamod:Source) 然后(Metamod:Source 加载原有server.dll)。
2： 大多CSS服都使用 Metamod:Source 没有不稳定之说，看看 mani 插件现在80% CSS服都使用就是证明（小量bug所有软件都不能避免）
3:SourceMod 是 Metamod:Source 的插件，不能不加载 Metamod:Source

金闪闪

Post by jop
言下之意，服务器不需要加载 Metamod:Source?

如果是：需要更正一些说明
1：Metamod:Source 的主文件虽然是一个server.dll，但并不是代替原有的server.dll
只是因为hl2最先加载server.dll文件名的dll，不像hl1可以指定加载文件的名字，所以需要使用这个名字。另外因为 hook 的需要两个文件会被先后依次加载 (hl2 engine>加载Metamod:Source) 然后(Metamod:Source 加载原有server.dll)。
2： 大多CSS服都使用 Metamod:Source 没有不稳定之说，看看 mani 插件现...

我的意思是。SourceEngine本身就有自身的插件管理。
看看Mani就知道了。没有Metamod:Source，他照样可以用。

甚至一些第三方的BOT，例如rcbot，也不需要Metamod:Source。

如果用以前HL1的理解，这些都需要在Metamod的基础上才能实现。

这个server.dll文件肯定是替换服务器的server.dll文件的。在一个目录可能同时存在2个server.dll文件么？

或则你认为“hl2 engine>加载Metamod:Source>游戏原有server.dll”，会比原始的“hl2 engine>游戏原有server.dll”更有效？

现在的SDK要求SourceEngine的插件，是addons中通过vdf设置来加载。
如果替换了Metamod:Source的server.dll文件，来改变加载的方式，反而很多第三方的插件会无效的。

:D

monkie

目前阶段的SourceMOD自称还是加载于Metamod: Source之上的。

官方引擎直接加载第三方插件也无不可，可能Bail他们的意思是，日久年深，东西越来越多的时候，有个管理集来作用于引擎和大量插件之间会比较好。因此，SourceMOD也就是起AMX Mod X式的作用。

当然，如果最终能达到这个目的，Source引擎服务器插件世界也像HL1时代那样被他们一统江湖了？！……

jop

Post by 金闪闪

如果用以前HL1的理解，这些都需要在Metamod的基础上才能实现。

这个server.dll文件肯定是替换服务器的server.dll文件的。在一个目录可能同时存在2个server.dll文件么？

或则你认为“hl2 engine>加载Metamod:Source>游戏原有server.dll”，会比原始的“hl2 engine>游戏原有server.dl...

虽然文件名相同，但并不安装在同一目录下，请看清楚 Metamod:Source 的安装说明。更没有代替原有 serve.dll 的可能。
再次提醒：SourceMod == (hl2版的amxx)，不能没有Metamod:Source 也就是俗称的SourceMM

：：没有感觉两者有可以论的地方，不会继续参与讨论，只是希望更正信息。

金闪闪

Post by jop
虽然文件名相同，但并不安装在同一目录下，请看清楚 Metamod:Source 的安装说明。更没有代替原有 serve.dll 的可能。
再次提醒：SourceMod == (hl2版的amxx)，不能没有Metamod:Source 也就是俗称的SourceMM

：：没有感觉两者有可以论的地方，不会继续参与讨论，只是希望更正信息。

jop认为Metamod:Source是基础，而SourceMOD是其上的插件。两者不能等同。
但我更倾向于认为，两者都是插件，都必须符合SDK标准。

从Valve的角度出发，他不会让人任意替换server.dll文件的。
就像不允许替换steam.dll和engine.dll文件一样，这其中涉及到VAC2的检测问题。

Metamod:Source还是SourceMod都要符合SourceSDK的开发标准。诚如monkie说的，他们想管理的更方便。当这些危机到Valve自身的SourceSDK定义的插件管理时，我想其中肯定会打架的。

我们知道HL1时代，Metamod就曾和HL1 Engine发生过不兼容而错误的问题。

Mani从某种角度上说，他遵循SourceSDK的开发标准，严格利用vdf来加载插件。
SourceMOD是开源的，因此每个人都可以自行按照SourceSDK标准来重新编译bin而非必要于Metamod:Source。
:D