Difference between revisions of "Frequently Asked Questions (Metamod:Source)"
(→Q: What's the difference between SourceMM and Metamod:Source?) |
(cleaned up the faq for this... year) |
||
Line 16: | Line 16: | ||
=====Q: Will Server Plugins run on Metamod: Source?===== | =====Q: Will Server Plugins run on Metamod: Source?===== | ||
No. You can still run them as server plugins though, and they will still work. Metamod: Source plugins are separate. | No. You can still run them as server plugins though, and they will still work. Metamod: Source plugins are separate. | ||
+ | |||
+ | =====Q: Why is Metamod:Source not a Server Plugin?===== | ||
+ | Metamod:Source is not a server plugin so it can have complete control over its environment. This lets us (and by extension, developers) isolate exactly what they need to do, in the most minimalistic manner we choose. It also lets you intercept the GameDLL, which you cannot do as a server plugin. | ||
+ | |||
+ | Once Valve fixes some crucial flaws of Server Plugins (such as better error messaging and adding unloadability) we will consider porting MM:S to that platform. | ||
=====Q: Why does HL2 say 'GameDLL loaded for Metamod:Source'?===== | =====Q: Why does HL2 say 'GameDLL loaded for Metamod:Source'?===== | ||
Line 27: | Line 32: | ||
As you can see, steps 2-4 are somewhat out of order. Therefore, when Metamod:Source is asked for the mod's name, it doesn't actually know it yet, as it is unable to have loaded the mod without engine information. So it passes the name "Metamod: Source" instead, and then changes the value in memory once the mod is actually loaded. | As you can see, steps 2-4 are somewhat out of order. Therefore, when Metamod:Source is asked for the mod's name, it doesn't actually know it yet, as it is unable to have loaded the mod without engine information. So it passes the name "Metamod: Source" instead, and then changes the value in memory once the mod is actually loaded. | ||
− | Unfortunately, srcds/HL2 might not catch this in time, or might not update its field, and the game name will appear as "Metamod: Source" in the server-side GUI. As the mod name doesn't change anywhere else, it is not really a | + | Unfortunately, srcds/HL2 might not catch this in time, or might not update its field, and the game name will appear as "Metamod: Source" in the server-side GUI. As the mod name doesn't change anywhere else, it is not really a problem. |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
=====Q: Is there a tutorial/example of how to write a SourceMM plugin?===== | =====Q: Is there a tutorial/example of how to write a SourceMM plugin?===== | ||
Line 52: | Line 47: | ||
=====Q: How does it work? Like Metamod-P?===== | =====Q: How does it work? Like Metamod-P?===== | ||
− | + | No. Metamod-P is a highly optimized version of Metamod for Half-Life 1 created by Jussi Kivilinna. By using dynamic link patching, it is able to resolve entity export differences between the Engine and GameDLL - this means it does not require updates for mods like the original Metamod. It also has other related optimization techniques. | |
− | No. Metamod-P is a highly optimized version of Metamod for Half-Life 1 created by Jussi Kivilinna. By using dynamic link patching, it is able to resolve entity export differences between the Engine and GameDLL - this means it does not require updates for mods like the original Metamod. It also has | ||
Metamod: Source is different because it uses virtual function hooking - which means individual functions in classes can be dynamically altered. Half-Life 1's engine functions were passed as a list of pointers in a struct, which requires an entirely different method of interception (that is, a wrapper set of functions that act as a router to the plugins). You can think of the design in this way: | Metamod: Source is different because it uses virtual function hooking - which means individual functions in classes can be dynamically altered. Half-Life 1's engine functions were passed as a list of pointers in a struct, which requires an entirely different method of interception (that is, a wrapper set of functions that act as a router to the plugins). You can think of the design in this way: | ||
Line 59: | Line 53: | ||
Metamod: The Engine gives the GameDLL its set of functions, and the GameDLL gives the Engine its set of functions. Metamod sits in between and actually exchanges false versions, which have new functions that allow you to decide whether to override the original calls. | Metamod: The Engine gives the GameDLL its set of functions, and the GameDLL gives the Engine its set of functions. Metamod sits in between and actually exchanges false versions, which have new functions that allow you to decide whether to override the original calls. | ||
Metamod: Source: You can take any virtual function of a known class and declare a hook on it. The hook is applied by patching memory directly, at runtime. The only interception that occurs between the GameDLL and Engine is the factories which provide class retrieval. | Metamod: Source: You can take any virtual function of a known class and declare a hook on it. The hook is applied by patching memory directly, at runtime. The only interception that occurs between the GameDLL and Engine is the factories which provide class retrieval. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
=====Q: What's the difference between SourceMM and Metamod:Source?===== | =====Q: What's the difference between SourceMM and Metamod:Source?===== |
Revision as of 11:13, 7 September 2006
Contents
- 1 Frequently Asked Questions
- 1.1 Q: Does Metamod:Source support (some) mod?
- 1.2 Q: How do I install Metamod:Source?
- 1.3 Q: Does Metamod: Source Create Lag?
- 1.4 Q: Will Server Plugins run on Metamod: Source?
- 1.5 Q: Why is Metamod:Source not a Server Plugin?
- 1.6 Q: Why does HL2 say 'GameDLL loaded for Metamod:Source'?
- 1.7 Q: Is there a tutorial/example of how to write a SourceMM plugin?
- 1.8 Q: If I create a SourceMM plugin, does it have to be open source?
- 1.9 Q: Can you port this to another game engine?
- 1.10 Q: How does it work? Like Metamod-P?
- 1.11 Q: What's the difference between SourceMM and Metamod:Source?
- 1.12 Q: Where can I find more about SourceHook?
Frequently Asked Questions
Q: Does Metamod:Source support (some) mod?
Metamod:Source only requests the core public interfaces of Source, so it will run on all mods that work with the version of Half-Life 2 it was built for.
Q: How do I install Metamod:Source?
Please look in the Installation section of the documentation.
Q: Does Metamod: Source Create Lag?
No. The library Metamod: Source is based off is called SourceHook. Unlike the original Metamod for Half-Life 1, Metamod: Source only hooks functions when a hook is declared. It does not intercept every call by default, and does not require a complex routing table for each individual call regardless of whether that call is being used.
In non-technical terms? Metamod: Source is only there when you need it to be. The hooking method, although complicated, is very efficient and takes advantage of some of the odder features of C++.
And unlike the original Metamod, the binary is one tenth the size - the Half-Life 2 engine does not require a massive repository of linked entities to be exported in the same way Half-Life 1 did.
Q: Will Server Plugins run on Metamod: Source?
No. You can still run them as server plugins though, and they will still work. Metamod: Source plugins are separate.
Q: Why is Metamod:Source not a Server Plugin?
Metamod:Source is not a server plugin so it can have complete control over its environment. This lets us (and by extension, developers) isolate exactly what they need to do, in the most minimalistic manner we choose. It also lets you intercept the GameDLL, which you cannot do as a server plugin.
Once Valve fixes some crucial flaws of Server Plugins (such as better error messaging and adding unloadability) we will consider porting MM:S to that platform.
Q: Why does HL2 say 'GameDLL loaded for Metamod:Source'?
The Half-Life 2 engine has weird quirks. One of these is that it requests information before actually telling the GameDLL (mod) that it is loaded. It goes something like this:
- Engine loads the mod binary into memory.
- Engine asks mod binary for some classes.
- Engine asks mod for its name.
- Engine requests that the mod be loaded by giving it engine information.
As you can see, steps 2-4 are somewhat out of order. Therefore, when Metamod:Source is asked for the mod's name, it doesn't actually know it yet, as it is unable to have loaded the mod without engine information. So it passes the name "Metamod: Source" instead, and then changes the value in memory once the mod is actually loaded.
Unfortunately, srcds/HL2 might not catch this in time, or might not update its field, and the game name will appear as "Metamod: Source" in the server-side GUI. As the mod name doesn't change anywhere else, it is not really a problem.
Q: Is there a tutorial/example of how to write a SourceMM plugin?
Yes, look in the source code for "stub_mm" and "sample_mm", which contain examples of how to use the SourceMM API. You should be familiar with C++ and the Half-Life 2 SDK in order to proceed.
Q: If I create a SourceMM plugin, does it have to be open source?
No. Unlike the original Metamod, we decided to use the libpng/zLib license instead of the GPL. This is because Valve does not impose the same restrictions on Server Plugins. We'd like to keep the playing field level, as well as provide everyone with the same freedom and opportunities.
Q: Can you port this to another game engine?
Every game engine is different. Currently Metamods have been developed for three major game engines: The original Metamod for Half-Life 1 (by Will Day), Quake3 MultiMod (by CyberMind), and SourceMM (Metamod:Source, what you're reading about now). Each one needs to be carefully designed and built upon a specific set of rules, so a direct port is usually not possible. However, SourceMM is built upon a library called SourceHook. SourceHook provides a fast, efficient, and simple way to create virtual hooks. Any game that uses a modern virtual interface design for engine calls can take advantage of SourceHook.
Q: How does it work? Like Metamod-P?
No. Metamod-P is a highly optimized version of Metamod for Half-Life 1 created by Jussi Kivilinna. By using dynamic link patching, it is able to resolve entity export differences between the Engine and GameDLL - this means it does not require updates for mods like the original Metamod. It also has other related optimization techniques.
Metamod: Source is different because it uses virtual function hooking - which means individual functions in classes can be dynamically altered. Half-Life 1's engine functions were passed as a list of pointers in a struct, which requires an entirely different method of interception (that is, a wrapper set of functions that act as a router to the plugins). You can think of the design in this way:
Metamod: The Engine gives the GameDLL its set of functions, and the GameDLL gives the Engine its set of functions. Metamod sits in between and actually exchanges false versions, which have new functions that allow you to decide whether to override the original calls. Metamod: Source: You can take any virtual function of a known class and declare a hook on it. The hook is applied by patching memory directly, at runtime. The only interception that occurs between the GameDLL and Engine is the factories which provide class retrieval.
Q: What's the difference between SourceMM and Metamod:Source?
Metamod:Source refers to the overall application package we distribute. SourceMM refers to the specific code and the implementation therein. You'll hear us use these almost interchangeably, however, SourceMM is the official project name.
Q: Where can I find more about SourceHook?
PM has plans to release SourceHook as a separate library that can be embedded in other applications. He'll update this FAQ entry when that time comes :)