#pentagram@irc.freenode.net logs for 23 Sep 2003 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage

[03:26:19] --> Kirben has joined #pentagram
[03:26:19] --- ChanServ gives channel operator status to Kirben
[06:00:51] --> phadin has joined #pentagram
[07:11:36] --> servus has joined #pentagram
[07:11:55] * servus moos in distemper at pentagram.sf.net's abysmal site.
[07:14:25] <DarkeZzz> You need to sneak up on wjp, then club him other the head to get him to update the site to the php stuff if he wishes it to be so. *grin*
[07:14:36] <servus> PHP stuff? It is written?
[07:15:11] <servus> I put a lot of work into the Pentagram site! Pleh! Petty Politics of the Princes of Pentagram!
[07:15:40] <DarkeZzz> No. He'd just have to modify your site to mung it like the php stuff for exult. If you check the various pages under the web directory, you'll see how the pages are actually constructed.
[07:16:05] <servus> It's already set up for that, actually.
[07:16:25] <servus> The main page is an SSI include header, a few lines to set up the main tables, SSI include body, and SSI include footer.
[07:16:40] <servus> All I have to do is replace the middle SSI include with a CGI query and it's done-and-done.
[07:16:57] <DarkeZzz> Cool.
[07:17:05] * servus considers writing a messageboard in C...
[07:17:22] <DarkeZzz> He did mention something about fiddling with the menu, and not having it over the logo too, I think.
[07:17:28] <servus> I even brushed on up CGI by writing a few programs from scratch! But what do I get for the effort? Scratch!
[07:17:36] <servus> I did that
[07:17:59] <DarkeZzz> Not a chance. *grin* We'll either use the exult forums, or something standard like phpbb.
[07:18:17] <servus> I didn't say I wanted to write the CGI programs for *that*, I was making a sidenote.
[07:18:27] <DarkeZzz> Forums are something that the wheel has been reinvented so many times it's not funny. *grin*
[07:18:38] <DarkeZzz> Heh.
[07:19:28] <servus> The uwadv crowd has dried up
[07:19:35] <servus> I have unreleased models languishing on my computer!
[07:21:28] <DarkeZzz> Such is life. Keep plugging away and they'll come back again, and so the wheel turns, just like exult. *grin*
[07:23:43] * servus gets no credit around here. Heh. I even wrote my own Exult, before Exult! Mwauahhaha. Stick it in your eye!
[07:26:40] * servus continues chewing on foxgloves.
[07:28:47] * DarkeZzz snickers.
[07:29:37] <-- Kirben has left IRC ("System Meltdown")
[07:30:12] * servus dies.
[07:52:46] * servus starts to decompose
[07:55:58] * servus is interred by Vividos.
[08:46:52] <watt> anyone else still living or a brain-eating zombie?
[08:48:32] <DarkeZzz> Hrm... maybe.
[08:48:38] * DarkeZzz checks servus to see if he's still alive.
[08:51:20] * servus croaks. Wis Corp Mani!
[08:54:17] <watt> heh.
[08:57:01] <watt> Anywho.. I was taking a look at the current source.. very nice stuff. Especially the p_dynamic_cast with the java-esqe IsOfType macro method.
[08:57:51] <watt> Actually, I can't recall ever seeing this nice of C++, but that may just be a lack of exposure to it on a full project scale
[08:58:18] <watt> But I do have a question from what I've read so far.
[08:58:44] <DarkeZzz> Don't look in the 'old' pentagram module, nor in the /tools/ dir of the 'pentagram' one then. *grin*
[08:59:16] * DarkeZzz is all ears for questions, at least at the moment anyway. *grin*
[08:59:17] <watt> Yeah.. I did about a year ago..
[08:59:47] <watt> It was scary, but I didn't know enough at that point to follow it
[08:59:52] <DarkeZzz> Don't worry, your psyche will recover from the trauma sometime soon. *grin*
[08:59:59] <watt> hehe
[09:01:02] <watt> I was wondering about the macros in pent_include. Is there a reason that they are surronded with do/while(0)'s? I'
[09:01:18] <watt> I'm assuming it has something to do with exult code
[09:01:31] <watt> like it was different there
[09:01:50] <DarkeZzz> Let's see, in old there's a pile of hacked up stuff, a minimal x86 emulator to decode sound, two different decompilers (they're a headache in themselves, let alone my quick&dirty coding style...), and a few other messy bits. *grin*
[09:01:57] <DarkeZzz> Ah. That's easy.
[09:02:04] <DarkeZzz> Take, for example the following macro:
[09:02:33] <DarkeZzz> #define DO_TWO_THINGS(X) X++; X++;
[09:02:44] <DarkeZzz> Now, if you call it like this:
[09:02:59] <DarkeZzz> if(non_zero==0) DO_TWO_THINGS(X)
[09:03:03] <DarkeZzz> You get the incorrect code:
[09:03:11] <DarkeZzz> if(non_zero==0) X++; X++;
[09:03:17] <DarkeZzz> which is equilivant to:
[09:03:29] <DarkeZzz> if(non_zero==0) { X++; } X++;
[09:03:43] <DarkeZzz> If instead you have the define like:
[09:04:07] <DarkeZzz> #define DO_TWO_THINGS(X) do { X++; X++} while(0);
[09:04:18] <DarkeZzz> You get the correct and expected output:
[09:04:32] <DarkeZzz> if(non_zero==0) do { X++; X++; } while(0):
[09:04:39] <DarkeZzz> Which translates into effectively:
[09:04:46] <DarkeZzz> if(non_zero==0) { X++; X++; }
[09:04:49] <DarkeZzz> Make sense? *grin*
[09:05:40] <watt> oh. that makes sense, but the do/while isn't neccessary is it? You could just say #define DO_TWO_THINGS(X) {X++; X++;} .. right?
[09:06:56] <DarkeZzz> No, because there's situations where a basic block isn't valid, where a macro call could be expected to be used.
[09:07:40] <watt> is there an easy example?
[09:07:41] <DarkeZzz> (And a do/while loop is valid.)
[09:08:03] <DarkeZzz> Hrm... *think*
[09:10:01] <watt> for(int x=0; x<size; DO_TWO_THINGS(x)) ?
[09:10:27] <watt> I think that could be a case.. but I'm not sure
[09:11:38] * DarkeZzz ahhs! He thinks he remembers!
[09:13:07] <watt> hmm.. mine didn't work either way
[09:13:19] * DarkeZzz does a quick search for an example, since it'll be easier to find it then for him to type it. *grin*
[09:14:22] <DarkeZzz> http://www.eskimo.com/~scs/C-faq/q10.4.html <- Easier example then for me to type. Lazy I am. *grin*
[09:19:01] <watt> ohhhhhhh... I see.
[09:19:07] * watt sees
[09:21:50] <watt> Ok, that's all I had right now. I'll read some more of the code, and hopefully I could understand it all to a point that I could actually be useful soon.
[09:21:52] <servus> comma, watt.
[09:22:05] <servus> for( int i = 0; i < 10; i++, j++ );
[09:24:10] <watt> oh.. yeah.. I've never had to bother with that. Multiple lines usually worked well as methods in most of my code.
[09:24:42] <watt> Think I've only seen that once in one of my books.
[09:24:42] <servus> I prefer to do things in one line
[09:24:45] <servus> For instance...
[09:25:04] <servus> inline void mystrcpy( char* a, char* b ) { while( *a++ = *b++ ); }
[09:25:06] <servus> :-)
[09:28:35] <watt> ah, there's where the school of thought differs.. if I have to read it twice, I usually perfer to rewrite it in a more verbose way.. separate lines. for ease on the eyes.
[09:28:49] <watt> but then again, my code quadruples in length
[09:31:00] <watt> and your's should speed up the copy. slightly.
[09:32:54] --> Fingolfin has joined #pentagram
[09:32:54] --- ChanServ gives channel operator status to Fingolfin
[09:34:07] <servus> You have to admit, my strcpy is nice :)
[09:34:26] <watt> granted
[09:35:14] <servus> 8 lines of assembly
[09:36:10] <watt> is that the compled conversion.. or a different version in asembly?
[09:36:26] <servus> $ gcc -O3 -S -masm=intel out.c -o out.asm
[09:36:39] <watt> oh.
[09:37:05] <watt> of course the -O3 doesn't hurt
[09:37:12] <servus> No opt is 10 lines
[09:37:20] <servus> My hand-written assembly version is 12 lines =/
[09:37:25] <servus> I'm better at C:)
[09:37:29] <watt> still nice
[09:38:18] <servus> I'm not good enough at Intel assembly to cut down on the verbosity...
[09:38:59] <watt> although, you may have to admit that instruction counting is a little out of date when you deal in Ghz
[09:39:28] <servus> Nahhh:)
[09:39:36] <servus> I have a full game at 25KB:P
[09:40:48] <servus> Consider all the data segments, that is *very* compact code, especially since that's with a Microsoft linker
[09:40:54] <watt> hehe.. time to break out the 286 and load up pentagram.. hehe.. I don't compiler will run natively on it though :(
[09:41:13] <servus> 286? Pentagram?
[09:41:19] <watt> a joke.
[09:41:32] <servus> Exult takes a fast computer!
[09:41:43] <servus> It's like my QBasic Ultima7 Emulator :P
[09:41:46] <DarkeZzz> I'd suggest using your mystrcmp would be rather pessimal in most cases. There's much more efficent ways of copying a block of bits then that. *grin*
[09:41:50] * servus grins evilly at Darke >:)
[09:42:12] <servus> It's the fastest way for a const char*
[09:42:20] <watt> memcpy?
[09:42:39] <servus> That'd require another call to strlen() which would search through the string first to find the \0
[09:42:56] <servus> This method contains it all, the NULLcharacter search and the copying
[09:43:22] <servus> I use memcpy and std::string though :P
[09:43:32] <DarkeZzz> Nope. You're doing byte aligned copies. Which is less efficient on a 32bit processor then uint32 aligned copies. Check out how a few different compilers optimise their strcpy to, and you'll fine some curious tricks to speed things up. *grin*
[09:44:43] <servus> I could use a 32 bit integer and compare and'd bitmasks for varL and varH then copy it in 32 bit chunks
[09:45:09] <DarkeZzz> For such common, and critical path code, it's just a case of "don't bother, the compiler can figure it out better then you can", you're better off concentrating on making your algorithms more efficient, that's where the primary speed gain will be.
[09:46:03] <servus> Such a buzzkill you are :)
[09:46:40] <servus> I use std::string nowadays though, it is funner to use, even if slower :)
[09:46:49] * servus uses std::list's to handle raw sockets >:)
[09:47:15] <servus> std::string rather, bugger I'm tired.
[09:47:34] * DarkeZzz is using std::deque's to juggle opcodes. His decompiler is much more fun then Towers of Hanoi ever was. *grin*
[09:47:50] <servus> A VM seems fun.
[09:48:21] <servus> I wasn't good enough to figure it out when I made U7C:)
[09:48:32] <DarkeZzz> It is. Check out the UCMachine code in pentagram, proper. Very, very pretty it is.
[09:49:19] * servus considers his code very pretty, thank you!
[09:49:23] <servus> I'd sleep with my code if I could.
[09:49:30] <DarkeZzz> Weirdo.
[09:49:57] <servus> You've never seen "Weird Science"?
[09:50:43] * DarkeZzz considers his code rather ugly, simply because he doesn't spend enough time refactoring it, he finds it quicker just to rewrite it. *grin*
[09:50:58] <DarkeZzz> Of course! Thus the compilment. *grin*
[09:51:17] <servus> My code's ugly when I'm learning a new concept
[09:51:28] <servus> You should see my first revision packet-defragmenting code >.<
[09:53:43] <DarkeZzz> That's why my code is perpetually ugly. *grin*
[09:54:01] <servus> Exult uses TCP for the debugger, yes? Does it support remote debug or just localhost? :)
[09:54:28] <DarkeZzz> I'd figure both, I've never tried.
[09:55:06] <servus> Never even attempted multiplayer? I'd think it'd be a snap... It seems like you already have all the necessary infstructure.
[09:56:42] <watt> multiplayer??? I thought that was taboo.
[09:57:13] <DarkeZzz> Syncronising game state is non-trivial, and usually built in from the ground up, not added on later. *grin*
[09:57:33] <servus> Ah, yes, you have a monolithic game kernel, hmm
[09:58:11] <servus> Well just designating one player as the host and treating the client(s) as as dumb-terminal as possible would probably work, even if it's a bit hacky
[09:59:43] <servus> Or make a stripped down game version that doesn't run a player, but just serves other players as NPCs.
[10:01:10] <servus> Too bad my eyes turn to water whenever I try to read anyone else's code :)
[10:02:33] <DarkeZzz> You'd also need to handle cases where there's more then one, non-overlapping cached in region. Unless you wanted to cache everything in, and execute everything as if the PCs were nearby.
[10:03:43] <servus> Just create a different stack for each PC that would allocate... Once you've got that down, you can optimize by overlapping the information
[10:04:36] <DarkeZzz> You'd also have to properly handle latency, prediction, properly synchronising usecode machines and other fun stuff. *grin*
[10:05:28] <servus> Nahhh you don't need to worry about that :P
[10:05:42] <DarkeZzz> And more importantly the fact that lots of usecode assumes there's only one 'avatar' (aka, 'user') to trigger things, whereas you'll have multiple ones.
[10:05:53] <servus> Just keep one virtual machine for all the usecode, like you already have
[10:06:29] <servus> In overlapping regions, there is always just one avatar, and the "avatar" has its position swapped round-robin with all the nearby PC's for egg checks
[10:06:49] <DarkeZzz> So you're doing no prediction, or processing in parallel on the client machine? That sounds like a recipe for lots of lag related problems.
[10:07:09] <servus> For a simple simple game with *extremely* coarse user information?
[10:07:29] <servus> Nah. Especially since it'd be a pre-alpha hack to get any multiplayer working in the first place
[10:07:36] <servus> 1. Make it work 2. Make it work better
[10:07:36] <DarkeZzz> With spells (the lich for instance?) which can kill you in under a second?
[10:08:13] <servus> That falls under 1. getting it to work at all :)
[10:08:17] <servus> Fix it up later
[10:08:52] <DarkeZzz> Sure. But designing for a hack you can improve on is important. Not much point putting lots of effort and research into hacking something together, which you know is going to fail is worthless if you don't study current ways of doing things and making an educated choice. *grin*
[10:08:53] <servus> Plus, what can you really do about that, if there are two players fighting this lich, and only one lags?
[10:09:08] <servus> Option 1. Lag the entire region until the laggiest player resumes (bad)
[10:09:20] <servus> Option 2. Make the player invulnerable? (Weird)
[10:09:22] <DarkeZzz> For example, what you're describing sounds like the way X11 works, which is fine for low latency connections, but doesn't work so well over high latency networks.
[10:09:53] <servus> Client-side prediction just doesn't really make sense for an application like this
[10:11:02] <servus> But consider this: You seem to think lag is the biggest problem to overcome for this project -- doesn't that sound like it's nearly done? :)
[10:11:09] <DarkeZzz> 3) If the usecode on the server and the client is synced, and the client 'spawns' recieves the trigger that 'spawns' the lich, the client can actually enter combat/flee immediately, rather then 300-500 seconds later when the lich finally spawns.
[10:11:13] <servus> It's like putting the carpet into a house you're building!
[10:11:32] <servus> That's how it'd be by default, right?
[10:11:45] <DarkeZzz> Nope. It's like deciding if you want carpted floors, polished wood, or tiles. *grin*
[10:11:46] <servus> The user enters combat via the usecode (?). This is all controlled by the server.
[10:12:15] <servus> The clients are dumb. All they do it receive information (which is useless, from the server's point of view), and give minimal information(though all the automated stuff is handled by the server )
[10:12:18] <DarkeZzz> Each different application would vary the materials and way you build your house. Just like the design of your interconnections will vary the way you build your client/server and protocols.
[10:13:54] <servus> Use Ultima Online as a highlag model, then
[10:13:58] <servus> Are you familiar?
[10:14:42] <DarkeZzz> Precicely. And if you look over all the mmorgs/muds/online-games out there, even the slow ones, you'll find almost all of them use client prediction in one facet or another. It obviously has *some* benefit to a significant proportion of the population, so it's unwise to discard it immediately. *Grin*
[10:14:44] <DarkeZzz> A little.
[10:14:45] <servus> The client sends minimal input, and nothing automated. In the case of combat, for instance, if you get attacked while lagged out, you will auto-defend yourself because this is a server-scripted response
[10:15:08] <servus> It's not client-side prediction, it's server-side autonomy.
[10:15:21] <DarkeZzz> Yup.
[10:17:55] <servus> Or...
[10:18:15] <servus> You could simplify matters by making a separate stack and VM for each PC, and segregating them somewhat.
[10:18:30] <servus> If both of the PC's walk on the lich egg at once, two liches spawn! Makes it challenging :P
[10:19:11] <servus> The overlap occurs in the main world cache, which I'm sure can already supporting caching in multiple regions at once
[10:19:54] * DarkeZzz notes that he hasn't been aruging that client side prediction is the be-all-and-end-all, server-side automony is fine, and what he'd expect too. He just thinks you're dismissing a valuable tool because it's 'too hard'.
[10:20:25] <servus> Not because it's too hard, I've done it:P
[10:20:37] <servus> It's not any harder in fact, it's just a different way of doing things
[10:21:04] <servus> It's a fun idea though.
[10:21:20] <servus> I simply fail to see how client-side prediction could help anything though
[10:21:40] <servus> If you lag out while fighting the lich, you're dead with or without the prediction:)
[10:23:45] <servus> What do you think of the idea of using highly segregated VM's and caches per each user? The only overlap being the manifest in the game world?
[10:24:20] <DarkeZzz> (dead with/without prediction) Not really. The server/client's argue as to where you 'are' and potentially roll back the damage if you evaded the blast locally, even though you might have got it on the server. The benefit of doing such on a fan-game is that there's no impetius, and no morass of crackers, to write bots and such to inject movement packets to exploit such events. *grin*
[10:24:32] <DarkeZzz> It makes sense, it's the way I'd do it.
[10:24:38] <servus> chat (And of course you'd use SOME client side prediction, so that the client knows you cannot walk over a rock &c... that rubberbanding effect would drive one nuts)
[10:25:05] <servus> With segregated VM's, such a thing would be easier
[10:25:29] <-- Fingolfin has left IRC (Read error: 110 (Connection timed out))
[10:25:48] <servus> I wonder how slim you could get a console version of exult...
[10:25:58] <servus> Kill all the rendering/gui/sfx code... Hmm:)
[10:26:06] <watt> hmm.. too tired to follow conversation. Thanks for your help.. bye.
[10:26:11] <DarkeZzz> You'd have to have some sort of object-locking like u8 has to stop two people from exeucting usecode on the same object.
[10:26:14] <DarkeZzz> Bye!
[10:26:25] <-- watt has left IRC (Remote closed the connection)
[10:26:40] <servus> No you wouldn't
[10:26:46] <servus> Segregated Usecode VM's.
[10:27:03] <servus> Problem solved, and situation *improved*:)
[10:27:30] <servus> Each player sets their own egg-tripped flag on their very own usecode virtual machine...
[10:28:52] <DarkeZzz> Umm... how would that help? I only see it causing more problems. Person1 actives usecode on objectX, that ultimately causes it to be deleted, Person2 starts it activating half way through Person1's activation of said usecode. Usecode terminates at end of Player1's activation, and deletes ObjectX, Player2's usecode then tries to access it at some point and segfaults.
[10:29:21] <servus> The usecode is only deleted on Person1's virtual machine!
[10:29:28] <DarkeZzz> This is what u8's usecode-locking is for. So you can't double-click on an item twice, or something.
[10:29:33] <DarkeZzz> The object is on the server though.
[10:29:35] <servus> Person2's virtual machine has no idea what Person1's virtual machine is doing
[10:29:44] <DarkeZzz> That's the problem.
[10:29:49] <servus> Of course
[10:29:53] <servus> The server is running more than one virtual machine
[10:30:00] <DarkeZzz> They're both working on the same object, and neither of them knows it is.
[10:30:20] <servus> No they're not...
[10:30:25] <DarkeZzz> Unless when Person1's usecode interpreter locks said object from being activated by anyone else, you'll get that problem.
[10:30:27] <servus> They are both running on copies of the same object
[10:30:32] <servus> They have their own stacks!
[10:30:47] <DarkeZzz> Umm... eh? *blink* Why's the object on the stack?
[10:30:52] <servus> Each player has his own virtual machine (with its only private stack)
[10:31:04] <servus> You'd have to create a stack for each VM to store separate copies of the usecode
[10:31:09] <servus> Or a heap, rather.
[10:31:12] <DarkeZzz> Take, for example, you double click on a fish. The fish is in the game world, right?
[10:31:14] <servus> Tired:)
[10:31:34] <DarkeZzz> Player1 starts his usecode, at the end of it the fish is going to be deleted.
[10:31:50] <servus> I don't think you understand me at all =-/
[10:32:03] <DarkeZzz> As Player1's 'fish' usecode is running, (it adds to his food total), then Player2 activates the fish as well, wanting a feed.
[10:32:11] <servus> There is a master "fresh" copy of the usecode, but neither Person1 nor Person2 ever touch this.
[10:32:20] <servus> When Person1 is made, he gets a brand new copy of the usecode.
[10:32:27] <servus> When Person2 is made, he gets his OWN brand new copy of the usecode.
[10:32:47] <servus> Usecode events that happen to Person1 have absolutely nothing to do with Person2's usecode-virtual-machine
[10:33:19] <DarkeZzz> So? I don't care in the least about the usecode. I care about the fish. If the pointer pointing to the fish is invalid when Player2 tries to acess/delete it, bad things happen. No one ever modifies the usecode.
[10:33:34] <servus> Fish = an NPC?
[10:33:45] <DarkeZzz> Fish==object.
[10:33:54] <servus> Ah okay
[10:33:56] <DarkeZzz> Just a thing. Could be a bottle of wine, or the door a player is about to open.
[10:34:27] <servus> You'd have to create a new layer of abstraction between the usecodemachines and the gameworld to funnel all the usecodemachines to the world...
[10:34:52] <DarkeZzz> It *could* even be a NPC, imagine what would happen to a conversation if you deleted the NPC half way through it? That's why u7 never truely deleted mpcs, it tossed them into a 'dead room'.
[10:35:05] <DarkeZzz> Something like that.
[10:35:28] <servus> Then the deadroom will still let them talk :P
[10:35:31] <DarkeZzz> Or you could just set a flag everytime someone uses an object, that no-one else can use that object until I'm through with it. *grin*
[10:35:37] <DarkeZzz> Precicely!
[10:35:49] <servus> 'Make a deadroom for objects!
[10:36:01] <servus> Or copy objects that are used by usecode...
[10:36:06] <servus> Make a version for each relevant PC
[10:36:23] <DarkeZzz> What happens when the usecode terminates without deleting the object then?
[10:36:30] <DarkeZzz> s/object/copy of the object/
[10:36:42] <servus> Ugh
[10:37:00] <servus> Well, that's a situation where one single VM would be the easiest option
[10:37:08] <DarkeZzz> You'd have to somehow detect the object was being deleted inside the usecode, and make sure that the code doesn't delete the copy afterwards, otherwise... segfault!
[10:38:13] <servus> UsecodeFunction locking..
[10:38:27] <servus> "Someone is doing that already, avatar #6546!"
[10:38:29] <DarkeZzz> No. The easiest option is to *lock* the object from being touched by anyone else if some usecode is acting on it. Really. Truely! You get all the benefits of multiple VM's, along with the safety of knowing you're not going to break anything by deleting/modifying/moving something. *grin*
[10:39:56] <servus> So multiple VM's but you'll have to add authenticating code to the usecode when it tries to point to an object?
[10:40:28] <DarkeZzz> Actually, what exactly do you mean by a VM?
[10:40:35] * DarkeZzz is slightly confused by terms. *grin*
[10:40:56] <DarkeZzz> Pentagram actually has one VM, called 'UCMachine', it however has multiple threads of usecode running inside it.
[10:41:11] <servus> VM, virtual machine. I'm using Java terminology... java is just like usecode, wherein it's arbitrary bytecode that has a separate process interpreting it into stuff that means something on the OS (the OS is Exult)
[10:41:24] <DarkeZzz> Ah, sure, one VM is fine then.
[10:41:45] <servus> But separate eggflags per player?
[10:41:54] <DarkeZzz> I'm thinking exult, where I thought only one usecode thread could run at a time.
[10:42:10] <servus> Well, more players = more usecode interpreting threads:)
[10:42:14] <DarkeZzz> Wouldn't you have severe problems with overlap?
[10:42:40] <servus> That's why you make fresh copies of usecode in the memory for each "machine"
[10:42:44] <DarkeZzz> I think you're going to have to have everyone running all in the same VM. Since all your globals aren't seperated into 'personal' and 'world' values.
[10:43:06] <servus> That is why I suggested multiple VMs... Precisely so players *don't* share globals
[10:44:04] <DarkeZzz> Unfortunately, u7 wouldn't work that way, since it stores 'general world state' flags into the same memory area as 'avatar specific flags' (such as "Have I met this person?").
[10:44:33] <DarkeZzz> Seperating the two would also be quite a challenge for someone wanting to do multiplayer of it. *grin*
[10:44:52] <servus> Exactly why you'd make separate copies of those flaglists per avatar
[10:45:02] <servus> std::vector<CAvatar> *grin*
[10:45:15] <servus> No one said it'd be easy
[10:45:29] <servus> You need copies of EVERYTHING for each player though, until you disentangle things to feel brave enough to overlap :)
[10:47:00] <DarkeZzz> Talk about things being painful for beta testers. *grin*
[10:47:27] <servus> Nah, no beta testers needed... Who says you can't connect localhost to localhost three times? :D
[10:49:26] <servus> Well no one said it'd be easy.
[10:49:45] <servus> I made a physics engine for UWAdv... It wasn't easy but no ones even been around to see it yet. Hah
[10:51:32] <servus> And I've made a few net programs... There's always time to learn:)
[10:52:32] <DarkeZzz> I'm sure someone will be appreciative of your l33t physics sk1llz. *grin*
[10:53:53] <servus> Hey they are actually getting pretty good, honest! I have a nearly-finished game that relies on physics as the chief effect:)
[10:56:10] * DarkeZzz snickers.
[10:56:22] <DarkeZzz> Anyway, this bunny should try and nap. *grin* Tired am I. Night!
[10:56:34] <servus> Night, flayrah enu
[10:58:35] <servus> Flayrah Fu Inle', rather.
[11:02:42] <servus> Oh that didn't even make sense
[11:02:46] * servus kicks his sleepy Lapine
[11:03:08] <servus> M'saion Inleroo? :P
[12:47:43] --> Colourless has joined #Pentagram
[12:53:42] <-- phadin has left IRC (Read error: 104 (Connection reset by peer))
[12:53:46] <Colourless> hi
[13:04:58] --- ChanServ gives channel operator status to Colourless
[16:24:24] --> wjp has joined #pentagram
[16:24:25] --- ChanServ gives channel operator status to wjp
[17:44:23] --> phadin has joined #pentagram
[17:54:08] --> Cless has joined #Pentagram
[17:55:20] <-- Colourless has left IRC (Nick collision from services.)
[17:55:21] --- Cless is now known as Colourless
[17:55:23] --- ChanServ gives channel operator status to Colourless
[19:18:35] <-- Colourless has left IRC (Read error: 104 (Connection reset by peer))
[19:18:36] --> Dark-Star has joined #pentagram
[19:36:36] <-- phadin has left IRC (Read error: 110 (Connection timed out))
[23:18:36] <-- wjp has left IRC ("Zzzz...")