Difference between revisions of "Frequently Asked Questions (Metamod:Source)"

From AlliedModders Wiki
Jump to: navigation, search
(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 big problem.
+
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: How do I tell my glibc version?=====
 
 
 
There are a few common ways. The first is to run this command at a shell or command prompt: /lib/libc.so.6 This will print something like: "GNU C Library 20040808 release version 2.3.4"
 
 
 
Another method is to run "gcc -v" and go by your GCC version. 3.3 usually means glibc 2.3.3, 3.4 usually means glibc 2.3.4.
 
 
 
Another method is to use "locate libstc++.so". If you have libstdc++.so.5, you probably have glibc 2.3.3. If you have .so.6, you probably have glibc 2.3.4.
 
 
 
If all else fails, don't worry - glibc is usually backwards compatible. You can probably get away with using the SourceMM with the oldest glibc version, or simply using trial and error.
 
  
 
=====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 many optimization techniques, such as detecting when new functions are hooked in order to efficiently decide which calls need to be intercepted.
 
  
 
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: Both this site and your name are stolen from Will Day?=====
 
 
We decided to keep the layout of the site very similar so people would feel at home. However, the HTML, style sheets, etc, are completely original. The site is powered by a very tiny backend written in PHP+Smarty, and if there's a big enough request, we'll post the code (it is based entirely on templates and objects).
 
 
We did, however, use the Metamod name. We believe this was the best action to take because "Metamod" has become a familiar name throughout the gaming community. We believe the name "metamod" should be a word implying "a tool that sits in between a game engine and mod DLL, allowing the interception of the calls that pass in between". As such, the tool we developed is a "Metamod" for Source, therefore we took the name Metamod:Source. Will Day is not associated with this project, nor did he imply any such thing. If we were to develop a similar tool for, say, Diablo 2, we would call it "Metamod: Diablo 2". We greatly respect the contributions Will Day made to the Half-Life community, as his tool revolutionized modding. However, there is no association between us or the code bases (which was also necessary to avoid the restrictions the GPL has).
 
  
 
=====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

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:

  1. Engine loads the mod binary into memory.
  2. Engine asks mod binary for some classes.
  3. Engine asks mod for its name.
  4. 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 :)