Ironically the second problem still exists here taking Lua as an example I was extremely disappointed that is has 'shelling-out' functions included in the core/default library - making it entirely useless as a sandboxed environment (without a large amount of effort, luck and maintenance), it's hard to portray how angry I am about this, but I really hope they were drinking some strong cocktails when they included these anti-features. The first problem here is that most scripting languages are interpreted, which may not be acceptable for real-time systems (although, see LuaJIT) such as games. You would either require a language that could invoke native code (to interface with Lua) or you would have to write your own scripting language in your language of choice. Modders would use a language such as Lua to create mods. As a worst-case scenario you could write a mod that sets up a seedbox if this was installed at an ISP it could do some serious harm to their reputation. People don't really like foreign code running on their system with no sandbox in place. Taking C# for example a modder could simply use reflection to access private members, C can also do this (although more effort is required). The first problem with this approach is hiding internal state. You could even do some meta-modding, where a mod could host other mods (e.g.
This will obviously limit you to languages which can do late binding - and there are a good many that can do this (even C can do late binding with some clever LoadLibrary trickery). Most likely you will require that your modders use the same language as you do, and load up mods via reflection (or similar, depending on your language of choice). It depends on how you want to design your mod system.
0 kommentar(er)
