Q3VM – Lightweight, embeddable Quake III Interpreter/Virtual Machine | Hacker News Reader

Q3VM – Lightweight, embeddable Quake III Interpreter/Virtual Machine

github.com

117 pointsjanosch900129 comments

Really smart.

It's worth mentioning that the Q3VM was the entry point to many of the exploits created for Q3, just something to bear in mind.

How did that work? You need to load your custom scripts somehow in the first place, Im guessing in a form of game mod. So you are already running custom code at this point.

Whenever you connect to a server, the client autodownloads any game mods used by the server. Random servers and their game mods aren't supposed to have arbitrary unsandboxed code execution on your system, but they could if they exploited a vulnerability in the code vm. The code vm is supposed to be safe for running arbitrary code in a sandbox.

It is forked from the well maintained ioquake3 project. But do you have further informations? I'd love to fix stuff if possible (and maybe back port that to ioquake3).

What could be usecase for using this VM? Any idea why to use it in non-game app?

Hi, author here. It is indeed a niche thing. But there are some use cases:

* Sandbox for code you don't fully trust (e.g. download the bytecode from a web server)

* Mods for small hobby game engines

* There are many virtual machines, but not many are so small, with strong typing and no garbage collector

* Learn about virtual machines in general, but directly have a C compiler available for the virtual machine

* Sandbox for embedded applications, e.g. plug-ins for IoT applications on microcontrollers (bounded CPU time, bounded memory area, restrict access to peripheral devices)

* There is also a historical value: learn about the Quake III engine

> … strong typing … C …

This is incorrect. Wikipedia specifies C’s typing discipline as “static, weak, manifest, nominal”, which isn’t great, but is at least in the right ballpark. “Strong” and “weak” are unhelpfully overloaded words.

http://blogs.perl.org/users/ovid/2010/08/what-to-know-before...

I don't understand either. If you have to write in C, and you have to compile, what's the advantage?

The main advantage for Quake 3 was that the server, client and UI code could be compiled into platform-independent bytecode modules. This was mostly a boon to mod creators, who had to build only one version of their mod that would work on all Windows, Mac and Linux systems alike.

I thought I heard this was also a boon for the scenario creators and level builders working alongside the graphics engineeers.

They get something a little less hairy and volatile to work with, and execution speed isn’t that critical because you’re only making hundreds or thousands of decisions per second.

Speculation: Assuming the VM has no bugs it is sandboxed. The code run can't access the file system or freely allocate memory. Thus code from less trusted sources can be executed. (Another comment indicates that the VM has a history of bugs, so it might not be advisable, but I have no experience with it)

You compile it once and it runs on all architectures (including ones that did not exist at the time).

These days, there isn't much advantage. You'd be much better off using a well supported third party vm implementation like coreclr for instance.

Source code of third party mods ?

You don't really get source code. You only get bytecode that's harder to reverse than a fully compiled binary if only for the lack of tooling.

Also, how was it used in Quake3?

All of the code for the UI, server-side game logic, and client-side game logic in Quake 3 was run in the VM. It allowed code to be stored with game data, and client-side mods to be safely downloaded directly from the game server.

The link in the sibling post has most everything you'd ever want to know about it.

It might be worth mentioning that there’s a long tradition of this pattern in game design. In quite a few cases, much of the game logic is separated from the graphics engine, in a simpler language with an interpreter.

In the case of world of Warcraft, the Lua interpreter allowed for a rich ecosystem of UI (and light behavioral) addons. In some cases very popular addons features were added into the core UI in later updates.

I find that arrangement pretty compelling. In the few cases where I’ve worked on or with a team with addon support I bring this up: use the community sourced features as a popular vote for what to incorporate (just be sure to reward the author somehow).

A lot of stuff.

http://fabiensanglard.net/quake3/qvm.php

It's not clear from the documentation, is this forked out of the Q3 codebase or based on the LCC book or just totally independently created?

The README says that this is forked from the Quake 3 codebase.

It is forked from the ioquake3 code base. I've added computed gotos to the interpreter to speed it up a bit.

id took the LCC compiler and targeted it toward their custom bytecode VM. I have no idea what this author has done with the code since then, though.

How good is this in terms of execution speed ? Compared to Lua for example (since that is mentioned in the README).

WoW, i had no idea Quake had a vm inside it.

Does it have VR support?

It does, as well as support for the other 24 letters. ;)

WebAssembly is a better choice today. This thing is interpreting C, so just embed wasm instead so people can use stuff like Rust too.

There are of course many VMs out there. Totally depends on the individual use case.

Reply on news.ycombinator.com