IRCLogs • ArmaNelgTron.tk

Log from 2018-03-27:
[00:44:10] <Z-Man> Lucifer_arma: IIRC, it's super easy, like C structs.
[00:44:10] <Z-Man> If you have message A, it can just include message B as a sub-message.
[00:44:11] <Z-Man> If you later add an optional data element to B, it'll also be in the B that's part of A.
[00:44:37] <Z-Man> (Everything you add needs to be optional if you want to keep compatibility)
[00:44:50] <Z-Man> A and B don't need to be defined in the same file, of course.
[01:27:45] *** Quits: Z-Man (~Z-Man@x59cc99c1.dyn.telefonica.de) (Ping timeout: 256 seconds)
[01:51:18] *** Joins: zmanuel (uid118715@gateway/web/irccloud.com/x-lnmepvozmxvitdeo)
[05:01:13] <Lucifer_arma> zmanuel: so I'm still limited to a tree-like structure, then?  So, if B is a submessage of A, then to get to a member of B, I'd have to do something like A.B['memberofB']?
[05:01:27] <Lucifer_arma> or rather, A.B.memberofB
[05:01:56] <Lucifer_arma> I wouldn't be able to declare B to be something to be added later and have it be included as a peer to A, so I can't access a member of B by going A.memberofB?
[05:02:55] <Lucifer_arma> the idea here is that, in my game network library, I want to add an optional member to each standard message type the library uses to allow people using the library to add optional members to the standard messages without having to create new message types that do the same thing as existing message types
[05:04:40] <zmanuel> That would be inheritance. I don't know if that is supported. On a protocol level certainly not, it would cause chaos with the element ids.
[05:05:30] <Lucifer_arma> Ah, right, duh.  I think it's not supported.  I remember looking, because I wanted all the basic message types to have several members that are the same (message ID, timestamp, etc)
[05:34:50] *** Joins: testman (~ubuntu@160.17.187.35.bc.googleusercontent.com)
[05:35:07] <testman> sup duds
[05:35:18] <Lucifer_arma> dud?
[05:35:24] <testman> Armagetron Advanced 2 with new engine when?
[05:35:39] <Lucifer_arma> um, probably never?  heh
[05:35:43] <testman> :(
[05:35:57] <Lucifer_arma> I'm currently unemployed, if your pockets are deep enough, I could make it happen
[05:36:16] <testman> how deep?
[05:36:24] <testman> I can throw 100 EUR at you
[05:36:48] <Lucifer_arma> that wouldn't get me far enough to be able to commit in such a way that you wouldn't feel like you threw your money away, sorry
[05:37:29] <Lucifer_arma> I have a plan, but for it to actually happen, I need either a solid income in the meantime (which takes away development time) or a few extra hands coding (which aren't available right now)
[05:37:36] <testman> I should have gotten into Bitcoin around 2011, then I could pay people to make games for me
[05:37:43] <Lucifer_arma> heh
[05:38:00] <Lucifer_arma> yeah, I should've listened to luke-jr and mined  couple back when it was cheap and easy.
[05:38:23] <Lucifer_arma> I could've sat on them and sold them as the bubble went up and made a few bucks
[05:38:32] <testman> I actually tried to use Godot Engine to make something that could become the sequel to Armagetron.
[05:38:42] <Lucifer_arma> but that bubble's going to burst (and may be right now)
[05:38:43] <testman> Actually, why don't you make a Kickstarter or Patreon?
[05:39:11] <Lucifer_arma> I might, if I could get some other people to agree to the plan
[05:39:19] <Lucifer_arma> for that to happen, I have to share the details, heh
[05:39:21] <testman> any ideas for plan yet?
[05:39:30] <Lucifer_arma> yeah, it's simple, really
[05:39:40] <Lucifer_arma> I'm working on a pure python game network library
[05:39:44] <Lucifer_arma> so, first step: make that work
[05:39:58] <Lucifer_arma> second step: make it possible to implement legacy arma network protocol with it
[05:40:14] <Lucifer_arma> third step: tempt zmanuel enough with it that he decides to write a pure python arma server
[05:40:21] <Lucifer_arma> fourth step: write a panda3d game client
[05:41:24] <testman> Do you intentionally want to work so low level / so from scratch?
[05:41:34] <testman> Did you ever check out Godot Engine?
[05:41:36] <Lucifer_arma> it's not that low level
[05:41:54] <Lucifer_arma> zmanuel did.  I sorta looked at it, but I didn't like the "custom" language it uses
[05:42:10] <Lucifer_arma> the two big languages in the game industry right now that matter are python and lua
[05:42:19] <Lucifer_arma> so I'm not going to favor anything that doesn't use one of those
[05:43:02] <Lucifer_arma> and, as far as "from scratch" is concerned, the python standard library provides every single thing the server needs, as it works right now
[05:43:20] <Lucifer_arma> so a pure python arma server, using my network library, would only have one dependency, instead of the 37 dependencies it has right now
[05:43:47] <Lucifer_arma> a  python+panda3d arma server could use the panda engine to improve performance, though, which would give it the exact same dependencies the hypothetical client would have
[05:44:05] <Lucifer_arma> the panda3d engine gives us literally our entire wish list and more for the client
[05:44:21] <Lucifer_arma> including the experimental android port
[05:45:19] <Lucifer_arma> it's a good plan that also results in a solid python game network library being released for other people to use
[05:47:12] <Lucifer_arma> I'm working on the first step of that plan right now, because the primary purpose of the game network library is for me and my son to write games together
[05:48:46] <testman> The "custom" language it uses (GDscript) is the most Python thing I have ever seen besides Python itself.
[05:49:55] <Lucifer_arma> does it have access to the python standard library, as well as the myriad third-party python modules?
[05:50:13] <Lucifer_arma> it's not the language that matters so much as it is the support that comes with it
[05:51:22] <Lucifer_arma> I chose python for my network library for several reasons, besides personal preference.  On Android, you can use Kivy+Jython to run a python app on the JVM
[05:51:49] <testman> oh, nice
[05:51:49] <Lucifer_arma> on the desktop, you can use pygame or Kivy for 2d games, or panda3d for 3d games
[05:52:04] <Lucifer_arma> I think Kivy also support iOS, but I'm not sure about that
[05:52:32] <Lucifer_arma> so, basically, my network library, written in pure python with only the python standard library as dependency, will be extremely flexible
[05:52:58] <Lucifer_arma> one of the use cases I'm using to design it is "implement legacy Arma protocol", regardless of whether or not anybody actually does that
[05:53:03] <Lucifer_arma> but that's how flexible I want it to be
[05:54:51] <Lucifer_arma> if I achieve all of my design goals, then there becomes a real possibility that an arma rewrite with Python happens
[05:55:20] <Lucifer_arma> and the panda3d engine is a top-notch, commercial+academically supported game engine that's not disappearing anytime soon
[05:55:39] <Lucifer_arma> (It's maintained out of CMU, with a number of commercial studios using/supporting it)
[05:57:59] <Lucifer_arma> so, if I were to put a price on what it takes to get that far, we're probably talking several thousand US dollars to take me off the job market and working full-time on this
[06:00:13] *** Quits: Lucifer_arma (~quassel@cpe-66-68-59-243.austin.res.rr.com) (Remote host closed the connection)
[06:00:51] <testman> I don't know how much interest there is for a Armagetron sequel / remake, but probably not enough to crowdfund for full-time job.
[06:02:17] <testman> Maybe you could get some monetary support as an incentive to work in your free time (provided you would have any). But if in all these years there was no interest for more lightcycles, I don't see why there would be now.
[06:02:37] *** Joins: Lucifer_arma (~quassel@cpe-66-68-59-243.austin.res.rr.com)
[06:02:43] <testman> Tron Legacy was 8 years ago and Tron 3 got canned AFAIK
[06:03:55] <Lucifer_arma> well, the "legacy" protocol I'm talking about is the current arma protocol.  If this rewrite happens using my network library, then the new series would use the library's protocol (with customizations as needed) and would only use the current arma protocol for backwards compatibility
[07:28:22] <Lucifer_arma> zmanuel: is there a reason the server *must* report ping to the client?  Or is it reasonable for the client to calculate ping for itself?
[07:34:18] <zmanuel> The arms server mostly sends the ePlayer ping to the clients so that the clients know the pings of the other clients. Once upon a time, this was required for the ping charity time sync algorithm.
[07:34:52] <zmanuel> For itself, the client can calculate its own ping.
[07:39:15] <Lucifer_arma> so there's no technical reason the client shouldn't do it?
[07:39:37] <Lucifer_arma> other than the server has more round-trips to work with, since the client mostly sends commands and acks
[11:15:08] <Lucifer_arma> zmanuel: Turns out there's another Z-man, and he used to work for Microsoft.  http://www.indiegameguy.com/blogs/zman/default.aspx
[12:13:33] *** Joins: G5 (~g5@p200300EB4BCDC600486BE121AB4C0B2D.dip0.t-ipconnect.de)
[14:44:31] *** Quits: zmanuel (uid118715@gateway/web/irccloud.com/x-lnmepvozmxvitdeo) (Quit: Connection closed for inactivity)
[15:40:27] *** Joins: Z-Man (~Z-Man@x59cc9bb7.dyn.telefonica.de)
[15:57:53] *** Quits: Z-Man (~Z-Man@x59cc9bb7.dyn.telefonica.de) (Ping timeout: 248 seconds)
[16:03:23] *** Joins: Z-Man (~Z-Man@x59cc9938.dyn.telefonica.de)
[16:11:11] *** Quits: G5 (~g5@p200300EB4BCDC600486BE121AB4C0B2D.dip0.t-ipconnect.de) ()
[16:49:33] *** Quits: Z-Man (~Z-Man@x59cc9938.dyn.telefonica.de) (Ping timeout: 264 seconds)
[16:56:04] *** Joins: Z-Man (~Z-Man@x59cc9a8b.dyn.telefonica.de)
[16:58:22] <Z-Man> Is that the same ZMan that runs/used to run ZManGames? I'm still on phone internet and it's too painful to look myself.
[17:07:48] <Z-Man> Apparently not.
[17:07:51] <Z-Man> Oh, but I do remember your ZMan from the XNA forums. Seemed like a nice and competent guy.
[17:10:52] <Z-Man> On the topic of no internet, fucking wankers. So in their first "your error report is being processed" message, they ask you not to contact them asking about progress so they can process everyone smoothly.
[17:11:12] <Z-Man> Guess what happens when you do that? They forget about you.
[17:14:24] <Z-Man> I'm pretty sure making any from-scrach project network compatible with armagetron is pointless. By the time the new thing is in a playable state, really absolutely nobody will be playing on the old servers.
[17:14:59] <Z-Man> And unless you completely botch it, nobody but /dev/null would want to connect to the new servers with the old clients.
[17:15:59] <Z-Man> Now, making the new servers able to import old settings and interpret them as best as they can in new game logic, that would be useful.
[18:27:36] <ct|kyle> if the update is sty+ct compadable, I'd update my servers
[18:28:01] <ct|kyle> Bugfarm wild fortress :P
[19:18:02] *** Joins: Long_Shoota (LS@cpc76132-clif11-2-0-cust623.12-4.cable.virginm.net)
[19:18:09] *** Quits: Guest57901823 (~LS@cpc76132-clif11-2-0-cust623.12-4.cable.virginm.net) (Ping timeout: 268 seconds)
[20:31:34] *** Quits: Long_Shoota (LS@cpc76132-clif11-2-0-cust623.12-4.cable.virginm.net) (Read error: Connection reset by peer)
[20:31:44] *** Joins: Long_Shoota (LS@cpc76132-clif11-2-0-cust623.12-4.cable.virginm.net)
[21:24:00] *** Quits: testman (~ubuntu@160.17.187.35.bc.googleusercontent.com) (Remote host closed the connection)
[22:11:11] *** Joins: AmarokNelg (~AmarokNel@unaffiliated/amaroknelg)
[22:11:11] *** Server sets mode: +cnt 
[23:26:46] <Lucifer_arma> Well, Z-man, you just made the best argument for completely breaking compatibility with older versions.
[23:27:11] <Lucifer_arma> ct|kyle: you'd go with a pure python server no problem.  Maybe it sty+ct compatible would be a breeze, so even if it didn't have it out of the box, you'd still go for it :P
[23:27:44] <Lucifer_arma> Z-Man: and, yeah, that's the ZMan from the XNA forums.  I was tired of looking at code, so I was trying to see what it would take to make panda3d work on the xbox 360
View entire month
DISCLAIMER: These logs of public chat may contain some content which may not be appropriate for all audiences. Use at your own risk.
Logs from 2006-2009 pulled from wrtlprnft
Format changes at: 2015-08-25, 2017-02-20, and 2020-03-23. Times (2015 and later) should be Eastern.
. [About this site] [Credits]