How is modding done in Counter-Strike?

In Spring RTS, how do a map's scripts work with different mods if for example they act on certain unit types that might not be available in a mod?

http://springrts.com/wiki/FAQ:Content

How is it all synchronized between clients?

(Disclaimer: I have no experience with CS or Spring mods)

What do you mean by "synchronized"? If you're talking about distribution, the server either needs to require clients to have a given mod, or it needs to upload the given mods to the client when they join.

To operate on modded units explicitly, you need some kind of lookup system, typically string lookup, e.g. doStuffIfExists(getUnitByName("MISC_EXT_TANK_1"));

More realistically, your engine would probably have some kind of index lookup so the mod only needs to do the string lookup once.

All the client's files must be synchronized. Can you imagine what would happen if a client modified one of the scripts? He might gain an advantage or break the game for himself. All the files that are loaded would have to be tracked and a hash generated to compare to the server. If the file doesn't exist, it can be downloaded from the server. If the hash doesn't match, the client can choose to overwrite his versions in favour of the server's.

And what if the game's rules are moddable by script? And there are different map types, eg. CTF, biz, war. If the game rules are changed too much they might not be compatible with certain map types.

And how best to handle the scripting/mod detection aspect.

How do you distinguish a mod? Is it an archive file in the /mods/ folder with an autoexec script? Would you then have a mod selector on startup load up that script which sets everything up, calling other scripts? The mod loader/selector functionality would have to be built into the engine then and require a restart to reload all the assets. Or this can be done with resource tracking, not requiring a restart to change mods. But that means mods can't share models or images or sounds or utility scripts. Maybe they can reference other archives or files? If there's a model or a script that's named the same in the same folder in two adjacent archives or in the same folder, there would be a conflict, and the server and clients would have to make sure the archive (or lack of it) they come from matches. Also it can be difficult for newer versions of content appearing, if you had a newer version of a map or utility script but the server had an older version, you'd have to revert to the server's version to join. Also one version of the utility script might be compatible with a certain map but updating or reverting to a server's version of the utility script might make it incompatible with another of your maps, which you might only discover when you try to host a game.

The main use for scripts in maps would be scenarios though. And there's not much you can do if the tutorial is meant to demonstrate a unit or building or rule that doesn't exist in the mod or is different.

A game that properly supports mods is going to have some kind of "entry point" for the mod in question -- usually something like a definition file of some sort. It could just be a text file in the mods folder (e.g. modname_mod.txt) that lists components and dependencies. Yes, your engine has to be aware of it, and has to know how to load them. Modding in games that don't actively support it typically involves editing data files or DLL injection.

This can all be done lazily. When the user clicks "select mods", for example, the mod loader can scan the mods directory for entry points. When the user selects an entry point, the mod can then load the requisite dlls ('plugins'), mods, or resources. If the user adds a mod, quits to the main menu, and then clicks "select mods" again, the engine could theoretically reload the mods again. Realistically though, most engines I've seen load mods at startup (or have the selector in a pre-game splash screen a la mount and blade or some paradox games), and it's nice to be able to do that for things like "mod manager" mods. It's worth noting that you can however do all of this dynamically, and it shouldn't be performance-impacting if you do so at the right place and time.

As for sharing resources, that should be fine. Just require a certain model in the models folder, or a certain sound in the sounds folder. Mods should ask the game engine to load resources the game engine can load. If multiple mods need the resource, you can just use a reference counting solution or something to track cleanup.

Version incompatibilities are a thing, but that's just like game version incompatibilities. Either the server needs to require a specific version of the mod, or it needs to automatically give that version to clients. As for your synchronization questions, that all depends on the operation. If the client modifies the UI to be purple or something, who cares? Anything the client can do in an RTS that affects other players should be sent to other players. If the client says "I have a tank here with 10,000,000 damage", the server can say "I know what your tank is, and I know you've given it two upgrades and it has 30 damage". That kind of validation isn't a modding issue, it's a fundamental anti-cheat issue that the core game needs anyway.

This can all be done lazily. When the user clicks "select mods", for example, the mod loader can scan the mods directory for entry points. When the user selects an entry point, the mod can then load the requisite dlls ('plugins'), mods, or resources. If the user adds a mod, quits to the main menu, and then clicks "select mods" again, the engine could theoretically reload the mods again. Realistically though, most engines I've seen load mods at startup (or have the selector in a pre-game splash screen a la mount and blade or some paradox games), and it's nice to be able to do that for things like "mod manager" mods. It's worth noting that you can however do all of this dynamically, and it shouldn't be performance-impacting if you do so at the right place and time.

I like how Counter-Strike does it. It still remains Counter-Strike with the same menu background and options, but a map can be zombie infection mod or gungame, without requiring a restart. It doesn't even have any official label for mods in the server list, people just write it in the server name.

Version incompatibilities are a thing, but that's just like game version incompatibilities. Either the server needs to require a specific version of the mod, or it needs to automatically give that version to clients. As for your synchronization questions, that all depends on the operation. If the client modifies the UI to be purple or something, who cares? Anything the client can do in an RTS that affects other players should be sent to other players. If the client says "I have a tank here with 10,000,000 damage", the server can say "I know what your tank is, and I know you've given it two upgrades and it has 30 damage". That kind of validation isn't a modding issue, it's a fundamental anti-cheat issue that the core game needs anyway.

I couldn't connect to a CS mod server once because I had to delete some model file or something. That's how I want it to work.

If GUI's are defined in scripts, they're inseparable from the important code. GUI scripts might be made to define new dialogs and things. This is important in my case. Not sure how far I want to go with scripting. Might be too slow to write game mechanics in it.