&gt;Anyway, *supposing* someone did this, it might be easiest to record<br>&gt;every player&#39;s commands and userinfo strings, and play them back as if<br>&gt;the players were actually connected.<br><br>Haha, excuse my ignorance, but I&#39;ve always imagined something like that! In fact, that&#39;s how I actually thought it originally worked, the regular recording haha, wow I&#39;m pretty stupid. But yeah that&#39;s a good idea.
<br><br><div><span class="gmail_quote">On 3/7/07, <b class="gmail_sendername">Neil Toronto</b> &lt;<a href="mailto:ntoronto@cs.byu.edu">ntoronto@cs.byu.edu</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Lovely self-reply...<br><br>Neil Toronto wrote:<br>&gt; *snip*<br>&gt;<br>&gt; Server-side demos might be easier to do in-engine. We had to jump<br>&gt; through quite a few hoops to make it work well.<br><br>It was here we learned that the QVM has the same endian-ness as the
<br>architecture it ran on, which surprised us a bit. We had to write our<br>own hton*() and ntoh*() functions...<br><br>Anyway, *supposing* someone did this, it might be easiest to record<br>every player&#39;s commands and userinfo strings, and play them back as if
<br>the players were actually connected. Then the mod wouldn&#39;t need support<br>for the feature - it would just think some players were connected. Well,<br>it would need to know when a demo was being played back so it could keep
<br>players from joining the game.<br><br>This assumes, of course, that server events proceed deterministically.<br>Hmm... maybe this is harder than I thought.<br><br>The engine used to have a &quot;serverrecord&quot; command that recorded
<br>server-side demos, but I don&#39;t know how it worked or what&#39;s become of<br>it, and I don&#39;t know how to play them back.<br><br>Neil<br><br></blockquote></div><br>