john-carmack-plan-archive

osystem if you wanted to address this. Would have been nice to see this rectified in the re-release. With the re-release you're basically sending out 4x the rate of the original and there's still slow connections which might chug on all that data. Some parts of the US still deal with speeds that are closer to modem than broadband. Anecdotal evidence: Some years ago I was advising a fellow Quake II modder on how they could fix some limitations of the network model. They took the easy way and changed the update rate to something higher that felt smooth enough for them and it'd render anything but listen/local games unplayable because they were sending out too much data over the network. Eventually they gave up and started on top of a QuakeWorld based engine to avoid reinventing the wheel. Also some fun trivia: In the original Quake II, physics are rounded down to network precision. They are not rounded to nearest, mind you - which results in a drunken walk. Unless you're around the [0,0,0] vector on the map's coordinate system, you will be unable to walk forward/back in a straight line. [1] https://github.com/ESWAT/john-carmack-plan-archive/blob/mast...

I am serious. DO NOT SEND ME ANY MAIL ABOUT THIS! When we have more to say about it, we will make a formal announcement. This would be a good time to start a heated debate in the newsgroups about what the fairest tourney rules would be, though. The specs: 1987 328 GTS with turbocharged engine. Feature in the january, 1994 issue of Turbo magazine. Made 360 HP at the rear wheels on a chassis dyno. New engine (I melted the first one...), new paint. The interior could use a little work. I plan to also include enough cash to cover tax and insurance.

st spawn a loop at the background, which gathers idleness status from the OS and uploads it when it changes, into world readable files and the remote clients can just check those file whenever they want. 4. extra status indication with automatic expiry, eg when someone is away from the keyboard, coz they are having lunch we do use this feature often and it's a really helpful regarding when can we expect a response from someone. again, quite simple to model this as a plain text file and we can even use emojis, to have a very similar effect to setting " lunch" on slack. ppl would need to know what's the emoji selector shortcut though... like cmd-ctrl-space on macos. 5. text search across all channels/rooms assuming the chat is being logged into files, then a recursive (rip)grep could work to some extent, but then from the search results one might want to get back to the context of the result too. 6. threads this complicates implementation a lot more, but we found it an obvious improvement over the single threaded IRC model of communication 7. having threads open on the side, so ppl can track 2 streams of comms at once at least it would require starting the chat app multiple times and do some window management to see them side-by-side now obviously all this can be done a lot simpler, but those implementations typically always lack somehow. not sure why is that... see https://cancel.fm/ripcord/ or http://www.altme.com/what.html the REBOL 3 programming language even had a quite full featured, text-mode chat built in: http://www.rebol.com/r3/docs/functions/chat.html !