Hi and Happy New Year
Over the holidays I wrote a Quake importer into SketchUp. Point it at a map file and and it decodes all geometry and entities - it uses bit-struct to map the binary files into Ruby.
The repo is here if you want to have a play:
https://github.com/Elektraglide/ruby-quake
I’ve been trying out the models with the new GPU raytracer in LightUp and it looks pretty cool!
Nice Job! That’s really cool
I’ll have a look later on.
This looks great, thanks. How about one for HL2 levels? 
Thanks for sharing. However your code has some issues relating to a shared Ruby environment.
ALL code must be wrapped in an author/company namespace module.
Each extension from an author/company should probably be within it’s own extension submodule so as not to clash with other extensions in the same namespace. (ie, by the same author.)
This means also that only Ruby core classes should be defined in the top level ObjectSpace.
Extension specific methods should never be defined in the top level ObjectSpace as they will become global. Ie, this top level is a special instance of class Object called “main” (from the interpreter’s main function loop.)
Since everything in Ruby is an object, therefore is an Object or a subclass of Object, and any method or constant defined at the top level will add it to every other author’s modules and classes.
Ruby uses 2 space indentation. The tabs have been converted to 8 spaces in the Git repository.
What we usually do is set our code editors to automatically replace TAB characters with 2 spaces so that the indents are correct when displayed in forum or GitHub.
It is a BIG “NO-NO” to ever modify Ruby classes or SketchUp API classes. This effects everyone else’s extensions. If it were allowed, we’d have chaos.
Instead, use a Ruby Refinement that only your extension uses. This will then not affect anyone else’s code.
The SketchUp API has an abstract Importer interface class. It would be best to use this.
And the whole thing should be properly packaged as a SketchupExtension.
In the GitHub repository, all the code for the project should better be placed in a src subdirectory and the project files like the README etc. go in the repo’s root folder.
The src directory plays the part of SketchUp’s “Plugins” directory. When packaging up rbz zip archive, the extension’s registrar script and the extension subfolder in the src directory are zipped up together into the rbz archive. (This way the project files in the root or the repository are not installed into SketchUp’s “Plugins” folder.)
Thanks Dan. Just to be clear, this is not an Extension or a product in any sense. Its just some code I wrote over the holidays for fun and I thought others may find it interesting.
(I’ve added some scope wrapping now)
Would you accept PRs that converts it into an extension?
Btw, any place to get hold of Quake files without having Quake?
I think Quake is open source now, although maybe that is just the engine
With pleasure! Reviewing it in the light of Dan’s comments, I realize it has some classes to ‘run’ Entities etc - not sure where they would fit in an Extension. Happy to chat about it.
Quake1 is £3 on Steam and you get all the level files.
https://store.steampowered.com/app/2310/Quake/
What part of the code are you referring to with that?
I would have though this should be possible to restructure into an extension that implement the Sketchup::Importer interface: Class: Sketchup::Importer — SketchUp Ruby API Documentation
PlayGameTool
Yeah, that could work. My intention is to subclass Quake1Parser to do HL1Parser etc
Ah, didn’t notice that initially. Yea, there’s probably parts that can be part of the importer interface and part that can be part of the general extension.
