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. 

Detail as I go, stream of consciousness mapping. I plan out a rough idea for the map in my head or even a napkin sketch but then just let creativity take over and have fun with it as I go. My maps aren't typically that coherent as a result but each area is typically well contained and, I hope, fun. Keep it fun. Go map. 

check out these threads for discussion of mapping technique: (feel free to add to them too)

http://celephais.net/board/view_thread.php?id=61057
http://celephais.net/board/view_thread.php?id=60554 

http://www.celephais.net/board/view_thread.php?id=60386 

I rarely have the slightest idea of what I'll end up with at first. I often start with placing both the beginning and ending at once. The next thing is to fill in the middle part.

I sometimes have the exit/ending visible from the start position. If not, then at least have the first goal in sight. Getting to it being the trick.

Always I have built solid and error free from the beginning, none of this plugging the leaks later nonsense.

Texture and lighting as it goes, but often just a guess at first, knowing it will get tweaked and adjusted as the map progresses. Rooms, areas, and brushes will get rearranged and changed many times. 

I struggle with going back and removing or rearranging what I have, feels like taking a nice painting and scribbling crayon all overit, just seems wrong though it probably ends up making the map better in the long haul. 

Is now the most powerful person in America.

I....I...never asked for this. 

Remember: the GEP gun takedown is the most silent takedown.

deus ex theme plays in the distance (the good one) 

Thanks metlslime, I will have a look at those threads. I knew there were some floating around.

I am starting to think "going as you go" may be the best approach because now that I have fully invested on doing that (Even though I have large greybox to currently work with) I find I can appreciate my map as I see it truly being from concept to releasable material.

If this conversation continues on, I'll try to sway it towards one of the existing threads.