From iggyvolz at gmail.com Wed May 6 18:22:31 2015 From: iggyvolz at gmail.com (iggyvolz .) Date: Wed, 6 May 2015 19:22:31 -0400 Subject: [netrek-dev] Netrek Server Code Message-ID: So I haven't been able to find the repository for the server code. Everything seems to point to http://www.netrek.org/repos/netrek-server, which 404's out. Any way to get the repository itself, or has it been lost to time and therefore we must use the latest zipped version to start out from? On a side note - I'd be willing to maintain a GitHub repo for server code unless someone more experienced with the code wants to. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrd at gerdesas.com Wed May 6 18:35:51 2015 From: jrd at gerdesas.com (John R. Dennison) Date: Wed, 6 May 2015 18:35:51 -0500 Subject: [netrek-dev] Netrek Server Code In-Reply-To: References: Message-ID: <20150506233551.GS17115@frodo.gerdesas.com> On Wed, May 06, 2015 at 07:22:31PM -0400, iggyvolz . wrote: > So I haven't been able to find the repository for the server code. > Everything seems to point to http://www.netrek.org/repos/netrek-server, > which 404's out. Any way to get the repository itself, or has it been lost > to time and therefore we must use the latest zipped version to start out > from? The repos are darcs, which are, by nature, distributed. Anything missing from netrek.org can be put back with a minimum of fuss. I was not aware that these were missing. I've pinged James regarding it. > On a side note - I'd be willing to maintain a GitHub repo for server code > unless someone more experienced with the code wants to. I would prefer to keep bits off of github if possible but that's just my opinion which isn't worth much these days. John -- I don't know. Just because we are stupid doesn't mean everybody else was. -- JP Morgan CEO Jamie Dimon, arguing against increased regulation as a response to his company's $2 billion loss, in a conference call, 10 May 2012 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From quozl at laptop.org Wed May 6 18:56:43 2015 From: quozl at laptop.org (James Cameron) Date: Thu, 7 May 2015 09:56:43 +1000 Subject: [netrek-dev] Netrek Server Code In-Reply-To: References: Message-ID: <20150506235643.GE15384@us.netrek.org> http://vanilla.netrek.org/ correctly points to my darcs repositories: http://james.tooraweenah.com/darcs/ I will only accept GitHub workflow once there is work to flow. I use GitHub all the time, but it is _not_ worth using until there is a steady stream of patches. It is also becoming unreliable. For the moment, send patches to me. On Wed, May 06, 2015 at 07:22:31PM -0400, iggyvolz . wrote: > So I haven't been able to find the repository for the server code.? Everything > seems to point to [1]http://www.netrek.org/repos/netrek-server, which 404's > out.? Any way to get the repository itself, or has it been lost to time and > therefore we must use the latest zipped version to start out from? > > On a side note - I'd be willing to maintain a GitHub repo for server code > unless someone more experienced with the code wants to. > > References: > > [1] http://www.netrek.org/repos/netrek-server > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev -- James Cameron http://quozl.linux.org.au/ From iggyvolz at gmail.com Wed May 6 20:45:03 2015 From: iggyvolz at gmail.com (iggyvolz .) Date: Wed, 6 May 2015 21:45:03 -0400 Subject: [netrek-dev] Autoconf not set Message-ID: So I tried to compile the netrek-client-cow from source. However, in Makefile, it specifically on line 81 references $(AUTOCONF), even though it is never set. It also references $(MAKE) even though that is never set. Should these both be set to which autoconf and which make, respectively? For example, add before line 3: AUTOCONF=$(shell which autoconf) MAKE=$(shell which make) Setting these don't make the install go off without a hitch, though. I'm still investigating those errors (specifically I'm getting "undefined macro: AM_PATH_SDL, AM_CONDITIONAL, and AM_GNU_GETTEXT" on running make for the configure.in processing, then it can't find config.sub for ./configure) but I'll submit a separate bug report after I look into it some more, unless someone knows the cause just by a glance. I'm on OS X Mavericks if that makes any difference, although it shouldn't. -------------- next part -------------- An HTML attachment was scrubbed... URL: From quozl at us.netrek.org Wed May 6 21:19:11 2015 From: quozl at us.netrek.org (James Cameron) Date: Thu, 7 May 2015 12:19:11 +1000 Subject: [netrek-dev] Autoconf not set In-Reply-To: References: Message-ID: <20150507021911.GI15384@us.netrek.org> On Wed, May 06, 2015 at 09:45:03PM -0400, iggyvolz . wrote: > So I tried to compile the netrek-client-cow from source. Which source? .tar.gz or darcs? Here is a build after darcs get: http://dev.laptop.org/~quozl/z/1YqBKv.txt Your problem does not reproduce here. > However, in Makefile, it specifically on line?81 references > $(AUTOCONF), even though it is never set. It also references > $(MAKE) even though that is never set.? Should these both be set to > which autoconf and which make, respectively?? For example, add > before line 3: > > AUTOCONF=$(shell which autoconf) > MAKE=$(shell which make) No, these are unused, superfluous. I can remove them. > Setting these don't make the install go off without a hitch, > though.? I'm still investigating those errors (specifically I'm > getting "undefined macro: AM_PATH_SDL, AM_CONDITIONAL, and > AM_GNU_GETTEXT" on running make for the [1] configure.in processing, > then it can't find config.sub for ./configure) but I'll submit a > separate bug report after I look into it some more, unless someone > knows the cause just by a glance. I don't see those problems. > I'm on OS X Mavericks if that makes any difference, although it > shouldn't. You have an X server installed? This code requires an X server, and GNU Autotools. -- James Cameron http://quozl.linux.org.au/ From quozl at us.netrek.org Wed May 6 21:22:43 2015 From: quozl at us.netrek.org (James Cameron) Date: Thu, 7 May 2015 12:22:43 +1000 Subject: [netrek-dev] Netrek Server Code In-Reply-To: References: Message-ID: <20150507022243.GA26504@us.netrek.org> http://vanilla.netrek.org/ correctly points to my darcs repositories: http://james.tooraweenah.com/darcs/ I will only accept GitHub workflow once there is work to flow. I use GitHub all the time, but it is _not_ worth using until there is a steady stream of patches. It is also becoming unreliable. For the moment, send patches to me. On Wed, May 06, 2015 at 07:22:31PM -0400, iggyvolz . wrote: > So I haven't been able to find the repository for the server code.? Everything > seems to point to [1]http://www.netrek.org/repos/netrek-server, which 404's > out.? Any way to get the repository itself, or has it been lost to time and > therefore we must use the latest zipped version to start out from? > > On a side note - I'd be willing to maintain a GitHub repo for server code > unless someone more experienced with the code wants to. -- James Cameron http://quozl.linux.org.au/ From lbrass at gmail.com Wed May 6 21:32:50 2015 From: lbrass at gmail.com (Lawrence Brass) Date: Wed, 6 May 2015 23:32:50 -0300 Subject: [netrek-dev] Netrek for mobiles, really? Message-ID: <37FE2885-D8A6-4FD3-B791-7561F71AE77C@gmail.com> Hello again, I have just subscribed to the dev-list. Should I copy content from from netrek-forever google group? Regards, Lawrence (LarryX). From iggyvolz at gmail.com Wed May 6 21:41:58 2015 From: iggyvolz at gmail.com (iggyvolz .) Date: Wed, 6 May 2015 22:41:58 -0400 Subject: [netrek-dev] Autoconf not set In-Reply-To: <20150507021911.GI15384@us.netrek.org> References: <20150507021911.GI15384@us.netrek.org> Message-ID: I'm assuming Xquartz/X11 fulfills the "X server" requirement? If so, then yes I have both. And what do you mean - "I can remove them"? The first problem is that $(AUTOCONF) (and $(MAKE) for that matter) is not set to anything, so it tries to run the file directly (failing of course). Either the two lines should be added, or the $(AUTOCONF) and $(MAKE)'s should be changed to autoconf and make, or it should be specified in the docs that AUTOCONF and MAKE should point to autoconf and make binaries. I have no idea what the undefined macro means. It seems to be halting execution, which prevent config.sub from being created and configure from being chmod +x'd. I'll look into that more later when I get the chance. On Wed, May 6, 2015 at 10:19 PM, James Cameron wrote: > On Wed, May 06, 2015 at 09:45:03PM -0400, iggyvolz . wrote: > > So I tried to compile the netrek-client-cow from source. > > Which source? .tar.gz or darcs? > > Here is a build after darcs get: > http://dev.laptop.org/~quozl/z/1YqBKv.txt > > Your problem does not reproduce here. > > > However, in Makefile, it specifically on line 81 references > > $(AUTOCONF), even though it is never set. It also references > > $(MAKE) even though that is never set. Should these both be set to > > which autoconf and which make, respectively? For example, add > > before line 3: > > > > AUTOCONF=$(shell which autoconf) > > MAKE=$(shell which make) > > No, these are unused, superfluous. I can remove them. > > > Setting these don't make the install go off without a hitch, > > though. I'm still investigating those errors (specifically I'm > > getting "undefined macro: AM_PATH_SDL, AM_CONDITIONAL, and > > AM_GNU_GETTEXT" on running make for the [1] configure.in processing, > > then it can't find config.sub for ./configure) but I'll submit a > > separate bug report after I look into it some more, unless someone > > knows the cause just by a glance. > > I don't see those problems. > > > I'm on OS X Mavericks if that makes any difference, although it > > shouldn't. > > You have an X server installed? > > This code requires an X server, and GNU Autotools. > > -- > James Cameron > http://quozl.linux.org.au/ > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lbrass at gmail.com Thu May 7 11:22:04 2015 From: lbrass at gmail.com (Lawrence Brass) Date: Thu, 7 May 2015 13:22:04 -0300 Subject: [netrek-dev] Netrek for mobiles, really? In-Reply-To: <37FE2885-D8A6-4FD3-B791-7561F71AE77C@gmail.com> References: <37FE2885-D8A6-4FD3-B791-7561F71AE77C@gmail.com> Message-ID: Copied this fragment from netrek-forever... >> On May 6, 2015, at 7:50 PM, James Cameron wrote: >> >> On Wed, May 06, 2015 at 05:19:33PM -0300, Lawrence Brass wrote: >> I agree, the matrix has us all. >> I browsed the COW-XP client sources last night and liked what I >> saw. It seems that the game logic is isolated from the video stuff, >> the "W_" module implements the glue code between the classic Windows >> API, GDI graphics, inputs and the game. Keyboard and mouse events >> are enqueued in a (single?) event queue. Very clear and classic C, >> even with Allman bracketing style! (tip of the hat). > > Yes, in those days we did peer code reviews. The "W_" module was > added to the client on Unix before it was ported to Windows in 1996. > >> If the "W_" module graphics functionality is reimplemented in say, >> openGL(ES), and the proper native framework code is used to capture >> the events and feed them into the game event queue, is very probable >> that the "game code" could be ported almost untouched to OSX/iOS, >> Plain C is actually a subset of objC and fits nicely. On Android I >> am not that sure (of the cost). The same strategy could be applied >> using the NDK to hold the C game loop and logic, and feed the input >> event queue from the native framework, but it may be harder. Porting >> from the Java clients is a competitive alternative for Android. >> The nice thing about this *hypothetical* scheme is that the game, >> network, and video(using openGL) code would be common and game and >> network stay almost untouched. >> Sounds crazy? > > Yes. Especially because the input devices are entirely different. There should be a mapping, before queuing control events, that would convert swipes and taps into meaningful synthetic keystrokes and mouse movements and clicks that the current game code would understand. This mapping is were the "feel" of the game would be defined. > The "W_" API presumes too much about the input devices and the > underlying graphics libraries. Yes, this would be the hard part. The API should be divided into 2 modules, one for Graphics in open GL, common to all platforms and the other for the input event handling, particular to each platform. I will focus on the "W_" module. I guess that I should look at both unix and win implementations to get more insight. Regards. > On May 6, 2015, at 11:32 PM, Lawrence Brass wrote: > > Hello again, I have just subscribed to the dev-list. > Should I copy content from from netrek-forever google group? > Regards, > Lawrence (LarryX). > -------------- next part -------------- An HTML attachment was scrubbed... URL: From apsillers at gmail.com Fri May 8 08:06:37 2015 From: apsillers at gmail.com (Andrew Sillers) Date: Fri, 8 May 2015 09:06:37 -0400 Subject: [netrek-dev] Netrek for mobiles, really? In-Reply-To: References: <37FE2885-D8A6-4FD3-B791-7561F71AE77C@gmail.com> Message-ID: I saw that my HTML5 client (https://github.com/apsillers/html5-netrek) was already mentioned earlier in the Netrek Forever thread. I just wanted to weigh in a little on on the shape of that code. The code could be turned into a mobile app with Cordova/Phonegap ( https://cordova.apache.org/), and in fact, it already has been, for an other version of the code: https://github.com/apsillers/html5-netrek/tree/phonegap. The code is set up so that the message stream is abstracted away, and you can easily replace the Websocket-based networking with any other message source (e.g., TCP). (Compare `/assets/www/js/net_phonegap.js` in the Phongap branch and `/js/net.js` in master.) Back then, I wrote my own Android TCP plugin for Phonegap, but at least one cross-platform TCP plugin has matured since then: https://github.com/Tlantic/cdv-socket-plugin. However, as a client, it's a bit feature-incomplete; in particular, I recall that ship-refitting and plasmas are totally unimplemented, as is UDP support. (The code assumes only one, reliable message source, so you'd need to expand it a bit to accept two message sources.) It's not clear to me whether it would be less work to modify the C code to interface correctly on mobile devices, or to modify the JavaScript code to include a more complete feature set. One potential easy win (again borrowing from the thread on NT Forever) would be to modify the HTML5 client to implement observer mode, which would provide a quick way to observe games directly in-browser. If you want to invite someone to watch the game, you could send them a URL to tune in immediately. Andrew On Thu, May 7, 2015 at 12:22 PM, Lawrence Brass wrote: > Copied this fragment from netrek-forever... > > On May 6, 2015, at 7:50 PM, James Cameron wrote: > > > On Wed, May 06, 2015 at 05:19:33PM -0300, Lawrence Brass wrote: > > I agree, the matrix has us all. > > I browsed the COW-XP client sources last night and liked what I > > saw. It seems that the game logic is isolated from the video stuff, > > the "W_" module implements the glue code between the classic Windows > > API, GDI graphics, inputs and the game. Keyboard and mouse events > > are enqueued in a (single?) event queue. Very clear and classic C, > > even with Allman bracketing style! (tip of the hat). > > > Yes, in those days we did peer code reviews. The "W_" module was > > added to the client on Unix before it was ported to Windows in 1996. > > > If the "W_" module graphics functionality is reimplemented in say, > > openGL(ES), and the proper native framework code is used to capture > > the events and feed them into the game event queue, is very probable > > that the "game code" could be ported almost untouched to OSX/iOS, > > Plain C is actually a subset of objC and fits nicely. On Android I > > am not that sure (of the cost). The same strategy could be applied > > using the NDK to hold the C game loop and logic, and feed the input > > event queue from the native framework, but it may be harder. Porting > > from the Java clients is a competitive alternative for Android. > > The nice thing about this *hypothetical* scheme is that the game, > > network, and video(using openGL) code would be common and game and > > network stay almost untouched. > > Sounds crazy? > > > Yes. Especially because the input devices are entirely different. > > > There should be a mapping, before queuing control events, that would > convert swipes and taps into meaningful synthetic keystrokes and mouse > movements and clicks that the current game code would understand. This > mapping is were the "feel" of the game would be defined. > > The "W_" API presumes too much about the input devices and the > > underlying graphics libraries. > > > Yes, this would be the hard part. The API should be divided into 2 > modules, one for Graphics in open GL, common to all platforms and the other > for the input event handling, particular to each platform. > > I will focus on the "W_" module. I guess that I should look at both unix > and win implementations to get more insight. > > Regards. > > On May 6, 2015, at 11:32 PM, Lawrence Brass wrote: > > Hello again, I have just subscribed to the dev-list. > Should I copy content from from netrek-forever google group? > Regards, > Lawrence (LarryX). > > > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lbrass at gmail.com Wed May 13 17:41:52 2015 From: lbrass at gmail.com (Lawrence Brass) Date: Wed, 13 May 2015 19:41:52 -0300 Subject: [netrek-dev] Netrek for mobiles, really? In-Reply-To: References: <37FE2885-D8A6-4FD3-B791-7561F71AE77C@gmail.com> Message-ID: <5CA3E8FB-A91C-4855-80A4-F6334BA99AB0@gmail.com> Hello Andrew, It was James that mentioned that your work could be a good starting point for a mobile client. It would be great to have a common code HTML5 client running on desk, lap and mobile platforms. I launched the demo from the project's page in github and actually played with the bots at pickled for a while! I have not actual experience with Cordova or Phonegap but have done, or at least tried to do, things with WebViews on mobiles with mixed results. My concern is about achieving fluidity comparable to actual clients. I guess we should do some minimal implementation just to test that. Do you think that the phonegap tree of your code can be compiled and loaded on Android, as it is? If we take the HTML5 route, I think that the server should be modified to support websocket connections. It would make HTML5 clients life much simpler and would remove the actual HTML5 client dependency on the proxy-adapter. Some interesting links that I found during research: Cordova compatible, "better" WebView: https://crosswalk-project.org openGL-js wrapper/library, looks good: http://www.pixijs.com Regards, Lawrence. On May 8, 2015, at 10:06 AM, Andrew Sillers wrote: > I saw that my HTML5 client (https://github.com/apsillers/html5-netrek) was already mentioned earlier in the Netrek Forever thread. I just wanted to weigh in a little on on the shape of that code. > > The code could be turned into a mobile app with Cordova/Phonegap (https://cordova.apache.org/), and in fact, it already has been, for an other version of the code: https://github.com/apsillers/html5-netrek/tree/phonegap. The code is set up so that the message stream is abstracted away, and you can easily replace the Websocket-based networking with any other message source (e.g., TCP). (Compare `/assets/www/js/net_phonegap.js` in the Phongap branch and `/js/net.js` in master.) > > Back then, I wrote my own Android TCP plugin for Phonegap, but at least one cross-platform TCP plugin has matured since then: https://github.com/Tlantic/cdv-socket-plugin. > > However, as a client, it's a bit feature-incomplete; in particular, I recall that ship-refitting and plasmas are totally unimplemented, as is UDP support. (The code assumes only one, reliable message source, so you'd need to expand it a bit to accept two message sources.) > > It's not clear to me whether it would be less work to modify the C code to interface correctly on mobile devices, or to modify the JavaScript code to include a more complete feature set. > > One potential easy win (again borrowing from the thread on NT Forever) would be to modify the HTML5 client to implement observer mode, which would provide a quick way to observe games directly in-browser. If you want to invite someone to watch the game, you could send them a URL to tune in immediately. > > Andrew > > > On Thu, May 7, 2015 at 12:22 PM, Lawrence Brass wrote: > Copied this fragment from netrek-forever... > >>> On May 6, 2015, at 7:50 PM, James Cameron wrote: >>> >>> On Wed, May 06, 2015 at 05:19:33PM -0300, Lawrence Brass wrote: >>> I agree, the matrix has us all. >>> I browsed the COW-XP client sources last night and liked what I >>> saw. It seems that the game logic is isolated from the video stuff, >>> the "W_" module implements the glue code between the classic Windows >>> API, GDI graphics, inputs and the game. Keyboard and mouse events >>> are enqueued in a (single?) event queue. Very clear and classic C, >>> even with Allman bracketing style! (tip of the hat). >> >> Yes, in those days we did peer code reviews. The "W_" module was >> added to the client on Unix before it was ported to Windows in 1996. >> >>> If the "W_" module graphics functionality is reimplemented in say, >>> openGL(ES), and the proper native framework code is used to capture >>> the events and feed them into the game event queue, is very probable >>> that the "game code" could be ported almost untouched to OSX/iOS, >>> Plain C is actually a subset of objC and fits nicely. On Android I >>> am not that sure (of the cost). The same strategy could be applied >>> using the NDK to hold the C game loop and logic, and feed the input >>> event queue from the native framework, but it may be harder. Porting >>> from the Java clients is a competitive alternative for Android. >>> The nice thing about this *hypothetical* scheme is that the game, >>> network, and video(using openGL) code would be common and game and >>> network stay almost untouched. >>> Sounds crazy? >> >> Yes. Especially because the input devices are entirely different. > > There should be a mapping, before queuing control events, that would convert swipes and taps into meaningful synthetic keystrokes and mouse movements and clicks that the current game code would understand. This mapping is were the "feel" of the game would be defined. > >> The "W_" API presumes too much about the input devices and the >> underlying graphics libraries. > > Yes, this would be the hard part. The API should be divided into 2 modules, one for Graphics in open GL, common to all platforms and the other for the input event handling, particular to each platform. > > I will focus on the "W_" module. I guess that I should look at both unix and win implementations to get more insight. > > Regards. > > On May 6, 2015, at 11:32 PM, Lawrence Brass wrote: > >> Hello again, I have just subscribed to the dev-list. >> Should I copy content from from netrek-forever google group? >> Regards, >> Lawrence (LarryX). >> > > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > > > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From iggyvolz at gmail.com Wed May 13 21:41:11 2015 From: iggyvolz at gmail.com (iggyvolz .) Date: Wed, 13 May 2015 22:41:11 -0400 Subject: [netrek-dev] Client specifications? Message-ID: This is probably a stupid question with a REALLY simple answer, but where (if any) are the specifications for a Netrek client, as in building one from scratch? Looking through the site turned up nothing, and some google searches for "netrek client specifications" and "netrek client documentation" turned up nothing of the sort. -------------- next part -------------- An HTML attachment was scrubbed... URL: From quozl at us.netrek.org Wed May 13 21:43:39 2015 From: quozl at us.netrek.org (James Cameron) Date: Thu, 14 May 2015 12:43:39 +1000 Subject: [netrek-dev] Client specifications? In-Reply-To: References: Message-ID: <20150514024339.GQ12547@us.netrek.org> Could you tell me what type of client specifications you need? We don't generally keep specifications that duplicate the sources, because then we have to maintain two artefacts; the specifications and the sources. -- James Cameron http://quozl.linux.org.au/ From iggyvolz at gmail.com Wed May 13 22:01:05 2015 From: iggyvolz at gmail.com (iggyvolz .) Date: Wed, 13 May 2015 23:01:05 -0400 Subject: [netrek-dev] Client specifications? In-Reply-To: <20150514024339.GQ12547@us.netrek.org> References: <20150514024339.GQ12547@us.netrek.org> Message-ID: Essentially I'm looking for all the things that my client needs to do in order to be called a "netrek client". I'm sure I could guess from the COW sources, but I've never done C so it would be mostly guess-and-check coding with a local server. On May 13, 2015 10:44 PM, "James Cameron" wrote: > Could you tell me what type of client specifications you need? > > We don't generally keep specifications that duplicate the sources, > because then we have to maintain two artefacts; the specifications and > the sources. > > -- > James Cameron > http://quozl.linux.org.au/ > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From quozl at us.netrek.org Wed May 13 23:22:36 2015 From: quozl at us.netrek.org (James Cameron) Date: Thu, 14 May 2015 14:22:36 +1000 Subject: [netrek-dev] Client specifications? In-Reply-To: References: <20150514024339.GQ12547@us.netrek.org> Message-ID: <20150514042236.GS12547@us.netrek.org> No, there's no such thing. Both the client and the server were originally one program (xtrek), written by university students and researchers. There was no specification; the original program and the derivatives grew by gradual accretion. There is later documentation for the server and the protocol, and you'll find them in the server source. The daemon documentation uses doxygen format. The protocol is a plain text description. There are clients using Python, Java, and JavaScript if you'd like to understand better with those languages. Meanwhile, it's probably time you learned C, or you won't be able to understand anything inside Netrek. The best way to learn C is to write in it. -- James Cameron http://quozl.linux.org.au/ From apsillers at gmail.com Thu May 14 10:40:38 2015 From: apsillers at gmail.com (Andrew Sillers) Date: Thu, 14 May 2015 11:40:38 -0400 Subject: [netrek-dev] Netrek for mobiles, really? In-Reply-To: <5CA3E8FB-A91C-4855-80A4-F6334BA99AB0@gmail.com> References: <37FE2885-D8A6-4FD3-B791-7561F71AE77C@gmail.com> <5CA3E8FB-A91C-4855-80A4-F6334BA99AB0@gmail.com> Message-ID: Lawrence, > If we take the HTML5 route, I think that the server should be modified to support websocket connections. It would make HTML5 clients life much simpler and would remove the actual HTML5 client dependency on the proxy-adapter. I completely agree. There was some (very brief) discussion about Websocket server support when I was originally working on the client. There is actually a `ws-direct` branch on the Github repo as well that doesn't use my custom proxy, but assumes a direct Websocket port on the server. You can accomplish WS support easily with websockify ( https://github.com/kanaka/websockify) which is a very straightforward WS-to-TCP proxy. (The difference between my proxy and a websockify proxy is that my proxy has lots of unnecessary Netrek-specific cruft and is also a Web server. The `ws-direct` branch was modified to eliminate my proxy-wrapper protocol and just contact the server directly.) I don't know what kind of performance impact a WS-to-TCP proxy has, but it's a very easy first step, and it can be run on the same machine as the real server, so there's no second network hop. > Do you think that the phonegap tree of your code can be compiled and loaded on Android, as it is? I think so, but (1) it needs to merge in master to update to the most recent UI and Netrek protocol support and (2) it was designed to run on an older version of Android so you might need to tweak the target-platform settings when you set up a project. Otherwise, yes, I would expect it to compile and run okay. Also, I'm not sure what happens if the screen is too small to show the whole UI. I designed the UI to scale down to a certain point (note: that functionality is not present in the current phonegap branch; it needs to be merge in from master), but it caps out at some limit, so you might not see the entire UI on a small screen. If you want to see how the client UI does on a mobile device, you can just navigate to https://netrek-apsillers.rhcloud.com/ in a mobile browser. It should work, for some definition of "work". Tap to shoot, and drag your finger out from your ship to steer. I think you can shoot phasers by holding a finger on your ship and then tapping elsewhere simultaneously. > Cordova compatible, "better" WebView Neat! This indeed looks like a drop-in repalcement for Cordova that might be better. > openGL-js wrapper/library, looks good The HTML5 client uses a canvas library called CAKE.js which is badly out of date, but still works. It might be worthwhile to replace it with another graphics library like this one to get performance improvements and a better UI-event interface. I would personally place this lower on the priority list than getting a working mobile prototype Android app and mildly refactoring the UI, but it definitely seems worthwhile. Andrew On Wed, May 13, 2015 at 6:41 PM, Lawrence Brass wrote: > Hello Andrew, > > It was James that mentioned that your work could be a good starting point > for a mobile client. It would be great to have a common code HTML5 client > running on desk, lap and mobile platforms. > I launched the demo from the project's page in github and actually played > with the bots at pickled for a while! > I have not actual experience with Cordova or Phonegap but have done, or at > least tried to do, things with WebViews on mobiles with mixed results. My > concern is about achieving fluidity comparable to actual clients. I guess > we should do some minimal implementation just to test that. > Do you think that the phonegap tree of your code can be compiled and > loaded on Android, as it is? > > If we take the HTML5 route, I think that the server should be modified to > support websocket connections. It would make HTML5 clients life much > simpler and would remove the actual HTML5 client dependency on the > proxy-adapter. > > Some interesting links that I found during research: > > Cordova compatible, "better" WebView: > https://crosswalk-project.org > > openGL-js wrapper/library, looks good: > http://www.pixijs.com > > Regards, > Lawrence. > > On May 8, 2015, at 10:06 AM, Andrew Sillers wrote: > > I saw that my HTML5 client (https://github.com/apsillers/html5-netrek) > was already mentioned earlier in the Netrek Forever thread. I just wanted > to weigh in a little on on the shape of that code. > > The code could be turned into a mobile app with Cordova/Phonegap ( > https://cordova.apache.org/), and in fact, it already has been, for an > other version of the code: > https://github.com/apsillers/html5-netrek/tree/phonegap. The code is set > up so that the message stream is abstracted away, and you can easily > replace the Websocket-based networking with any other message source (e.g., > TCP). (Compare `/assets/www/js/net_phonegap.js` in the Phongap branch and > `/js/net.js` in master.) > > Back then, I wrote my own Android TCP plugin for Phonegap, but at least > one cross-platform TCP plugin has matured since then: > https://github.com/Tlantic/cdv-socket-plugin. > > However, as a client, it's a bit feature-incomplete; in particular, I > recall that ship-refitting and plasmas are totally unimplemented, as is UDP > support. (The code assumes only one, reliable message source, so you'd need > to expand it a bit to accept two message sources.) > > It's not clear to me whether it would be less work to modify the C code to > interface correctly on mobile devices, or to modify the JavaScript code to > include a more complete feature set. > > One potential easy win (again borrowing from the thread on NT Forever) > would be to modify the HTML5 client to implement observer mode, which would > provide a quick way to observe games directly in-browser. If you want to > invite someone to watch the game, you could send them a URL to tune in > immediately. > > Andrew > > > On Thu, May 7, 2015 at 12:22 PM, Lawrence Brass wrote: > >> Copied this fragment from netrek-forever... >> >> On May 6, 2015, at 7:50 PM, James Cameron wrote: >> >> >> On Wed, May 06, 2015 at 05:19:33PM -0300, Lawrence Brass wrote: >> >> I agree, the matrix has us all. >> >> I browsed the COW-XP client sources last night and liked what I >> >> saw. It seems that the game logic is isolated from the video stuff, >> >> the "W_" module implements the glue code between the classic Windows >> >> API, GDI graphics, inputs and the game. Keyboard and mouse events >> >> are enqueued in a (single?) event queue. Very clear and classic C, >> >> even with Allman bracketing style! (tip of the hat). >> >> >> Yes, in those days we did peer code reviews. The "W_" module was >> >> added to the client on Unix before it was ported to Windows in 1996. >> >> >> If the "W_" module graphics functionality is reimplemented in say, >> >> openGL(ES), and the proper native framework code is used to capture >> >> the events and feed them into the game event queue, is very probable >> >> that the "game code" could be ported almost untouched to OSX/iOS, >> >> Plain C is actually a subset of objC and fits nicely. On Android I >> >> am not that sure (of the cost). The same strategy could be applied >> >> using the NDK to hold the C game loop and logic, and feed the input >> >> event queue from the native framework, but it may be harder. Porting >> >> from the Java clients is a competitive alternative for Android. >> >> The nice thing about this *hypothetical* scheme is that the game, >> >> network, and video(using openGL) code would be common and game and >> >> network stay almost untouched. >> >> Sounds crazy? >> >> >> Yes. Especially because the input devices are entirely different. >> >> >> There should be a mapping, before queuing control events, that would >> convert swipes and taps into meaningful synthetic keystrokes and mouse >> movements and clicks that the current game code would understand. This >> mapping is were the "feel" of the game would be defined. >> >> The "W_" API presumes too much about the input devices and the >> >> underlying graphics libraries. >> >> >> Yes, this would be the hard part. The API should be divided into 2 >> modules, one for Graphics in open GL, common to all platforms and the other >> for the input event handling, particular to each platform. >> >> I will focus on the "W_" module. I guess that I should look at both unix >> and win implementations to get more insight. >> >> Regards. >> >> On May 6, 2015, at 11:32 PM, Lawrence Brass wrote: >> >> Hello again, I have just subscribed to the dev-list. >> Should I copy content from from netrek-forever google group? >> Regards, >> Lawrence (LarryX). >> >> >> _______________________________________________ >> netrek-dev mailing list >> netrek-dev at us.netrek.org >> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev >> >> > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > > > > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From apsillers at gmail.com Fri May 15 07:27:19 2015 From: apsillers at gmail.com (Andrew Sillers) Date: Fri, 15 May 2015 08:27:19 -0400 Subject: [netrek-dev] Netrek for mobiles, really? In-Reply-To: References: <37FE2885-D8A6-4FD3-B791-7561F71AE77C@gmail.com> <5CA3E8FB-A91C-4855-80A4-F6334BA99AB0@gmail.com> Message-ID: Just a quick note that I just merged master into the phonegap branch, so it should have the most recent UI and Netrek protocol support now. It runs *very* slowly on my Android emulator; I'm going to test it on a physical device soon. On Thu, May 14, 2015 at 11:40 AM, Andrew Sillers wrote: > Lawrence, > > > If we take the HTML5 route, I think that the server should be modified > to support websocket connections. It would make HTML5 clients life much > simpler and would remove the actual HTML5 client dependency on the > proxy-adapter. > > I completely agree. There was some (very brief) discussion about Websocket > server support when I was originally working on the client. There is > actually a `ws-direct` branch on the Github repo as well that doesn't use > my custom proxy, but assumes a direct Websocket port on the server. You can > accomplish WS support easily with websockify ( > https://github.com/kanaka/websockify) which is a very straightforward > WS-to-TCP proxy. (The difference between my proxy and a websockify proxy is > that my proxy has lots of unnecessary Netrek-specific cruft and is also a > Web server. The `ws-direct` branch was modified to eliminate my > proxy-wrapper protocol and just contact the server directly.) I don't know > what kind of performance impact a WS-to-TCP proxy has, but it's a very easy > first step, and it can be run on the same machine as the real server, so > there's no second network hop. > > > Do you think that the phonegap tree of your code can be compiled and > loaded on Android, as it is? > > I think so, but (1) it needs to merge in master to update to the most > recent UI and Netrek protocol support and (2) it was designed to run on an > older version of Android so you might need to tweak the target-platform > settings when you set up a project. Otherwise, yes, I would expect it to > compile and run okay. Also, I'm not sure what happens if the screen is too > small to show the whole UI. I designed the UI to scale down to a certain > point (note: that functionality is not present in the current phonegap > branch; it needs to be merge in from master), but it caps out at some > limit, so you might not see the entire UI on a small screen. > > If you want to see how the client UI does on a mobile device, you can just > navigate to https://netrek-apsillers.rhcloud.com/ in a mobile browser. It > should work, for some definition of "work". Tap to shoot, and drag your > finger out from your ship to steer. I think you can shoot phasers by > holding a finger on your ship and then tapping elsewhere simultaneously. > > > Cordova compatible, "better" WebView > > Neat! This indeed looks like a drop-in repalcement for Cordova that might > be better. > > > openGL-js wrapper/library, looks good > > The HTML5 client uses a canvas library called CAKE.js which is badly out > of date, but still works. It might be worthwhile to replace it with another > graphics library like this one to get performance improvements and a better > UI-event interface. I would personally place this lower on > the priority list than getting a working mobile prototype Android app and > mildly refactoring the UI, but it definitely seems worthwhile. > > Andrew > > On Wed, May 13, 2015 at 6:41 PM, Lawrence Brass wrote: > >> Hello Andrew, >> >> It was James that mentioned that your work could be a good starting point >> for a mobile client. It would be great to have a common code HTML5 client >> running on desk, lap and mobile platforms. >> I launched the demo from the project's page in github and actually played >> with the bots at pickled for a while! >> I have not actual experience with Cordova or Phonegap but have done, or >> at least tried to do, things with WebViews on mobiles with mixed results. >> My concern is about achieving fluidity comparable to actual clients. I >> guess we should do some minimal implementation just to test that. >> Do you think that the phonegap tree of your code can be compiled and >> loaded on Android, as it is? >> >> If we take the HTML5 route, I think that the server should be modified to >> support websocket connections. It would make HTML5 clients life much >> simpler and would remove the actual HTML5 client dependency on the >> proxy-adapter. >> >> Some interesting links that I found during research: >> >> Cordova compatible, "better" WebView: >> https://crosswalk-project.org >> >> openGL-js wrapper/library, looks good: >> http://www.pixijs.com >> >> Regards, >> Lawrence. >> >> On May 8, 2015, at 10:06 AM, Andrew Sillers wrote: >> >> I saw that my HTML5 client (https://github.com/apsillers/html5-netrek) >> was already mentioned earlier in the Netrek Forever thread. I just wanted >> to weigh in a little on on the shape of that code. >> >> The code could be turned into a mobile app with Cordova/Phonegap ( >> https://cordova.apache.org/), and in fact, it already has been, for an >> other version of the code: >> https://github.com/apsillers/html5-netrek/tree/phonegap. The code is set >> up so that the message stream is abstracted away, and you can easily >> replace the Websocket-based networking with any other message source (e.g., >> TCP). (Compare `/assets/www/js/net_phonegap.js` in the Phongap branch and >> `/js/net.js` in master.) >> >> Back then, I wrote my own Android TCP plugin for Phonegap, but at least >> one cross-platform TCP plugin has matured since then: >> https://github.com/Tlantic/cdv-socket-plugin. >> >> However, as a client, it's a bit feature-incomplete; in particular, I >> recall that ship-refitting and plasmas are totally unimplemented, as is UDP >> support. (The code assumes only one, reliable message source, so you'd need >> to expand it a bit to accept two message sources.) >> >> It's not clear to me whether it would be less work to modify the C code >> to interface correctly on mobile devices, or to modify the JavaScript code >> to include a more complete feature set. >> >> One potential easy win (again borrowing from the thread on NT Forever) >> would be to modify the HTML5 client to implement observer mode, which would >> provide a quick way to observe games directly in-browser. If you want to >> invite someone to watch the game, you could send them a URL to tune in >> immediately. >> >> Andrew >> >> >> On Thu, May 7, 2015 at 12:22 PM, Lawrence Brass wrote: >> >>> Copied this fragment from netrek-forever... >>> >>> On May 6, 2015, at 7:50 PM, James Cameron wrote: >>> >>> >>> On Wed, May 06, 2015 at 05:19:33PM -0300, Lawrence Brass wrote: >>> >>> I agree, the matrix has us all. >>> >>> I browsed the COW-XP client sources last night and liked what I >>> >>> saw. It seems that the game logic is isolated from the video stuff, >>> >>> the "W_" module implements the glue code between the classic Windows >>> >>> API, GDI graphics, inputs and the game. Keyboard and mouse events >>> >>> are enqueued in a (single?) event queue. Very clear and classic C, >>> >>> even with Allman bracketing style! (tip of the hat). >>> >>> >>> Yes, in those days we did peer code reviews. The "W_" module was >>> >>> added to the client on Unix before it was ported to Windows in 1996. >>> >>> >>> If the "W_" module graphics functionality is reimplemented in say, >>> >>> openGL(ES), and the proper native framework code is used to capture >>> >>> the events and feed them into the game event queue, is very probable >>> >>> that the "game code" could be ported almost untouched to OSX/iOS, >>> >>> Plain C is actually a subset of objC and fits nicely. On Android I >>> >>> am not that sure (of the cost). The same strategy could be applied >>> >>> using the NDK to hold the C game loop and logic, and feed the input >>> >>> event queue from the native framework, but it may be harder. Porting >>> >>> from the Java clients is a competitive alternative for Android. >>> >>> The nice thing about this *hypothetical* scheme is that the game, >>> >>> network, and video(using openGL) code would be common and game and >>> >>> network stay almost untouched. >>> >>> Sounds crazy? >>> >>> >>> Yes. Especially because the input devices are entirely different. >>> >>> >>> There should be a mapping, before queuing control events, that would >>> convert swipes and taps into meaningful synthetic keystrokes and mouse >>> movements and clicks that the current game code would understand. This >>> mapping is were the "feel" of the game would be defined. >>> >>> The "W_" API presumes too much about the input devices and the >>> >>> underlying graphics libraries. >>> >>> >>> Yes, this would be the hard part. The API should be divided into 2 >>> modules, one for Graphics in open GL, common to all platforms and the other >>> for the input event handling, particular to each platform. >>> >>> I will focus on the "W_" module. I guess that I should look at both >>> unix and win implementations to get more insight. >>> >>> Regards. >>> >>> On May 6, 2015, at 11:32 PM, Lawrence Brass wrote: >>> >>> Hello again, I have just subscribed to the dev-list. >>> Should I copy content from from netrek-forever google group? >>> Regards, >>> Lawrence (LarryX). >>> >>> >>> _______________________________________________ >>> netrek-dev mailing list >>> netrek-dev at us.netrek.org >>> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev >>> >>> >> _______________________________________________ >> netrek-dev mailing list >> netrek-dev at us.netrek.org >> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev >> >> >> >> _______________________________________________ >> netrek-dev mailing list >> netrek-dev at us.netrek.org >> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sven-netrek-dev at sven.de Sat May 16 05:46:36 2015 From: sven-netrek-dev at sven.de (Sven Neuhaus) Date: Sat, 16 May 2015 12:46:36 +0200 Subject: [netrek-dev] Netrek for mobiles, really? In-Reply-To: References: <37FE2885-D8A6-4FD3-B791-7561F71AE77C@gmail.com> <5CA3E8FB-A91C-4855-80A4-F6334BA99AB0@gmail.com> Message-ID: <5557200C.7060706@sven.de> Am 14.05.15 um 17:40 schrieb Andrew Sillers: > I completely agree. There was some (very brief) discussion about > Websocket server support when I was originally working on the client. Instead of using Websocket, nowadays using a WebRTC data connection in the browser is probably preferable. WebRTC uses UDP and should provide better latency. -Sven From apsillers at gmail.com Sat May 16 11:18:21 2015 From: apsillers at gmail.com (Andrew Sillers) Date: Sat, 16 May 2015 12:18:21 -0400 Subject: [netrek-dev] Netrek for mobiles, really? In-Reply-To: <5557200C.7060706@sven.de> References: <37FE2885-D8A6-4FD3-B791-7561F71AE77C@gmail.com> <5CA3E8FB-A91C-4855-80A4-F6334BA99AB0@gmail.com> <5557200C.7060706@sven.de> Message-ID: WebRTC support would be a great addition. WebRTC could be used alongside a Websocket connection, just like UDP is used alongside TCP in the current clients (since those are the underlying WebRTC and WS transport protocols). For a mobile Phonegap app, we can just use native TCP and UDP plugins without needing to use the Web-specific wrappers. On May 16, 2015 6:52 AM, "Sven Neuhaus" wrote: > Am 14.05.15 um 17:40 schrieb Andrew Sillers: > > I completely agree. There was some (very brief) discussion about > > Websocket server support when I was originally working on the client. > > Instead of using Websocket, nowadays using a WebRTC data connection in > the browser is probably preferable. WebRTC uses UDP and should provide > better latency. > > -Sven > > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lbrass at gmail.com Sun May 17 13:02:06 2015 From: lbrass at gmail.com (Lawrence Brass) Date: Sun, 17 May 2015 15:02:06 -0300 Subject: [netrek-dev] Netrek for mobiles, really? In-Reply-To: References: <37FE2885-D8A6-4FD3-B791-7561F71AE77C@gmail.com> <5CA3E8FB-A91C-4855-80A4-F6334BA99AB0@gmail.com> <5557200C.7060706@sven.de> Message-ID: <13F1C5F3-D35F-419A-B562-3BE647F41497@gmail.com> The problem with WebRTC is that is not fully supported on all, notably on Apple devices through Safari. > On May 16, 2015, at 1:18 PM, Andrew Sillers wrote: > WebRTC support would be a great addition. WebRTC could be used alongside a Websocket connection, just like UDP is used alongside TCP in the current clients (since those are the underlying WebRTC and WS transport protocols). > > For a mobile Phonegap app, we can just use native TCP and UDP plugins without needing to use the Web-specific wrappers. > >> On May 16, 2015 6:52 AM, "Sven Neuhaus" wrote: >> Am 14.05.15 um 17:40 schrieb Andrew Sillers: >> > I completely agree. There was some (very brief) discussion about >> > Websocket server support when I was originally working on the client. >> >> Instead of using Websocket, nowadays using a WebRTC data connection in >> the browser is probably preferable. WebRTC uses UDP and should provide >> better latency. >> >> -Sven >> >> _______________________________________________ >> netrek-dev mailing list >> netrek-dev at us.netrek.org >> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From lbrass at gmail.com Sun May 17 15:46:57 2015 From: lbrass at gmail.com (Lawrence Brass) Date: Sun, 17 May 2015 17:46:57 -0300 Subject: [netrek-dev] Netrek for mobiles, really? In-Reply-To: References: <37FE2885-D8A6-4FD3-B791-7561F71AE77C@gmail.com> <5CA3E8FB-A91C-4855-80A4-F6334BA99AB0@gmail.com> Message-ID: <6FBBD721-E187-478B-A294-25F6FCAB3A87@gmail.com> This might help speed the emulator, if you haven't installed it already. https://software.intel.com/en-us/android/articles/intel-hardware-accelerated-execution-manager On May 15, 2015, at 9:27 AM, Andrew Sillers wrote: > Just a quick note that I just merged master into the phonegap branch, so it should have the most recent UI and Netrek protocol support now. It runs *very* slowly on my Android emulator; I'm going to test it on a physical device soon. From iggyvolz at gmail.com Sun May 17 21:37:18 2015 From: iggyvolz at gmail.com (iggyvolz .) Date: Sun, 17 May 2015 22:37:18 -0400 Subject: [netrek-dev] Netrek for mobiles, really? In-Reply-To: <6FBBD721-E187-478B-A294-25F6FCAB3A87@gmail.com> References: <37FE2885-D8A6-4FD3-B791-7561F71AE77C@gmail.com> <5CA3E8FB-A91C-4855-80A4-F6334BA99AB0@gmail.com> <6FBBD721-E187-478B-A294-25F6FCAB3A87@gmail.com> Message-ID: @Lawrence, there is a browser plugin available for desktop Safari and IE here: https://temasys.atlassian.net/wiki/display/TWPP/WebRTC+Plugins On Sun, May 17, 2015 at 4:46 PM, Lawrence Brass wrote: > This might help speed the emulator, if you haven't installed it already. > > https://software.intel.com/en-us/android/articles/intel-hardware-accelerated-execution-manager > > On May 15, 2015, at 9:27 AM, Andrew Sillers wrote: > > > Just a quick note that I just merged master into the phonegap branch, so > it should have the most recent UI and Netrek protocol support now. It runs > *very* slowly on my Android emulator; I'm going to test it on a physical > device soon. > > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From quozl at us.netrek.org Sun May 17 21:51:04 2015 From: quozl at us.netrek.org (James Cameron) Date: Mon, 18 May 2015 12:51:04 +1000 Subject: [netrek-dev] Netrek Server Code In-Reply-To: References: Message-ID: <20150518025104.GD11587@us.netrek.org> If you're unable to use darcs for some reason, my netrek-server repository is on github. https://github.com/quozl/netrek-server Ran out of time to import history fully, after trying a couple of methods, but if someone else can do that, feel free, and I can then pull the history from your branch. -- James Cameron http://quozl.linux.org.au/ From netrek at gmail.com Sun May 17 22:09:54 2015 From: netrek at gmail.com (Zachary Uram) Date: Sun, 17 May 2015 23:09:54 -0400 Subject: [netrek-dev] Netrek Server Code In-Reply-To: <20150518025104.GD11587@us.netrek.org> References: <20150518025104.GD11587@us.netrek.org> Message-ID: Found this: https://github.com/jaredthirsk/DotNetrek Code that may be useful for building a .NET *netrek* client On Sun, May 17, 2015 at 10:51 PM, James Cameron wrote: > If you're unable to use darcs for some reason, my netrek-server > repository is on github. > > https://github.com/quozl/netrek-server > > Ran out of time to import history fully, after trying a couple of > methods, but if someone else can do that, feel free, and I can then > pull the history from your branch. > > -- > James Cameron > http://quozl.linux.org.au/ > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > -- http://www.fidei.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared.accounts at thirsk.ca Sun May 17 23:26:09 2015 From: jared.accounts at thirsk.ca (Jared Thirsk) Date: Sun, 17 May 2015 22:26:09 -0600 Subject: [netrek-dev] C# development update & Money makes the world go 'round In-Reply-To: <9649EFCD-9C4B-441C-9924-6E496BF29564@gmail.com> References: <4e8c3ee7-6eca-4b11-984e-0e7d2c6a6c59@googlegroups.com> <338fc8ca-74ee-4181-9b37-5690ebe77cc4@googlegroups.com> <153f36fd-9ba7-412f-abc9-3cc9138eb3b7@googlegroups.com> <9649EFCD-9C4B-441C-9924-6E496BF29564@gmail.com> Message-ID: <555969E1.5020605@thirsk.ca> Hi guys, It is great to see progress on the HTML5 client. I think it is great to pursue that route. Responding to a couple emails, one from netrek-forever: On 5/5/2015 8:02 AM, Lawrence Brass wrote: > On your last comments about your interest in evolving the game, my opinion is that the right people for the task is already around, probably with less spare time than years ago but I would bet that there is a genuine and common interest in the same direction. I remember a few years ago in this forum someone trying to revive netrek. He had this "entrepreneural" stance, too ambitious in my opinion, never gathered steam as far as i know. Maybe you're talking about me. I have a day job(s) to pay bills but I am still working towards this end. Who knows when I will finish. Don't wait for me. My goal (definitely ambitious): create a newfangled game with lots of crazy stupid fun ideas (because I want this for myself), draw a crowd, and provide netrek (or as close to verbatim as I can get) as a free gameplay mode (whether the game is purchased or not). (And/or provide a netrek client as part of the game and use the existing server code.) Basically, the new game would be free marketing for netrek, and be able to leverage assets and development work that people would (hopefully) be paying substantial cash for. (If the netrek playerbase revived, I would want to be careful to not compete for attention over the playerbase, but since the playerbase is basically nil I guess I don't have to worry about that at the moment.) On Sun May 17 22:09:54 CDT 2015 - Zachary Uram: > Found this: > https://github.com/jaredthirsk/DotNetrek > Code that may be useful for building a .NET *netrek* client Zach asked me if I had more code. I have code from my own engine that I have not carved out, but if let me know if anyone is going a C# route and I'll see what I can do to help. BTW, I'm primarily targeting Unity3D (languages: C#, Boo, some imitation of Javascript, and whatever else its old version of Mono will handle), which has a compelling cross platform story IMO. I also am using NoesisGUI (not free) for Unity3D which allows the use of XAML to define interfaces, similar to how WPF/Silverlight interfaces are defined. I have also been learning cordova/phonegap and think it is promising so long as it can deliver on performance and networking, so like I said, I am glad to see progress on that front. (I am concerned when people want to do something in Java/C/C++/python because the game toolkits for those seem weak and I don't seem to see a lot of serious cross-platform games come from them. But I think Unity3D and Phonegap are both strong choices that have staying power and strong ecosystems, and strong cross-platform potential.) BTW, if we did a kickstarter to pay someone(s), I wonder how much we could raise for someone to quit their job for a while, or someone like me with casual part time contract work to devote a few cycles? I also have got my first taste of outsourcing, hiring a group from Elance. So far I think it is a good thing, although we went with the #1 team on the site. Also there is https://www.mturk.com/mturk/welcome -Jared aka Mahalalel back in the day From quozl at us.netrek.org Mon May 18 00:48:49 2015 From: quozl at us.netrek.org (James Cameron) Date: Mon, 18 May 2015 15:48:49 +1000 Subject: [netrek-dev] C# development update & Money makes the world go 'round In-Reply-To: <555969E1.5020605@thirsk.ca> References: <4e8c3ee7-6eca-4b11-984e-0e7d2c6a6c59@googlegroups.com> <338fc8ca-74ee-4181-9b37-5690ebe77cc4@googlegroups.com> <153f36fd-9ba7-412f-abc9-3cc9138eb3b7@googlegroups.com> <9649EFCD-9C4B-441C-9924-6E496BF29564@gmail.com> <555969E1.5020605@thirsk.ca> Message-ID: <20150518054849.GE11587@us.netrek.org> Welcome back, Jared. Don't forget to subscribe, so I don't have to keep approving your posts. Crowd funding to pay someone is certainly a possibility, and I'm also available for any contract work. The tools are a trivial cost compared to such work, so I don't see any use in talking about them unless the user experience is defined and funded. -- James Cameron http://quozl.linux.org.au/ From lbrass at gmail.com Mon May 18 22:35:15 2015 From: lbrass at gmail.com (Lawrence Brass) Date: Tue, 19 May 2015 00:35:15 -0300 Subject: [netrek-dev] C# development update & Money makes the world go 'round In-Reply-To: <555969E1.5020605@thirsk.ca> References: <4e8c3ee7-6eca-4b11-984e-0e7d2c6a6c59@googlegroups.com> <338fc8ca-74ee-4181-9b37-5690ebe77cc4@googlegroups.com> <153f36fd-9ba7-412f-abc9-3cc9138eb3b7@googlegroups.com> <9649EFCD-9C4B-441C-9924-6E496BF29564@gmail.com> <555969E1.5020605@thirsk.ca> Message-ID: On May 18, 2015, at 1:26 AM, Jared Thirsk wrote: > On 5/5/2015 8:02 AM, Lawrence Brass wrote: >> On your last comments about your interest in evolving the game, my opinion is that the right people for the task is already around, probably with less spare time than years ago but I would bet that there is a genuine and common interest in the same direction. I remember a few years ago in this forum someone trying to revive netrek. He had this "entrepreneural" stance, too ambitious in my opinion, never gathered steam as far as i know. > Maybe you're talking about me. I have a day job(s) to pay bills but I am still working towards this end. Who knows when I will finish. Don't wait for me. Hi Jared, I don't know if it was you really, I just recall the posts. Please excuse me if you were the one and I if offended you in any way. The point I was trying to make is that small, focused and incremental steps sometimes work better than a big plan, in the context of open source projects., with few developer time available. I have nothing against commercial software development, in fact that is what I do for a living. Regards, Lawrence. -------------- next part -------------- An HTML attachment was scrubbed... URL: From apsillers at gmail.com Wed May 27 20:22:08 2015 From: apsillers at gmail.com (Andrew Sillers) Date: Wed, 27 May 2015 21:22:08 -0400 Subject: [netrek-dev] Netrek for mobiles, really? In-Reply-To: References: <37FE2885-D8A6-4FD3-B791-7561F71AE77C@gmail.com> <5CA3E8FB-A91C-4855-80A4-F6334BA99AB0@gmail.com> <6FBBD721-E187-478B-A294-25F6FCAB3A87@gmail.com> Message-ID: Just a quick heads-up that I started working on a small-screen UI for the JavaScript client. It is in the `small-screen` branch on GitHub. If you want to include the work so far into a mobile app, checkout the phonegap branch and do `git merge small-screen`. I will probably merge it eventually, whenever I make a "usable" chat interface. I took (yet another) page out of Gytha and made the small-screen galactic map a toggleable overlay on top of the ship view. I'll probably do something similar with chat. On May 17, 2015 10:37 PM, "iggyvolz ." wrote: > @Lawrence, there is a browser plugin available for desktop Safari and IE > here: https://temasys.atlassian.net/wiki/display/TWPP/WebRTC+Plugins > > On Sun, May 17, 2015 at 4:46 PM, Lawrence Brass wrote: > >> This might help speed the emulator, if you haven't installed it already. >> >> https://software.intel.com/en-us/android/articles/intel-hardware-accelerated-execution-manager >> >> On May 15, 2015, at 9:27 AM, Andrew Sillers wrote: >> >> > Just a quick note that I just merged master into the phonegap branch, >> so it should have the most recent UI and Netrek protocol support now. It >> runs *very* slowly on my Android emulator; I'm going to test it on a >> physical device soon. >> >> _______________________________________________ >> netrek-dev mailing list >> netrek-dev at us.netrek.org >> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev >> > > > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From apsillers at gmail.com Wed May 27 20:29:07 2015 From: apsillers at gmail.com (Andrew Sillers) Date: Wed, 27 May 2015 21:29:07 -0400 Subject: [netrek-dev] Standard macro messages? Message-ID: Is there a list of standard macro messages I can use? I'd like to parse chat macro messages and visualize their content on the galactic map for the mobile client, where the map will be easier to use than chat. Not that chat should ever be ignored, but anything I can do to make things easier on a small screen... If anyone has any strong objections to this, I'm all ears. Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From quozl at us.netrek.org Wed May 27 20:52:22 2015 From: quozl at us.netrek.org (James Cameron) Date: Thu, 28 May 2015 11:52:22 +1000 Subject: [netrek-dev] Standard macro messages? In-Reply-To: References: Message-ID: <20150528015222.GL4294@us.netrek.org> Yeah, know how you feel, Gytha has messages visualised on tactical or galactic, depending on display switch. There's no definitive list because the clients can invent their own at any time. There's a minimum list you can find in the server and clients, so go read that code. References: - gytha/rcd.py - netrek-server-vanilla, include/struct.h, struct distress for the binary format enum dist_type for the distress types (take, etc) enum target_type for the target types (none, planet, player) plus following comments - netrek-client-vanilla, struct.h, enum dist_type for the distress types known by client (different to above) - netrek-client-vanilla, input.c, default mapping from keyboard to distress types -- James Cameron http://quozl.linux.org.au/ From netrek at gmail.com Sat May 30 12:48:02 2015 From: netrek at gmail.com (Zachary Uram) Date: Sat, 30 May 2015 13:48:02 -0400 Subject: [netrek-dev] Vanilla package dependencies Message-ID: Does anyone know the Debian packages you need to compile the Vanilla server? I used to know, but forgot. Zach -- http://www.fidei.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From netrek at gmail.com Sat May 30 12:48:45 2015 From: netrek at gmail.com (Zachary Uram) Date: Sat, 30 May 2015 13:48:45 -0400 Subject: [netrek-dev] BRMH sources? Message-ID: Does anyone know where I may find the latest BRMH sources? IIRC Karthik was the maintainer. Zach -- http://www.fidei.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From quozl at us.netrek.org Sun May 31 20:26:14 2015 From: quozl at us.netrek.org (James Cameron) Date: Mon, 1 Jun 2015 11:26:14 +1000 Subject: [netrek-dev] BRMH sources? In-Reply-To: References: Message-ID: <20150601012614.GH4873@us.netrek.org> Source code repository https://launchpad.net/netrek-client-brmh Sources http://www.netrek.org/files/archive/BRMH/src/ Binaries http://www.netrek.org/files/BRMH/ Copied from http://karthik.com/netrek/brmh/ Release announcement http://mailman.us.netrek.org/pipermail/netrek-dev/2009-July/005522.html -- James Cameron http://quozl.linux.org.au/ From netrek at gmail.com Sun May 31 20:50:04 2015 From: netrek at gmail.com (Zachary Uram) Date: Sun, 31 May 2015 21:50:04 -0400 Subject: [netrek-dev] BRMH sources? In-Reply-To: <20150601012614.GH4873@us.netrek.org> References: <20150601012614.GH4873@us.netrek.org> Message-ID: Thanks! On Sun, May 31, 2015 at 9:26 PM, James Cameron wrote: > Source code repository > https://launchpad.net/netrek-client-brmh > > Sources > http://www.netrek.org/files/archive/BRMH/src/ > > Binaries > http://www.netrek.org/files/BRMH/ > > Copied from > http://karthik.com/netrek/brmh/ > > Release announcement > http://mailman.us.netrek.org/pipermail/netrek-dev/2009-July/005522.html > > -- > James Cameron > http://quozl.linux.org.au/ > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > -- http://www.fidei.org -------------- next part -------------- An HTML attachment was scrubbed... URL: