;) 

search for #TF tag and join, it's public. 

Judging by recent screenshots, I think there are plenty of individual maps in the works! 

It does look pretty funky. Thanks. 

NEGKE GO MAP. 

does anyone have an animated conveyor belt texture? 

Maybe check Quake 2 textures? I remember reading that it used some. 

Friendly reminder that if a map jam theme and dates are decided please send me all info and media so I can make a video promotion for you, thx! 

I do.

Qmaster's Collection"

+0GRATECONVTEK, in quake_part3.wad. Can't remember where I found it ir maybe I made it myself.

Tips:
Conveyor animated texture is choppy but you might try: "High FPS Texture Animations (Preach)"

An alternative is to use custents which has a conveyor of sorts using multiple trains linked but they have the problem of z-fighting eachother due to ltime discrepancies causing them to get out of sequence and overlap.

The best method is to use my qrobot.qc package with its func_robot_controller to sync multiple "robots"....BUT OH WAIT, I didn't ever release it, and I never did test the conveyor belt idea I had planned...I was waiting to finish that map I've been working on forever that uses them in a clever way. 

You're a champ, thanks man :) 

Four Player in FitzQuake Mark V - YouTube Video

Should be standard engine feature in a few weeks. It's very prototype at the moment.

/Fifth is largely to blame. 

It strikes me that if you're going to add four "sessions" in a single engine, it would be the prime time to add multi-threading to the engine. 

 

Because at the moment (at least in QS) most of the processing in the engine happens within a single rendering loop.

Somebody can correct me if I'm wrong, but if all the "clients" are being processed under the one thread and one slows down, it will effect the others. Whereas if each "client" has its own thread it shouldn't be affected by the performance of the others.

And the frame rate on that video is atrocious =P 

opengl doesn't really support threading. as such, drawing each seat in a different thread isn't practical, and threading the rest of the engine would be a nightmare too. 

I'm a little surprised since opengl has been around forever, thanks spike 

its been around a while, but it also has far too much state to track+sync.
d3d11 has limited multithreading, in that you can at least queue calls from another thread, but vulkan/d3d12 are what you need for proper threading support (multiple device queues mean that even the gpu can safely 'thread' the rendering).
Whereas older apis would need too many locks.

regarding the rest of the engine, multithreading and globals are basically mutually incompatible... and quake just LOVES its globals...
A couple of engines have moved audio mixing off into another thread. FTE has moved various resource loading into worker threads too. Doing such things requires fixing all sorts of things, like console prints, cvar accesses, anything that might interact with simultaneous console commands, etc. Its not fun, which is why I've not tried to properly thread fte's vulkan renderer even though it'd probably be a nice speedup. 

I've been making a mod and am about done with features and coding. Need to document it all. What's the best kind of readme?

Some mods use html with pictures, others use simple txt, some both. 

http://imgur.com/a/PoerM

A glimpse into where "Muk" came from aside from Pokemon. :)

Qmaster: Id say whatever you feel is going to lead to a further understanding of the material. Id bet some things would be fine with simple text explanations, whereas some things might need a screenshot or two to get the idea.

that being, said Im unaware to the extent of your mod.

bit basic, but i didnt wanna ignore ya. 

If you are willing to put in the time to learn it, Pandoc is a great option. You can write your documentation in Markdown, which is a simple markup language with example and documentation all over the web. It can convert Markdown documents to .docx, HTML, LaTeX and various other forms--even plain text files. Markdown by itself is also quite readable.

http://pandoc.org/

Note that one of the demos on the site allows you to try Pandoc online.

Installing and setting up the LaTeX backend so you can create PDFs is a bit of a pain on Windows. You don't need to do it if you don't need that particular output format, though. 

Additional comment on the pictures. If you add pictures to the documentation, it allows people to learn what the various features are while playing the mod. For example, you only learn what the names of monsters are if they kill you in stock Quake at least, and other interactive objects rarely tell you their names either. And they can look stuff up they've seen in game much more easily.

Most mappers would probably just open their editors or the source files and look at them when they want to learn what the various mod features from the docs look like. That means the pictures aren't that important, but they are a nice addition. 

So +1 for pandoc. asciidoctor is also very good and adhoc has a more expressive syntax than markdown. 

Working on my map, starting to lay down basic textures and minor brush details and I have to say what a difference it makes. Although I could visualize what I plan to make from the grey boxing, it really helped me appreciate what I am trying to create after seeing it in partially complete form.

I know there has been older threads on this but general abuse...meh.

For people currently working on maps, do you grey box entirely first? Texture as you go? Light as you go...or even fully detail as you go? 

I go room by room. I wouldn't call my results necessarily full detail/lighting when I finish an area, as I do sometimes go back and make revisions, but I have found in the past that greyboxing too far ahead can be very painful when things need to change to work hoe you really want.

Much better to run into issues in small sections than with sn entire map when one little hallway is too short/long to fit a texture properly.