From netrek at gmail.com Fri Feb 19 10:46:13 2010 From: netrek at gmail.com (Zachary Uram) Date: Fri, 19 Feb 2010 11:46:13 -0500 Subject: [netrek-dev] bad press >_< Message-ID: Some project about "Integration of TWiki and VoIP with a Game" reviewed various games and decided to pick either TeeWorlds or Netrek. Interesting to see their reasons for not choosing netrek. It's funny they classify it as a FPS, usually see it as RTS. http://people.cse.iitd.ernet.in/~cs1070167/CSP.pdf 2.3 The Final Choice So we decided to focus our search on First Person Shooter(FPS Games) .We focussed on trying to nd games that had their source code readily available on the internet and were the focus of active interst among the pro- gramming community We shortlisted two games:Netrek and Teeworlds. We nally choose Teeworlds over Netrek because 1. It had better graphics. 2. It's forums were more active than that of Netrek. 3. Its source code had better readibility. 4. It had versions for various systems-macintosh,windows and linux thus of- fering us greater freedom to choose our base operating system Zach <>< http://www.fidei.org ><> From quozl at us.netrek.org Fri Feb 19 15:44:00 2010 From: quozl at us.netrek.org (James Cameron) Date: Sat, 20 Feb 2010 08:44:00 +1100 Subject: [netrek-dev] bad press >_< In-Reply-To: References: Message-ID: <20100219214400.GF8124@us.netrek.org> Summary: this is good news, because Netrek was shortlisted instead of discarded. Your quote was from page 5 of an academic paper, which was based on research done in 2008. It isn't bad press. It isn't even bad academia. It is an accurate comparison between two very different games. It is good that Netrek reached their shortlist. We could have been omitted much earlier on. Take that as a positive. > 1. It had better graphics. Certainly true. > 2. It's forums were more active than that of Netrek. Certainly true. > 3. Its source code had better readibility. Netrek source code came from an era where readability was not as important as it is now. So it would be surprising to find any current game with worse readability than Netrek. > 4. It had versions for various systems-macintosh,windows and linux > thus offering us greater freedom to choose our base operating system Certainly true, if you consider only the server. There were no published versions of the server for anything except Linux, for example. Since then a version for Mac OS X was made available. While I like Netrek and continue to develop, I won't lie about it in the interests of promotion. Such a method of advocacy leads to failure. -- James Cameron http://quozl.linux.org.au/ From netrek at gmail.com Sat Feb 20 04:02:30 2010 From: netrek at gmail.com (Zachary Uram) Date: Sat, 20 Feb 2010 05:02:30 -0500 Subject: [netrek-dev] bad press >_< In-Reply-To: <20100219214400.GF8124@us.netrek.org> References: <20100219214400.GF8124@us.netrek.org> Message-ID: On Fri, Feb 19, 2010 at 4:44 PM, James Cameron wrote: > Summary: this is good news, because Netrek was shortlisted instead of > discarded. I see. > Netrek source code came from an era where readability was not as > important as it is now. ?So it would be surprising to find any current > game with worse readability than Netrek. Is this something we can/should fix? > While I like Netrek and continue to develop, I won't lie about it in the > interests of promotion. Nor would I. Zach From quozl at us.netrek.org Sun Feb 21 03:28:37 2010 From: quozl at us.netrek.org (James Cameron) Date: Sun, 21 Feb 2010 20:28:37 +1100 Subject: [netrek-dev] bad press >_< In-Reply-To: References: <20100219214400.GF8124@us.netrek.org> Message-ID: <20100221092837.GA3941@us.netrek.org> On Sat, Feb 20, 2010 at 05:02:30AM -0500, Zachary Uram wrote: > On Fri, Feb 19, 2010 at 4:44 PM, James Cameron wrote: > > Netrek source code came from an era where readability was not as > > important as it is now. So it would be surprising to find any > > current game with worse readability than Netrek. > Is this something we can/should fix? There is no automatic method that would be welcome, since it would certainly make mistakes with the code. It takes manual work by people who know the code ... and if those people are available we'd far rather have them work on features the community needs than readability that some university student discarded us for. -- James Cameron http://quozl.linux.org.au/ From quozl at us.netrek.org Sun Feb 21 04:17:09 2010 From: quozl at us.netrek.org (James Cameron) Date: Sun, 21 Feb 2010 21:17:09 +1100 Subject: [netrek-dev] p_explode damage frame, classic vs 50 fps Message-ID: <20100221101709.GA5866@us.netrek.org> G'day, I'd like a second pair of eyes on this please. When a ship explodes, the status is set to PEXPLODE, a countdown fuse p_explode is set, and at a particular point in that countdown the explosion damage is assigned to nearby ships using blowup(). I was going to add an explosion frame on a client that gave a flash of light at the frame that the server assigns damage from an explosion. So I went looking into when that happens. But I found that the changes in early 2007 changed which explosion frame was used. Chain reactions would have gone five times faster. Didn't anybody notice? Here's how it works in detail: 1. at the time a ship explodes, p_explode is set to 10, in both the new code and the classic code, 2. p_explode is decremented every simulation frame, 3. in the frame where p_explode is decremented to 6, the explosion damage is assigned, 4. when p_explode reaches zero, the ship status changes to PDEAD, and p_explode is reset to 600, which doesn't matter because; 5. when the ntserv sees the PDEAD it calls death() causing status to change to POUTFIT. It seems that the change from 10 fps to 50 fps should be changing step 1 to set p_explode to 50, and step 5 to assign explosion damage at a p_explode of 30. At the moment in the code the explosion damage is happening at explosion time plus four fiftieths of a second (80ms), instead of four tenths of a second (400ms). Also, explosions are shorter than they should be; 200ms instead of 1000ms. This should *entirely* change base ogging. -- James Cameron http://quozl.linux.org.au/ From netrek at gmail.com Sun Feb 21 09:54:24 2010 From: netrek at gmail.com (Zachary Uram) Date: Sun, 21 Feb 2010 10:54:24 -0500 Subject: [netrek-dev] bad press >_< In-Reply-To: <20100221092837.GA3941@us.netrek.org> References: <20100219214400.GF8124@us.netrek.org> <20100221092837.GA3941@us.netrek.org> Message-ID: On Sun, Feb 21, 2010 at 4:28 AM, James Cameron wrote: > > There is no automatic method that would be welcome, since it would > certainly make mistakes with the code. ?It takes manual work by people > who know the code ... and if those people are available we'd far rather > have them work on features the community needs than readability that > some university student discarded us for. Ok. That make sense. Zach From netrek at gmail.com Sun Feb 21 09:56:25 2010 From: netrek at gmail.com (Zachary Uram) Date: Sun, 21 Feb 2010 10:56:25 -0500 Subject: [netrek-dev] p_explode damage frame, classic vs 50 fps In-Reply-To: <20100221101709.GA5866@us.netrek.org> References: <20100221101709.GA5866@us.netrek.org> Message-ID: Wow so all XP 2009, XP 2010 clients will have this problem? Zach <>< http://www.fidei.org ><> From mark at mark.mielke.cc Sun Feb 21 10:08:57 2010 From: mark at mark.mielke.cc (Mark Mielke) Date: Sun, 21 Feb 2010 11:08:57 -0500 Subject: [netrek-dev] bad press >_< In-Reply-To: References: <20100219214400.GF8124@us.netrek.org> <20100221092837.GA3941@us.netrek.org> Message-ID: <4B815A99.2050408@mark.mielke.cc> On 02/21/2010 10:54 AM, Zachary Uram wrote: > On Sun, Feb 21, 2010 at 4:28 AM, James Cameron wrote: > >> There is no automatic method that would be welcome, since it would >> certainly make mistakes with the code. It takes manual work by people >> who know the code ... and if those people are available we'd far rather >> have them work on features the community needs than readability that >> some university student discarded us for. >> > Ok. That make sense. > I think the readability has actually improved significantly since the early '90s. :-) There is always room for improvement, but I have seen much worse. When I first started hacking on the client and the server, around 1990(?), I was around 12, and was able to navigate the code, create a borg client with all the standard features (assisted targeting, automatic phaser of plasma, automatic detonate others, etc.), and extend the server to do various things ("natural" planet orbits - both ways, smooth galaxy wrap around with visibility back to the client across the borders, etc.). It was not really that hard. If the code was really that bad, I think I would have had more trouble... :-) Cheers, mark From netrek at gmail.com Sun Feb 21 14:03:31 2010 From: netrek at gmail.com (Zachary Uram) Date: Sun, 21 Feb 2010 15:03:31 -0500 Subject: [netrek-dev] bad press >_< In-Reply-To: <4B815A99.2050408@mark.mielke.cc> References: <20100219214400.GF8124@us.netrek.org> <20100221092837.GA3941@us.netrek.org> <4B815A99.2050408@mark.mielke.cc> Message-ID: On Sun, Feb 21, 2010 at 11:08 AM, Mark Mielke wrote: > When I first started hacking on the client and the server, around 1990(?), I > was around 12, and was able to navigate the code, create a borg client with > all the standard features (assisted targeting, automatic phaser of plasma, > automatic detonate others, etc.), and extend the server to do various things > ("natural" planet orbits - both ways, smooth galaxy wrap around with > visibility back to the client across the borders, etc.). It was not really > that hard. If the code was really that bad, I think I would have had more > trouble... :-) Interesting. Can we see this borg code and server code? :) Zach From mark at mark.mielke.cc Sun Feb 21 16:13:49 2010 From: mark at mark.mielke.cc (Mark Mielke) Date: Sun, 21 Feb 2010 17:13:49 -0500 Subject: [netrek-dev] bad press >_< In-Reply-To: References: <20100219214400.GF8124@us.netrek.org> <20100221092837.GA3941@us.netrek.org> <4B815A99.2050408@mark.mielke.cc> Message-ID: <4B81B01D.6090904@mark.mielke.cc> On 02/21/2010 03:03 PM, Zachary Uram wrote: > On Sun, Feb 21, 2010 at 11:08 AM, Mark Mielke wrote: > >> When I first started hacking on the client and the server, around 1990(?), I >> was around 12, and was able to navigate the code, create a borg client with >> all the standard features (assisted targeting, automatic phaser of plasma, >> automatic detonate others, etc.), and extend the server to do various things >> ("natural" planet orbits - both ways, smooth galaxy wrap around with >> visibility back to the client across the borders, etc.). It was not really >> that hard. If the code was really that bad, I think I would have had more >> trouble... :-) >> > Interesting. Can we see this borg code and server code? :) > Already sent some of the server patches in on this list - I don't recall if any were actually incorporated. :-) Many of them "change game behaviour", which I considered good - but were not so good for those who had become accustomed to the prior behaviour. :-) For the borg code - plenty of borgs have been written since, and the clients have changed so that my patches probably don't apply any more. If you really want to see them, I can post them, though. Some of these files were last updated in 1995. See attached. I didn't include everything, just enough to whet your appetite? :-) The entry point is in borg_update.c / borg_update(). Lots of useful features in there, like guessing how many armies are on the planet, extrapolating cloaker positions, ... see for yourself. The borg itself was capable of full auto-pilot, and if 16 of them were started, they would play a game - but I never really completed the dog fighting or the LPS. A few years ago (2001?) I had talked on this list about having the borg players "work together", having one program run multiple clients like arms and legs - very "borg-like" - but I had a family and ran out of time. I think it would be awesome to see 8 borg clients act as one and dive on a star base in a 100% co-ordinated attack designed to inflict massive injury in minimum time. Even narrowing down on the "detected" cloaking position between 8 clients by computing an average of the min() and max() detected position between all clients. With 8 clients, I think a higher level client compiling data from all sources would know exactly where the cloaked SB is, and even what direction it was going. I have this sense that this sort of approach has not been done yet, and would be "unstoppable" if done correctly, or even if done just adequately (lots of advantages that would be card to compete against, even if it wasn't the absolute best at other aspects). But, no time. *sigh* Cheers, mark -------------- next part -------------- A non-text attachment was scrubbed... Name: borg_defense.c Type: text/x-csrc Size: 2083 bytes Desc: not available Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20100221/29240bf9/attachment-0006.c -------------- next part -------------- A non-text attachment was scrubbed... Name: borg_monitor.c Type: text/x-csrc Size: 8257 bytes Desc: not available Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20100221/29240bf9/attachment-0007.c -------------- next part -------------- A non-text attachment was scrubbed... Name: borg_nearest.c Type: text/x-csrc Size: 2182 bytes Desc: not available Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20100221/29240bf9/attachment-0008.c -------------- next part -------------- A non-text attachment was scrubbed... Name: borg_pilot.c Type: text/x-csrc Size: 12593 bytes Desc: not available Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20100221/29240bf9/attachment-0009.c -------------- next part -------------- A non-text attachment was scrubbed... Name: borg_planet.c Type: text/x-csrc Size: 4017 bytes Desc: not available Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20100221/29240bf9/attachment-0010.c -------------- next part -------------- A non-text attachment was scrubbed... Name: borg_update.c Type: text/x-csrc Size: 4650 bytes Desc: not available Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20100221/29240bf9/attachment-0011.c From netrek at gmail.com Sun Feb 21 17:21:54 2010 From: netrek at gmail.com (Zachary Uram) Date: Sun, 21 Feb 2010 18:21:54 -0500 Subject: [netrek-dev] bad press >_< In-Reply-To: <4B81B01D.6090904@mark.mielke.cc> References: <20100219214400.GF8124@us.netrek.org> <20100221092837.GA3941@us.netrek.org> <4B815A99.2050408@mark.mielke.cc> <4B81B01D.6090904@mark.mielke.cc> Message-ID: Thanks for the code Mark will look it over. Yes what you are describing is a sort of netrek expert system which I think is fascinating. I also have some ideas for such an enterprise. There is actually some academic work which has already been completed on this so you may find that useful. Zach <>< http://www.fidei.org ><> From billbalcerski at gmail.com Tue Feb 23 07:57:30 2010 From: billbalcerski at gmail.com (Bill Balcerski) Date: Tue, 23 Feb 2010 08:57:30 -0500 Subject: [netrek-dev] Need Windows 7 beta tester for Netrek XP 2010 bug report Message-ID: <45ab86181002230557o26090773y2c796f9cce133ff2@mail.gmail.com> Hi all. I've received a bug report from a user of Netrek XP 2010 where he reports the client crashes his operating system (Windows 7 64-bit) if he tries to resize the local or map window in game via right click border/drag mouse. Can someone with access to that operating system confirm this bug report? Would appreciate it. Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20100223/0ea93af0/attachment.htm From quozl at us.netrek.org Tue Feb 23 23:33:57 2010 From: quozl at us.netrek.org (James Cameron) Date: Wed, 24 Feb 2010 16:33:57 +1100 Subject: [netrek-dev] p_explode damage frame, classic vs 50 fps In-Reply-To: References: <20100221101709.GA5866@us.netrek.org> Message-ID: <20100224053357.GG1723@us.netrek.org> On Sun, Feb 21, 2010 at 10:56:25AM -0500, Zachary Uram wrote: > Wow so all XP 2009, XP 2010 clients will have this problem? No, no clients are affected. Only game play is affected. -- James Cameron http://quozl.linux.org.au/ From niclas at acc.umu.se Wed Feb 24 07:24:26 2010 From: niclas at acc.umu.se (Niclas Fredriksson) Date: Wed, 24 Feb 2010 14:24:26 +0100 (MET) Subject: [netrek-dev] p_explode damage frame, classic vs 50 fps In-Reply-To: <20100221101709.GA5866@us.netrek.org> References: <20100221101709.GA5866@us.netrek.org> Message-ID: On Sun, 21 Feb 2010, James Cameron wrote: > This should *entirely* change base ogging. It sounds like another change that makes it easier and more advantageous to play passively rather than aggressively, just like all the changes to updates per second? -- Niclas From netrek at gmail.com Wed Feb 24 08:04:46 2010 From: netrek at gmail.com (Zachary Uram) Date: Wed, 24 Feb 2010 09:04:46 -0500 Subject: [netrek-dev] p_explode damage frame, classic vs 50 fps In-Reply-To: <20100224053357.GG1723@us.netrek.org> References: <20100221101709.GA5866@us.netrek.org> <20100224053357.GG1723@us.netrek.org> Message-ID: On Wed, Feb 24, 2010 at 12:33 AM, James Cameron wrote: > On Sun, Feb 21, 2010 at 10:56:25AM -0500, Zachary Uram wrote: >> Wow so all XP 2009, XP 2010 clients will have this problem? > > No, no clients are affected. Only game play is affected. I don't follow. You need a client with 50fps support and you must enable it in client to make use of this. I don't use such a client. Zach <>< http://www.fidei.org ><> From quozl at us.netrek.org Wed Feb 24 16:21:55 2010 From: quozl at us.netrek.org (James Cameron) Date: Thu, 25 Feb 2010 09:21:55 +1100 Subject: [netrek-dev] p_explode damage frame, classic vs 50 fps In-Reply-To: References: <20100221101709.GA5866@us.netrek.org> <20100224053357.GG1723@us.netrek.org> Message-ID: <20100224222155.GJ5978@us.netrek.org> On Wed, Feb 24, 2010 at 09:04:46AM -0500, Zachary Uram wrote: > I don't follow. You need a client with 50fps support and you must > enable it in client to make use of this. I don't use such a client. That's an entirely naive view of the situation. The change was to the server, so what client you are using is irrelevant. Game play is affected. Ships are damaged by explosions at a different time relative to the commencement of the explosion. -- James Cameron http://quozl.linux.org.au/ From quozl at us.netrek.org Wed Feb 24 16:25:25 2010 From: quozl at us.netrek.org (James Cameron) Date: Thu, 25 Feb 2010 09:25:25 +1100 Subject: [netrek-dev] p_explode damage frame, classic vs 50 fps In-Reply-To: References: <20100221101709.GA5866@us.netrek.org> Message-ID: <20100224222525.GK5978@us.netrek.org> On Wed, Feb 24, 2010 at 02:24:26PM +0100, Niclas Fredriksson wrote: > On Sun, 21 Feb 2010, James Cameron wrote: > > This should *entirely* change base ogging. > > It sounds like another change that makes it easier and more advantageous > to play passively rather than aggressively, just like all the changes to > updates per second? I don't see how this coding error would favour passive strategy over aggressive strategy. Could you explain? If the explanation makes sense, I'll have an argument for adjusting things in the other direction to favour aggressive strategy; something we obviously need given the new players we are getting. Does nobody have anything material to say about this error ... like should it be fixed, have you noticed it, have you understood it? -- James Cameron http://quozl.linux.org.au/ From netrek at gmail.com Wed Feb 24 16:30:59 2010 From: netrek at gmail.com (Zachary Uram) Date: Wed, 24 Feb 2010 17:30:59 -0500 Subject: [netrek-dev] p_explode damage frame, classic vs 50 fps In-Reply-To: <20100224222155.GJ5978@us.netrek.org> References: <20100221101709.GA5866@us.netrek.org> <20100224053357.GG1723@us.netrek.org> <20100224222155.GJ5978@us.netrek.org> Message-ID: On Wed, Feb 24, 2010 at 5:21 PM, James Cameron wrote: > > That's an entirely naive view of the situation. ?The change was to the > server, so what client you are using is irrelevant. ?Game play is > affected. ?Ships are damaged by explosions at a different time relative > to the commencement of the explosion. It was not naive, just incomplete based on my understanding at the time. Sounds like this serious coding error should be fixed forthwith. Zach From jeffrey.w.watts at gmail.com Wed Feb 24 16:41:32 2010 From: jeffrey.w.watts at gmail.com (Jeffrey Watts) Date: Wed, 24 Feb 2010 16:41:32 -0600 Subject: [netrek-dev] p_explode damage frame, classic vs 50 fps In-Reply-To: References: <20100221101709.GA5866@us.netrek.org> <20100224053357.GG1723@us.netrek.org> <20100224222155.GJ5978@us.netrek.org> Message-ID: <65631e801002241441w7fdcb8dahda2fd4c155c618d6@mail.gmail.com> From quozl at us.netrek.org Wed Feb 24 17:09:21 2010 From: quozl at us.netrek.org (James Cameron) Date: Thu, 25 Feb 2010 10:09:21 +1100 Subject: [netrek-dev] p_explode damage frame, classic vs 50 fps In-Reply-To: References: <20100221101709.GA5866@us.netrek.org> <20100224053357.GG1723@us.netrek.org> <20100224222155.GJ5978@us.netrek.org> Message-ID: <20100224230921.GL5978@us.netrek.org> On Wed, Feb 24, 2010 at 05:30:59PM -0500, Zachary Uram wrote: > It was not naive, just incomplete based on my understanding at > the time. As Jeffrey points out, you can't be both not naive and not understanding at the time. > Sounds like this serious coding error should be fixed forthwith. Yeah, I feel like doing it, but why should it be fixed? Does it really exist? Have you even noticed it? -- James Cameron http://quozl.linux.org.au/ From jrd at gerdesas.com Wed Feb 24 17:24:01 2010 From: jrd at gerdesas.com (John R. Dennison) Date: Wed, 24 Feb 2010 17:24:01 -0600 Subject: [netrek-dev] p_explode damage frame, classic vs 50 fps In-Reply-To: <20100224230921.GL5978@us.netrek.org> References: <20100221101709.GA5866@us.netrek.org> <20100224053357.GG1723@us.netrek.org> <20100224222155.GJ5978@us.netrek.org> <20100224230921.GL5978@us.netrek.org> Message-ID: <20100224232400.GK26264@frodo.gerdesas.com> On Thu, Feb 25, 2010 at 10:09:21AM +1100, James Cameron wrote: > On Wed, Feb 24, 2010 at 05:30:59PM -0500, Zachary Uram wrote: > > It was not naive, just incomplete based on my understanding at > > the time. > > As Jeffrey points out, you can't be both not naive and not understanding > at the time. > > > Sounds like this serious coding error should be fixed forthwith. > > Yeah, I feel like doing it, but why should it be fixed? Does it really > exist? Have you even noticed it? Leave it as is. It has been in place long enough for the current crop of newbies and existing players to consider it the "standard"; there has also been no outcry by (semi-) clue against it so I would take this to mean that it wasn't that big of a thing in the first place. John -- If man does find the solution for world peace it will be the most revolutionary reversal of his record we have ever known. -- George C. Marshall (1880 - 1959), American military leader and statesman, creator of the Marshall Plan, the only US Army general to receive the Nobel Peace Prize, Biennial Report of the Chief of Staff, US Army, 1 September 1945 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20100224/fb275030/attachment.pgp From netrek at gmail.com Wed Feb 24 17:38:22 2010 From: netrek at gmail.com (Zachary Uram) Date: Wed, 24 Feb 2010 18:38:22 -0500 Subject: [netrek-dev] p_explode damage frame, classic vs 50 fps In-Reply-To: <65631e801002241441w7fdcb8dahda2fd4c155c618d6@mail.gmail.com> References: <20100221101709.GA5866@us.netrek.org> <20100224053357.GG1723@us.netrek.org> <20100224222155.GJ5978@us.netrek.org> <65631e801002241441w7fdcb8dahda2fd4c155c618d6@mail.gmail.com> Message-ID: On Wed, Feb 24, 2010 at 5:41 PM, Jeffrey Watts wrote: > From wikipedia:? Naive is a French loanword indicating having or showing a > lack of experience, understanding, or sophistication. > > So, yes, it was naive by your own admission.? :) :) Zach From netrek at gmail.com Wed Feb 24 17:37:55 2010 From: netrek at gmail.com (Zachary Uram) Date: Wed, 24 Feb 2010 18:37:55 -0500 Subject: [netrek-dev] p_explode damage frame, classic vs 50 fps In-Reply-To: <20100224230921.GL5978@us.netrek.org> References: <20100221101709.GA5866@us.netrek.org> <20100224053357.GG1723@us.netrek.org> <20100224222155.GJ5978@us.netrek.org> <20100224230921.GL5978@us.netrek.org> Message-ID: On Wed, Feb 24, 2010 at 6:09 PM, James Cameron wrote: > > Yeah, I feel like doing it, but why should it be fixed? ?Does it really > exist? ?Have you even noticed it? Nope. Zach From niclas at acc.umu.se Thu Feb 25 01:07:23 2010 From: niclas at acc.umu.se (Niclas Fredriksson) Date: Thu, 25 Feb 2010 08:07:23 +0100 (MET) Subject: [netrek-dev] p_explode damage frame, classic vs 50 fps In-Reply-To: <20100224222525.GK5978@us.netrek.org> References: <20100221101709.GA5866@us.netrek.org> <20100224222525.GK5978@us.netrek.org> Message-ID: On Thu, 25 Feb 2010, James Cameron wrote: > On Wed, Feb 24, 2010 at 02:24:26PM +0100, Niclas Fredriksson wrote: >> On Sun, 21 Feb 2010, James Cameron wrote: >>> This should *entirely* change base ogging. >> >> It sounds like another change that makes it easier and more advantageous >> to play passively rather than aggressively, just like all the changes to >> updates per second? > > I don't see how this coding error would favour passive strategy over > aggressive strategy. Could you explain? I probably didn't understand your explanation but it seemed to me the change makes it more difficult to deal ship explosion damage to the base when ogging. If it's more difficult to damage with explosions then there will be less of an advantage of being aggressive and trying to close the distance to the enemy. But if I misunderstood your explanation, how do you mean this change should "*entirely* change base ogging"? -- Niclas From quozl at us.netrek.org Thu Feb 25 15:35:25 2010 From: quozl at us.netrek.org (James Cameron) Date: Fri, 26 Feb 2010 08:35:25 +1100 Subject: [netrek-dev] p_explode damage frame, classic vs 50 fps In-Reply-To: References: <20100221101709.GA5866@us.netrek.org> <20100224222525.GK5978@us.netrek.org> Message-ID: <20100225213525.GA6717@us.netrek.org> On Thu, Feb 25, 2010 at 08:07:23AM +0100, Niclas Fredriksson wrote: > I probably didn't understand your explanation but it seemed to me the > change makes it more difficult to deal ship explosion damage to the base > when ogging. If it's more difficult to damage with explosions then there > will be less of an advantage of being aggressive and trying to close the > distance to the enemy. > > But if I misunderstood your explanation, how do you mean this change > should "*entirely* change base ogging"? Okay, my mistake. I shall try to explain better. The reason it changed base ogging is that the explosion damage arrives sooner than it used to. This matters only when there is a significant difference in momentum between the base and the ogger. In the prior code, the best damage was achieved by timing the explosion to arrive in the vicinity of the base 400ms after the explosion begins. In the current code, this best time is 80ms after the explosion begins. For ogging pilots, especially the new ones, they will have learned to deliver their explosion sooner. Also, for base pilots with good reaction time (under 400ms plus lag), it was possible in the prior code to react to manage the explosion damage; by either pressor, tractor, steering, or shield changes. Moving out of the near field of the explosion reduces the damage applied. In the current code, there is insufficient time to react. For base pilots, they will have learned to concentrate on managing the situation leading up to the explosion and no longer managing the situation after the explosion. I think that the coding error makes it more easy to deal ship explosion damage to the base when ogging, since an explosion is uncontrolled once it starts, whereas previously the defender could exert some control over the explosion by moving. -- James Cameron http://quozl.linux.org.au/ From mark at mark.mielke.cc Thu Feb 25 22:19:02 2010 From: mark at mark.mielke.cc (Mark Mielke) Date: Thu, 25 Feb 2010 23:19:02 -0500 Subject: [netrek-dev] p_explode damage frame, classic vs 50 fps In-Reply-To: References: <20100221101709.GA5866@us.netrek.org> <20100224222525.GK5978@us.netrek.org> Message-ID: <4B874BB6.9060906@mark.mielke.cc> On 02/25/2010 02:07 AM, Niclas Fredriksson wrote: > On Thu, 25 Feb 2010, James Cameron wrote: > >> I don't see how this coding error would favour passive strategy over >> aggressive strategy. Could you explain? >> > I probably didn't understand your explanation but it seemed to me the > change makes it more difficult to deal ship explosion damage to the base > when ogging. If it's more difficult to damage with explosions then there > will be less of an advantage of being aggressive and trying to close the > distance to the enemy. > > But if I misunderstood your explanation, how do you mean this change > should "*entirely* change base ogging"? > Just to play devil's advocate for a second - doesn't reduced time window during which you can inflict damage imply that you must SPEED UP to apply the most damage, i.e. you must be MORE aggressive? :-) Being slow and passive while ogging now means zero damage to the SB, whereas before it meant *some* damage... Cheers, mark From quozl at us.netrek.org Thu Feb 25 22:54:29 2010 From: quozl at us.netrek.org (James Cameron) Date: Fri, 26 Feb 2010 15:54:29 +1100 Subject: [netrek-dev] p_explode damage frame, classic vs 50 fps In-Reply-To: <4B874BB6.9060906@mark.mielke.cc> References: <20100221101709.GA5866@us.netrek.org> <20100224222525.GK5978@us.netrek.org> <4B874BB6.9060906@mark.mielke.cc> Message-ID: <20100226045429.GB16147@us.netrek.org> On Thu, Feb 25, 2010 at 11:19:02PM -0500, Mark Mielke wrote: > Just to play devil's advocate for a second - doesn't reduced time window > during which you can inflict damage [...] But it's not a reduced time window during which you can inflict damage (by explosion) ... it's a shift of the time window. For the base pilot, it is a reduced time window during which they can avoid damage following an explosion. -- James Cameron http://quozl.linux.org.au/ From mark at mark.mielke.cc Fri Feb 26 00:55:21 2010 From: mark at mark.mielke.cc (Mark Mielke) Date: Fri, 26 Feb 2010 01:55:21 -0500 Subject: [netrek-dev] p_explode damage frame, classic vs 50 fps In-Reply-To: <20100226045429.GB16147@us.netrek.org> References: <20100221101709.GA5866@us.netrek.org> <20100224222525.GK5978@us.netrek.org> <4B874BB6.9060906@mark.mielke.cc> <20100226045429.GB16147@us.netrek.org> Message-ID: <4B877059.5040207@mark.mielke.cc> On 02/25/2010 11:54 PM, James Cameron wrote: > On Thu, Feb 25, 2010 at 11:19:02PM -0500, Mark Mielke wrote: > >> Just to play devil's advocate for a second - doesn't reduced time window >> during which you can inflict damage [...] >> > But it's not a reduced time window during which you can inflict damage > (by explosion) ... it's a shift of the time window. > > For the base pilot, it is a reduced time window during which they can > avoid damage following an explosion. > Which means you must be closer to the target when you die to inflict the same damage, which I would call MORE aggressive, not less. :-) Less aggressive would imply that one changes strategies entirely, by giving up using the ship explosion as a weapon. Although some people might give up - I doubt that the experts will remove this tool from their tool chest and "give up", just because they have to get a big closer before they die... Cheers, mark From mrbax.nospam.2007 at gmail.com Fri Feb 26 20:24:54 2010 From: mrbax.nospam.2007 at gmail.com (mrbax.nospam.2007 at gmail.com) Date: Fri, 26 Feb 2010 18:24:54 -0800 (PST) Subject: [netrek-dev] p_explode damage frame, classic vs 50 fps In-Reply-To: <1031151697.3489811267237417101.JavaMail.root@zm03.stanford.edu> Message-ID: <211460733.3489971267237494156.JavaMail.root@zm03.stanford.edu> Hi folks > In the prior code, the best damage was achieved by timing the explosion > to arrive in the vicinity of the base 400ms after the explosion begins. > > In the current code, this best time is 80ms after the explosion begins. I vote for restoration of the original behaviour: ? It is the time-tested version optimized for classic play. ? A bug is unlikely ever to result in optimal play. ? Old players are used to the original behaviour and are impacted. ? New players users are not often found to be competent base pilots and are unlikely to benefit, let alone notice. ? Typical minimum human response times are around 100 ms. A delay of 80 ms is likely too small to be of value, especially when some players already have to deal with round-trip delays of over 300 ms. ? If the traditional value is determined to be suboptimal, an optimal value should be determined by thorough play-testing. Cheers Michael From netrek at gmail.com Fri Feb 26 20:37:30 2010 From: netrek at gmail.com (Zachary Uram) Date: Fri, 26 Feb 2010 21:37:30 -0500 Subject: [netrek-dev] p_explode damage frame, classic vs 50 fps In-Reply-To: <211460733.3489971267237494156.JavaMail.root@zm03.stanford.edu> References: <1031151697.3489811267237417101.JavaMail.root@zm03.stanford.edu> <211460733.3489971267237494156.JavaMail.root@zm03.stanford.edu> Message-ID: On Fri, Feb 26, 2010 at 9:24 PM, wrote: > Hi folks > > I vote for restoration of the original behaviour: > ? ?? It is the time-tested version optimized for classic play. > ? ?? A bug is unlikely ever to result in optimal play. > ? ?? Old players are used to the original behaviour and are impacted. > ? ?? New players users are not often found to be competent base pilots and > ? ? ?are unlikely to benefit, let alone notice. > ? ?? Typical minimum human response times are around 100 ms. ?A delay of > ? ? ?80 ms is likely too small to be of value, especially when some > ? ? ?players already have to deal with round-trip delays of over 300 ms. > ? ?? If the traditional value is determined to be suboptimal, an optimal > ? ? ?value should be determined by thorough play-testing. I agree with you Michael - good points. Please restore the original code server admins. Zach From jrd at gerdesas.com Fri Feb 26 20:47:51 2010 From: jrd at gerdesas.com (John R. Dennison) Date: Fri, 26 Feb 2010 20:47:51 -0600 Subject: [netrek-dev] p_explode damage frame, classic vs 50 fps In-Reply-To: References: <1031151697.3489811267237417101.JavaMail.root@zm03.stanford.edu> <211460733.3489971267237494156.JavaMail.root@zm03.stanford.edu> Message-ID: <20100227024751.GP26264@frodo.gerdesas.com> On Fri, Feb 26, 2010 at 09:37:30PM -0500, Zachary Uram wrote: > > I agree with you Michael - good points. Please restore the original > code server admins. Please push a patch that restores original behavior and *then* ask for it to be put back in place. You *do* understand that this doesn't affect the only server that gets any activity to speak of, right? John -- This is all happening because my father didn't buy me a train set as a kid. -- Warren Buffett, joking about his decision to buy a railroad, the Burlington Northern Santa Fe Corporation, New York Times, 4 November 2009 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20100226/0d833a0e/attachment.pgp From mark at mark.mielke.cc Fri Feb 26 20:50:51 2010 From: mark at mark.mielke.cc (Mark Mielke) Date: Fri, 26 Feb 2010 21:50:51 -0500 Subject: [netrek-dev] p_explode damage frame, classic vs 50 fps In-Reply-To: <211460733.3489971267237494156.JavaMail.root@zm03.stanford.edu> References: <211460733.3489971267237494156.JavaMail.root@zm03.stanford.edu> Message-ID: <4B88888B.7010300@mark.mielke.cc> On 02/26/2010 09:24 PM, mrbax.nospam.2007 at gmail.com wrote: > Hi folks > > >> In the prior code, the best damage was achieved by timing the explosion >> to arrive in the vicinity of the base 400ms after the explosion begins. >> >> In the current code, this best time is 80ms after the explosion begins. >> > I vote for restoration of the original behaviour: > ? It is the time-tested version optimized for classic play. > The test of time has shown Netrek to come up short. :-) > ? A bug is unlikely ever to result in optimal play. > In many games, design intent is later exposed as not providing optimal play. That's why games such as C&C will adjust the specs for units with each patch release. Design intent does not guarantee optimal play. Analysis of play, and careful evolution based on user feedback provides for optimal play. A bug may or may not affect optimal play. Did you notice the difference? > ? Old players are used to the original behaviour and are impacted. > Where are the old players? They probably have families and careers and no longer have time to play with the exception of those who make time. :-) > ? New players users are not often found to be competent base pilots and > are unlikely to benefit, let alone notice. > Who noticed? > ? Typical minimum human response times are around 100 ms. A delay of > 80 ms is likely too small to be of value, especially when some > players already have to deal with round-trip delays of over 300 ms. > I used to find the delayed explosion really odd. My memory might be wrong - but I think in high speed scenarios, a starbase could tractor and repress the ship right through the SB, and achieve reduced damage. To me, that's a bug. Try doing that in real life when a car is bearing down on you. :-) > ? If the traditional value is determined to be suboptimal, an optimal > value should be determined by thorough play-testing. > Or simply by vote. I vote much ado about damage long done and unnoticed. :-) Cheers, mark P.S. Sorry - still playing devil's advocate. I'm more amused about this issue than anything. From jrd at gerdesas.com Fri Feb 26 20:55:36 2010 From: jrd at gerdesas.com (John R. Dennison) Date: Fri, 26 Feb 2010 20:55:36 -0600 Subject: [netrek-dev] p_explode damage frame, classic vs 50 fps In-Reply-To: <4B88888B.7010300@mark.mielke.cc> References: <211460733.3489971267237494156.JavaMail.root@zm03.stanford.edu> <4B88888B.7010300@mark.mielke.cc> Message-ID: <20100227025536.GQ26264@frodo.gerdesas.com> On Fri, Feb 26, 2010 at 09:50:51PM -0500, Mark Mielke wrote: > > In many games, design intent is later exposed as not providing optimal > play. That's why games such as C&C will adjust the specs for units with > each patch release. Design intent does not guarantee optimal play. > Analysis of play, and careful evolution based on user feedback provides > for optimal play. A bug may or may not affect optimal play. Did you > notice the difference? The only server to see any meaningful amount of usage isn't affected; this is truly a non-issue. John -- Never, never be afraid to do what's right, especially if the well-being of a person or animal is at stake. Society's punishments are small compared to the wounds we inflict on our soul when we look the other way. -- Martin Luther King Jr. (1929-1968), civil-rights leader -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20100226/b64e21de/attachment.pgp From mrbax.nospam.2007 at gmail.com Fri Feb 26 21:19:05 2010 From: mrbax.nospam.2007 at gmail.com (mrbax.nospam.2007 at gmail.com) Date: Fri, 26 Feb 2010 19:19:05 -0800 (PST) Subject: [netrek-dev] p_explode damage frame, classic vs 50 fps In-Reply-To: <1056372217.3497241267240558313.JavaMail.root@zm03.stanford.edu> Message-ID: <252973366.3497521267240745368.JavaMail.root@zm03.stanford.edu> Hi folks > The test of time has shown Netrek to come up short. :-) Indeed, but why aggravate that? :-P > In many games, design intent is later exposed as not providing optimal > play. That's why games such as C&C will adjust the specs for units with > each patch release. Design intent does not guarantee optimal play. True, but which is more _likely_ to result in good play: accident or design? > Did you notice the difference? No meaningful SB track record myself. > Where are the old players? They probably have families and careers and > no longer have time to play with the exception of those who make time. :-) But those who make time constitute ~50% of the current player base! :-P > I used to find the delayed explosion really odd. My memory might be > wrong - but I think in high speed scenarios, a starbase could tractor > and repress the ship right through the SB, and achieve reduced damage. > To me, that's a bug. Sounds like a tractor-pressor philosophical issue to me, although if you consider Z-depth it can be explained away; delayed explosion surely is another issue? I assume the idea is to simulate a chain reaction: fatal damage triggering warp core explosion. > The only server to see any meaningful amount of usage isn't > affected; this is truly a non-issue. Surely the server will be upgraded at some point? I would bet that the 400 ms delay was a feature deliberately added in the mists of time, and retained for its depth of play; I assume that ogging was formerly considered to be too easy. Either way, 80 ms is too small to be meaningful. I see two options as superior to the status quo: 1. Remove the delay entirely. 2. Restore the original play-tested feature (my vote). Cheers Michael From jrd at gerdesas.com Fri Feb 26 21:33:01 2010 From: jrd at gerdesas.com (John R. Dennison) Date: Fri, 26 Feb 2010 21:33:01 -0600 Subject: [netrek-dev] p_explode damage frame, classic vs 50 fps In-Reply-To: <252973366.3497521267240745368.JavaMail.root@zm03.stanford.edu> References: <1056372217.3497241267240558313.JavaMail.root@zm03.stanford.edu> <252973366.3497521267240745368.JavaMail.root@zm03.stanford.edu> Message-ID: <20100227033300.GR26264@frodo.gerdesas.com> On Fri, Feb 26, 2010 at 07:19:05PM -0800, mrbax.nospam.2007 at gmail.com wrote: > > Surely the server will be upgraded at some point? "Upgraded"? It's up-to-date; there are no plans for it to run at more than 10 updates / second. John -- All I ask is this: Do something. Try something. Speaking out, showing up, writing a letter, a check, a strongly worded e-mail. Pick a cause -- there are few unworthy ones. And nudge yourself past the brink of tacit support to action. Once a month, once a year, or just once. -- Joss Whedon (1964-), writer and film director -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20100226/2cad44f7/attachment.pgp From mrbax.nospam.2007 at gmail.com Fri Feb 26 21:49:08 2010 From: mrbax.nospam.2007 at gmail.com (Michael Bax) Date: Fri, 26 Feb 2010 19:49:08 -0800 (PST) Subject: [netrek-dev] p_explode damage frame, classic vs 50 fps In-Reply-To: <20100227033300.GR26264@frodo.gerdesas.com> Message-ID: <406946249.3500471267242548531.JavaMail.root@zm03.stanford.edu> Hi John > > Surely the server will be upgraded at some point? > > "Upgraded"? It's up-to-date; there are no plans for it to run > at more than 10 updates / second. Have you decided on a feature freeze for the core server? Surely some worthy features may be introduced over the next decade? What is your position on lower-frequency updates being a newbie deterrent? Cheers Michael From mark at mark.mielke.cc Fri Feb 26 22:10:25 2010 From: mark at mark.mielke.cc (Mark Mielke) Date: Fri, 26 Feb 2010 23:10:25 -0500 Subject: [netrek-dev] p_explode damage frame, classic vs 50 fps In-Reply-To: <406946249.3500471267242548531.JavaMail.root@zm03.stanford.edu> References: <406946249.3500471267242548531.JavaMail.root@zm03.stanford.edu> Message-ID: <4B889B31.6040903@mark.mielke.cc> On 02/26/2010 10:49 PM, Michael Bax wrote: >>> Surely the server will be upgraded at some point? >>> >> "Upgraded"? It's up-to-date; there are no plans for it to run >> at more than 10 updates / second. >> > Have you decided on a feature freeze for the core server? Surely some worthy features may be introduced over the next decade? > > What is your position on lower-frequency updates being a newbie deterrent? 10 fps is still pretty good for online gaming. Now *5* fps was not enough. My memory is really weak on this, but I recall how SB was allowed to use 10 fps, but regular ships were only 5 fps. Ah the times of much slower networks... Good riddance! :-) Cheers, mark From jrd at gerdesas.com Fri Feb 26 22:51:31 2010 From: jrd at gerdesas.com (John R. Dennison) Date: Fri, 26 Feb 2010 22:51:31 -0600 Subject: [netrek-dev] p_explode damage frame, classic vs 50 fps In-Reply-To: <406946249.3500471267242548531.JavaMail.root@zm03.stanford.edu> References: <20100227033300.GR26264@frodo.gerdesas.com> <406946249.3500471267242548531.JavaMail.root@zm03.stanford.edu> Message-ID: <20100227045131.GS26264@frodo.gerdesas.com> On Fri, Feb 26, 2010 at 07:49:08PM -0800, Michael Bax wrote: > > Have you decided on a feature freeze for the core server? Surely some > worthy features may be introduced over the next decade? I've not decided anything for pickled; I don't set policy there as it's not my server. I have, however, spent many hours talking with Karthik about policy there and there is absolutely no reason to bump up updates / second. Karthik has conducted at least one poll of players to determine the desire of the player base to have UPS ramped to 50. The results were either neutral or totally against it, very few wanted it. And 50 UPS does change game mechanics no matter how much others claim or wish otherwise. And I would think that Karthik would evaluate features on a case by case basis as he has always done in the past. But I'm pretty sure that anything that changes the base nature of the game won't be enabled. Hence why more of the more retarded borg features are not enabled on pickled :) > What is your position on lower-frequency updates being a newbie deterrent? It is completely irrelevant. John -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20100226/b048a3f8/attachment.pgp