Skip to content

Instantly share code, notes, and snippets.

@Cervator

Cervator/log Secret

Created January 24, 2015 04:53
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save Cervator/b9d999505902c29510fc to your computer and use it in GitHub Desktop.
Save Cervator/b9d999505902c29510fc to your computer and use it in GitHub Desktop.
Terasology dev meeting, part 2, January 10th 2015
4:58:07 PM - PrivateAlpha: Is meeeting tiime
4:58:23 PM - Cervator: yep, pretty much :)
4:58:28 PM - Halamix2: in 1m
4:58:57 PM - Halamix2: 30s
4:59:12 PM - Halamix2: 15s
4:59:23 PM * Cervator pokes SuperSnark, synopia, skaldarnar , Josharias_Away, nh_99, Limeth, Gimpanse
4:59:28 PM - Halamix2: And meeting time NOW
4:59:45 PM - Halamix2: (sorry for that)
4:59:48 PM - Cervator: :D
4:59:53 PM - nh_99: geez cerv
4:59:59 PM - Cervator: excitement is good! meetings exciting - uh, dunno!
5:00:03 PM - Cervator: i know, i'm such a poker
5:00:04 PM - nh_99: I don't know why you keep poking me
5:00:17 PM - Cervator: it is like i'm on a quest or something! :D
5:00:26 PM - nh_99: you know I'm just going to come on and comment how nice the push notifications are
5:00:26 PM - glasz: hoy
5:00:34 PM - nh_99: lol
5:00:39 PM - Cervator: haha, yes, i do still need to set that up
5:00:59 PM - Cervator: maybe after meeting time if you're still around for a bit
5:01:03 PM - nh_99: ah, yay, dev meeting!
5:01:07 PM - nh_99: psh
5:01:08 PM - skaldarnar: hehe, just replying to Flos list :D
5:01:13 PM - nh_99: of course
5:01:39 PM - Cervator: hearing weird rumbling, think we have guests - brb
5:01:54 PM - nh_99: lol
5:03:24 PM - Gimpanse: Hello there
5:03:27 PM - Flo_K: hi
5:03:36 PM - Halamix2: hi
5:04:06 PM - Cervator: good timing for unexpected guests
5:04:16 PM - Cervator: must find some Gevalia - if any of our europeans get that one
5:04:25 PM - Cervator: (and if i'm remembering the right brand)
5:05:01 PM - Cervator: msteiger the ninja got away again
5:05:10 PM - Cervator: Immortius: still there?
5:05:18 PM - Immortius: ya
5:05:34 PM - Cervator: alrighty
5:05:55 PM - Cervator: looking at the topic list, was hoping msteiger would make it back
5:06:40 PM - Cervator: real quick to get Waffle / Trello / Bountysource out of the way - any objections against any of those if anybody knows anything? nobody needs to use them unless you want to :-)
5:06:59 PM - Gimpanse: uh
5:07:02 PM - Cervator: i should probably save you all from my nerdy ramblings on how to organize it all - at least the details, anyway ;-)
5:07:42 PM - Cervator: right now we've just got the individial GitHub issue trackers - i was playing with Trello at first for general brainstorming, got stuff like that: https://trello.com/b/etuFcHR7/light-shadow
5:08:12 PM - Gimpanse: i really dont know enough about any of those tools to comment i guess
5:08:18 PM - Cervator: that's fine
5:08:37 PM - Cervator: they're really more for project brainstorming and organizing :-) GitHub is better for bugs or support
5:08:50 PM - nh_99: oh yes, those look neat
5:09:05 PM - Josharias_Away is now known as Josharias.
5:09:12 PM - Cervator: i'm thinking about finding a like-minded individual or two to help brainstorm topics like Light & Shadow, Throughout the Ages, and so on, in Trello
5:09:50 PM - Immortius: I have no comment other than we need to be clear on what to use when, so we don't end up with information and activity spread across multiple locations (forum, issues, wiki, etc).
5:10:21 PM - Cervator: then organize what might be in a next release, likewise in Trello, figure out what goes where, submit issues when we know what modules are involved - that's where Waffle.io can be nice: https://waffle.io/Terasology/ThroughoutTheAges
5:10:41 PM - Cervator: Immortius: yep, i promise to do a wiki writeup, even will try to make it brief, on our various trackers and forum threads :-)
5:11:10 PM - Gimpanse: the current wiki is still github, right?
5:11:16 PM - Cervator: yep
5:11:33 PM - Cervator: Bountysource has nice integrations with GitHub issues and Waffle issues (which are just GitHub issues presented in a nice cross-repo fashion
5:12:07 PM - Cervator: anyway, if anybody is interested in helping me figure out nice columns or workflow just let me know - but i figure probably not :D
5:12:18 PM - Cervator: if no objections then that's enough, i'll sort something out :-)
5:13:03 PM - Cervator: a more important topic is trying to confirm if i'm nuts or on to something with the module packaging
5:13:12 PM - Cervator: http://forum.terasology.org/threads/module-tracker-infrastructure.1075/
5:13:12 PM - Josharias: I would also be wary about spreading information too thin. Maybe its just the trello part that I am scared of. One could probably do a lot of that in github/waffle
5:13:34 PM - Cervator: yeah most the time can do without, Trello is almost like a live brainstorming thing you can then ignore later :-)
5:13:55 PM - Cervator: i don't want to spam github any more than i do currently with spurious issues :D
5:14:27 PM - Cervator: that big thread i linked is a long read, but to summarize:
5:14:31 PM - nh_99: gosh, I keep thinking you're saying Zello, lol
5:14:42 PM - nh_99: which, obviously, has no place in this conversation
5:14:46 PM - Cervator: :D
5:14:48 PM - Flo_K: also to consider: the amount of user accounts to make :|
5:15:01 PM - Cervator: yeah that's where Waffle is nice, GitHub OAuth :-)
5:15:17 PM - Cervator: 1) Current game zip in Jenkins no longer has extra modules in it
5:15:53 PM - Cervator: 2) This zip does, i call it the Omega distro as it contains all stable modules (the previous setup): http://jenkins.terasology.org/job/DistroOmega/
5:16:10 PM - PrivateAlpha has left the room (Quit: Leaving).
5:16:17 PM - Flo_K: that's quite nice
5:16:22 PM - Cervator: 3) Distros are simply defined here: https://github.com/Terasology/Index/tree/master/distros
5:16:31 PM - Flo_K: (the way you can login via github
5:16:33 PM - Cervator: yup
5:16:51 PM - Gimpanse: That is going to get complicated should we start bundling a JRE :P
5:17:02 PM - Cervator: yeah that's why we're here :D
5:17:14 PM - Cervator: i did it mainly for Jenkins - now the engine build runs solo
5:17:24 PM - Gimpanse: for everything "installable" (i guess applet doesnt count for instance), you'd need to multiply each release by the number of supported architectures
5:18:26 PM - Cervator: yeah i'm not sure we'd want a download for everything, some ideas are more for organizing's sake, or for use as options in the Launcher
5:19:16 PM - Cervator: as in, only provide a binary download for the game, then do module additions differently - maybe with just the Omega zip available as an easy download
5:19:22 PM - Cervator: but i'm not sure
5:20:02 PM - Cervator: the more interesting Distro is what i call Iota, the old Mode Zero concept - the batch of modules that make up fundamental pieces of the game (inventory, spawning, combat, hunger, thirst, etcetcetc)
5:20:10 PM - Gimpanse: what would playing any terasology game mode look like for a "normal" player?
5:20:27 PM - Gimpanse: what would someone like that download?
5:21:05 PM - Cervator: i believe Iota should provide our "normal" gameplay, like a typical survival style
5:21:18 PM - Cervator: but Omega is a superset of Iota, so that's probably what you'd download
5:21:31 PM - Cervator: also contains L&S, TTA, and so on
5:21:58 PM - Gimpanse: so effectively when someone goes to terasology.org and presses download for whatever OS/Arch he has, he gets that?
5:22:07 PM - Gimpanse: Do we need any other dist beside that?
5:22:27 PM - Cervator: not for download, no, some are more for behind the scenes work
5:22:38 PM - Immortius: Ideally I think we'ld just have the small distro, and the module browser/downloader
5:22:58 PM - Immortius: so you start with some minimal set and obtain the rest as desired.
5:23:23 PM - Cervator: Iota should be the set of modules we officially support as part of the core game, and the suggested set of modules you'd build more involved gameplay on top of
5:23:30 PM - Cervator: right, that's Iota in my mind :-)
5:23:49 PM - Cervator: Omega probably should eventually become less commonly used
5:23:50 PM - Gimpanse: Josharias implemented a form of "modpacks", right?
5:23:52 PM - Gimpanse: the game modes?
5:23:52 PM - skaldarnar: I agree with Immortius, probably we should place a reminder in the game (if no modules are present)
5:23:54 PM - Cervator: it is just what we have right now
5:24:01 PM - Gimpanse: or am i mistaken there
5:24:07 PM - Cervator: Josharias might have done the gameplay template UI?
5:24:09 PM - Cervator: been a while
5:24:20 PM - Cervator: we have gameplay modules that get an entry on the create game screen
5:24:55 PM - Gimpanse: directing the player to download a "game mode" whene they click "create game" without any game modes installed should be fine, right?
5:24:58 PM - Gimpanse: so iota would be ok
5:25:15 PM - Cervator: if we can add in a module downloader, yeah
5:25:20 PM - Cervator: that's still a ways out i think
5:25:34 PM - Immortius: Iota should still have a simple game mode, methinks.
5:25:50 PM - Cervator: yeah, "normal" or what not - all the Iota modules enabled, but in a somewhat generic world
5:26:13 PM - Immortius: But it should also include the launcher, and the launcher should have something upfront directing the user to get more modules.
5:26:19 PM - Cervator: so you have thirst, hunger, ambient creatures, and so on
5:26:31 PM - Immortius: Maybe even a recommendation or "advertisement"
5:26:55 PM - Cervator: we've talked about the ModuleManager as a potential library that could be used similarly from inside the game or launcher - for those who dislike launchers
5:27:03 PM - Gimpanse: hmmm. it might leave the impression that there isn't much to terasology
5:27:07 PM - Gimpanse: if it's just a minimal gameplay mode
5:27:12 PM - Gimpanse: and players dont "find" the module downloader hehe
5:27:26 PM - Cervator: i would put that on the create game screen in the main game :-)
5:27:33 PM - glasz: i think there are 2 kind of modules, basic bricks, and game modes that include basic bricks. Player should only care about game mods
5:27:40 PM - Immortius: ya
5:27:42 PM - Cervator: only the version in the launcher might be more fully featured / larger
5:27:43 PM - Gimpanse: primarily yes
5:27:49 PM - Immortius: well, the third is mods
5:27:50 PM - Gimpanse: i guess there are some mods that can be "added" to a game mode
5:28:00 PM - Gimpanse: but the primary driver certainly is a game mode
5:28:01 PM - Cervator: and might offer more stuff like jre upgrades and other things you might not want to do from inside the game
5:28:17 PM - Gimpanse: the user should not need to care about JRE updates :P
5:28:23 PM - Gimpanse: it should just be a game update like any other
5:28:51 PM - Cervator: alright, i'm spacing on a few other items the launcher seemed to have an advantage for
5:29:02 PM - Immortius: I would suggest the source of the module index should not be github, but rather some sort of artifact repository, to allow for third party modules to also be indexed.
5:29:23 PM - Cervator: msteiger has been looking at Bintray, which we can publish to from Artifactory
5:29:23 PM - Gimpanse: regarding github as the primary source of such information. i am a bit worried to depend on that thing so much, heh
5:29:31 PM - Gimpanse: but i have little experience with using github for such purposes
5:29:38 PM - Cervator: it is like a Maven Central, but apparently with more focus for "normal" releases, not just libs
5:29:41 PM - Gimpanse: the thing i saw in the release api however was some form of API call throttling, which could be troublesome
5:30:03 PM - Cervator: for instance if you look at https://www.vagrantup.com/downloads.html they're actually offering their app installer hosted on Bintray
5:30:20 PM - Cervator: Gimpanse: ah - yeah, hm
5:30:47 PM - Cervator: my thought on the Index is that it makes for a nice central single repo to query, and a good central spot to build a basic module site out of
5:30:48 PM - Gimpanse: isn't the index part kinda low traffic / low computational complexity? can't we "host" that as a static file on terasology.org?
5:31:25 PM - Cervator: possibly, but with it hosted on GitHub we don't get the traffic at all, so traffic spikes would be blunted :-)
5:31:58 PM - Cervator: that's why i've been focusing on using GitHub for binary storage - release zips or jars in each repo, index by the Index repo
5:32:01 PM - Gimpanse: yeah it would be possible i guess. the URL that'S coded into the game should be terasology.org/something though
5:32:03 PM - Gimpanse: we can redirect from there
5:32:04 PM - Cervator: but maybe Bintray is another good option
5:32:06 PM - Cervator: yup
5:32:17 PM - Gimpanse: oh well the binary blobs can still be stored on the github release stuff
5:32:23 PM - Cervator: yep
5:32:23 PM - Gimpanse: we need to be able to hotlink to those anyway
5:32:43 PM - Cervator: terasology.org is currently hosted on GitHub out of the MovingBlocks org, we can make another out of the Terasology org for modules, could be simply terasology.net
5:32:55 PM - Cervator: .org = game and group, .net = modules
5:33:41 PM - Cervator: this is the kind of GitHub site i have in mind: http://netflix.github.io
5:33:48 PM - Halamix2 is now known as Halamix2_afk.
5:33:53 PM - Cervator: just with modules
5:34:40 PM - Cervator: in any case - we'd look up some sort of central registry
5:35:05 PM - Cervator: there's no real reason we can't make the game support multiple registries, if somebody wants to host a set of modules somewhere off GitHub, for instance
5:35:11 PM - SuperSnark: hey hey
5:35:14 PM - Gimpanse: Hmmmm
5:35:14 PM - Cervator: heyo
5:35:19 PM - Gimpanse: It's a complicated issue for sure
5:35:24 PM - SuperSnark: how goes it guys?
5:35:36 PM - Cervator: fine, talking about how to distribute the game and the modules :-)
5:36:01 PM - Josharias: They would just have to host the third party modules in the same structure as the official one, right?
5:36:03 PM - Cervator: i feel like i'm not crazy after all, so that's a plus, just need to figure out which parts need to be tweaked :-)
5:36:06 PM - Cervator: exactly
5:36:07 PM - Gimpanse: so just to clarify this for me.
5:36:22 PM - Gimpanse: modules in the current sense are NOT mods / game modes. game modes / mods are made up of modules
5:36:40 PM - Immortius: yes
5:36:53 PM - Cervator: correct, so far we've got "gameplay templates" which get an entry on the create game screen - there is a central gameplay module that defines it and has a bunch of dependencies
5:36:53 PM - Gimpanse: so to the player, modules don't really need to be presented for download
5:36:56 PM - Gimpanse: but mods / game modes need to be
5:36:58 PM - Cervator: right
5:37:06 PM - Immortius: So we certainly need our registry entries to highlight the modules providing mods/gametypes
5:37:08 PM - Gimpanse: with some additional fluff probably (images, descriptions, support website links, etc.)
5:37:15 PM - Cervator: the extra is that you can still edit the module list and enable extras if you want
5:37:17 PM - Cervator: yup
5:37:27 PM - Immortius: but all modules need to be registered for dependency fetching
5:37:33 PM - Cervator: yes
5:38:14 PM - Gimpanse: would you mix all those into one?
5:38:22 PM - Cervator: eventually i think it would make sense to base gameplay templates off something like Iota, so you wouldn't need to enter every single dependency in a growing list to maintain the "base game" you're building on top off
5:38:23 PM - Gimpanse: i mean basing them all off of modules?
5:38:37 PM - Cervator: everything so far is modules :-)
5:38:38 PM - Gimpanse: or would you rather introduce new artifacts / concepts for game modes / modules that then reference modules for the actual implementation?
5:39:04 PM - Gimpanse: I am thinking from a presentational point of view
5:39:21 PM - Immortius: From a presentation point of view the user would never directly look at the registry
5:39:23 PM - Gimpanse: To display a list of all available game modes, we'd need to sift through *all* modules
5:39:28 PM - Gimpanse: and find the ones that are game modes
5:39:31 PM - Cervator: i think the gameplay modules just need to get fancier - more presentation options
5:39:38 PM - Immortius: they would look at a filtered view showing only game modes and/or mods as desired
5:39:40 PM - Cervator: correct, that's how it works now
5:39:47 PM - Gimpanse: hmmm
5:39:48 PM - Immortius: and with versions collated
5:39:57 PM - Cervator: there is also http://forum.terasology.org/threads/module-categories.1068/ for that
5:40:15 PM - Immortius: in game I don't think we have a marker or filtering of mods yet
5:40:17 PM - Cervator: you can imagine that "library" modules aren't visible as they provide no direct benefit for an end user
5:40:18 PM - Gimpanse: Stuff is rattling in my head a bit. sorry :D
5:40:27 PM - Immortius: which is the last thing that needs to be done to hide building-block modules
5:40:31 PM - Gimpanse: Are game modes really required to be modules?
5:40:34 PM - Gimpanse: Aren't they just metadata?
5:40:36 PM - Cervator: also correct :-) only special thing currently is gameplay module -> goes in the dropdown
5:40:58 PM - Cervator: you can make them pretty thin: https://github.com/Terasology/ThroughoutTheAges
5:41:14 PM - Cervator: TTA used to be hosted in WoodAndStone, which was kinda messy
5:41:47 PM - Gimpanse: Hehe to be honest, I am almost thinking of this from a web dev perspective (how to store / serve / present this information)
5:41:54 PM - Cervator: sure, makes sense
5:42:05 PM - Cervator: with module categories we can filter and decorate to our heart's content
5:42:07 PM - Gimpanse: It could be an advantage to have game modes / mods be pure-metadata descriptions (JSON blobs basically)
5:42:10 PM - Halamix2_afk is now known as Halamix2.
5:42:12 PM - Gimpanse: that get referenced from the main repository
5:42:13 PM - skaldarnar: and that way you can include small library-like stuff in the game mode module, right?
5:42:41 PM - Gimpanse: to do that in a metadata-only concept, that logic would need to be compiled into a mini-module that then gets referenced in the game modes dependency list
5:42:47 PM - Gimpanse: still possible. a bit more hassle for the developer
5:42:51 PM - Cervator: skaldarnar: might have lost me there :-) i guess the main reason for instance the TTA module exists is to depend normally on other modules
5:43:16 PM - Gimpanse: Hmmmmm. Well actually i think it's okay
5:43:20 PM - Cervator: i'm torn on whether Iota should be a module of some sort, it might be a better candidate for pure json
5:43:23 PM - skaldarnar: I was looking for the main difference between game modes (GM) as module and as pure metadata ;)
5:43:25 PM - Gimpanse: I think we do need some server side logic for this
5:43:43 PM - Gimpanse: We can simple produce a metadata-only view of game modes
5:43:44 PM - Immortius: Hmm, the way I see it there is always some code specific to a game type - otherwise that game type isn't anything.
5:43:47 PM - Cervator: well, right now Iota is a prop file, really
5:43:51 PM - Cervator: right
5:44:10 PM - Gimpanse: Hmmm not necessarily I think
5:44:29 PM - skaldarnar: and I thought that tiny tiny features specific for a game mode, but not general enough for its own module could be easily included in GM modules, but not in the metadata variant
5:45:03 PM - Gimpanse: Yeah it's fine. But we should preprocess the game mode list server-side to avoid clients having to download all game mode modules to display a nice list
5:45:21 PM - Cervator: that could be done easily in the Index
5:45:25 PM - Josharias: I would expect game mode modules to need configuration and tweaking using normal module mechanics so that the author could pull a bunch of different modules together for the game mode's own purpose.
5:45:26 PM - Gimpanse: It could be an offline job that commits the new repo with metadata to github btw.
5:45:41 PM - Cervator: just put a list of gameplay templates in there that gets updated if Jenkins builds something new that turned out to offer new gameplay
5:46:06 PM - Cervator: oh, yeah, we said the same thing, really
5:46:22 PM - Gimpanse: We'd need to define a repository protocol for this
5:46:38 PM - Cervator: for the gameplay listing?
5:46:42 PM - Immortius: REST/json api preferably
5:46:45 PM - Gimpanse: And yes. While the actual dirty stuff that needs to be done to install a game mode resembles the dependency management provided by maven/ivy/whatever *VERY* closely
5:47:03 PM - Gimpanse: presenting that list of game modes is something pretty different i think
5:47:30 PM - Gimpanse: Immortius: I concur. Read-Only should suffice. It should be enough for a client to fetch a static JSON file i guess. Unless we think we need server-side search
5:47:39 PM - Gimpanse: But to be honest. That gets interesting from 1000+ game modes onwards hehe
5:47:50 PM - Cervator: yes :D some of my planning is for the long-term like that
5:47:59 PM - Immortius: or else something like http://www.nexusmods.com/skyrim/mods/61249/?
5:48:03 PM - Gimpanse: Do it the SCRUM way. Keep it simple :P
5:48:10 PM - Cervator: i'd rather depend on stuff like GitHub or Bintray so our sites don't die
5:48:33 PM - Gimpanse: My approach would be to avoid server-side processing if at all possible
5:48:41 PM - Gimpanse: Downloading a pre-compressed JSON file as the index
5:49:04 PM - Cervator: that's fine too, as an initial cache, but that would go out of date and need to update from somewhere :-)
5:49:17 PM - Gimpanse: Yeah but that's traffic only. Not CPU time
5:49:33 PM - Gimpanse: You could host that file in bintary/github/amazon S3 (cost blergh)
5:49:39 PM - Josharias: confused, it sounds like you guys are talking about making another mechanism to describe game modes. Dont we already have that in the existing module architecture? One would download the game mode module, then check its dependencies and recursively download all dependencies until satisfied.
5:49:41 PM - Gimpanse: it should be signed as well
5:49:59 PM - Gimpanse: Josharias: It's about a mechanism to discover and install new game modes from the internet
5:50:02 PM - Cervator: Immortius: yeah that site is close to what i imagine for a *major* module site - that's sort of out of scope for me so far, Phillaxx had an actual module site working for a while, but went inactive. The GitHub Page i'm talking about is sort of a minimal version
5:50:29 PM - Gimpanse: Josharias: It would still hold true that one game mode = one module with many dependencies
5:50:32 PM - Cervator: Gimpanse: the cpu load would just be in Jenkins at build time :-) make calcs and update the Index
5:50:43 PM - Cervator: Index holds a static file the launcher/game can use
5:50:45 PM - Josharias: Ah, this is all about how to describe that communication. got it. Continue!
5:50:52 PM - Gimpanse: Cervator: You are forgetting 3rd party modules we dont have in our jenkins though ;)
5:50:57 PM - Cervator: true
5:51:11 PM - Cervator: not everybody is going to want to put their modules on github
5:51:18 PM - Gimpanse: Josharias: I'd imagine we need some more metadata in the gameplay module though. Like a teaser-image, support URLs, contact data, a nice description, etc. etc. to make it presentable
5:51:30 PM - Cervator: some might not want to use a Terasology/Module location either
5:51:48 PM - Gimpanse: Josharias: I'd extract all that info on the server-side and put it into a nice JSON file that clients can download to find new game modes, without downloading those game modes first
5:52:11 PM - Immortius: we could source from artifactory, and if people want their modules available but don't use github they can be manually uploaded.
5:52:13 PM - SuperSnark: that's a good idea
5:52:14 PM - Josharias: Agreed. Thanks for setting my brain straight.
5:52:38 PM - Cervator: my thought was: 1) Iota modules and stuff we directly support in Terasology/[Name]; 2) Third party modules we can ship with the game hosted on GitHub and forked to Terasology/[Name]; 3) Third party modules hosted in compatible third party registries the user can add to their client/launcher
5:53:01 PM - Gimpanse: Since everything is based off modules, how we host and download modules is the next question, right?
5:53:14 PM - SuperSnark: true
5:53:23 PM - Gimpanse: And the maven dependency mechanism is a pretty good fit, isn't it?
5:54:06 PM - Cervator: if we use something like Bintray we could possibly put third party modules there, yeah - it is practically Artifactory
5:54:25 PM - Gimpanse: We could also look at how bower / NPM in the javascript world do it
5:54:33 PM - Gimpanse: They pretyt much have what you describe
5:54:41 PM - Cervator: unfamiliar there, unless that's akin to Yum etc?
5:55:08 PM - Gimpanse: NPM had 30 million module downloads just yesterday
5:55:11 PM - Cervator: in my journeys through Chef automation land i came across some articles about building your stuff to deploy directly to Yum-type repositories
5:55:12 PM - Gimpanse: It's the maven for javascript
5:55:18 PM - Cervator: ah okay :-)
5:55:22 PM - Gimpanse: But if i remember correctly, they allow for actual files to be hosted on github.
5:55:38 PM - Gimpanse: Hmmm I am not sure here
5:55:43 PM - Gimpanse: So imagine this
5:55:47 PM - Gimpanse: Someone wants to build a new game mode
5:55:55 PM - Cervator: brb
5:56:01 PM - Gimpanse: Someone who doesn't really knows us and we don't know them
5:56:17 PM - Gimpanse: How do they get their game mode accessible from within the game? Do we even want that? (malicious code et al)
5:58:49 PM - Immortius: Well, all modules run in our security sandbox, which is *hopefully* secure
5:59:23 PM - Gimpanse: what kind of security do we want there? someone could impersonate official modules theoretically (even if by name)
5:59:40 PM - Cervator: hooray random cat emergencies
6:00:32 PM - Cervator: Gimpanse: IMHO third party devs who don't want to use our infrastructure can choose to implement our "registry api" and then instruct users to add that registry to access their modules
6:00:51 PM - Gimpanse: okay requiring user interaction does sound sensible here
6:00:54 PM - Cervator: i *really* want to keep the barrier of entry to our infrastructure as low as possible so everybody will just use it :-)
6:01:00 PM - Gimpanse: what gets a bit iffy is how to resolve modules across different repositories
6:01:05 PM - Cervator: yeah, lots of disclaimers too about using third party registries
6:01:06 PM - Immortius: Theoretically our registry could allow users to register with it and then upload modules, with the restriction that once a module id has been used it cannot be reused.
6:01:07 PM - Cervator: yeah
6:01:42 PM - Gimpanse: Whew that all sounds pretty complicated. But i guess we dont get a free lunch here
6:01:46 PM - Cervator: i'm not sure if we should overly worry about third party registries depending on other third party registries - i'd say either they depend on stuff inside their own or inside ours and that's it
6:01:49 PM - Gimpanse: Making it friendly for players and developers is never easy
6:01:58 PM - Flo_K: interesting might also be the use case that some just makes a block pack via a ingame editor
6:02:17 PM - Immortius: This won't prevent a potential issue with joining a server and being sent a module with the same id but different author. Although we would also potentially have uses fetch modules from the registry rather than the server where possible.
6:02:19 PM - Cervator: helps avoid the naming impersonation - if our repo "wins" for any name that exists
6:02:45 PM - Gimpanse: oh god servers haha i forgot about that issue. yeah
6:03:05 PM - Gimpanse: hm. is there some form of maven repository backed by github releases?
6:03:06 PM - Cervator: which incidentally could be a third use case for the ModuleManager lib :3
6:03:12 PM - Immortius: better to be downloading modules from a site designed for it rather than a server when possible anyway.
6:03:24 PM - Gimpanse: The best thing we could possibly hope for is being able to just reuse the maven dependency resolution library
6:03:28 PM - Cervator: oh! and that was my thought on hyping the Launcher, doing remote setup and management of a headless server from it
6:04:00 PM - Cervator: maven repo backed by github releases is sort of what i wish we could find or implement
6:04:09 PM - Gimpanse: Kinda sounds like it
6:04:19 PM - Cervator: with the Index repo to avoid those API limits
6:04:23 PM - Gimpanse: I mean, maven repos are just a directory structure if i remember correctly
6:04:34 PM - Immortius: pretty much
6:04:50 PM - Cervator: only one hit to gain info then additional hits to gain modules - if you *really* go nuts maybe you could still overflow if they count api hits per org on release downloads
6:04:55 PM - Gimpanse: i guess the only thing such a "proxy repo" would need to do is send a HTTP redirect when the actual jar file gets requested
6:05:07 PM - Gimpanse: while having an offline index of the github releases in maven repository form
6:05:22 PM - Cervator: could be neat to "mirror" yeah
6:05:39 PM - Cervator: we could release module binaries both to GitHub releases and say Bintray
6:05:45 PM - Gimpanse: Well that's kinda the question. Would we just continue using artifactory on our end, while hosting the actual raw files on github?
6:05:57 PM - Cervator: yep - Artifactory is for devs
6:06:15 PM - Cervator: GitHub/Bintray for users (and fallback for devs, maybe, if Artifactory is down)
6:06:21 PM - Gimpanse: Well no wait, i also mean for player module resolution
6:06:33 PM - Cervator: Bintray can serve as an extension for Artifactory anyway
6:06:39 PM - Cervator: well
6:06:55 PM - Cervator: player module resolution i'd send through the Index on GitHub - our registry
6:07:00 PM - Gimpanse: Okay i really have to checkout bintray
6:07:06 PM - Cervator: me too
6:07:12 PM - Cervator: it is really like a fancy Maven Central
6:07:12 PM - Gimpanse: Well wait, you'd actually check in that maven directory structure?
6:07:19 PM - Cervator: no
6:07:28 PM - Cervator: just a simple json tree or something
6:07:33 PM - Cervator: with module info and maybe some urls
6:07:33 PM - Gimpanse: Of what? all modules?
6:07:45 PM - Gimpanse: I would try to reuse the existing maven dependency resolution stuff
6:07:54 PM - Cervator: all module releases tracked by that registry, updated on release builds in Jenkins, yup
6:08:03 PM - Cervator: if that's doable it would be cool :-)
6:08:27 PM - Gimpanse: heh next question. would a player ever update an individual module?
6:08:29 PM - Cervator: i've been tempted to involve Gradle and its dependency resolution at runtime, buuuuut .....
6:08:33 PM - Gimpanse: Because that's an issue with the maven repo structure
6:08:54 PM - Cervator: good question
6:09:12 PM - Cervator: in theory an end user should never need to deal with anything but gameplay modules
6:09:22 PM - Gimpanse: well and mods (which dont exist yet)
6:09:23 PM - Cervator: if a single module has an update, new release of the gameplay template
6:09:33 PM - Cervator: yeah i suppose
6:09:42 PM - Cervator: content modules you can enable together with gameplay modules
6:09:58 PM - Cervator: you could probably update individual modules if you really wanted to?
6:10:13 PM - Gimpanse: Would the client even have an interface for that though?
6:10:33 PM - Cervator: maybe not, to keep it simple - i am unsure
6:10:47 PM - Cervator: i kinda want to hide it, yet also kinda want to reveal it to powerusers who want to tinker
6:11:25 PM - glasz: you could have an advanced users interface
6:11:44 PM - skaldarnar1 [~skaldarna@pD9EB0EB2.dip0.t-ipconnect.de] entered the room.
6:11:47 PM - Gimpanse: I just wonder. Wouldn't that conflict with the dependency version specified in the gameplay module though?
6:12:22 PM - Cervator: depends - you can enter the dependency requirement with an allowed range
6:12:37 PM - Cervator: so 2.1.? would allow any 2.1.something
6:12:43 PM - Cervator: but would complain if you went to 2.2
6:13:03 PM - Gimpanse: Hmmm that would kinda make it possible to "check for updates" if a gameplay module specified a range
6:13:07 PM - Cervator: and yeah, module listing would definitely move to an advanced screen at some point
6:13:11 PM - Cervator: yup
6:13:11 PM - Gimpanse: and an update for that particular module is available
6:13:14 PM - skaldarnar has left the room (Quit: Ping timeout: 256 seconds).
6:13:17 PM - Cervator: works the same in Gradle
6:13:38 PM - Cervator: would also help cut down on too many git updates and releases for the gameplay module itself
6:13:58 PM - Immortius: If you don't provide a range, the default upper bound is the next major version
6:14:20 PM - Immortius: so if you depend on 2.2.0 of a module, it will attempt to use anything up to 3.0.0 exclusive
6:14:35 PM - Gimpanse: that can be kinda dangerous hehe
6:14:45 PM - Cervator: not if you truly follow good ole SemVer :-)
6:14:55 PM - Gimpanse: but wait.
6:14:56 PM - Cervator: but naturally some devs will probably not do it right ...
6:15:01 PM - Gimpanse: that's the "enforced" dependency by the module manager, right?
6:15:17 PM - Gimpanse: the module "downloader" could still adhere to the version number specified
6:15:22 PM - Cervator: it is behavior in gradle and / or gestalt-module, probably both
6:15:30 PM - Gimpanse: I do see a use case for game mode creators wanting to include a very specific version of a module
6:15:34 PM - Cervator: yep
6:16:23 PM - Cervator: so that was a lot of good discussion, but what did we actually decide :D
6:16:29 PM - Halamix2 has left the room (Quit: Read error: Connection reset by peer).
6:16:35 PM - Gimpanse: i think more research is needed heheh
6:16:38 PM - Cervator: yeah
6:16:48 PM - Cervator: keep those two threads handy if you're interested and put some notes in there
6:16:56 PM - Cervator: http://forum.terasology.org/threads/module-tracker-infrastructure.1075/
6:17:02 PM - Cervator: http://forum.terasology.org/threads/module-categories.1068/
6:17:28 PM - Cervator: the main thing i really wanted was to get some attention on it so we can start delivering extra modules to users again :-)
6:17:59 PM - Cervator: really, we can probably just make the Launcher distribute the Omega zips instead of the zip from the engine job - but still check that for changelog
6:18:34 PM - Cervator: i can put an issue in for that and pester skaldarnar1 and msteiger :-)
6:19:06 PM - Cervator: anybody still with us, or did everybody not involved in that big discussion fall asleep? :D
6:19:15 PM - glasz: here
6:19:59 PM - Immortius: watching
6:20:18 PM - Cervator: another topic i put on the list is Input Bindings, as i have been wanting us to sort out some standard keys
6:20:30 PM - Cervator: but that might be more of a "Please go here and voice your opinion" :-) http://forum.terasology.org/threads/input-bindings.1143/
6:20:52 PM - Cervator: what came up was stuff like auto-run vs run-toggle and what keys to reserve for stuff like that
6:21:38 PM - Cervator: i'm happy if some more people just respond to the thread
6:21:44 PM - Gimpanse: is it possible to bind default keys to the physical location on the keyboard? probably not without writing custom stuff for every keyboard, right?
6:21:54 PM - Gimpanse: *every layout
6:21:54 PM - Cervator: probably not :(
6:22:05 PM - Gimpanse: Just thinking about that w.r.t. the console key
6:22:09 PM - Cervator: i'm hardly an expert tho
6:22:25 PM - Gimpanse: Because the "position" of it is usually the same, it's just a different key code here :P
6:22:29 PM - Cervator: i very much would like to be able to assign both primary and secondary keys
6:22:30 PM - Cervator: yep
6:22:46 PM - Cervator: console key i think would work great being *both* on ` and F1
6:22:55 PM - skaldarnar1: I think the idea of an additional mapping layout came up before
6:23:12 PM - Cervator: those with ` and being used to it would hit that by nature, those without or with a tricky ` could use F1 which is right there
6:23:36 PM - Cervator: Immortius: i am figuring we can only put one key in the annotation that assigns a key binding right now?
6:23:37 PM - skaldarnar1: where the user can select a specific layout, but play with the standard physical layout
6:23:59 PM - Immortius: you could just have two methods at worst
6:24:30 PM - Cervator: alright, should we do that, or tweak the annotation?
6:24:41 PM - Cervator: easy?
6:24:44 PM - Immortius: probably better to tweak the annotation
6:25:11 PM - Cervator: okay - i had the thought of a third option too, an "Alternate" mode, where the whole keyboard swaps into a different keyset
6:25:17 PM - Gimpanse: are our keys bindable ? i dont remember
6:25:25 PM - Cervator: imagine being in "Creature command mode" with a 2D map present
6:25:45 PM - Cervator: keys bindable?
6:26:00 PM - Gimpanse: well, can the user change the binding. i dont remember :D
6:26:06 PM - Cervator: yep!
6:26:12 PM - Cervator: that is all kinds of fancy :-)
6:26:19 PM - Cervator: we have two options, primary and secondary key
6:26:32 PM - Cervator: but the annotation only allows you to include one default in code
6:26:41 PM - Immortius: the config supports an arbitrary number of keys
6:26:47 PM - Cervator: oh good, even better
6:26:54 PM - Gimpanse: if this is just about the default key. leave console at grave
6:27:00 PM - Cervator: just the controls UI only shows 2?
6:27:02 PM - Gimpanse: or whatever it is right now
6:27:06 PM - Gimpanse: as long as its rebindable :P
6:27:20 PM - Cervator: yeah but it is annoying on keyboards where it doesn't work by default :-)
6:27:35 PM - Gimpanse: in general having a concept of context sensitive keys would be more beneficial to avoid the key binding hell that modded minecraft has
6:27:37 PM - Gimpanse: that is _insane_
6:27:45 PM - Cervator: yessss
6:28:34 PM - Cervator: Immortius: do you think that would be easy to support? a set of input contexts, where if the context changes the stored key bindings change to an alternate?
6:29:05 PM - Gimpanse: well no wait :D
6:29:07 PM - Gimpanse: that's not what i meant
6:29:19 PM - Cervator: oh :D
6:29:20 PM - Gimpanse: it's double binding mutually exclusive uses to the same key
6:29:29 PM - Cervator: ahh
6:29:35 PM - Gimpanse: we probably dont have that use case yet
6:30:02 PM - Immortius: I sometimes wonder if I should change the binding system to bind against buttons and/or console commands.
6:30:29 PM - Immortius: or a scriptable input binding system like some other engines have, essentially
6:31:01 PM - Cervator: that sounds nice and fancy, beyond what i was looking for :-)
6:31:07 PM - Immortius: an bindable input could be "jump | vAxis+ | mantle"
6:31:15 PM - Immortius: yeah, I dunno
6:31:24 PM - Immortius: in a way I think it is already context sensitive
6:31:38 PM - Immortius: in so far as it is up to whatever systems process the inputs to garner a result
6:31:52 PM - Cervator: so if a system is active it could override a key
6:31:59 PM - Immortius: yeah
6:32:18 PM - Immortius: I cannot remember if multiple buttons can be bound to a single key or not
6:32:22 PM - Cervator: so really you could just use a system like that to enable a context like a command map
6:33:00 PM - Cervator: survey says: nope
6:33:07 PM - Cervator: not in the settings UI anyway
6:33:54 PM - Cervator: i guess quite a related topic is modules introducing uses of the same key - there's that key binding hell
6:34:15 PM - Gimpanse: yes. it should be the gameplay mode's job to solve that mess
6:34:21 PM - Gimpanse: by providing a saner default config
6:34:43 PM - Immortius: you'll still have the same issue with mods
6:35:12 PM - Gimpanse: if a player adds the mod, it's probably their problem to solve
6:35:12 PM - Cervator: i think one of my examples was making some conventions for key usage
6:35:18 PM - Cervator: that's the hell :D
6:35:30 PM - Immortius: I think it is better to just avoid adding so many keys
6:35:40 PM - Cervator: yeah, that too
6:35:49 PM - Immortius: and you do that by proving a decent set of interfaces to hang off of
6:35:55 PM - Cervator: better to have workstations than in-hand crafting keys
6:36:05 PM - Gimpanse: yes
6:36:20 PM - Gimpanse: i guess one of the reasons in Minecraft was that there was no extensible "character sheet" of shorts
6:36:21 PM - Gimpanse: ~sorts
6:36:22 PM - Gooey: Gimpanse: No factoid for sorts
6:36:26 PM - Cervator: :D
6:36:27 PM - Immortius: so instead of an inventory key, you could have a player info key that opens a panel which includes inventory, plus any additional stuff you want.
6:36:32 PM - Gimpanse: yes
6:36:36 PM - Gimpanse: that sounds good
6:36:41 PM - Gimpanse: could that be tab?
6:36:41 PM - Immortius: We don't have shorts in Terasology either
6:36:52 PM - Immortius: sure
6:37:07 PM - Cervator: tab? that already does stuff :D
6:37:16 PM - Cervator: that's where it might be nice with a convention
6:37:41 PM - Cervator: in the thread i linked there were some highlighted zones
6:38:07 PM - Cervator: if we set down a convention and encourage module authors follow it maybe we can channel some of the similar uses through the same keys
6:39:10 PM - Cervator: 'c' is for "character" whatever that might be, 'v' is for inventory, whatever that might be, etc? 'i' is so far out of the way, tho it could be a secondary for ease ...
6:39:31 PM - Cervator: maybe secondary keys like that would be overridden by default if a different module declares it as a primary, but that gets too complicated :-)
6:40:34 PM - Gimpanse: well we can just set that in our own modules
6:40:39 PM - Gimpanse: i dont think a convention will do much here
6:40:47 PM - Gimpanse: other than generall encouraging mod authors to not add more keys hehe
6:40:48 PM - Immortius: The other thing is to make sure most keys are shortcut keys, and their function is otherwise in the UI.
6:41:19 PM - Immortius: so if the default is overriden, they are still usable and the player knows they exist (to later rebind as desired)
6:41:44 PM - Cervator: well, in any case, help me out and post some thoughts in that thread? :D so we remember
6:43:33 PM - Cervator: we're a fair bit past an hour, if anybody is antsy to go enjoy the sunlight, if there is any in your locale - i'm fairly happy, if we get some forum posts to follow up with
6:43:42 PM - Cervator: L&S design came up in the earlier session some
6:44:12 PM - Cervator: i agreed with Flo_K that it would be nice to get some general building improvements, and other usability tweaks
6:44:53 PM - Cervator: i think we can do some more of the L&S stuff pretty easily, especially stuff like generating nice looking structures and seeding more ambient stuff like creatures, flora, and minerals
6:45:05 PM - Cervator: glasz: you up for making some of SuperSnark's critters, akin to the deer?
6:45:46 PM - Cervator: i've thrown some of the tasks at skaldarnar1 and Josharias too, and will do what i can on making a bigger list of stuff we need by next meeting
6:46:31 PM - Cervator: anybody else have anything? i pushed some of the topics to next time
6:46:47 PM - glasz: well finish the chess pieces first maybe
6:46:50 PM - Gimpanse: the JRE embeding / updater thing is for next time?
6:47:08 PM - Cervator: i actually don't have that one
6:47:13 PM - Cervator: glasz: that's fine too
6:47:13 PM - Flo_K: Gimpanse: I am looking very much forward to a switch to java 8
6:47:19 PM - Flo_K: and to a new launcher :)
6:47:33 PM - Cervator: Java 8 i added to the general Alpha topic, which yeah is on the agenda for next time
6:47:41 PM - Cervator: so that ties to it
6:47:52 PM - Immortius: I'm... a little cautious about updating to Java 8. I don't think everything we're using supports it yet.
6:47:59 PM - glasz: but we still dont have a finite specific and detailled game description that would allow us to list all thats needed for a very first game version
6:48:15 PM - Cervator: some Linux distros still don't seem to have 8 available by default
6:48:19 PM - Gimpanse: Immortius: are you sure? i had no issues so far
6:48:29 PM - Gimpanse: yeah that makes the JRE bundling a requirement of sorts to use it
6:48:32 PM - glasz: until we do we can keep making stuff and hardly get nearer to that first complete game
6:48:32 PM - Flo_K: Immotius about what are you thinking about?
6:48:36 PM - Cervator: glasz: valid point - i'll try to push that further :-)
6:48:44 PM - Immortius: We've had bug reports suggesting some issues with Javassist with Java 8.
6:48:58 PM - Cervator: one or two critters would be nice just to add some default creatures to the L&S setup
6:49:15 PM - Gimpanse: Immortius: it might require a version update. where are we using javassist?
6:49:46 PM - Gimpanse: but yeah. a discussion for another time hehe
6:50:07 PM - Cervator: or the forum, or whenever you feel like it :-)
6:50:18 PM - Cervator: i'm done, so go nuts if you like!
6:50:33 PM - Flo_K: Immortius: 5 days ago there was a javassist release with java 8 support
6:50:42 PM - Flo_K: https://github.com/jboss-javassist/javassist/releases
6:50:51 PM - Immortius: ah, that is probably what we need :)
6:50:58 PM - Gimpanse: that seems pretty late hehe
6:51:03 PM - Gimpanse: i didnt even realize we were using javassist
6:51:23 PM - Immortius: Java 8 is going to be a little slow being uptaken, but I believe it will end up being the new Java 5.
6:51:40 PM - Immortius: that is my take on it anyway
6:51:44 PM - Gimpanse: probably yes. although it depends on what java 9 will bring hehe
6:52:12 PM - Gimpanse: we're using it in a project at work and it's really neat
6:52:43 PM - Cervator: brb
6:52:48 PM - Gimpanse: regardless of the java 8 issue though, I see bundling the JRE as a necessity to remove the burden of having the "right" version from the player
6:53:03 PM - Flo_K: yes, that is a big advantage
6:53:18 PM - Immortius: It does mean we'll need a version per platform, or else we have a slim version and a version per platform.
6:53:21 PM - Flo_K: they are switching to doing that in minecraft too
6:53:30 PM - Immortius: but yeah, I agree it is desirable
6:53:40 PM - Flo_K: just too many players have issues with 32 bit java on 64 bit systems
6:53:48 PM - Gimpanse: I have the required packaging implemented for the launcher right now in gradle
6:53:56 PM - Gimpanse: But I'd prefer having that for the game itself
6:54:15 PM - Gimpanse: otherwise there'd be a headache with version-interdependencies between the JRE version bundled with the launcher and the JRE-less game
6:54:31 PM - Gimpanse: I'd plan on supporting win32/win64/linux32/linux64/macosx
6:54:36 PM - Immortius: well, I think we should stop distributing the game without the launcher
6:54:37 PM - Gimpanse: + a generic one for power users
6:54:58 PM - Gimpanse: hehe i'd go into the other direction, but i'd defer that to the next meeting i guess
6:55:10 PM - Immortius: I barely care about 32 bit systems, but I *guess* we should support them. :P
6:55:23 PM - Immortius: well, either way.
6:55:39 PM - Gimpanse: heh i'd probably not support 32-bit either, but there are some people that still have 32-bit OS's on 64-bit machines
6:55:54 PM - Immortius: like my work :(
6:56:03 PM - Gimpanse: yup, my previous employer had that as well
6:58:20 PM - Halamix2_wifi [~Halamix2@ip-109196061086.syrion.pl] entered the room.
6:59:50 PM - skaldarnar1 has left the room (Quit: Ping timeout: 264 seconds).
7:00:27 PM - Halamix2_wifi has left the room (Quit: Client Quit).
7:00:29 PM - Cervator: some people are dead-set against using a launcher too, so we should try to support the game solo - thus desire to add in some module availability inside there too :-)
7:00:41 PM - Halamix2_wifi [~Halamix2@unaffiliated/halamix2] entered the room.
7:01:07 PM - Gimpanse: i dont like launchers either. they always seem like an unnecessary layer between me and the game hehe
7:01:14 PM - Cervator: slim version should be good enough for that though, powerusers can do their own java
7:03:51 PM - Immortius: I've never really worried about launchers, except those for asian mmos that actually exist to start their overly-invasive anti-cheating tech
7:03:53 PM - Gimpanse: i personally would prefer distributing the launcher as a slim version and the game self-contained
7:06:44 PM - Flo_K: I personally got a first bad impression of terasology because I started it without modules
7:06:48 PM - Xanhou has left the room (Quit: Read error: Connection reset by peer).
7:07:05 PM - Gimpanse: yeah me too
7:07:10 PM - Gimpanse: i just think the module-downloader should be in the game
7:07:12 PM - Cervator: better gameplay presentation would help there, but yeah, tons of videos on youtube with noooo modules
7:07:17 PM - Cervator: it should, imho
7:07:41 PM - Cervator: thus lib project for module organizing, i bet that could even be used on a site to some degree :-)
7:08:03 PM - Cervator: (a fancy big module site as opposed to the light weight GitHub page i want)
7:08:17 PM - Gimpanse: the primary problem i see with presenting all this ingame is making the UI for that
7:08:43 PM - Cervator: yup
7:09:16 PM - Immortius: it would be nice to have an embedded browser system for that sort of thing
7:09:18 PM - Cervator: launcher may have a flexibility advantage there, but we must be able to sort of make a mini version not listing all kinds of extra details like news/changelog
7:09:23 PM - Gimpanse: yeah it really would
7:09:30 PM - Gimpanse: but i guess in general the number of dialogs is manageable
7:09:41 PM - Gimpanse: i really thought about rendering javafx stuff to a pixmap
7:09:44 PM - Gimpanse: and displaying that ingame haha
7:09:51 PM - Gimpanse: but the performance woud likely be atrocious
7:10:12 PM - Cervator: :D
7:10:35 PM - Cervator: brrr, getting cold here, and i'm doing a thing or two around the house on occasion, semi-afk
7:11:21 PM - Halamix2_wifi: Maybe small in game (basic info &download) and fancy (more info &download) in launcher?
7:14:04 PM - Flo_K: if the displayed info ingame is standardized (e.g. fixed size image) then no browser is needed for rendering
7:14:49 PM - Gimpanse: yeah i think it's doable
7:14:55 PM - Gimpanse: probably a bit more work than with a browser, but such is life
7:17:14 PM - Flo_K: Gimpanse: next step would be the new launcher + java 8 I think :), do you have plans to activly get that going?
7:17:42 PM - Gimpanse: well i do have a version of the launcher with a bundled JRE
7:17:51 PM - Gimpanse: but i have to work on an incremental game updater to make that worthwhile
7:18:29 PM - Flo_K: incremental game updater? Would then the game contain the JRE?
7:18:35 PM - Flo_K: (instead of launcher)
7:18:54 PM - Gimpanse: well right now the updater would incrementally update the launcher too
7:19:03 PM - Gimpanse: but i guess that depends on what should be the primary download
7:19:12 PM - Gimpanse: if you can download the game individually. it should probably also be able to update itself
7:19:53 PM - Flo_K: hmm, not sure if that feature is needed
7:20:12 PM - Flo_K: I think having the update functionity in the launcher is the right place
7:20:21 PM - Flo_K: I mean that is what a launcher is mainly for isn't it?
7:20:28 PM - Halamix2_wifi: Yup
7:20:35 PM - Gimpanse: is it? :P
7:20:40 PM - Gimpanse: i remember the good old diablo 2 days
7:20:43 PM - Gimpanse: where the game just updated itself
7:21:19 PM - Halamix2_wifi: But what if someone wants to test/play older version?
7:21:40 PM - Gimpanse: you'd have to download that old version from a website and dont update
7:22:06 PM - Flo_K: if not for updating, what is the launcher then good for?
7:22:29 PM - Flo_K: (if JRE is in game too)
7:22:29 PM - Gimpanse: managing multiple versions of the game?
7:22:46 PM - Flo_K: hmm but if the version updates itself and be another version
7:22:51 PM - Gimpanse: but only up
7:22:57 PM - Gimpanse: and only within it's own "branch"
7:23:02 PM - Gimpanse: so not to testing versions for example
7:23:34 PM - Flo_K: sounds to me a bit like mixed reponsibilities
7:23:53 PM - Flo_K: I would have seen the launcher as version manager that is then also responsible for getting new versions
7:23:54 PM - Gimpanse: look at it from the player's perspective
7:24:03 PM - Gimpanse: how many minecraft players really play different versions of minecraft at the same time
7:24:06 PM - Gimpanse: i'd argue, not that many
7:24:12 PM - Gimpanse: but they still push their launcher for whatever reason
7:24:53 PM - Flo_K: so?
7:25:19 PM - Halamix2_wifi: I still see many 1.4.7 (or 1.6.4, I don't remember ) servers because mods are not compatible with newer ones
7:25:48 PM - Halamix2_wifi: And there everything is modular
7:26:02 PM - Flo_K: I am not sure what your argument is gimpanse
7:26:28 PM - Gimpanse: argument for what exactly?
7:26:29 PM - Flo_K: in minecraft you mainly use the launcher to switch to verions servers need and to try out the latest snapshot
7:26:45 PM - Flo_K: your argumentation about "look at it form player's perspective"
7:27:08 PM - Gimpanse: well yes. i could be wrong here, but i rarely need multiple versions at the same time
7:27:27 PM - Gimpanse: for some reason minecraft exists in a vacuum there
7:27:36 PM - Gimpanse: look at openttd for example
7:27:40 PM - Cervator: i've been close to that myself - chances are if you play on two different servers you need two different versions, haha
7:27:59 PM - Gimpanse: that's cool, just use a version-manager :P
7:28:03 PM - Cervator: it is probably from the pretty much unmatched size of the modding community :-)
7:28:04 PM - Gimpanse: but why is it *required* to use that?
7:28:12 PM - Cervator: it shouldn't be, imho
7:28:35 PM - Cervator: but i dunno if auto-updating in the game should be default? the launcher offers a self-update on startup, could the game do the same?
7:29:24 PM - Gimpanse: i would do it asynchronously on the main screen
7:29:33 PM - Gimpanse: i.e. upper right corner "Looking for updates..." and if it finds one, it offers it
7:29:37 PM - Gimpanse: but players can just skip into a game
7:29:41 PM - Gimpanse: minimizing the time from start to ingame
7:29:57 PM - Flo_K: so your goal is to get rid of the launcher?
7:30:15 PM - Gimpanse: for simple use cases? i dont want to *have* to use it
7:30:58 PM - Halamix2_wifi: Or don't add autoupdate, leave launcher as it is, maybe add command line option for launcher to automatically download and run newest version?
7:31:43 PM - Halamix2_wifi: (It's too late for thinking...)
7:31:46 PM - Flo_K: if the updating is done ingame, what would be done in the launcher?
7:32:06 PM - Flo_K: theoretically everything could be moved ingame
7:32:09 PM - Cervator: multiple versions, more informative module / gameplay browsing, various launch settings (memory settings)
7:32:13 PM - Cervator: nah not everything :-)
7:32:24 PM - Gimpanse: managing multiple installations doesn't make sense ingame
7:32:34 PM - Cervator: i would love to also use the launcher for server admin
7:32:46 PM - Cervator: launch headless from launcher, then get a console in the launcher linked to the server
7:33:22 PM - Cervator: you can do all that stuff manually with just the game if you want, but they're nice conveniences in the launcher
7:33:34 PM - Halamix2_wifi: (someone launches older version through launcher and game itself cjecks for newer versions)
7:33:47 PM - Gimpanse: you can always reject the update
7:33:56 PM - Gimpanse: or the launcher could disable the auto update check in the game config for that version
7:34:04 PM - Cervator: oh, launcher could just ... yeah, that :-)
7:34:23 PM - Cervator: just make another command line flag the launcher uses
7:35:02 PM - Cervator: i think there are solid cases for both game auto-update (easy) and the launcher
7:35:20 PM - Cervator: game stays minimal for startup stuff, launcher gives you all kinds of options
7:35:24 PM - Flo_K: I guess both viewpoints are valid: the launcher could update the game. Or the launcher could just be a game installation manager
7:35:35 PM - Cervator: both use the same module manager lib inside to download modules
7:35:44 PM - Gimpanse: you are right though. there isn't that much a launcher needs to do
7:36:05 PM - Cervator: nah, not *need* - just lots of optional stuff :-)
7:36:12 PM - Gimpanse: why would you want to put a module downloader into the launcher if the game can do it?
7:36:30 PM - Flo_K: against having the updating in the game is: It is specific to a certain way of getting the game
7:36:56 PM - Gimpanse: huh? why? doesn't that apply 1:1 to the launcher as wel?
7:36:58 PM - Gimpanse: ~wll
7:36:58 PM - Gooey: Gimpanse: No factoid for wll
7:36:58 PM - Flo_K: if we have in 1 year a differnt structure of how we save updates, then the game won't be able to deal with it
7:37:00 PM - Gimpanse: argh
7:37:00 PM - Cervator: launcher can display nice big "mod pack" style presentations, including lots of news, changelogs, and so on
7:37:12 PM - Flo_K: There is no reason to get a old launcher
7:37:19 PM - Gimpanse: Flo_K: would we even provide updates to old versions in over a year?
7:37:57 PM - Gimpanse: to use the minecraft analogy. that would only apply if mojang released an update to minecraft 1.0.0
7:38:19 PM - Cervator: or if a player doesn't play for a year :-)
7:38:29 PM - Cervator: although that's sort of an edge case
7:38:32 PM - Gimpanse: true. but you can always provide one last update on the old infrastructure
7:38:35 PM - Gimpanse: that updates the updater :P
7:38:38 PM - Cervator: yup
7:38:41 PM - Cervator: brb
7:38:42 PM - Gimpanse: which also applies to the launcher self updater btw
7:38:52 PM - Gimpanse: since there is no guarantee that the newer launcher versions will import your old game installations
7:39:45 PM - Flo_K: about need to update old istallations: propably not. But it would try to update
7:39:57 PM - Flo_K: if you downloaded an old version
7:40:01 PM - Flo_K: and try to run it
7:40:06 PM - Gimpanse: and since it would be asynchronous, it would spin for a bit and then say "no upgrade available"
7:40:11 PM - Gimpanse: which in my eye would be acceptable
7:40:24 PM - Gimpanse: while not preventing the player from proceeding in the main menu
7:40:31 PM - Gimpanse: i would *not* make the auto update check a mandatory modal dialog at the beginning
7:41:24 PM - Cervator: async like that is nice
7:41:37 PM - Flo_K: also to take in mind: a launcher could run in background too and download the next version
7:41:57 PM - Gimpanse: that is the primary use case for big game launchers, that is correct
7:42:00 PM - Gimpanse: but how big are our releases, really?
7:42:30 PM - synopia: hi there
7:42:37 PM - Flo_K: hi synopia
7:42:44 PM - synopia: hi Flo_K
7:42:44 PM - Halamix2_wifi: Hi
7:42:47 PM - Cervator: heya synopia :-)
7:43:05 PM - Cervator: Gimpanse: engine alone should remain small, 40-50mb right now - some gameplay module series could be huge though :-)
7:43:31 PM - Halamix2_wifi: (Stupid question :modules can be updated too?)
7:43:36 PM - Gimpanse: that would be plus for the launcher then
7:43:40 PM - Immortius: To me, the problem with updating the game in game is you have to restart the game as part of the update process (unavoidable), so it is (a) easist to do that outside of the game and (b) avoids the user having to load the game, update and load the game again.
7:43:58 PM - Gimpanse: Immortius: that is true, but applies to the launcher self update as well
7:44:11 PM - Cervator: launcher is tiny tho :-)
7:44:22 PM - Gimpanse: oh i mean the self-restart
7:44:37 PM - Gimpanse: and it might not be true depending on where the "starting point" is (-> JRE)
7:45:03 PM - Cervator: Halamix2_wifi: modules auto-updating - you'd probably again want an option , with info loading in the background
7:45:28 PM - Halamix2_wifi: And we have, let's say tera.jar launched, it cannot update *itself*, so tera2.jar is created , and game quits. Now tera must be removed somehow and tera2 tenamed, am I right?
7:45:29 PM - Cervator: in either case that would happen inside the ModuleManager which could be used the same both in-game and in-launcher
7:45:51 PM - Cervator: i dunno how the launcher does it, but probably something like that
7:46:02 PM - Gimpanse: Halamix2_wifi: that's standard self-updater fare. Usually you'd make a copy of yourself that you then launch to actually *make* the update
7:46:10 PM - Immortius: with modules, you don't really update them. you download the new version and it coexists.
7:46:23 PM - Cervator: that too, versioned files
7:47:04 PM - Cervator: incidentally, just as a side note with people active on here: thank you all :-) i really enjoy this project and our work together
7:47:21 PM - Flo_K: same
7:47:36 PM - Gimpanse: We could have an issue when we bundle the JRE with the launcher though, and that is having a JRE upgrade in the future where older versions that could be downloaded through the launcher would still require the old JRE version
7:47:54 PM - Cervator: i feel like i can finally do something else today, but i just want to go fix things, organize things, and so on, haha
7:48:49 PM - synopia: is the java8 poll finished already?
7:48:54 PM - synopia: wanna vote for j8!
7:48:55 PM - synopia: :-D
7:49:04 PM - Cervator: no poll :D we're going there, just question of when
7:49:19 PM - Halamix2_wifi: I thought that apps cpmpiled with older jdk can be run with newer one (compile on 7, run with 8)
7:49:23 PM - Cervator: Gimpanse: i think i get you, but you're getting to my level of worrying about things :D we should just do it already :-)
7:49:39 PM - Cervator: sure, that too
7:50:22 PM - Flo_K: Gimpanse: I don't mind much about a self updating game but to me it looks kind of redundant if the launcher is able to download a specific version too
7:50:26 PM - Immortius: generally but not always, Halamix2_wifi
7:50:45 PM - Immortius: but this is an more about switching to compile on 8 to get the new features
7:50:47 PM - Cervator: Flo_K: there is a good chance we can use the same process for both :)
7:50:48 PM - Flo_K: synopia: btw. will you have time to continue to work on your behavior tree stuff in the near future?
7:50:49 PM - Halamix2_wifi: Writing on mobile is neither comfortable nor fast :(
7:50:52 PM - Gimpanse: Flo_K: I kinda see the launcher as a branch-switcher, while the game itself only updates within the branch it is from
7:50:56 PM - Cervator: so it isn't necessarily extra work
7:51:20 PM - Gimpanse: but i will re-consider :P
7:51:36 PM - synopia: Flo_K: yes, i am on it
7:51:39 PM - Immortius: I need to think about if and how to leverage lambdas in our current systems
7:51:41 PM - Gimpanse: i guess if the launcher is the thing that users download from the terasology site and it becomes "integral" it would also be fine
7:51:42 PM - Cervator: Halamix2_wifi: however, writing on mobile leads to auto correct, auto correct leads to suffering, suffering leads to the dark side, and the dark side leads to entertainment
7:51:51 PM - Gimpanse: but maintaining both worlds with a full feature set sounds insane
7:52:03 PM - Gimpanse: Immortius: One thing I saw was all the GUI callback code
7:52:08 PM - Immortius: the interface improvements have an obvious role in the future use of interfaces in components
7:52:10 PM - Gimpanse: That looked like prime material for lambdas
7:52:19 PM - Flo_K: Gimpanse: I see, well I don't mind much either way. I just wanted you to also have considred the points I mentioned :)
7:52:30 PM - Cervator: most the functionality shared between launcher and game can be truly shared and not be extra work imho :-)
7:52:45 PM - Gimpanse: There's quite a bit of GUI logic involved though
7:53:10 PM - Gimpanse: Complete context switch here... Have you considered confluence as a central wiki, Cervator?
7:53:33 PM - Cervator: not really, as i think we need to self-host that one :-) i'm familiar with it though
7:53:44 PM - Cervator: we can get a freebie license, sure, but ...
7:53:52 PM - Flo_K: @synopia: nice, what exactly is that behavior tree 2 stuff?
7:53:56 PM - Halamix2_wifi: (Too much for one day. And too late (2
7:54:01 PM - synopia: Flo_K: the central question is, what we will gain using behavior trees
7:54:01 PM - Cervator: as for personal preference, i dunno, something irks me about Confluence
7:54:12 PM - Gimpanse: we recently got it at work
7:54:23 PM - Halamix2_wifi: Gtg
7:54:24 PM - Gimpanse: and i am very impressed by its editor
7:54:30 PM - synopia: Flo_K: its kinda different from the existing entity/system stuff
7:54:37 PM - Gimpanse: and the navigational feature + subspaces for project documentation
7:54:38 PM - Cervator: probably beats a lot of other options :-) is probably great especially when you use other Atlassian stuff
7:54:41 PM - Cervator: later Halamix2_wifi
7:54:49 PM - Immortius: farewell
7:54:52 PM - Gimpanse: To be honest i dont really care all that much about the other atlassian stuff heh
7:54:55 PM - Gimpanse: bye Halamix2_wifi
7:54:57 PM - Halamix2_wifi has left the room (Part: "1:55").
7:55:04 PM - Cervator: they have good integrations i'm sure
7:55:06 PM - Gimpanse: I had to work with bamboo. Not that impressed
7:55:12 PM - Cervator: me neither ;-)
7:55:16 PM - Flo_K: Flo_K: so defining behavior trees is competlty differnt?
7:55:30 PM - Gimpanse: I worked with TeamCity before which costs roughly the same and is better
7:55:31 PM - Flo_K: Synopia: I mean
7:55:35 PM - synopia: ;-)
7:55:52 PM - Gimpanse: But regarding confluence, for me it's more about the sidebar navigation, "spaces" and mostly the editor, really
7:55:58 PM - Gimpanse: I am a very very lazy guy when it comes to writing wiki pages
7:56:05 PM - Gimpanse: The confluence editor makes that easier hehe
7:56:08 PM - Cervator: :-)
7:56:33 PM - Cervator: we can probably help out our poor GitHub wiki some with more & better sidebar/footer stuffs
7:56:35 PM - Immortius: when I did something similar to behavior trees in unity, I had an entity per behavior node. but doing it that way inTerasology is annoying without multi-entity prefabs.
7:56:42 PM - Cervator: but yeah editor probably stays simple
7:56:45 PM - Flo_K: synopia: I started a bit with writing a behavior tree node that searches the nearby area for entities with a certain component
7:56:49 PM - synopia: most stuff of any future game developed using terasology would probably work perfectly without behavior trees
7:57:16 PM - synopia: i recently coded a small tower defense game using libgdx
7:57:27 PM - synopia: there is an entity system like we use
7:57:42 PM - Cervator: on BTs, i reeeaaaally like the in-game editor, i might not use it, it might not even be that useful for all i know, but it looks soooo cool :D
7:57:43 PM - synopia: so i can see, where all this stuff is going in real games
7:58:11 PM - synopia: for my td i need a behavior tree for calculating damage :-D
7:58:48 PM - synopia: so i will use my jdt project and the result should be integrated into terasology
7:58:59 PM - Flo_K: synopia: I am a bit confused, you seemed to have just said that you are working on behavior trees 2.0 but you thinkg behavior trees aren't good?
7:59:14 PM - synopia: i wonder, if we really need them
7:59:28 PM - synopia: wait, i push some code
7:59:33 PM - Cervator: they seem like a good option, but maybe not the only option :-)
7:59:37 PM - Cervator: cool
8:00:38 PM - Flo_K: I am a bit suprised to say the least
8:01:19 PM - Gimpanse: Cervator: would you use the github wiki for end user documentation?
8:01:30 PM - Flo_K: I mean that you implemented behavior trees in the first place means that you were confinced that they are good and now you doo a 180 degree turn
8:02:49 PM - synopia: no 180 degrees
8:03:05 PM - synopia: but i dont like the idea to have features, that we dont need
8:03:22 PM - synopia: if we find a good reason to have bt, fine
8:03:40 PM - synopia: if not, we should not put more energy into this topic
8:03:51 PM - synopia: https://github.com/synopia/tdx
8:04:03 PM - synopia: https://github.com/synopia/tdx/tree/master/core/src/com/synopia/tdx
8:04:20 PM - synopia: in the packages component and systems you see all the components and systems
8:04:25 PM - synopia: much like in terasology
8:05:59 PM - synopia: here i included the pathfinder into the movement system - so you just add a component MovemenntComponent to any entity and it will find its path to target
8:06:07 PM - Cervator: Gimpanse: that part - not so sure. I might reserve Github wiki for the basics + development then later auto-generate a Github Page with more in-depth objective doc
8:06:23 PM - Cervator: the Index site and individual module readmes would factor in too
8:06:35 PM - synopia: now, when i review this code, i hardly find situations, where the bt would improve code quality
8:06:51 PM - Gimpanse: hmhmhm that doesn't sound so bad actually
8:07:05 PM - Gimpanse: ah well, i guess i gotta try to write some github wiki pages hehehe
8:07:06 PM - Flo_K: how would you make a entity change the behavior?
8:07:13 PM - Flo_K: e.g.
8:07:14 PM - Cervator: community / third party sites can host the more traditional wikis too :-)
8:07:17 PM - synopia: except for the effectsystem, which is in fact a PERFECT example for behavior trees :-D
8:07:19 PM - Flo_K: I made a stray behavior tree
8:07:28 PM - Flo_K: where the entity waits 3s
8:07:36 PM - Flo_K: and then walks to a random block
8:07:41 PM - Cervator: Gimpanse: github wiki actually isn't bad :-) it is basic, but cool
8:07:44 PM - Flo_K: and then waits again 3s after it arrived
8:08:16 PM - synopia: i dont say, we dont need it - i just ask myself, if its worth the work :-D
8:08:29 PM - Flo_K: but we already have behavior trees
8:08:30 PM - Flo_K: ?
8:08:33 PM - synopia: yes
8:08:36 PM - Flo_K: can't we just go with them
8:08:44 PM - synopia: no
8:08:45 PM - synopia: :-D
8:08:48 PM - synopia: maybe
8:08:59 PM - synopia: cant remember, but there was a problem
8:09:01 PM - Cervator: haha you're as indecisive as i am
8:09:05 PM - Cervator: :)
8:09:06 PM - synopia: https://github.com/synopia/jbt
8:09:14 PM - synopia: this is my new implementation
8:09:22 PM - Gimpanse: Cervator: *sigh* any way of getting you aboard the confluence train? haha :)
8:09:38 PM - Cervator: hehe i like the github life
8:09:39 PM - synopia: but its so much crazy stuff, just for behavior trees... so i am not so sure anymore :-)
8:10:03 PM - Cervator: i have an old $5 confluence premium license and everything, but it takes hosting last i knew :)
8:10:03 PM - synopia: (i basicllay compile the behavior tree into jvm bytecode :-D)
8:10:24 PM - Gimpanse: they have a hosted version, but i dont know if the open source license applies to that too
8:11:46 PM - synopia: but, in this implementation are all behavior nodes that we need - we should never need any more (in the current implemention in terasology, you extend from the node class
8:11:50 PM - Cervator: even if so probably some sort of usage limitation
8:12:17 PM - synopia: but i think this is the wrong way
8:12:17 PM - Gimpanse: Cervator: it seems it does apply though, they specifically mention that for "OnDemand" (-> Atlassian Cloud) checking the opensource application takes longer
8:12:24 PM - Gimpanse: But yeah, i'll shut up about it hehehe
8:12:32 PM - Flo_K: synopia: what is wrong?
8:12:36 PM - Gimpanse: i will try to get the motivation to write down my JRE thoughts in a github wiki page
8:12:44 PM - synopia: performance
8:13:26 PM - Cervator: Gimpanse: for me it is sort of like this: if somebody is willing to put in the effort to port to a new tool to where it is superior than what we have *and* maintain it better than currently then it most certainly an option - but usually we do not get that far :-)
8:13:33 PM - Flo_K: and that is better in your behavior tree 2 version?
8:13:34 PM - synopia: if you have a full blown behavior tree for every entity instance, it may be a huge performance issue
8:13:51 PM - Flo_K: Cervator reported some performance issues with 20 deers
8:13:53 PM - Gimpanse: oh if *that* is the problem i can probably get something together hehe
8:13:59 PM - Gimpanse: i will check what the reqs for confluence are though
8:14:07 PM - Flo_K: although it is unclear what the exact performance issue was
8:14:09 PM - Gimpanse: if they host it, that would certainly be the best option
8:14:11 PM - Gimpanse: less maintenance
8:14:24 PM - glasz: maybe we need some practical case
8:14:36 PM - synopia: yes, we do
8:14:46 PM - Cervator: righto - that's just to make it an option for me though, it may still be preferred more by others as-is :-) lots of cool github integrations
8:14:51 PM - synopia: that is why i built this td thing
8:14:58 PM - Cervator: and yeah deers go funny in numbers
8:14:59 PM - Gimpanse: even with the wiki?
8:15:14 PM - Gimpanse: how does the permission stuff work by the way? i haven't looked into that
8:15:20 PM - Cervator: yep, being that you can push to it with Git
8:15:21 PM - Gimpanse: can you give wiki permissions separate of code?
8:15:44 PM - Cervator: options are limited, you can leave it open or lock down to users with push rights to the repo
8:16:27 PM - Cervator: generally it is so easy to have multiple repos you can always have an open wiki and a more permissive repo - even private ones if you are paying for some private repos
8:16:35 PM - Gimpanse: yeah that's true
8:16:50 PM - Flo_K: it was a informative evening, but I have to go to bed now seriously (2:17 AM here)
8:16:53 PM - Cervator: and i love the automation, everything matches with repos and readmes and so on
8:17:00 PM - Flo_K: synopia: maybe we can talk another time about behavior trees
8:17:02 PM - Cervator: thanks for staying up Flo_K :D
8:17:07 PM - Flo_K: good night everyone
8:17:10 PM - Gimpanse: ugh same time for me
8:17:17 PM - Cervator: g'night :)
8:17:21 PM - Gimpanse: you are right, i should go too
8:17:30 PM - Gimpanse: i will try to write something down regarding packaging / JRE / updating stuff
8:17:36 PM - Gimpanse: there's quite a lot of work involved in that area
8:17:44 PM - Gimpanse: good night
8:17:50 PM - Cervator: cool - keep in mind forum is better for design / discussion
8:17:58 PM - Flo_K has left the room (Quit: Konversation terminated!).
8:18:00 PM - Cervator: although maybe not for examples etc
8:18:51 PM - Gimpanse: i think there should be a forum thread (or multiple) about it, yes
8:19:30 PM - synopia: mh cant find that link about the behavior tree stuff
8:19:47 PM - Cervator: what link?
8:20:00 PM - synopia: http://aigamedev.com/insider/presentations/behavior-trees/
8:20:04 PM - synopia: maybe its in there
8:20:23 PM - synopia: it was a comparison of different implementations
8:20:35 PM - Cervator: oh, yeah, i remember you referencing stuff in there long ago
8:20:58 PM - synopia: the obvious implementation, the data driven thing (this is the current terasology impl) and another thing
8:22:00 PM - synopia: which timezone flo lives in?
8:22:16 PM - Cervator: germany iirc
8:22:25 PM - synopia: cant guess the location by his ipv6
8:22:27 PM - synopia: :-D
8:22:52 PM - synopia: ok, so i should meet him another time here
8:24:00 PM - synopia: i only hope, i did not killed his motivation :-)
8:24:03 PM - Cervator: yep :-)
8:24:08 PM - Cervator: just confused him i think, hehe
8:24:15 PM - Gimpanse: he's from germany as far as i know
8:24:18 PM - Cervator: he saw a system that worked and started using it :-)
8:24:30 PM - synopia: great
8:24:32 PM - synopia: :-)
8:24:48 PM - Cervator: he wants to get things working in-game better yesterday. so now i bet he's wondering if we're losing a nice system that works
8:25:31 PM - nh_99: hallo
8:25:31 PM - synopia: we wont - as long as it doesnt do any bad things, i see no reason to remove anything right now
8:25:39 PM - nh_99: does the dev meeting continue m
8:25:43 PM - nh_99: *?
8:25:48 PM - Cervator: heyo nh_99 - you're about two hours late :D
8:25:52 PM - nh_99: lol
8:25:56 PM - nh_99: I have the playback
8:26:01 PM - nh_99: did it finish m
8:26:04 PM - nh_99: *?
8:26:05 PM - Cervator: but we've still been talking on and off :-)
8:26:10 PM - nh_99: I was there for some of it
8:26:16 PM - nh_99: heheh
8:26:20 PM - Cervator: some are drifting off to sleepy time
8:26:39 PM - synopia: is there a 'agenda'for the meetings?
8:26:43 PM - Cervator: so probably getting more quiet but if there are topics and people there can be talk
8:26:48 PM - nh_99: did you do the ZNC's
8:27:00 PM - Cervator: this time there was, yeah : http://forum.terasology.org/threads/upcoming-dev-meeting-alpha-more.1179
8:27:07 PM - Cervator: haven't done ZNCs yet no
8:27:14 PM - Cervator: you said you can host more?
8:27:32 PM - nh_99: of course
8:27:38 PM - Cervator: or show me how to set it up somewhere? we could probably just add it to one of our servers
8:27:45 PM - synopia: znc?
8:27:49 PM - nh_99: either way
8:27:56 PM - nh_99: synopia, yeah
8:27:58 PM - Cervator: auto-online IRC magic
8:28:02 PM - nh_99: with push notifications
8:28:06 PM - Cervator: or always-online, rather
8:28:10 PM - synopia: ah, i see
8:28:33 PM - Cervator: it is just a yum install something, put in some config, attach phone, done?
8:28:53 PM - nh_99: oh god, that's right, yum :)
8:29:04 PM - nh_99: I use debian, lol
8:29:06 PM - Cervator: om nom yum
8:29:11 PM - Cervator: brb
8:29:11 PM - nh_99: but
8:29:16 PM - nh_99: I'll check :)
8:29:42 PM - synopia: irssi for president :-P
8:30:11 PM - nh_99: lol
8:30:12 PM - Gimpanse has left the room (Quit: Leaving.).
8:30:16 PM - nh_99: I use irssi
8:30:24 PM - nh_99: znc is just my bouncer
8:30:32 PM - nh_99: always online ftw!
8:30:44 PM - synopia: why you need a bouncer, when you have irssi?
8:30:59 PM - nh_99: because I can't always leave my laptop on
8:31:28 PM - nh_99: and znc is a better all around solution for always on irc than running an instance of znc on my server
8:31:33 PM - synopia: i have a small server somewhere, with irssi running - so i only need to ssh there and screen -x
8:31:57 PM - nh_99: yeah, I connect with many clients
8:32:02 PM - nh_99: not just irssi
8:32:09 PM - nh_99: I do it from my phone too
8:32:18 PM - synopia: oki, thats a problem with irssi
8:32:27 PM - nh_99: yeah
8:32:41 PM - synopia: but its good to have some time without this :-P
8:32:51 PM - nh_99: lol
8:33:40 PM - synopia: and there is a irssi google app
8:33:41 PM - synopia: :-D
8:33:46 PM - synopia: its a ssh terminal
8:34:26 PM - synopia: but it eats power and is a usability horror show
8:34:44 PM - nh_99: lol
8:34:53 PM - nh_99: I use yaaic on android
8:34:59 PM - nh_99: just connect right into my bouncer
8:35:51 PM - nh_99: Cervator: http://wiki.znc.in/Installation#Fedora.2FCentOS.2FRed_Hat_Enterprise_Linux
8:35:57 PM - nh_99: does zat work?
8:37:43 PM - synopia: is there an official tersology channel for german speaking ppl?
8:38:47 PM - glasz has left the room (Quit: Remote host closed the connection).
8:43:33 PM - Cervator: back
8:43:52 PM - Cervator: synopia: i don't think so, am not sure the main german is active anymore either
8:43:59 PM - Cervator: main german forum, that is
8:44:04 PM - Cervator: haven't heard from Phillaxx forever
8:44:47 PM - Cervator: nh_99: thx checking :)
8:45:01 PM - synopia: yea, i message flo in forum, there i can just use german for conversations with him
8:45:27 PM - Cervator: sure :)
8:50:00 PM - Cervator: sheesh, forum droplet uptime is already at 112 days, haven't had to do a thing to it
9:05:21 PM - synopia: pew, done
9:06:54 PM - synopia: Cervator: your mail was perfectly timed - the behavior trees was the missing part of my td thing :-D
9:07:07 PM - synopia: were
9:07:17 PM - synopia: <- drunk, much, too
9:08:09 PM - synopia: now, if i can integrate them into the effect system of the td, it should be a good example to verify its usefulness
9:08:28 PM - synopia: usefulnes? is that a word?
9:12:42 PM - angeles: If you don't like the idea of using IRC bouncers, I recommend irccloud
9:13:22 PM - angeles: I get mobile notifications and always online, plus I can use it in any browser.
9:16:07 PM - Cervator: synopia: hehe, nice - drunk coding best coding? "usefulness" is indeed a word
9:16:41 PM - Cervator: angeles: thanks - almost looks like Slack
9:16:55 PM - Cervator: which i really should be using, i set it up but i think it stopped and i didn't get any more notifications ...
9:17:19 PM - Cervator: anyway, afk a while :-)
9:17:26 PM - angeles: Cya
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment