search of the:   for: 
code logs -> 2011 -> Wed, 23 Mar 2011< code.20110322.log - code.20110324.log >
--- Log opened Wed Mar 23 00:00:10 2011
00:01 Attilla_ is now known as Attilla
00:15 cpux [chatzilla@Nightstar-c978de34.dyn.optonline.net] has quit [[NS] Quit: ChatZilla 0.9.86 [Firefox 3.6.14/20110218125750]]
00:17 cpux [chatzilla@Nightstar-c978de34.dyn.optonline.net] has joined #code
00:36 You're now known as TheWatcher[T-2]
00:38 You're now known as TheWatcher[zZzZ]
01:10 Attilla [Some.Dude@37647E.0E7447.22C7B1.567421] has quit [Ping timeout: 121 seconds]
01:19 DiceBot [Reiver@5B433A.77CB96.194A93.12F406] has quit [Ping timeout: 121 seconds]
01:20 Reiver [reaverta@ServerAdministrator.Nightstar.Net] has quit [Ping timeout: 121 seconds]
01:20 Kindamoody is now known as Kindamoody[zZz]
01:22 DiceBot [Reiver@Nightstar-aec8191b.xnet.co.nz] has joined #code
01:22 Reiver [reaverta@ServerAdministrator.Nightstar.Net] has joined #code
01:22 mode/#code [+qo Reiver Reiver] by ChanServ
01:55 gnolam [lenin@Nightstar-38637aa0.priv.bahnhof.se] has quit [[NS] Quit: Z?]
03:27 SmithKurosaki [smith@DCDEB4.F95CFD.2EEAA4.B1AE3D] has joined #code
05:36 Derakon is now known as Derakon[AFK]
05:53 AnnoDomini [annodomini@D553D1.9D4909.D8029A.E53810] has joined #code
05:53 mode/#code [+o AnnoDomini] by Reiver
06:17 celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
07:41 Kindamoody[zZz] is now known as Kindamoody
08:46 You're now known as TheWatcher
09:56 Attilla [Some.Dude@37647E.0E7447.22C7B1.567421] has joined #code
09:56 mode/#code [+o Attilla] by Reiver
10:06 AnnoDomini [annodomini@D553D1.9D4909.D8029A.E53810] has quit [[NS] Quit: leaving]
10:29 Kindamoody is now known as Kindamoody|out
10:47 AnnoDomini [annodomini@F67919.F326B3.98D923.BDA7B6] has joined #code
10:47 mode/#code [+o AnnoDomini] by Reiver
11:02
<@AnnoDomini>
http://programming-motherfucker.com/
11:05
<@TheWatcher>
Pft, awesome
11:06
< Tamber>
hehe
11:16 gnolam [lenin@9D46A2.F4E9D7.E4B4CF.2072AD] has joined #code
11:32 cpux is now known as shade_of_cpux
12:29 AnnoDomini [annodomini@F67919.F326B3.98D923.BDA7B6] has quit [[NS] Quit: leaving]
12:38 Stalker [Z@3A600C.A966FF.5BF32D.8E7ABA] has quit [[NS] Quit: If the world didn't suck, we'd all fall off.]
12:45 celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has joined #code
13:01 AnnoDomini [annodomini@D553D1.41311B.346302.AC5555] has joined #code
13:01 mode/#code [+o AnnoDomini] by Reiver
14:02 Stalker [Z@26ECB6.A4B64C.298B52.D80DA0] has joined #code
14:31 celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
15:00 Attilla_ [Some.Dude@Nightstar-92c9199f.cable.virginmedia.com] has joined #code
15:03 Attilla [Some.Dude@37647E.0E7447.22C7B1.567421] has quit [Ping timeout: 121 seconds]
15:14 Reiv [orthianz@3CF3A5.E1CD01.36D449.95F5A5] has quit [Connection reset by peer]
15:14 Reiv [orthianz@3CF3A5.E1CD01.36D449.95F5A5] has joined #code
15:32 Rhamphoryncus [rhamph@C06FE3.F5723C.BE3FEB.9D4666] has quit [Client exited]
15:44 Attilla_ is now known as Attilla
15:49
<@ToxicFrog>
e
15:49
<@froztbyte>
v
16:31
<@TheWatcher>
How do you go from 'e' to 'v'?
16:31
<@Namegduf>
Knight's move.
16:31
<@TheWatcher>
Hah, indeed
16:34 * froztbyte was unfamiliar with that term
16:35
<@Namegduf>
In the game of chess you must never let your opponent know your moves..
16:36
<@froztbyte>
http://www.gpnotebook.co.uk/simplepage.cfm?ID=-1737818073
16:36
<@froztbyte>
Namegduf: yeah, but I'd still never run across it before
16:37
<@froztbyte>
definitely one I won't forget though
16:39 * TheWatcher ponders a varient of chess for keyboards, using only a king, bishop, knight, rook, and four pawns a side, with the width of the keyboard being the board
16:40
<@froztbyte>
would be interesting to try out, since you have variable path-lengths
16:40
<@TheWatcher>
Indeed.
16:40
<@jerith>
Is g->b a straight move or a diagonal?
16:41
<@TheWatcher>
I'd go for straight.
16:41
<@TheWatcher>
vgy/rgn being diagonals
16:42
<@Namegduf>
Press a key to select that square, or the piece in that square.
16:42
<@Namegduf>
Press another square to to move your piece to that square.
16:42
<@jerith>
TheWatcher: But g and n are almost as separated as g and j...
16:43
<@TheWatcher>
depends on the keyboard, I guess
16:53 celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has joined #code
17:21
<@ToxicFrog>
I'd call fgh and tgb straight, vgy diagonal and rgn disallowed, personally.
17:21
<@ToxicFrog>
Although this kind of breaks bishops.
17:29
< gnolam>
The real problem comes with different keyboard layouts.
17:29
< gnolam>
If a rook moves from Q to Z, has it moved two steps (sane layout) or five (German keyboards)?
17:39
< celticminstrel>
rfv would be the other diagonal, wouldn't it?
17:40
< celticminstrel>
It's a hex/tri layout with only three rather than four possible directions, at least on my keyboard.
17:41
< celticminstrel>
Except it's not actually hexes or triangles. <_<
17:53 Vornucopia [NSwebIRC@C888DE.7F9621.E9EB68.432608] has joined #code
18:07
< gnolam>
Oh hey - the requirements specification has finally arrived.
18:09
< Vornucopia>
Immediately make a certified copy and place it in a safe deposit box.
18:15
<@TheWatcher>
And then shed a single tear over it's sad, short existence before it is replaced by another.
18:16
<@TheWatcher>
*its
18:16
<@TheWatcher>
Gods, my brain is fried today.
18:31
< gnolam>
:)
19:00 * ToxicFrog sighs
19:01
<@ToxicFrog>
I have a sinking feeling that felt's design is inherently fucked
19:03
< Vornucopia>
In what way?
19:09
<@ToxicFrog>
The way server and clients interact, the way events are propagated
19:09
<@ToxicFrog>
In retrospect, I probably should have gone with an "absolutely everything happens on the server, all state is updated on the server, and clients get state updates as needed"
19:10
<@ToxicFrog>
(at present it's more like "server validates, then tells all clients to update themselves")
19:10
< Vornucopia>
I take it your model is spread across both willy-nilly now.
19:10
<@ToxicFrog>
Yes :(
19:10
< Vornucopia>
Oh, that madness. Yeah, the server should do all state updates and just throw those out there.
19:11
<@ToxicFrog>
And I really don't want to do another major rewrite, because it's so close to being playable!
19:12
<@ToxicFrog>
But at the same time, work on it is getting slower and slower as it gets more and more ugly
19:12
< Vornucopia>
What's the state of any design documents?
19:14
<@ToxicFrog>
The design documents, such as they are, only cover Descent, not the engine itsel
19:14
<@ToxicFrog>
The rest is not so much design documents as it is scattered notes.
19:15 * Vornucopia nods.
19:19
<@ToxicFrog>
At the moment, the revision I'm considering is that all true event handlers are called on the server; each class defines a bunch of methods, all of which are assumed to execute in server context, and a bunch of configuration used by the ui/ module (which executes in client context), and a list of properties to kept in sync automatically between client and server.
19:21
<@ToxicFrog>
Frob an item and the event dispatcher runs propagating the ui event (eg, click_left); it is assumed that this either operates completely client-side (pan/zoom, for example, do not need server involvement) or calls a non-UI event handler, which generates a message to the server and immediately returns.
19:21
<@ToxicFrog>
The server then does its thing and at some point in the future you may recieve one or more state updates resulting from your action.
19:23
< Vornucopia>
In the same way that IRC sometimes sends you confirmation updates for certain things, like join and nick?
19:26
<@ToxicFrog>
Yeah.
19:26
<@ToxicFrog>
Of course, I now need to come up with a good way of actually handling the state updates.
19:29
< Vornucopia>
Yeah. Other questions: if the server is running the game and all the state updates, it must know the game at whatever level the event handlers are for that game.
19:30
<@ToxicFrog>
Clarify?
19:31
< Vornucopia>
So for instance if I write a Go thing that (for instance) locks chips to gridlines, and prevents movement thereafter, the server now needs to know about that. Which I guess is almost the same as all clients needing to know it.
19:32
< Vornucopia>
But then if someone wants to play a game that's not in the server's list, they're mostly SOL.
19:33
<@ToxicFrog>
The latter I don't really consider an issue.
19:34
< Vornucopia>
--because it's easier to set up, and unlike IRC it doesn't have multiple games running at once, duh, silly me
19:34
< Vornucopia>
THough actually it makes players' lives easier too because the other clients now need just the art.
19:34
<@ToxicFrog>
Similarly, if player A wants to play chess and player B doesn't have the chess module installed, B will disconnect as soon as A tries to open the chess box with "server attempted to instantiate nonexistent class chess.ChessPiece; do you have the appropriate game module(s) installed?"
19:35
<@ToxicFrog>
That's, um, not entirely true
19:35
<@ToxicFrog>
Or at all true, really
19:35
< Vornucopia>
because they also need the VC stuff, right.
19:35
<@ToxicFrog>
For starters, clients need to know the UI event mapping -> server message mapping for each widget (unless we send raw UI events to the server, which squicks me out seriously)
19:36
< Vornucopia>
Oh squick, yeah, no.
19:37
<@ToxicFrog>
Right. So at minimum the client needs a way to, say, hand a click_lift(x,y) event to the object tree and let one or more objects catch it and send messages to the server as a result.
19:37
<@ToxicFrog>
...although
19:38
<@ToxicFrog>
At present, the way that basically happens is each widget type has a set of (event handler, event name, [suggested UI event bindings]) tuples.
19:39
<@ToxicFrog>
We might be able to get away with just sending to the client:
19:39
<@ToxicFrog>
- that tupleset, which it uses to automatically construct UI event handlers
19:40
<@ToxicFrog>
- the set of synchronized fields (minimally id so we can find it again later; typically also x, y, w, h, parent, and children)
19:40
<@ToxicFrog>
- the rendering information (basically, the name of a renderer to use for that object, and some optional parameters)
19:41
<@ToxicFrog>
In which case the client doesn't need any code for object types at all, just for the core engine.
19:41
<@ToxicFrog>
Alternate architecture: the client's version contains rendering methods and UI bindings, the server's version contains event handlers.
19:42
<@ToxicFrog>
That one I'm honestly not quite so enamored with, because it means we basically now have two complete class heirarchies for the same things, one for the client-side stuff and one for server-side
19:42
<@ToxicFrog>
On the other hand, it means the client has a lot more flexibility with respect to UI design and behaviour, which would be useful when porting it to things
19:43
<@ToxicFrog>
Hrm.
19:45
< celticminstrel>
Oh, someone is programming in Go?
19:45
< Vornucopia>
Right. One of the things I'd look into, which actually pisses me off no end in MAME, is seeing if you can make many kinds of objects - dice, cards, tiles - be pulled into categories so you can build a unified controls prefs page for them.
19:45
< celticminstrel>
Wait, what does that have to do with MAME?
19:45
< Vornucopia>
celticminstrel: no, TF is writing a board game subclient in Lua; I used Go (the game) as an example.
19:46
< celticminstrel>
Oh.
19:46
< celticminstrel>
<_<
19:46
<@ToxicFrog>
Unified controls as in "leftmouse+shift is "pick up" for everything in this category"?
19:46
< Vornucopia>
That sort of thing, yes.
19:47
<@ToxicFrog>
That kind of happens already, since types inherit the bindings from their supertype
19:47
< Vornucopia>
MAME, or at least every one I've tried, makes me mad because it doesn't try to build a unified control scheme -- every game must have its bindings set separately.
19:47
<@ToxicFrog>
So, for example, felt.Token:pickup binds by default to [click_left, click_left_shift], and consequently so do felt.Deck, felt.Die, etc
19:47
< celticminstrel>
Ah.
19:47
<@ToxicFrog>
And changing that binding will change it for all of the subtypes.
19:48
< celticminstrel>
Isn't it kinda difficult for MAME to do that when each game has a different set of bindable events?
19:48
<@ToxicFrog>
celticminstrel: yeah, but the complaint here is that they could still be generally categorized, eg, "movement controls -> wasd"
19:49
< celticminstrel>
I suppose.
19:49
<@ToxicFrog>
And then if a game uses a joystick, it lists its axes under "movement controls" so it gets those bindings by default unless you override them for that specific game.
19:51
<@ToxicFrog>
Hrm. I think splitting it into client code/server code is the right answer; it's tempting to have everything in one, server-side definition, but this damages client flexibility.
19:51
< Vornucopia>
And there's lots and lots of games with very similar controls. Arcade machines didn't really get fancy with that stuff until the 2000s.
19:52
<@ToxicFrog>
And while this means anything you want to play needs to be installed on client as well as on server, that's already the case because the clients need the artwork.
19:53
< Vornucopia>
Which technically you could pull off server-side too, with a pre-game package.
19:53
<@ToxicFrog>
Now I just need to come up with a nice way of organizing all of this. There should be a clear delineation between client and server code, but ideally without needing to manage two seperate source trees.
19:53
<@ToxicFrog>
That has unfortunate implications as soon as you want to play Descent, which has about 500MB of artwork.
19:54
< Vornucopia>
Which would even be Known Safe except for goatsei--shit, seriously?
19:54
< Vornucopia>
What's in there?
19:55
<@ToxicFrog>
Well, there's some amount of duplication in there, and a few high-res images not used by felt, so let's be very optimistic and call it 200MB.
19:56
< Vornucopia>
I mean I could fit, uh, Carcassonne in 30 megabytes of jpg and still use tile images biggerthan your screen.
19:56
<@ToxicFrog>
Well, let's see...several different kinds of dice; large, beefy decks of items, spells, and DM abilities; monster stat cards; cardboard sheets for dungeon terrain; tiles for normal and elite monsters, chests, items, gold, players, traps, etc; the world map;
19:57
<@ToxicFrog>
x four expansion packs
19:57
< Vornucopia>
oh crap.
19:57
<@ToxicFrog>
Descent is probably FFG's biggest game even before you factor in the expansions.
19:57
<@ToxicFrog>
And now, hometime.
19:58
< Vornucopia>
have fun.
20:01
<@McMartin>
Android has fewer expansion packs, but is so huge I've never successfully even set up a game
20:03
< Vornucopia>
Setting up Catan has gotten hard for me lately because I rarely play anything but the base game and that's only half the shit in the box.
20:08
< Vornucopia>
Carcassonne has some damn easy setup.
20:11
< Vornucopia>
(hand out dudes by color. find keystone piece and put it on the table. dump all the other tiles into the box.)
20:14
< Vornucopia>
I think Felt will definitely be particularly useful for those games where there's a lot of random shit going on. Particularly as you can still play the game when you have no - or few - scripts.
20:31 celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20:43
< gnolam>
Ah, legacy artifacts.
20:44
< gnolam>
The various lines of the input files my program should output are referred to as "cards".
20:44
< gnolam>
Why? Because once upon a time, they represented actual physical punch cards...
20:45 * McMartin suggests assigning them all rarities and casting costs.
20:47
< gnolam>
Heh
20:47 Kindamoody|out is now known as Kindamoody
20:58 Vornucopia [NSwebIRC@C888DE.7F9621.E9EB68.432608] has quit [[NS] Quit: Page closed]
21:04
<@ToxicFrog>
VornicusVashicus: "no or few scripts"?
21:30
< Alek>
gnolam: that's what COBOL does. every program line is supposed to be able to fit on a punch card. 80 characters iirc.
21:30
< Alek>
every output line, too.
22:20
< gnolam>
FORTRAN is the same (72 columns wide in FORTRAN 77 - with some additional hideous column restraints).
22:21
< gnolam>
But hey, this program was rewritten in shiny new FORTRAN 77 once, back in 1983...
22:22
< gnolam>
(Some poor sods then had to rewrite it in FORTRAN 90 in 2003)
22:33
<@McMartin>
(Isn't F90 Just Another ALGOL Derivative?)
22:33
<@McMartin>
(Or is that F95?)
22:35
< gnolam>
I don't think so?
22:37
<@McMartin>
Well, not genetically, but I mean, F90 is the one with things like recursive functions and pointer types
22:39 AnnoDomini [annodomini@D553D1.41311B.346302.AC5555] has quit [[NS] Quit: leaving]
23:13 celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has joined #code
23:23 Rhamphoryncus [rhamph@C06FE3.F5723C.BE3FEB.9D4666] has joined #code
23:49 shade_of_cpux is now known as cpux
--- Log closed Thu Mar 24 00:00:11 2011
code logs -> 2011 -> Wed, 23 Mar 2011< code.20110322.log - code.20110324.log >
 search of the:   for: