00:00:00
| * ircretary | quit (Remote host closed the connection) |
00:00:07
| * ircretary | joined |
00:03:11
| * intabulas | joined |
00:17:43
| * defunctzombie | changed nick to defunctzombie_zz |
00:18:25
| * defunctzombie_zz | changed nick to defunctzombie |
00:19:42
| * defunctzombie | changed nick to defunctzombie_zz |
00:34:35
| * defunctzombie_zz | changed nick to defunctzombie |
00:35:00
| * intabulas | quit (Remote host closed the connection) |
00:36:25
| * gwenbell | part |
00:36:57
| <mbalho> | substack: simplex noise with deterministic seeds http://maxogden.github.com/voxel-simplex-terrain/?seed=0.4658187120221555 |
00:38:39
| <mbalho> | substack: i think my math for world width might be off cause its not generating voxels in the entire world AND the api needs a little work (convert to use prototypes) but its cool nonetheless |
00:39:41
| <substack> | mbalho: I see you're inlining explode() https://github.com/maxogden/voxel-simplex-terrain/blob/master/demo.js#L54 |
00:39:53
| <substack> | you can just var explode = require('voxel-debris')(game) now |
00:40:17
| <substack> | then you don't need createDebris() either |
00:41:25
| <substack> | oh and voxel-debris does the setBlock() call so you only need to if (erase) explode(pos) |
00:47:30
| * st_luke | joined |
00:57:07
| * nk109 | quit (Quit: Computer has gone to sleep.) |
00:59:38
| * defunctzombie | changed nick to defunctzombie_zz |
01:01:29
| * defunctzombie_zz | changed nick to defunctzombie |
01:09:44
| * defunctzombie | changed nick to defunctzombie_zz |
01:19:14
| * mikeal | quit (Quit: Leaving.) |
01:29:09
| * defunctzombie_zz | changed nick to defunctzombie |
01:32:26
| <jez0990_> | mbalho: I was just playing around with the collision detection... trying to figure out if I can make voxelAtPosition return the voxel coordinates instead of just a boolean that way you potentially (or at least I'm hoping) don't have to mess around with velocities and can just set the yawObject to just on/outside the voxel's boundaries and the velocities to 0 |
01:32:35
| <jez0990_> | if that makes sense?! |
01:33:25
| <jez0990_> | but anyway, I just looked at chunker.js and it looks like a bit of effort to work it out, so I'm giving up for tonight :P |
01:38:44
| * gwenbell_ | quit (Read error: Connection reset by peer) |
01:42:28
| * AndChat648704 | joined |
01:49:26
| * mikeal | joined |
01:58:53
| * intabulas | joined |
01:59:57
| * mikeal | quit (Ping timeout: 255 seconds) |
02:02:26
| * intabulas | quit (Remote host closed the connection) |
02:07:03
| * intabulas | joined |
02:07:04
| * intabulas | quit (Remote host closed the connection) |
02:07:50
| * defunctzombie | changed nick to defunctzombie_zz |
02:20:02
| * dominictarr | joined |
02:20:06
| <dominictarr> | substack: mbalho chrisdickinson it possible to use a animated GIF as a texture in webGl? |
02:25:39
| * mikeal | joined |
02:25:59
| <substack> | dominictarr: testing |
02:26:41
| <dominictarr> | I'm thinking 3d html |
02:26:49
| <dominictarr> | 3d 90's html |
02:27:02
| <dominictarr> | where each page is a room |
02:27:07
| <substack> | or an in-game web browser |
02:27:12
| <dominictarr> | and then links are portals to other rooms |
02:27:15
| <substack> | hah |
02:27:27
| <dominictarr> | HOW THE WEB SHOULD HAVE BEEN! |
02:27:27
| <LOUDBOT> | SCREEEAAAAM FOR YOUR CREEEEAAM |
02:32:47
| <substack> | dominictarr: it appears that animated gifs don't work out of the box |
02:32:52
| <AndChat648704> | dominictarr: (this is jez0990 under a cryptic pseudonym) three.js css3d renderer composited with webgl in the background is the answer. I'm building something like that right now :) |
02:33:27
| <dominictarr> | css3d? |
02:33:49
| <AndChat648704> | check out mrdoob's periodic table demo |
02:35:03
| <dominictarr> | will do |
02:44:10
| * tilgovi | joined |
03:00:49
| * st_luke | quit (Remote host closed the connection) |
03:16:36
| * tilgovi | quit (Remote host closed the connection) |
03:21:44
| <mbalho> | dominictarr: there is a css renderer that does animated gifs but gpus dont support them natively and the css renderer wouldnt work with our voxel enging right now |
03:24:53
| <mbalho> | jez0990_: check out Chunker.prototype.voxelVector, it converts screen coords to voxel coords |
03:25:31
| * dominictarr_ | joined |
03:26:19
| <mbalho> | jez0990_: (relative to the current chunk) |
03:26:26
| * dominictarr | quit (Ping timeout: 255 seconds) |
03:26:27
| * dominictarr_ | changed nick to dominictarr |
03:32:41
| * tilgovi | joined |
03:47:53
| <mbalho> | substack: smooth world http://maxogden.github.com/voxel-simplex-terrain/?seed=01388834234 |
03:48:05
| <mbalho> | substack: (chunk distance of 3 so the world takes a little longer to build) |
03:48:35
| <mbalho> | substack: same world with rocks http://maxogden.github.com/voxel-simplex-terrain/?seed=21388834234 |
03:48:57
| <mbalho> | substack: same world with pillars http://maxogden.github.com/voxel-simplex-terrain/?seed=61388834234 |
03:49:18
| <mbalho> | (reverse engineering this demo http://29a.ch/sandbox/2012/voxelworld) |
04:08:57
| * dominictarr | quit (Quit: dominictarr) |
04:31:06
| * tphummel | quit (Quit: tphummel) |
04:42:13
| <chrisdickinson> | mbalho: you'd probably have to resend the gif each frame. |
04:42:13
| <chrisdickinson> | but you can definitely use a video element as a texture source, just like you'd use an image |
04:42:16
| <chrisdickinson> | (again, you have to resend it each frame) |
04:58:46
| <mbalho> | chrisdickinson: oooh ye agood point |
05:02:37
| <Raynos> | blargh |
05:02:59
| * dominictarr | joined |
05:03:04
| * ITpro | quit |
05:07:00
| * shuaib | quit (Ping timeout: 248 seconds) |
05:15:26
| <mbalho> | substack: paste this into the console of a running voxel game https://gist.github.com/4499643 |
05:40:15
| <mbalho> | chrisdickinson: in node if you do require('interact') it throws ReferenceError: document is not defined |
05:42:34
| <mbalho> | chrisdickinson: in interact/node_modules/drag-stream/node_modules/domnode-dom/lib/readable.js |
05:43:55
| <mbalho> | chrisdickinson: i am not trying to use it in node i just want to be able to require it without it breaking |
06:05:45
| <Raynos> | Weekend project idea! |
06:06:03
| <Raynos> | Build a custom distributed db on top of leveldb & map-reduce |
06:06:14
| <Raynos> | i wants to build one |
06:07:10
| <chrisdickinson> | mbalho: that's domnode-dom |
06:08:47
| <chrisdickinson> | fixing |
06:10:40
| <chrisdickinson> | mbalho: published a fix to domnode-dom; fresh installs of interact will pick up that fix |
06:14:16
| <chrisdickinson> | also, question: would you prefer a polling api for "actions" (via the keyboard) or a streaming api? |
06:14:39
| <chrisdickinson> | or does this exist? |
06:15:31
| <Raynos> | chrisdickinson: what do you mean? |
06:15:48
| <chrisdickinson> | so, ideally there's a disconnect between "keyup / keydown" and "game action" |
06:15:53
| <chrisdickinson> | so you can rebind keys to different actions |
06:16:47
| <chrisdickinson> | so there should be an api where you can set key -> action bindings, and when those keys go up or down you get events if that key is bound to an action |
06:16:48
| <Raynos> | ok so whats an action? |
06:17:01
| <chrisdickinson> | "walk forward", "turn right", "sidestep right" |
06:17:04
| <chrisdickinson> | for example. |
06:17:51
| <Raynos> | well theres two types of action inputs based on keyboard |
06:17:56
| <Raynos> | boolean and event |
06:18:12
| <chrisdickinson> | hm? |
06:18:17
| <Raynos> | like crawling for example |
06:18:25
| <Raynos> | can be set to true if ctrl is held |
06:18:32
| <Raynos> | and then set to false if its released |
06:18:44
| <Raynos> | or it can be toggled between true / false when capslock is pressed |
06:18:47
| <chrisdickinson> | ah |
06:18:49
| <Raynos> | where as move forward |
06:18:58
| <Raynos> | is a series of move forward events |
06:19:12
| <chrisdickinson> | well, no, move forward would be more of a "wantstomoveforward = true" |
06:19:16
| <chrisdickinson> | but i see what you're saying |
06:19:26
| <Raynos> | i dont think like that |
06:19:27
| <chrisdickinson> | like, "switch weapon" for example would be a "tap" |
06:19:32
| <Raynos> | I think moving forward is a series of events |
06:19:36
| <Raynos> | jumping is also a series of events |
06:19:44
| <Raynos> | even though jumps are triggered on keydown instead of keypress |
06:19:59
| <chrisdickinson> | the controller shouldn't be the mediator of the object physics, though. |
06:20:13
| <Raynos> | doesnt matter |
06:20:21
| <Raynos> | im not saying it is |
06:20:34
| <Raynos> | if you want to translate move forward into whilst held apply delta x at 60 fps |
06:20:52
| <Raynos> | then just sample the events at 60 fps and map to delta |
06:21:01
| <chrisdickinson> | but you don't know your fps. |
06:21:04
| <chrisdickinson> | necessarily. |
06:21:08
| <Raynos> | doesnt matter |
06:21:10
| <mbalho> | chrisdickinson: one one hand i like an api like this https://github.com/madrobby/keymaster |
06:21:15
| <Raynos> | im saying that its out of scope |
06:21:24
| <Raynos> | all your action api should provide |
06:21:25
| <mbalho> | key('ctrl+r', function() |
06:21:31
| <Raynos> | is a representation of boolean state |
06:21:38
| <Raynos> | and a representation of streaming events |
06:21:49
| <mbalho> | chrisdickinson: but i also want keyboard.on('w', moveForward) |
06:21:49
| <Raynos> | thats how i would think of it |
06:22:11
| <mbalho> | chrisdickinson: or keyboard.createReadStream('w').pipe(controls.forward) |
06:22:29
| <mbalho> | chrisdickinson: jsut an event emitter is fine i think |
06:22:39
| <mbalho> | chrisdickinson: since keyboard events dont really end |
06:22:46
| <mbalho> | chrisdickinson: or begin. they are momentary |
06:22:53
| <mbalho> | #metaphysicalstatements |
06:23:12
| <chrisdickinson> | haha |
06:23:13
| <Raynos> | var move = action({ type: "event", key: "w" }) |
06:23:26
| <chrisdickinson> | well, they do and don't -- "held" vs. "tapped" -- switch weapon could be a tap |
06:23:48
| <Raynos> | var jumps = action({ key: "space", type: "tapped" }) |
06:23:53
| <chrisdickinson> | you don't want to bind actions tightly to keys |
06:24:04
| <chrisdickinson> | because of things like, well, what if someone wants to rebind keys? or what if someone has a gamepad? |
06:24:07
| <Raynos> | var crouched = action({ key: "ctrl", type: "held" }) |
06:24:21
| <Raynos> | chrisdickinson: then allow it to change |
06:24:29
| <Raynos> | key: key |
06:24:33
| <Raynos> | or key: [...] |
06:25:03
| <Raynos> | map(sample(move, 60), function () { return { x: 1 } }) |
06:25:42
| <Raynos> | jumps are special because you want to disallow jumps from occurring until the last jump finished |
06:25:44
| <mbalho> | ooh for the action() thing in raynos' example that would be a good plac to use a stream |
06:25:55
| <Raynos> | mbalho: you mean gozala/reducers |
06:26:38
| <Raynos> | fold(jumps, function () { return jump(...); /* apply backpressure */ }) |
06:26:43
| <mbalho> | keyboard.on({ key: "ctrl", type: "}, function(stream) { game.emit('crouch', stream) }) |
06:27:02
| <Raynos> | you do actually want a stream for jumps |
06:27:13
| <Raynos> | so that the jump logic can emit("drain") when the jump finishes |
06:27:29
| <Raynos> | or you use some other construct with well defined back pressure |
06:28:08
| <mbalho> | chrisdickinson: so i guess for actions with beginnings and endings (like holding down a modifier key) a stream would be useful |
06:28:17
| <mbalho> | chrisdickinson: otherwise just an event emitter is good |
06:28:37
| <mbalho> | chrisdickinson: though streams around modifier keys might be overengineering |
06:28:50
| <Raynos> | well you want backpressure! |
06:29:05
| <Raynos> | or is backpressure not a good way to model disallowing double jumping |
06:29:11
| <mbalho> | function ctrlToggle (ev) { erase = !ev.ctrlKey }; window.addEventListener('keyup', ctrlToggle); window.addEventListener('keydown', ctrlToggle) |
06:29:15
| * chrisdickinson | writes a lil' api.. |
06:29:18
| <mbalho> | that is what we use right now in voxel games |
06:29:38
| <mbalho> | then you put an if statement in your click handler |
06:29:41
| <mbalho> | that checks if it should erase or not |
06:29:43
| <chrisdickinson> | Raynos: backpressure might be good there. |
06:29:44
| <mbalho> | nice and simple |
06:29:45
| * mikeal | quit (Quit: Leaving.) |
06:29:50
| <mbalho> | (cant get much simpler) |
06:30:11
| <Raynos> | but its stateful! |
06:30:17
| <Raynos> | The lisp demons will consume you |
06:30:30
| <mbalho> | everything is a nail |
06:31:12
| * mikeal | joined |
06:34:45
| <mbalho> | chrisdickinson: woot now voxel-server runs voxel-engine in node and generates the voxel terrain from a seed and then when clients connect they get sent game config including the seed and generate the exact same world |
06:34:55
| <chrisdickinson> | woo |
06:35:22
| <mbalho> | now im gonna use scuttlebutt to sync edits |
06:43:36
| <chrisdickinson> | hmm, hm, hm |
06:43:36
| <chrisdickinson> | https://gist.github.com/0c57ff97169fdf630980 |
06:44:28
| <chrisdickinson> | yeah, that's not good at all |
06:44:38
| <chrisdickinson> | there are some bits i like, but it's a little.. heavy |
06:45:19
| <chrisdickinson> | i definitely want actions to be streaming, so that you can pipe 'em to a replay file or database |
06:46:35
| <chrisdickinson> | but you really can't deal with the actions as they come in as events, since you need to mediate them with the time delta between frames |
06:46:53
| <chrisdickinson> | (or else players with faster computers go faster, players with slower computers go slower, or problems like that.) |
06:47:35
| <chrisdickinson> | though for some events (like switch weapon) you don't care about dt -- it's completely instantaneous |
06:50:54
| * owen1 | quit (Ping timeout: 255 seconds) |
06:57:49
| <Raynos> | that api is strange |
06:59:35
| * st_luke | joined |
07:04:12
| * owen1 | joined |
07:16:45
| * tilgovi | quit (Read error: Connection reset by peer) |
07:27:37
| <gozala> | Raynos: mbalho backpressure for user event streams is stupid |
07:27:56
| <gozala> | user creates events weather you're ready to handle it or not |
07:28:22
| <gozala> | so trying to back pressure mouse events or keyboard events make no sense |
07:28:54
| <gozala> | you should either skip if not ready to handle or queue and handle once ready |
07:28:56
| <dominictarr> | gozala: need a thing to give the user a electric shock, so they slow down |
07:29:16
| <gozala> | or yeah what dominictarr suggested :) |
07:29:18
| <dominictarr> | or you could just respond slower visually… that would probably slow them down |
07:29:26
| <gozala> | write proposal to w3c :) |
07:29:49
| <gozala> | so browsers implement, meanwhile we can polyfill |
07:30:01
| <dominictarr> | and lobby for a law that all computers have a kibble dispensor |
07:30:06
| <gozala> | dominictarr: that's queueing |
07:30:34
| <dominictarr> | then you have both positive and negative feedback |
07:32:27
| <Raynos> | gozala: it's not stupid |
07:32:39
| <Raynos> | gozala: it's just a convenient way to say "drop this data until im ready" |
07:32:58
| <Raynos> | I meant I want a way to skip |
07:33:01
| <Raynos> | how would you skip? |
07:33:02
| <gozala> | Then just say that instead |
07:33:31
| <gozala> | takeWhen(events, behaviour) |
07:33:44
| <gozala> | behaviour is stream representing state |
07:33:51
| <gozala> | weather events are taken or not |
07:33:53
| <Raynos> | how do you do that in non stateful fashion :p |
07:34:14
| <Raynos> | i guess it doesnt matter |
07:35:07
| <Raynos> | the point is consumer of spaces (jump logic) needs to tell stream someone to drop space messages |
07:36:07
| <gozala> | You basically end up with state machine |
07:36:33
| <gozala> | and have jumpable state |
07:36:41
| <gozala> | when in that state then you get jump events |
07:36:55
| <gozala> | I wrote these functions |
07:37:07
| <gozala> | forgot the name of lib :( |
07:37:48
| <gozala> | Raynos: here https://github.com/Gozala/transducer |
07:37:58
| <gozala> | Also take a look at http://elm-lang.org/ |
07:38:05
| <gozala> | that's exactly what it does |
07:38:20
| <gozala> | http://elm-lang.org/blog/games-in-elm/part-0/Making-Pong.html |
07:39:49
| <gozala> | That post describes very well streaming state machine |
07:40:02
| <gozala> | and how different inputs combined |
07:41:04
| * dominictarr | quit (Quit: dominictarr) |
07:41:47
| <gozala> | Trying to represent all of that via backpressure will just make things less obvious |
07:42:07
| <gozala> | IMO anyway |
07:44:03
| <gozala> | Raynos: so for example you will have signal jumping |
07:44:26
| <gozala> | which yields true on jumps and false once jump is finished |
07:44:50
| <gozala> | then you get jump events you need to react as |
07:45:58
| <gozala> | jumpEvents = takeWhen(jumpKey, complement(jumping)) |
07:49:24
| <Raynos> | complement? |
07:52:39
| * dguttman | quit (Quit: dguttman) |
07:57:54
| <Raynos> | rvagg: have you read chromium indexeddb implementation? |
08:16:27
| * AvianFlu | quit (Remote host closed the connection) |
08:34:18
| * No9 | joined |
08:44:18
| <mbalho> | prototypes aren't hoisted! |
08:58:53
| <niftylettuce> | anyone here from austin, tx? |
09:04:39
| * dominictarr | joined |
09:27:57
| * st_luke | quit (Remote host closed the connection) |
09:46:29
| * jibay | joined |
10:05:12
| <dominictarr> | heh, scuttlebutt is on the front page of google results for "scuttlebutt" |
10:05:24
| <dominictarr> | as well as a bunch of sailing stuff |
10:53:05
| * fotoverite_ | joined |
10:54:11
| * fotoverite | quit (Ping timeout: 255 seconds) |
10:54:11
| * fotoverite_ | changed nick to fotoverite |
12:09:48
| * shuaib | joined |
12:21:19
| * jibay | quit (Quit: Leaving) |
12:24:31
| * dominictarr | quit (Quit: dominictarr) |
12:28:23
| * dominictarr | joined |
13:21:29
| * AndChat|648704 | joined |
13:21:36
| * AndChat648704 | quit (Read error: Connection reset by peer) |
13:21:57
| * AndChat648704 | joined |
13:25:34
| * AndChat|648704 | quit (Ping timeout: 240 seconds) |
13:55:34
| * No9 | quit (Ping timeout: 240 seconds) |
13:57:53
| * No9 | joined |
13:58:34
| <dominictarr> | Raynos: ping? |
14:26:08
| * No9 | quit (Ping timeout: 255 seconds) |
14:27:47
| * No9 | joined |
14:46:11
| <dominictarr> | Raynos: sockjs-stream doesn't work for me from the server with reconnect … that is what it's for, right? |
14:53:29
| <ralphtheninja> | http://www.youtube.com/watch?v=-RMOGFaOLSQ&feature=related |
15:03:43
| <dominictarr> | the universe is obviously _at least_ a computer |
15:03:52
| <dominictarr> | look at how a computer works, |
15:04:24
| <dominictarr> | a computer is a logical machine that is sufficiently complicated that you can use it to simulate a computer. |
15:04:57
| <dominictarr> | their is a ceiling on complexity, it's either a computer or less that a computer |
15:05:27
| <substack> | fallacy of composition? |
15:05:37
| <dominictarr> | take a computer, you can simulate another computer on it, then simulate another computer on that computer, etc etc |
15:05:48
| <dominictarr> | computers all the way in |
15:06:02
| <dominictarr> | VMs running inside VMs, |
15:06:49
| <dominictarr> | so, if you can build a computer it in, the universe must be _at least_ a computer |
15:07:22
| <dominictarr> | whether it's somehow more than a computer, superturing, that is another question. |
15:07:54
| <pkrumins> | what are you smoking |
15:07:57
| <substack> | s/computer/widget/ |
15:08:04
| <substack> | and it still holds |
15:08:21
| <substack> | or bread |
15:08:59
| <substack> | if you can bake bread in a universe the universe must be at least bread! |
15:10:06
| <guybrush_> | or a bread oven |
15:10:28
| <dominictarr> | no, but you can't simulate bread inside a bread |
15:10:48
| <substack> | still, it seems somewhat suspect when computer programmers go around saying that the universe is akin to a giant computer |
15:10:59
| <dominictarr> | you can't use a bread to calculate how any other possible bread would respond |
15:12:00
| <guybrush_> | though i would rather use "machine" than "computer" |
15:12:26
| <dominictarr> | a computer is just a special class of machine |
15:12:33
| <dominictarr> | an information machine |
15:13:12
| <guybrush_> | it cant be that everything is virtual, there has to be a beginning! |
15:13:57
| <substack> | why? |
15:14:14
| <guybrush_> | im not sure actually now that i think about it |
15:14:17
| <substack> | our intuitions about what should or shouldn't be the case are suspect |
15:14:52
| <substack> | they were built by evolution to deal with medium-scale local phenomena |
15:15:14
| <guybrush_> | its hard to think about anything without a beginning |
15:15:53
| <guybrush_> | "it just exists", doesnt work for me |
15:15:55
| <dominictarr> | guybrush_: well, you get to a bit outside what we can ever reason about, because it's impossible to gather information |
15:16:08
| <dominictarr> | imagine if you lived inside one of our computers... |
15:16:13
| <substack> | being hard to think about doesn't preclude something from being false |
15:16:15
| <dominictarr> | could you learn about RAM |
15:16:17
| <guybrush_> | in the matrix! |
15:16:21
| <substack> | s/false/true/ |
15:16:29
| <dominictarr> | or L1, L2 caches? |
15:16:43
| <dominictarr> | you might be able to discover that experimentally |
15:16:47
| <guybrush_> | right substack but than it wouldnt make sense to argue about anything |
15:17:28
| <dominictarr> | the point of calling the universe a computer, is that it's a model |
15:17:34
| <substack> | I'm not making an argument for sophistry |
15:17:50
| <substack> | dominictarr: I prefer to classify that as a metaphorical tool |
15:18:03
| <substack> | it gives us the language to frame our thinking |
15:18:07
| <dominictarr> | it's not the "truth" it's just about an idea and how well it fits evidence |
15:18:17
| <dominictarr> | yes, that is all we have |
15:18:30
| <substack> | but you've got to be careful not to ascribe attributes falsely |
15:18:56
| <substack> | like for instance we build machines and computers but it would be a mistake to ascribe teleology |
15:19:04
| <substack> | to the universe at large |
15:20:13
| <guybrush_> | i have to google teleology |
15:20:14
| <dominictarr> | people think of computers as electronic devices |
15:20:22
| <dominictarr> | but that is incorrect. |
15:20:31
| <dominictarr> | a computer is a logical construct. |
15:21:03
| <dominictarr> | a set of constructs, rather |
15:22:03
| <guybrush_> | i like to think that its more like chaos, i mean everything in the universe we live in is just chaos |
15:22:10
| <guybrush_> | not logic |
15:22:47
| <dominictarr> | ah, but chaos is actually a logical (mathematical) construct too! |
15:22:59
| <guybrush_> | ha |
15:23:02
| <dominictarr> | guybrush_: have you heard about how they discovered chaos? |
15:23:18
| <guybrush_> | no but i am interested |
15:23:39
| <guybrush_> | who discovered chaos haha |
15:23:53
| <dominictarr> | Edward Lorentz |
15:24:11
| <dominictarr> | " In 1961, Edward Lorentz discovered the butterfly effect while trying to forecast the weather. He was running a long series of computations on a computer when he decided he needed another run. Rather than do the entire run again, he decided to save some time by typing in some numbers from a previous run. Later, when he looked over the printout, he found an entirely new set of results. The results should have been the same as before. After thinking |
15:24:11
| <dominictarr> | about this unexpected result, he discovered that the numbers he typed in had been slightly rounded off." |
15:25:00
| <dominictarr> | the thing with chaos is that a very small change in initial conditions creates large scale changes after a sufficient period |
15:25:22
| <dominictarr> | http://www.schuelers.com/ChaosPsyche/part_1_3.htm |
15:26:00
| <guybrush_> | why the hell is it edward lorenz without "t" on wikipedia |
15:26:43
| <guybrush_> | anyway interesting stuff |
15:27:34
| <dominictarr> | yes, incidentally, turns out humans needed computers to discover chaos theory. |
15:28:00
| * AvianFlu | joined |
15:29:30
| <dominictarr> | gtg. catch you dudes later. |
15:29:32
| * dominictarr | quit (Quit: dominictarr) |
15:31:29
| <ralphtheninja> | chaos is also related to things not being determenistic |
15:31:52
| <guybrush_> | quantum computers! |
15:31:53
| <ralphtheninja> | deterministic* |
15:32:26
| <ralphtheninja> | I agree that the universe must be at least a computer |
15:33:06
| <guybrush_> | it depends on the definition of "computer" :D |
15:33:12
| <ralphtheninja> | at least a turing machine is a more appropriate description :) |
15:37:03
| <pkrumins> | universe is just a regular expression |
15:41:22
| * jibay | joined |
16:31:45
| <isaacs> | anyone in here use websockets for stuff? (and not socketio) |
16:31:50
| <isaacs> | Raynos, substack ^? |
16:31:54
| <isaacs> | mbalho: ^? |
16:41:15
| * substack | does |
16:41:39
| <substack> | by way of shoe which uses sockjs |
16:44:21
| <isaacs> | substack: so.. when you get the upgrade event, it just grabs the actual TCP socket and uses that, right? |
16:44:44
| <substack> | I think so |
16:45:49
| <substack> | are you poking at new http api ideas? |
16:46:29
| <substack> | ideal websockets api: if (req.headers.upgrade) req.pipe(myStream).pipe(res) |
16:46:50
| <substack> | where `myStream` would handle the decoding or whichever |
16:47:17
| * mikeal | quit (Quit: Leaving.) |
16:54:38
| <isaacs> | substack: not quite yet. |
16:54:45
| <isaacs> | i'm poking at not breaking the existing http api |
16:54:53
| <isaacs> | which i'm pretty sure i did in 0.9 with streams2 |
16:54:56
| <isaacs> | but i'd like to fix |
16:56:11
| <isaacs> | ralphtheninja: actually, the butterfly effect that Lorentz talked about *depended on* the universe being deterministic |
16:56:32
| <isaacs> | ralphtheninja: without being deterministic, there's no "sensitive dependence on initial conditions", because there's no "dependence on initial conditions" |
17:01:46
| * tilgovi | joined |
17:02:02
| * saijanai_ | joined |
17:02:57
| * shuaib | quit (Ping timeout: 276 seconds) |
17:08:26
| * sorensen_ | joined |
17:10:33
| * mikeal | joined |
17:15:50
| * yorick | joined |
17:17:49
| * dguttman | joined |
17:26:29
| * No9 | quit (Ping timeout: 244 seconds) |
17:27:54
| * No9 | joined |
17:28:47
| * jibay | quit (Remote host closed the connection) |
17:36:36
| <Raynos> | isaacs: I use sockjs / engine.io |
17:48:37
| <ralphtheninja> | isaacs: ok, so the chaos is generated by a deterministic universe |
17:49:17
| * dominictarr | joined |
17:50:12
| <ralphtheninja> | it makes sense, just like cellular automatas can generate seemingly chaotic behavior |
18:01:59
| * AndChat648704 | quit (*.net *.split) |
18:01:59
| * owen1 | quit (*.net *.split) |
18:02:27
| * AndChat648704 | joined |
18:02:42
| * owen1 | joined |
18:03:16
| * shuaib_ | joined |
18:04:38
| * st_luke | joined |
18:04:55
| * shuaib_ | changed nick to shuaib |
18:06:25
| * tilgovi | quit (Remote host closed the connection) |
18:10:38
| * dominictarr | quit (Quit: dominictarr) |
18:16:36
| <isaacs> | ralphtheninja: of course, strict "determinism" is not necessarily for observable deterministic effects. only a certain level of statistical predictability. |
18:17:11
| <isaacs> | but SDIC depends on some dependence on initial conditions. truly random systems don't exhibit SDIC |
18:20:34
| <mbalho> | isaacs: i agree that the ideal websockets api is if (req.headers.upgrade) req.pipe(myStream).pipe(res) |
18:20:49
| <CoverSlide> | unfortunately a computer can only make measurements in integral units, and non-integral measurements are merely emulated. This goes for both spatial and temporal measurements. As of right now, we know of no distinct atomic unit of time or space, so most likely the universe in not a computer |
18:21:18
| <mbalho> | isaacs: i use the ws module for hosting websocket connections e.g. https://github.com/maxogden/voxel-server/blob/master/server.js#L35-L36 |
18:21:52
| <mbalho> | isaacs: but it would be way awesome if there was a good way to attach a websocket server to an existing http server e.g. what substack suggested |
18:22:13
| <mbalho> | isaacs: cause right now you have to remove all listeners and then add them to your own proxy, effectively monkeypatching an existing server |
18:23:25
| <substack> | please break backwards compat on that |
18:23:48
| <substack> | the way core http works now is encouraging so many painful interfaces |
18:24:32
| <CoverSlide> | remove http from core |
18:25:00
| <CoverSlide> | needs to be done at some point |
18:38:05
| <isaacs> | substack: we wont' break back compat in 0.10. but we will in 0.12, probably |
18:38:17
| <isaacs> | substack: especially if loudmouth community people call for that breakage. |
18:38:37
| <isaacs> | substack: (ie, you, mbalho, Raynos, etc. be loudmouths. call for breakage.) |
18:39:49
| <fotoverite> | isaacs: true, a random system could look totally deterministic though. :P It's just randomly doing that. |
19:02:08
| * wiwillia | joined |
19:02:56
| <wiwillia> | Hey pkrumins, any chance you have experience with Amazon s3? |
19:04:48
| <CoverSlide> | with enough variables, anything can look random |
19:05:52
| <CoverSlide> | a coin flip is deterministic, based on weight of the coin, force and aposition of the thumb, the placement of air molecules, the properties of the surface it lands on. the variables are immeasurable |
19:06:04
| <CoverSlide> | random is just another word for "too many variables" |
19:09:22
| <mbalho> | isaacs: in my defense im not a loudmouth usually |
19:09:39
| <mbalho> | mbalho: i usually dont care either way but the http websocket thing is just ugly |
19:12:54
| <fotoverite> | mbalho: Loudmouth no but you are opinionated |
19:14:54
| * dguttman | quit (Quit: dguttman) |
19:18:49
| <mbalho> | fotoverite: i am but a humble member of the Church Of Node Core |
19:20:47
| <fotoverite> | I don't think I can make nodeconf this year, :( |
19:20:51
| <fotoverite> | guess summer camp. |
19:21:13
| <fotoverite> | people are doing good work for nodepdx |
19:23:44
| <ralphtheninja> | CoverSlide: agree, but you don't necessarily need many variables or complex algorithms to create a random behavior |
19:24:07
| <CoverSlide> | in other words, pseudo-randomness |
19:24:50
| * tilgovi | joined |
19:27:07
| <ralphtheninja> | yeah I guess |
19:29:34
| <ralphtheninja> | the process of flipping a coin might have many variables, but even that is pseudo random in that case .. just have more variables |
19:31:37
| <ralphtheninja> | which in turn means that 100% randomness can never be achieved .. it's just different orders of complexity .. different degrees of randomness .. or? |
19:32:10
| <isaacs> | CoverSlide: "random" literally means "impossible to predict" |
19:32:15
| <isaacs> | not "without a cause" |
19:32:48
| <isaacs> | the difference between "pseudorandom" and "random" in computer lingo is that, if you know the seed, you CAN predict pseudorandom variables. |
19:33:01
| <ralphtheninja> | check |
19:33:03
| <isaacs> | (er, know the seed and the algo) |
19:33:20
| <isaacs> | random = pseudorandom algo seeded with machine entropy |
19:33:32
| <isaacs> | mouse movement, etc. |
19:33:45
| <ralphtheninja> | which is the same thing as a cellular automata .. you can reproduce the output 100% every time .. but the patterns might still be seemingly random |
19:33:47
| <isaacs> | fan speeds, CPU heat, other things that are hard to guess |
19:33:53
| <isaacs> | right |
19:34:07
| <CoverSlide> | which brings to mind this article which surfaced on reddit recently: http://www.empiricalzeal.com/2012/12/21/what-does-randomness-look-like/ |
19:34:29
| <ralphtheninja> | a night of randomness :) |
19:34:31
| <CoverSlide> | Which talks about Poisson distributions |
19:34:53
| <isaacs> | unless you reject the many-worlds interpretation (which is silly to do) there's nothing that is so random as to be causally disconnected from a prior state. |
19:35:06
| <isaacs> | but it IS random (as in, unpredictable) which universe you'll end up in sometimes. |
19:36:24
| <rowbit> | SubStack, pkrumins: At least 5 people waiting in the queue for free servers! (Waiting: 15) |
19:38:33
| <CoverSlide> | free servers? |
19:44:56
| * dguttman | joined |
19:46:50
| <Raynos> | isaacs: what are we breaking? |
19:47:33
| <CoverSlide> | http |
19:51:07
| * sorensen_ | quit (Quit: Bye!) |
19:53:00
| <mbalho> | CoverSlide: speaking or PRNGs i use your alea module to seed this http://maxogden.github.com/voxel-simplex-terrain/?seed=mattdamon |
19:53:29
| <CoverSlide> | awesome |
19:53:57
| <st_luke> | substack: I would argue that most caching in web apps nowadays isn't for saving bandwidth but for reducing db queries |
19:54:04
| <st_luke> | just from what I've experienced in my tenure in the hosting industry |
19:54:42
| <CoverSlide> | yeah the algo isn't mine, but I added some stuff specifically for syncing between client and server |
19:54:58
| <substack> | https://github.com/substack/gray-code |
19:55:01
| <CoverSlide> | haven't used it for anything as of yet |
19:55:19
| <substack> | isaacs: sooner or later every algorithm with a wikipedia entry will have its own npm module |
19:55:20
| <mbalho> | substack: wat |
19:55:27
| <CoverSlide> | haha |
19:55:33
| <mbalho> | CoverSlide: i found it in github.com/jwagner/voxelworlds/ actually |
19:56:24
| <mbalho> | isaacs: also every algorithm on npm will be able to be visualized in voxels |
19:56:45
| <mbalho> | substack: spun this out https://github.com/maxogden/player-physics |
19:56:48
| <substack> | mbalho: oh the default with voxel-debris is 1, more impressive when it's >= 4 |
19:57:16
| <substack> | yield that is |
19:57:53
| <substack> | var explode = require('voxel-debris')({ yield: function () { return 4 } }) |
19:58:02
| <substack> | var explode = require('voxel-debris')(game, { yield: function () { return 4 } }) |
19:58:26
| <mbalho> | sweet |
20:01:08
| <mbalho> | substack: pushed 0.2.1 of voxel-engine -- has some potentially breaking internal apis |
20:01:58
| <mbalho> | substack: basically ive been moving all dom + rendering code into functions and all the state and physics into other functions so the engine can run in node and compute physics without rendering anything to the screen |
20:02:04
| <mbalho> | substack: but i think thats done now |
20:02:49
| <substack> | sweet! |
20:03:30
| <substack> | although everything should be able to run entirely in the browser too |
20:03:56
| <mbalho> | yes |
20:03:56
| <substack> | but the freedom to move the computation around is certainly a plus |
20:04:33
| <substack> | we can test all that code independently too |
20:04:56
| <mbalho> | substack: last night i got my multiplayer server to run the engine and generate voxels in memory from a seed and then when clients join they get the game config sent to them and they generate the same base world |
20:07:55
| <CoverSlide> | that's awesome, no need to send the full world data over the wire |
20:08:17
| <mbalho> | CoverSlide: yea and then i just have to sync edits which is a few lines thanks to scuttlebutt |
20:08:28
| <mbalho> | CoverSlide: hard part is what im about to dive into which is syncing the game loop on both sides |
20:12:43
| <substack> | mbalho: will I be able to game.createStream() ? |
20:17:32
| <mbalho> | substack: what would it be a stream of |
20:18:31
| <CoverSlide> | state modifying events? |
20:20:13
| <substack> | mbalho: a serialization of the game update data that the other clients will need in order to synchronize the game state |
20:22:26
| <Raynos> | substack: it might be cleaner to have state seperate from game |
20:22:43
| <Raynos> | otherwise game object becomes god object |
20:23:05
| <Raynos> | game(state); stream.pipe(state.createStream()).pipe(stream) |
20:23:21
| <substack> | game can just make a state object itself |
20:23:52
| <substack> | the game has state already that would need to be serialized |
20:35:18
| * shuaib | quit (Quit: Textual IRC Client: http://www.textualapp.com/) |
20:45:45
| <mbalho> | substack: eventually yes i would like the game to be a stream |
21:00:44
| <jez0990_> | on the topic of serialisation - is mux-demuxing other mux-demux streams (potentially recursively) likely to have any limitations? |
21:03:03
| <hij1nx> | oh man, there's nothing interesting going on in the node room anymore... |
21:12:38
| <substack> | it's just a help channel |
21:14:33
| <CoverSlide> | time to move on to something else |
21:14:36
| <CoverSlide> | go here i come |
21:16:00
| <fotoverite> | Isn't that why we all stay in stackvm? |
21:18:08
| <CoverSlide> | #Node.js - newbie room #libuv - node dev room #stackvm - cool hacker room |
21:19:39
| <chrisdickinson> | cool guy shades are handed out at the door. |
21:29:29
| <isaacs> | mbalho, substack: Yes! put every algorithm in npm! visualize every npm in voxels! put every voxel visualization algo in npm and visialize in voxels! yo dawg!! |
21:32:11
| * dguttman | quit (Quit: dguttman) |
21:35:09
| * AndChat648704 | quit (Read error: Connection reset by peer) |
21:47:11
| <Raynos> | jez0990_: its inefficient |
21:50:23
| * jibay | joined |
21:51:29
| <mbalho> | substack: do you have an illustrated self portait or do you prefer http://substack.net/images/substack_240.png |
21:52:03
| <mbalho> | substack: also you should render this in voxel http://substack.net/images/substack_pixel.svg |
21:52:10
| <CoverSlide> | That looks like professional photography to me |
21:52:34
| <jez0990_> | Raynos: definitely agree with that sentiment, but I don't think there's any alternative. The module will have one of the mux streams being a control/registry stream that defines new demux streams to watch out for as they're generated |
21:52:36
| <substack> | mbalho: I like the robot avatar the best |
21:52:40
| <substack> | agreed @ voxelization |
21:52:41
| <mbalho> | substack: kewl |
21:53:07
| <substack> | there's also http://substack.net/images/avatars/robot_avatar.png |
21:54:15
| <mbalho> | oh sweet |
21:57:33
| * mikeal | quit (Quit: Leaving.) |
21:58:21
| * mikeal | joined |
21:59:29
| * CoverSlide | quit (Quit: REBOOTIN') |
22:03:10
| * CoverSlide | joined |
22:08:33
| * tphummel | joined |
22:16:00
| <Raynos> | jez0990_: the correct thing to do is to have a central muxxer and namespace the rest through it. |
22:16:16
| <Raynos> | its the same with p2p networking |
22:16:19
| <Raynos> | when building p2p apps |
22:16:27
| <Raynos> | you want all your apps to use the same network bus |
22:16:33
| <Raynos> | to the entire p2p network |
22:16:48
| <Raynos> | and each app builds it own sub network on top of the low level network infrastructure |
22:16:54
| <Raynos> | Now for sugar we can patch mux-demux |
22:17:01
| <Raynos> | so that it flattens multiple muxes on muxes |
22:17:33
| <Raynos> | mbalho: I want http://substack.net/images/substack_pixel.svg in a 3d voxel demo |
22:17:45
| <Raynos> | I also want to be able to push it over and watch substack "die" |
22:18:49
| <mbalho> | lol |
22:20:58
| <substack> | blarg I am so tired right now >_< |
22:21:36
| <substack> | need to finish this ui module to roll out some browserling pricing element updates |
22:21:58
| <substack> | for team plans and then later charging for testling-ci |
22:22:56
| <substack> | gotta keep that cash money rolling in |
22:23:20
| <mbalho> | substack "bling bling" halliday |
22:24:09
| <substack> | burrito time |
22:29:16
| <fotoverite> | Agreed burrito time. |
22:45:50
| <jez0990_> | Raynos: so I was only planning to use this nested mux stream as a oneway api exclusively between two different modules, but I think you're right about using the namespacing - thank you! |
22:51:58
| <pkrumins> | defunctzombie_zz, Raynos, i just put sandbox browser isolation for testling-ci in production, now all the browsers run the right engines. |
22:56:33
| * devaholic | quit (Ping timeout: 276 seconds) |
23:02:25
| * AvianFlu | quit (Remote host closed the connection) |
23:02:46
| * nk109 | joined |
23:09:47
| <mbalho> | substack: we should render this in voxels https://github.com/Platane/Procedural-Flower |
23:21:00
| * devaholic | joined |
23:28:04
| <Raynos> | jez0990_: I have a similar problem with https://github.com/Raynos/signal-channel/blob/master/connection.js#L14 and https://github.com/Raynos/peer-connection-shim/blob/master/open.js#L24 |
23:28:17
| <Raynos> | I build peer connection shim on top of a stream coming from signal channel |
23:28:23
| <Raynos> | it just turns out that both want multiplexing logic |
23:28:28
| <Raynos> | I think mux-demux should flatten it out |
23:28:37
| <Raynos> | pkrumins: sweet! |
23:30:36
| * dguttman | joined |
23:35:04
| <Raynos> | substack: what do you think of HTML macros? ( https://gist.github.com/25cadf7725af6105e77a ) as a compile time preprocessor. |
23:35:48
| <Raynos> | anyone else feedback welcome too :p |
23:40:08
| <kanzure> | what |
23:40:11
| <kanzure> | hrm. |
23:49:14
| <jez0990_> | Raynos: that looks pretty logical to me, but I don't have any perspective on how or why it's unique compared with other forms of templating already out there :3 |
23:49:34
| <Raynos> | jez0990_: because logic is compile-time only and not run-time |
23:50:32
| * yorick | quit (Remote host closed the connection) |
23:50:37
| <jez0990_> | ...and that would presumably "just work" with browserify? |
23:52:18
| <Raynos> | yes / no |
23:52:30
| <Raynos> | you have to tell browserify to use a tool to register these |
23:52:44
| <Raynos> | but you would be able to compile them to a javascript file that works with browserify |
23:53:15
| <Raynos> | or do `bundle.register(".template", require("macro-html")) ` |
23:54:17
| <jez0990_> | ah got it, cool |
23:55:47
| * AvianFlu | joined |