From ahn at netrek.org  Wed Jul  1 00:04:47 2020
From: ahn at netrek.org (Dave Ahn)
Date: Wed, 1 Jul 2020 01:04:47 -0400
Subject: [netrek-dev] github.com/netrek
Message-ID: <CABt_h+eoJyzEC+NWTh6AwkX7kxQ42Kk9AXSpHFmGqREujLF+Sw@mail.gmail.com>

We have decided to move all of our Netrek source code and other
repositories to github.com/netrek.  The Netrek community started using
shared SCCS at the end of the 90's, and most of the primary repositories
with over 20 years of history have been imported into github.

If you are an active developer or maintainer of Netrek software, we invite
you to join github.com/netrek as a contributor and associate your projects
with the Netrek org.  If you have disassociated or duplicate repositories,
we invite you to work with us to reassociate them to github.com/netrek in
order to preserve the original histories.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20200701/e3e862ba/attachment.htm>

From darrellroot at mac.com  Wed Jul  1 01:43:01 2020
From: darrellroot at mac.com (Darrell Root)
Date: Tue, 30 Jun 2020 23:43:01 -0700
Subject: [netrek-dev] github.com/netrek
In-Reply-To: <CABt_h+eoJyzEC+NWTh6AwkX7kxQ42Kk9AXSpHFmGqREujLF+Sw@mail.gmail.com>
References: <CABt_h+eoJyzEC+NWTh6AwkX7kxQ42Kk9AXSpHFmGqREujLF+Sw@mail.gmail.com>
Message-ID: <FA683560-E916-4A8E-845A-28D81275908C@mac.com>


I’d be happy to “join” as a contributor, but am not sure how to send a “join” request to the org.  My github username is darrellroot

https://github.com/darrellroot/Netrek-SwiftUI <https://github.com/darrellroot/Netrek-SwiftUI>  is my repository for the MacOS/iOS/iPadOS client currently distributed (for free) in the MacOS App Store.  It’s open source under the MIT license.  This is actively maintained.

https://github.com/darrellroot/SwiftNetrek <https://github.com/darrellroot/SwiftNetrek> is an old repository with the no longer maintained SpriteKit version of the MacOS client.  Your call whether that is worth forking to the repository.  It is also open source under the MIT license.

As long as I’m spamming the group, I can’t resist a sneak preview of my current project:

% sudo tcpdump port 2592 -vv -X

(showing packet #4, after the tcp handshake)

23:23:44.750362 IP6 (flowlabel 0xf2dfa, hlim 64, next-header TCP (6) payload length: 40) 2601:647:4802:1620:f90e:fafa:5906:114e.62508 > 2601:647:4802:1620:186d:f10a:3fb7:cb8.netrek: Flags [P.], cksum 0xc948 (incorrect -> 0xa176), seq 1:9, ack 1, win 2052, options [nop,nop,TS val 496760046 ecr 846968271], length 8
	0x0000:  3c22 fb28 3a6d 685b 3589 0a04 86dd 600f  <".(:mh[5.....`.
	0x0010:  2dfa 0028 0640 2601 0647 4802 1620 f90e  -..(.@&..GH.....
	0x0020:  fafa 5906 114e 2601 0647 4802 1620 186d  ..Y..N&..GH....m
	0x0030:  f10a 3fb7 0cb8 f42c 0a20 06e8 5cae 876b  ..?....,....\..k
	0x0040:  7ad0 8018 0804 c948 0000 0101 080a 1d9b  z......H........
	0x0050:  f4ee 327b b5cf 1b04 0a00 0000 8020       ..2{..........


struct socket_cpacket { /* CP_SOCKET py-struct "!bbbxI" #27 */
    char type;
    char version;
    char udp_version;	/* was pad2 */
    char pad3;
    u_int socket;
};

Yes, that is a Netrek CP_SOCKET packet, inside an IPv6 TCP segment!

Hopefully I’ll have an update in a couple weeks.

Darrell


> On Jun 30, 2020, at 10:04 PM, Dave Ahn <ahn at netrek.org> wrote:
> 
> We have decided to move all of our Netrek source code and other repositories to github.com/netrek <http://github.com/netrek>.  The Netrek community started using shared SCCS at the end of the 90's, and most of the primary repositories with over 20 years of history have been imported into github.
> 
> If you are an active developer or maintainer of Netrek software, we invite you to join github.com/netrek <http://github.com/netrek> as a contributor and associate your projects with the Netrek org.  If you have disassociated or duplicate repositories, we invite you to work with us to reassociate them to github.com/netrek <http://github.com/netrek> in order to preserve the original histories.
> 
> 
> 
> _______________________________________________
> 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: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20200630/ad11f147/attachment-0001.htm>

From quozl at laptop.org  Wed Jul  1 02:16:31 2020
From: quozl at laptop.org (James Cameron)
Date: Wed, 1 Jul 2020 17:16:31 +1000
Subject: [netrek-dev] github.com/netrek
In-Reply-To: <FA683560-E916-4A8E-845A-28D81275908C@mac.com>
References: <CABt_h+eoJyzEC+NWTh6AwkX7kxQ42Kk9AXSpHFmGqREujLF+Sw@mail.gmail.com>
 <FA683560-E916-4A8E-845A-28D81275908C@mac.com>
Message-ID: <20200701071631.GJ8017@laptop.org>

I've invited you as a member.

Once you have accepted the invitation, you may use GitHub to fork your
two repositories to the netrek org.  You then take on responsibility
to keep those forks up to date, e.g. on each release.

There's probably also a way on GitHub to create a repository that
mirrors your own, but I've not figured that out yet.

By having your two repos forked on netrek org, people can find them
more easily.

I'd say it's your call whether SwiftNetrek should be forked as well;
we have a lot of historical repositories, so no reason not to have
another.

On Tue, Jun 30, 2020 at 11:43:01PM -0700, Darrell Root wrote:
> 
> I’d be happy to “join” as a contributor, but am not sure how to send a “join”
> request to the org.  My github username is darrellroot
> 
> [1]https://github.com/darrellroot/Netrek-SwiftUI  is my repository for the
> MacOS/iOS/iPadOS client currently distributed (for free) in the MacOS App
> Store.  It’s open source under the MIT license.  This is actively maintained.
> 
> [2]https://github.com/darrellroot/SwiftNetrek is an old repository with the no
> longer maintained SpriteKit version of the MacOS client.  Your call whether
> that is worth forking to the repository.  It is also open source under the MIT
> license.
> 
> As long as I’m spamming the group, I can’t resist a sneak preview of my current
> project:
> 
> % sudo tcpdump port 2592 -vv -X
> 
> (showing packet #4, after the tcp handshake)
> 
> 23:23:44.750362 IP6 (flowlabel 0xf2dfa, hlim 64, next-header TCP (6) payload
> length: 40) 2601:647:4802:1620:f90e:fafa:5906:114e.62508 >
> 2601:647:4802:1620:186d:f10a:3fb7:cb8.netrek: Flags [P.], cksum 0xc948
> (incorrect -> 0xa176), seq 1:9, ack 1, win 2052, options [nop,nop,TS val
> 496760046 ecr 846968271], length 8
> 0x0000:  3c22 fb28 3a6d 685b 3589 0a04 86dd 600f  <".(:mh[5.....`.
> 0x0010:  2dfa 0028 0640 2601 0647 4802 1620 f90e  -..(.@&..GH.....
> 0x0020:  fafa 5906 114e 2601 0647 4802 1620 186d  ..Y..N&..GH....m
> 0x0030:  f10a 3fb7 0cb8 f42c 0a20 06e8 5cae 876b  ..?....,....\..k
> 0x0040:  7ad0 8018 0804 c948 0000 0101 080a 1d9b  z......H........
> 0x0050:  f4ee 327b b5cf 1b04 0a00 0000 8020       ..2{..........
> 
> struct socket_cpacket { /* CP_SOCKET py-struct "!bbbxI" #27 */
>     char type;
>     char version;
>     char udp_version; /* was pad2 */
>     char pad3;
>     u_int socket;
> };
> 
> Yes, that is a Netrek CP_SOCKET packet, inside an IPv6 TCP segment!
> 
> Hopefully I’ll have an update in a couple weeks.
> 
> Darrell
> 
>     On Jun 30, 2020, at 10:04 PM, Dave Ahn <[3]ahn at netrek.org> wrote:
> 
>     We have decided to move all of our Netrek source code and other
>     repositories to [4]github.com/netrek.  The Netrek community started using
>     shared SCCS at the end of the 90's, and most of the primary repositories
>     with over 20 years of history have been imported into github.
> 
>     If you are an active developer or maintainer of Netrek software, we invite
>     you to join [5]github.com/netrek as a contributor and associate your
>     projects with the Netrek org.  If you have disassociated or duplicate
>     repositories, we invite you to work with us to reassociate them to [6]
>     github.com/netrek in order to preserve the original histories.
> 
>     _______________________________________________
>     netrek-dev mailing list
>     [7]netrek-dev at us.netrek.org
>     http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
> 
> References:
> 
> [1] https://github.com/darrellroot/Netrek-SwiftUI
> [2] https://github.com/darrellroot/SwiftNetrek
> [3] mailto:ahn at netrek.org
> [4] http://github.com/netrek
> [5] http://github.com/netrek
> [6] http://github.com/netrek
> [7] mailto:netrek-dev at us.netrek.org

> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev


-- 
James Cameron
http://quozl.netrek.org/

From telackey at lacklustremedia.com  Wed Jul  1 09:43:44 2020
From: telackey at lacklustremedia.com (Thomas E. Lackey)
Date: Wed, 1 Jul 2020 14:43:44 +0000
Subject: [netrek-dev] github.com/netrek
In-Reply-To: <20200701071631.GJ8017@laptop.org>
References: <CABt_h+eoJyzEC+NWTh6AwkX7kxQ42Kk9AXSpHFmGqREujLF+Sw@mail.gmail.com>
 <FA683560-E916-4A8E-845A-28D81275908C@mac.com>,
 <20200701071631.GJ8017@laptop.org>
Message-ID: <DM6PR04MB53221A751301AD67E0255E84F16C0@DM6PR04MB5322.namprd04.prod.outlook.com>

If you could invite me, I'd appreciate it.

You can use this email address or my github username is telackey.

Did you ever track down the BRMH history?  I have some minor fixes for compiling on IRIX.

Cheers,

--
Thomas E Lackey

________________________________
From: netrek-dev <netrek-dev-bounces at us.netrek.org> on behalf of James Cameron <quozl at laptop.org>
Sent: Wednesday, July 1, 2020 2:25 AM
To: Darrell Root
Cc: Netrek Development Mailing List
Subject: Re: [netrek-dev] github.com/netrek

I've invited you as a member.

Once you have accepted the invitation, you may use GitHub to fork your
two repositories to the netrek org. You then take on responsibility
to keep those forks up to date, e.g. on each release.

There's probably also a way on GitHub to create a repository that
mirrors your own, but I've not figured that out yet.

By having your two repos forked on netrek org, people can find them
more easily.

I'd say it's your call whether SwiftNetrek should be forked as well;
we have a lot of historical repositories, so no reason not to have
another.

On Tue, Jun 30, 2020 at 11:43:01PM -0700, Darrell Root wrote:
>
> I’d be happy to “join” as a contributor, but am not sure how to send a “join”
> request to the org. My github username is darrellroot
>
> [1]https://github.com/darrellroot/Netrek-SwiftUI is my repository for the
> MacOS/iOS/iPadOS client currently distributed (for free) in the MacOS App
> Store. It’s open source under the MIT license. This is actively maintained.
>
> [2]https://github.com/darrellroot/SwiftNetrek is an old repository with the no
> longer maintained SpriteKit version of the MacOS client. Your call whether
> that is worth forking to the repository. It is also open source under the MIT
> license.
>
> As long as I’m spamming the group, I can’t resist a sneak preview of my current
> project:
>
> % sudo tcpdump port 2592 -vv -X
>
> (showing packet #4, after the tcp handshake)
>
> 23:23:44.750362 IP6 (flowlabel 0xf2dfa, hlim 64, next-header TCP (6) payload
> length: 40) 2601:647:4802:1620:f90e:fafa:5906:114e.62508 >
> 2601:647:4802:1620:186d:f10a:3fb7:cb8.netrek: Flags [P.], cksum 0xc948
> (incorrect -> 0xa176), seq 1:9, ack 1, win 2052, options [nop,nop,TS val
> 496760046 ecr 846968271], length 8
> 0x0000: 3c22 fb28 3a6d 685b 3589 0a04 86dd 600f <".(:mh[5.....`.
> 0x0010: 2dfa 0028 0640 2601 0647 4802 1620 f90e -..(.@&..GH.....
> 0x0020: fafa 5906 114e 2601 0647 4802 1620 186d ..Y..N&..GH....m
> 0x0030: f10a 3fb7 0cb8 f42c 0a20 06e8 5cae 876b ..?....,....\..k
> 0x0040: 7ad0 8018 0804 c948 0000 0101 080a 1d9b z......H........
> 0x0050: f4ee 327b b5cf 1b04 0a00 0000 8020 ..2{..........
>
> struct socket_cpacket { /* CP_SOCKET py-struct "!bbbxI" #27 */
> char type;
> char version;
> char udp_version; /* was pad2 */
> char pad3;
> u_int socket;
> };
>
> Yes, that is a Netrek CP_SOCKET packet, inside an IPv6 TCP segment!
>
> Hopefully I’ll have an update in a couple weeks.
>
> Darrell
>
> On Jun 30, 2020, at 10:04 PM, Dave Ahn <[3]ahn at netrek.org> wrote:
>
> We have decided to move all of our Netrek source code and other
> repositories to [4]github.com/netrek. The Netrek community started using
> shared SCCS at the end of the 90's, and most of the primary repositories
> with over 20 years of history have been imported into github.
>
> If you are an active developer or maintainer of Netrek software, we invite
> you to join [5]github.com/netrek as a contributor and associate your
> projects with the Netrek org. If you have disassociated or duplicate
> repositories, we invite you to work with us to reassociate them to [6]
> github.com/netrek in order to preserve the original histories.
>
> _______________________________________________
> netrek-dev mailing list
> [7]netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
>
> References:
>
> [1] https://github.com/darrellroot/Netrek-SwiftUI
> [2] https://github.com/darrellroot/SwiftNetrek
> [3] mailto:ahn at netrek.org
> [4] http://github.com/netrek
> [5] http://github.com/netrek
> [6] http://github.com/netrek
> [7] mailto:netrek-dev at us.netrek.org

> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev


--
James Cameron
http://quozl.netrek.org/
_______________________________________________
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: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20200701/52f91e32/attachment.htm>

From karthik at karthik.com  Thu Jul  2 20:30:07 2020
From: karthik at karthik.com (Karthik Arumugham)
Date: Thu, 2 Jul 2020 18:30:07 -0700
Subject: [netrek-dev] Where's BRMH commit history?
In-Reply-To: <CABt_h+fr8i=0Ds92nbSiwcTRC-jN_oGgKsXEjd49BxHN=Fu3HQ@mail.gmail.com>
References: <CABt_h+fr8i=0Ds92nbSiwcTRC-jN_oGgKsXEjd49BxHN=Fu3HQ@mail.gmail.com>
Message-ID: <FB79A525-5976-4583-A8D8-5034DFB3CE63@karthik.com>

I may have bits and pieces of it somewhere, but it’s possible much of it was lost to history...I don’t have the machines all that lived on anymore.

I’ll need to pull down and unpack some backups and will let you know if I find any of the old commits once I do that.

> On Jun 30, 2020, at 21:24, Dave Ahn <ahn at netrek.org> wrote:
> 
> 
> As I recall, Karthik maintained BRMH during that period.  Karthik, do you still have your old repo?
> 
>> On Tue, Jun 30, 2020 at 11:18 PM James Cameron <quozl at laptop.org> wrote:
>> There's a 2.4.1 with commit history between 2000 and 2001 in
>> https://github.com/netrek/netrek-client-brmh
>> 
>> There's a 2.5 unpacked from a tarball with commit history between 2017
>> and 2020 in
>> https://github.com/hyperyoda/netrek-client-brmh
>> 
>> The repositories are disassociated.
>> 
>> Where's the history between 2001 and 2017?
>> 
>> -- 
>> James Cameron
>> http://quozl.netrek.org/
>> _______________________________________________
>> 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: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20200702/6f39732f/attachment.htm>

From ahn at netrek.org  Fri Jul  3 08:20:22 2020
From: ahn at netrek.org (Dave Ahn)
Date: Fri, 3 Jul 2020 09:20:22 -0400
Subject: [netrek-dev] Where's BRMH commit history?
In-Reply-To: <FB79A525-5976-4583-A8D8-5034DFB3CE63@karthik.com>
References: <CABt_h+fr8i=0Ds92nbSiwcTRC-jN_oGgKsXEjd49BxHN=Fu3HQ@mail.gmail.com>
 <FB79A525-5976-4583-A8D8-5034DFB3CE63@karthik.com>
Message-ID: <CABt_h+fV_zCD94dtcdjtkekwOVpxcbM97xOiFkQif2BgZ6o44Q@mail.gmail.com>

We have full history through 2.4.0 in git, and I have copies of your
tarball sources from 2007 and 2008 (probably 2.5) and 2009 (2.6.0 pre).
Let me know what you find in the next couple of weeks.  If they're gone, I
can commit the diffs from tarballs and attribute them to you.

Also, will you be maintaining BRMH going forward?  Thomas Lackey
volunteered to help you or take over for you, so let us know.

On Thu, Jul 2, 2020 at 9:30 PM Karthik Arumugham <karthik at karthik.com>
wrote:

> I may have bits and pieces of it somewhere, but it’s possible much of it
> was lost to history...I don’t have the machines all that lived on anymore.
>
> I’ll need to pull down and unpack some backups and will let you know if I
> find any of the old commits once I do that.
>
> On Jun 30, 2020, at 21:24, Dave Ahn <ahn at netrek.org> wrote:
>
> 
> As I recall, Karthik maintained BRMH during that period.  Karthik, do you
> still have your old repo?
>
> On Tue, Jun 30, 2020 at 11:18 PM James Cameron <quozl at laptop.org> wrote:
>
>> There's a 2.4.1 with commit history between 2000 and 2001 in
>> https://github.com/netrek/netrek-client-brmh
>>
>> There's a 2.5 unpacked from a tarball with commit history between 2017
>> and 2020 in
>> https://github.com/hyperyoda/netrek-client-brmh
>>
>> The repositories are disassociated.
>>
>> Where's the history between 2001 and 2017?
>>
>> --
>> James Cameron
>> http://quozl.netrek.org/
>> _______________________________________________
>> 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: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20200703/9d768e11/attachment.htm>

From darrellroot at mac.com  Fri Jul  3 13:45:00 2020
From: darrellroot at mac.com (Darrell Root)
Date: Fri, 3 Jul 2020 11:45:00 -0700
Subject: [netrek-dev] Is the data in SP_STATUS 14 useless for the client?
Message-ID: <0A742008-FA68-40C5-A9BC-E341CB25E793@mac.com>


I login to pickled.netrek.org <http://pickled.netrek.org/> as guest.  No t-mode in progress.  Right at the start my client receives a SP_STATUS packet:

struct status_spacket { /* SP_STATUS py-struct "!bbxxIIIIIL" #14 */
    char type;
    char tourn;
    char pad1;
    char pad2;
    u_int armsbomb;
    u_int planets;
    u_int kills;
    u_int losses;
    u_int time;
    U_LONG timeprod;
};

That’s 28 bytes long.  Here are the bytes:

(lldb) po data
▿ 28 bytes
  - count : 28
  ▿ pointer : 0x00006000002fc9e0
    - pointerValue : 105553119398368
  ▿ bytes : 28 elements
    - 0 : 14
    - 1 : 0
    - 2 : 0
    - 3 : 0
    - 4 : 0
    - 5 : 13
    - 6 : 101
    - 7 : 235
    - 8 : 0
    - 9 : 0
    - 10 : 204
    - 11 : 190
    - 12 : 0
    - 13 : 12
    - 14 : 38
    - 15 : 249
    - 16 : 0
    - 17 : 12
    - 18 : 124
    - 19 : 118
    - 20 : 3
    - 21 : 158
    - 22 : 220
    - 23 : 147
    - 24 : 42
    - 25 : 198
    - 26 : 119
    - 27 : 106

Lets look at armsbomb, which is bytes 4 through 7 inclusive interpreted as an unsigned int.

    - 4 : 0
    - 5 : 13
    - 6 : 101
    - 7 : 235

Why are those not all 0?  I just joined the game as guest?  My code interprets that as 878059 armsBomb.

I just switched my username to “username5” (brand new user) and got the same values.  So it’s not a cumulative for “username guest for all time”.  Looks like it might be cumulative for the server.

Is SP_STATUS 14 a server-wide stat?  If yes then perhaps I should just throw the data I get from it away in my client (and use SP_STATS 23 instead).

Darrell




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20200703/dda0e5d9/attachment.htm>

From apsillers at gmail.com  Fri Jul  3 14:43:27 2020
From: apsillers at gmail.com (Andrew Sillers)
Date: Fri, 3 Jul 2020 15:43:27 -0400
Subject: [netrek-dev] Is the data in SP_STATUS 14 useless for the client?
In-Reply-To: <0A742008-FA68-40C5-A9BC-E341CB25E793@mac.com>
References: <0A742008-FA68-40C5-A9BC-E341CB25E793@mac.com>
Message-ID: <CAAHY0jQdj_iFrRt4scJ8S18AMbz99xCGqNm0ZQB067en9fALyw@mail.gmail.com>

Not an answer per se, but my client also throws away SP #14 (after
optionally logging it, it does nothing else):
https://github.com/apsillers/html5-netrek/blob/master/js/packets.js#L579

Andrew

On Fri, Jul 3, 2020, 2:45 PM Darrell Root <darrellroot at mac.com> wrote:

>
> I login to pickled.netrek.org as guest.  No t-mode in progress.  Right at
> the start my client receives a SP_STATUS packet:
>
> struct status_spacket { /* SP_STATUS py-struct "!bbxxIIIIIL" #14 */
>     char type;
>     char tourn;
>     char pad1;
>     char pad2;
>     u_int armsbomb;
>     u_int planets;
>     u_int kills;
>     u_int losses;
>     u_int time;
>     U_LONG timeprod;
> };
>
> That’s 28 bytes long.  Here are the bytes:
>
> *(lldb) **po data*
> ▿ 28 bytes
>   - count : 28
>   ▿ pointer : 0x00006000002fc9e0
>     - pointerValue : 105553119398368
>   ▿ bytes : 28 elements
>     - 0 : 14
>     - 1 : 0
>     - 2 : 0
>     - 3 : 0
>     - 4 : 0
>     - 5 : 13
>     - 6 : 101
>     - 7 : 235
>     - 8 : 0
>     - 9 : 0
>     - 10 : 204
>     - 11 : 190
>     - 12 : 0
>     - 13 : 12
>     - 14 : 38
>     - 15 : 249
>     - 16 : 0
>     - 17 : 12
>     - 18 : 124
>     - 19 : 118
>     - 20 : 3
>     - 21 : 158
>     - 22 : 220
>     - 23 : 147
>     - 24 : 42
>     - 25 : 198
>     - 26 : 119
>     - 27 : 106
>
> *Lets look at armsbomb, which is bytes 4 through 7 inclusive interpreted
> as an unsigned int.*
>
>     - 4 : 0
>     - 5 : 13
>     - 6 : 101
>     - 7 : 235
>
> Why are those not all 0?  I just joined the game as guest?  My code
> interprets that as 878059 armsBomb.
>
> I just switched my username to “username5” (brand new user) and got the
> same values.  So it’s not a cumulative for “username guest for all time”.
> Looks like it might be cumulative for the server.
>
> Is SP_STATUS 14 a server-wide stat?  If yes then perhaps I should just
> throw the data I get from it away in my client (and use SP_STATS 23
> instead).
>
> Darrell
>
>
>
>
> _______________________________________________
> 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: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20200703/f97333ed/attachment-0001.htm>

From darrellroot at mac.com  Fri Jul  3 17:03:16 2020
From: darrellroot at mac.com (Darrell Root)
Date: Fri, 3 Jul 2020 15:03:16 -0700
Subject: [netrek-dev] Is the data in SP_STATUS 14 useless for the client?
In-Reply-To: <CAAHY0jQdj_iFrRt4scJ8S18AMbz99xCGqNm0ZQB067en9fALyw@mail.gmail.com>
References: <0A742008-FA68-40C5-A9BC-E341CB25E793@mac.com>
 <CAAHY0jQdj_iFrRt4scJ8S18AMbz99xCGqNm0ZQB067en9fALyw@mail.gmail.com>
Message-ID: <3DF6EC1D-3C98-48F4-8663-6FE474208EC7@mac.com>

Thanks Andrew. I think I’ve got my answer and will throw it out.

It took me a while to confirm that I wasn’t messing up big-endian / little-endian again.  But 0 is 0 regardless of endianness ;-)

Darrell


> On Jul 3, 2020, at 12:43 PM, Andrew Sillers <apsillers at gmail.com> wrote:
> 
> Not an answer per se, but my client also throws away SP #14 (after optionally logging it, it does nothing else): https://github.com/apsillers/html5-netrek/blob/master/js/packets.js#L579 <https://github.com/apsillers/html5-netrek/blob/master/js/packets.js#L579>
> 
> Andrew
> 
> On Fri, Jul 3, 2020, 2:45 PM Darrell Root <darrellroot at mac.com <mailto:darrellroot at mac.com>> wrote:
> 
> I login to pickled.netrek.org <http://pickled.netrek.org/> as guest.  No t-mode in progress.  Right at the start my client receives a SP_STATUS packet:
> 
> struct status_spacket { /* SP_STATUS py-struct "!bbxxIIIIIL" #14 */
>     char type;
>     char tourn;
>     char pad1;
>     char pad2;
>     u_int armsbomb;
>     u_int planets;
>     u_int kills;
>     u_int losses;
>     u_int time;
>     U_LONG timeprod;
> };
> 
> That’s 28 bytes long.  Here are the bytes:
> 
> (lldb) po data
> ▿ 28 bytes
>   - count : 28
>   ▿ pointer : 0x00006000002fc9e0
>     - pointerValue : 105553119398368
>   ▿ bytes : 28 elements
>     - 0 : 14
>     - 1 : 0
>     - 2 : 0
>     - 3 : 0
>     - 4 : 0
>     - 5 : 13
>     - 6 : 101
>     - 7 : 235
>     - 8 : 0
>     - 9 : 0
>     - 10 : 204
>     - 11 : 190
>     - 12 : 0
>     - 13 : 12
>     - 14 : 38
>     - 15 : 249
>     - 16 : 0
>     - 17 : 12
>     - 18 : 124
>     - 19 : 118
>     - 20 : 3
>     - 21 : 158
>     - 22 : 220
>     - 23 : 147
>     - 24 : 42
>     - 25 : 198
>     - 26 : 119
>     - 27 : 106
> 
> Lets look at armsbomb, which is bytes 4 through 7 inclusive interpreted as an unsigned int.
> 
>     - 4 : 0
>     - 5 : 13
>     - 6 : 101
>     - 7 : 235
> 
> Why are those not all 0?  I just joined the game as guest?  My code interprets that as 878059 armsBomb.
> 
> I just switched my username to “username5” (brand new user) and got the same values.  So it’s not a cumulative for “username guest for all time”.  Looks like it might be cumulative for the server.
> 
> Is SP_STATUS 14 a server-wide stat?  If yes then perhaps I should just throw the data I get from it away in my client (and use SP_STATS 23 instead).
> 
> Darrell
> 
> 
> 
> 
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org <mailto:netrek-dev at us.netrek.org>
> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev <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: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20200703/fbff75a7/attachment.htm>

From quozl at laptop.org  Fri Jul  3 17:14:05 2020
From: quozl at laptop.org (James Cameron)
Date: Sat, 4 Jul 2020 08:14:05 +1000
Subject: [netrek-dev] Is the data in SP_STATUS 14 useless for the client?
In-Reply-To: <3DF6EC1D-3C98-48F4-8663-6FE474208EC7@mac.com>
References: <0A742008-FA68-40C5-A9BC-E341CB25E793@mac.com>
 <CAAHY0jQdj_iFrRt4scJ8S18AMbz99xCGqNm0ZQB067en9fALyw@mail.gmail.com>
 <3DF6EC1D-3C98-48F4-8663-6FE474208EC7@mac.com>
Message-ID: <20200703221405.GB25789@laptop.org>

Yes, they are server totals.  They can be used for assessing against
rank.  If your client does nothing with rank, and does not make
rank predictions, then you can ignore it.

-- 
James Cameron
http://quozl.netrek.org/

From darrellroot at mac.com  Fri Jul 10 16:07:33 2020
From: darrellroot at mac.com (Darrell Root)
Date: Fri, 10 Jul 2020 14:07:33 -0700
Subject: [netrek-dev] Announcing new Swift Netrek Server with IPv6 Support!
 (Early Alpha). Runs on Linux and MacOS
Message-ID: <1A105B08-146C-4FCE-BCC7-9B188951CDCC@mac.com>

Netrek-dev,

I am pleased to announce that I’ve partially implemented a new Netrek server in the Swift programming language!

My new server is at:  netrek.networkmom.net tcp port 2592.
Open source at https://github.com/darrellroot/netrek-server-swift <https://github.com/darrellroot/netrek-server-swift> under the MIT license.
I’ll fork a copy over to the Netrek organization once it is more stable.

My Swift code runs on both MacOS and Linux.  I did my development on MacOS and my server is a Linux VM.  This Swift netrek server does not use any Apple-specific frameworks.

Killer feature: IPv6 support!
13:43:00.437863 IP6 2601:647:4802:1620:403b:6b8a:3c56:83c7.62183 > 2604:a880:4:1d0::47:6000.netrek: Flags [.], ack 158093, win 2041, options [nop,nop,TS val 276688522 ecr 2709993860], length 0
13:43:00.437869 IP6 2601:647:4802:1620:403b:6b8a:3c56:83c7.62183 > 2604:a880:4:1d0::47:6000.netrek: Flags [.], ack 158105, win 2047, options [nop,nop,TS val 276688522 ecr 2709993860], length 0

My existing MacOS and iOS clients also support IPv6.  If a DNS entry for a Netrek server has both A and AAAA DNS records, my Swift clients automatically try the IPv6 connection first and fail back to IPv4 quickly (this is a standard feature of the modern “Network” API in MacOS / iOS).

 % host netrek.networkmom.net
netrek.networkmom.net has address 161.35.226.186
netrek.networkmom.net has IPv6 address 2604:a880:4:1d0::47:6000

I’ve been playing Netrek over IPv6 all week!

Major known issue:

* With BRMH and Windows clients, all planets show as invisible.  I’m assuming I’m messing up the SEEN flag and will figure out what the logic is supposed to be after a short break (my Mac/iOS clients are probably showing too much and may need an update).

How you can help:

Try connecting to the server with your favorite client, and report to me (darrellroot at mac.com <mailto:darrellroot at mac.com>) whether your client works (at least to the point of dogfighting and basic planet captures).  If it doesn’t, let me know the symptoms and the exact time you attempted to play so I can check the logs.

If I can get this server stable enough, I’d love for next Thursday’s 6PM game to be on netrek.networkmom.net <http://netrek.networkmom.net/> (with pickled.netrek.org <http://pickled.netrek.org/> as backup).

Darrell Root
darrellroot at mac.com

Here’s the current feature / not-yet-implemented lists:
Not currently implemented: (in rough order of imprtance)

Logic around t-mode, genocide, coup.
Authenticating logins
Remembering statistics between server restarts
Rank logic
Metaserver compatiblity / observers
No robots (not even iggy)
Plasma
Special starbase operations (docking, transwarp, rank requirements, spawn limitations, orbit limitations)
Refitting ships at homeworld
advanced cloaking visibility (1 per second, hiding far away ships)
hiding far away ships (PFSEEN flag?)
UDP sockets
Short packets
War logic (you are always at war with other teams)
coup
reset stats
 <https://github.com/darrellroot/netrek-server-swift#supported-but-everything-needs-more-testing>Supported, but everything needs more testing:

IPv6 (and IPv4) TCP Sockets!
Messages
Speed / direction
Laser
Torpedos
shields
repair
orbit
planet lock
player lock
bombing
beaming up/down
basic cloaking
Detting friendly and enemy torps
Tractor/pressor beam

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20200710/3d05a67e/attachment.htm>

From quozl at laptop.org  Fri Jul 10 18:27:58 2020
From: quozl at laptop.org (James Cameron)
Date: Sat, 11 Jul 2020 09:27:58 +1000
Subject: [netrek-dev] Announcing new Swift Netrek Server with IPv6
 Support! (Early Alpha). Runs on Linux and MacOS
In-Reply-To: <1A105B08-146C-4FCE-BCC7-9B188951CDCC@mac.com>
References: <1A105B08-146C-4FCE-BCC7-9B188951CDCC@mac.com>
Message-ID: <20200710232758.GC27619@laptop.org>

Cool.  Yes, lots of functionality is in the server.  Surprisingly lots.

-- 
James Cameron
http://quozl.netrek.org/

From darrellroot at mac.com  Tue Jul 14 02:10:27 2020
From: darrellroot at mac.com (Darrell Root)
Date: Tue, 14 Jul 2020 00:10:27 -0700
Subject: [netrek-dev] Swift IPv4/IPv6 Netrek Server Update. Request
 metaserver help
Message-ID: <72FF481F-1A6D-4FD3-A1A3-DCC1B98F6F6F@mac.com>

Reminder: the experimental Swift IPv4/IPv6 Netrek server is at netrek.networkmom.net

I fixed a bunch of bugs reported by Bill Balcerski: (thanks!)

+ max speed key now works
+ phaser misses show ok
+ cloaking fixed
+ flag “blinks” every second fixed
+ bombing drops shields
+ quit and fast quit now terminate the tcp socket, but no “countdown there everyone is looking at you” ;-)
- Still need to check out “planet identify when orbiting”.

I also added some features:

+ fixed planet visibility
+ plasma (including phasering plasmas and homing algorithm).  I even send the client a message telling them the target the plasma is “locked” onto when he fires.
+ Some restrictions on launching starbases (2+ kills, refit only)
+ Refitting ships works

Still many more to go, player stats, player invisibility when 1/3 map away from hostiles, and genocide logic.


I also made my server generate a report when you connect on port 2591.   Here’s the output:

droot at MacBookPro2019 ~ % nc netrek.networkmom.net 2591
<>=======================================================================<>
  Pl: Rank       Name             Login      Host name                Type
<>=======================================================================<>
  F0: Ensign     darrellR         SwiftRules redacted                  CA
<>=======================================================================<>
  Feds: 1   Roms: 0   Kli: 0   Ori: 0
  No wait queue.
<>=======================================================================<>

By comparison:

droot at MacBookPro2019 ~ % nc pickled.psychosis.net 2591
<>=======================================================================<>
  Pl: Rank       Name             Login      Host name                Type
<>=======================================================================<>
  R1: Ensign     Demoralizer      Pre_T_Robo #.psychosis.net           SC
  F2: Ensign     Shredder         Pre_T_Robo #.psychosis.net           CA
  F3: Ensign     Smasher          Pre_T_Robo #.psychosis.net           CA
  F4: Ensign     Wrecker          Pre_T_Robo #.psychosis.net           CA
  R5: Ensign     Banisher         Pre_T_Robo #.psychosis.net           BB
  F6: Ensign     Blaster          Pre_T_Robo #.psychosis.net           CA
  R7: Ensign     Eradicator       Pre_T_Robo #.psychosis.net           CA
  Iv: Ensign     Kathy            Robot      Nowhere                   SB
<>=======================================================================<>
  Feds: 4   Roms: 3   Kli: 0   Ori: 0
  No wait queue.
<>=======================================================================<>


Is that good enough to get the metaserver to work?   I was not immediately able to get the metaserver code in GitHub to run without segmentation faults so I haven’t tested.  I do not believe my server will accept “observer” logins so I think port 2591 is the only way to get data at this time.

Darrell


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20200714/6dd49f8a/attachment.htm>

From ahn at netrek.org  Tue Jul 14 09:13:16 2020
From: ahn at netrek.org (Dave Ahn)
Date: Tue, 14 Jul 2020 10:13:16 -0400
Subject: [netrek-dev] Swift IPv4/IPv6 Netrek Server Update. Request
 metaserver help
In-Reply-To: <72FF481F-1A6D-4FD3-A1A3-DCC1B98F6F6F@mac.com>
References: <72FF481F-1A6D-4FD3-A1A3-DCC1B98F6F6F@mac.com>
Message-ID: <CABt_h+e2r5CxBfabuCJSPBLNFQ9LAH_qVjAA789J-in-kjA_zA@mail.gmail.com>

On Tue, Jul 14, 2020 at 3:10 AM Darrell Root <darrellroot at mac.com> wrote:

> *Is that good enough to get the metaserver to work?*
>

No.

There are two ways for a server to get listed on the metaserver.  The old,
legacy way is to configure the metaserver to connect to ports 2591 and 2592
to retrieve info for the listing.  We generally don't use this anymore.
Your implementation is incomplete or inconsistent because it is not
returning expected data to the metaserver.  I've temporarily added your
server to metaserver2 so you can see this and make changes.  The metalog is
below.  Let me know when you are done fixing, and I will remove this manual
entry from metaserver2.

1594734993: connected to netrek.networkmom.net (2591)
1594734993: connected to netrek.networkmom.net (2592)
1594735099: ERROR: read buffer flooded by server netrek.networkmom.net

BTW, your empty server 2591 is returning an empty player list vs "No one
playing."  (See continuum's reply when it's empty.)  Not sure if this
matters.

The better way to get listed on both metaservers is to add metaserver
solicitation support in your server.  Your server then sends listing
information to one or more metaservers over UDP/3521 (point to
metserver[12].netrek.org).  Once you get this working, your server should
show up on metaserver1.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20200714/00b0f999/attachment.htm>

From darrellroot at mac.com  Tue Jul 14 16:50:32 2020
From: darrellroot at mac.com (Darrell Root)
Date: Tue, 14 Jul 2020 14:50:32 -0700
Subject: [netrek-dev] Swift Netrek server Metaserver submission on UDP 3521
 now working
In-Reply-To: <CABt_h+e2r5CxBfabuCJSPBLNFQ9LAH_qVjAA789J-in-kjA_zA@mail.gmail.com>
References: <72FF481F-1A6D-4FD3-A1A3-DCC1B98F6F6F@mac.com>
 <CABt_h+e2r5CxBfabuCJSPBLNFQ9LAH_qVjAA789J-in-kjA_zA@mail.gmail.com>
Message-ID: <FBC479BC-AC2C-4A1F-BF26-09A25E50D8B4@mac.com>

Dave wrote:

> The better way to get listed on both metaservers is to add metaserver solicitation support in your server.

Yes, having the Netrek server pushing data to the metaservers is superior.   Thank you for the push in the correct direction!

I’ve turned off my port 2591 listener and commented out the listening code.  Go ahead and remove netrek.networkmom.net <http://netrek.networkmom.net/> from your static polling configuration on metaserver2.

I have metaserver push on UDP:3521 working for the base server status, but not for detailed player list.  I’ve decided to leave it at that.  Below is output from metaserver1.netrek.org <http://metaserver1.netrek.org/>.   I’m pushing to each metaserver once every 2 minutes.

                                                 Mins  
Server Host                             Port     Ago  Status            Flags
--------------------------------------- -------- ---- ----------------- -------
-h netrek.sofurry.com                   -p 2592   15  Nobody playing          B
-h hockey.hyperyoda.org                 -p 2592    3  Nobody playing          H
-h continuum.us.netrek.org              -p 2592    4  Nobody playing          B
-h netrek.beeseenterprises.com          -p 2592    1  Nobody playing    T     S
-h pickled.netrek.org                   -p 2592    0  Nobody playing          B
-h netrek.networkmom.net                -p 2592    0  OPEN: 1 player          B
-h netrek.redbudcomputer.com            -p 2592    0  OPEN: 2 players   T     B


FYI, here’s a tcpdump of my push packet, with ASCII printout enabled:

21:40:58.366984 IP 161.35.226.186.56172 > federation.netrek.org.3521: UDP, length 55
E..S.X at .@..^.#..E..`.l...?.3b
netrek.networkmom.net
B
2592
0
1
15
n
n
n
Swift-IPv6

Here’s the format from the C metaserver source:

        sprintf(here, "%s\n%s\n%s\n%d\n%d\n%d\n%d\n%s\n%s\n%s\n%s\n",
                /* version */   "b",
                /* address */   m->ours,
                /* type    */   m->type,
                /* port    */   m->pport,
                /* observe */   m->oport,
                /* players */   nplayers,
                /* free    */   nfree,
                /* t-mode  */   status->tourn ? "y" : "n",
                /* RSA     */   isrsa ? "y" : "n",
                /* full    */   gamefull ? "y" : "n",
                /* comment */   m->comment
                );

Here’s an earlier version which did not seem to result in a detailed player list on the metaserver port 3522. I’ve since commented out the (not working) detailed player list submission:

14:26:38.055190 IP 192.168.0.29.59894 > federation.netrek.org.mc3ss: UDP, length 92
...]..<".(:m..E..x.7.. at ..s....E..`.....d..b
netrek.networkmom.net
B
2592
0
1
15
n
n
n
Swift-IPv6
0
F
2
0
darrellR
SwiftRules
redacted

And the format for that section, repeated per player:

        sprintf(here, "%c\n%c\n%d\n%d\n%s\n%s@%s\n",
                /* number */   players[j].p_mapchars[1],
                /* team   */   players[j].p_mapchars[0],
                /* class  */   players[j].p_ship.s_type,
                /* ??? note change from design, ship type number not string */
                /* rank   */   players[j].p_stats.st_rank,
                /* ??? note change from design, rank number not string */
                /* name   */   name,
                /* user   */   login,
                /* host   */   players[j].p_monitor );


Now I just have to implement a Swift Netrek Robot so people always have something to shoot at!

Darrell


> On Jul 14, 2020, at 7:13 AM, Dave Ahn <ahn at netrek.org> wrote:
> 
> On Tue, Jul 14, 2020 at 3:10 AM Darrell Root <darrellroot at mac.com <mailto:darrellroot at mac.com>> wrote:
> Is that good enough to get the metaserver to work?
> 
> No.
> 
> There are two ways for a server to get listed on the metaserver.  The old, legacy way is to configure the metaserver to connect to ports 2591 and 2592 to retrieve info for the listing.  We generally don't use this anymore.  Your implementation is incomplete or inconsistent because it is not returning expected data to the metaserver.  I've temporarily added your server to metaserver2 so you can see this and make changes.  The metalog is below.  Let me know when you are done fixing, and I will remove this manual entry from metaserver2.
> 1594734993: connected to netrek.networkmom.net <http://netrek.networkmom.net/> (2591)
> 1594734993: connected to netrek.networkmom.net <http://netrek.networkmom.net/> (2592)
> 1594735099: ERROR: read buffer flooded by server netrek.networkmom.net <http://netrek.networkmom.net/>
> 
> BTW, your empty server 2591 is returning an empty player list vs "No one playing."  (See continuum's reply when it's empty.)  Not sure if this matters.
> 
> The better way to get listed on both metaservers is to add metaserver solicitation support in your server.  Your server then sends listing information to one or more metaservers over UDP/3521 (point to metserver[12].netrek.org <http://netrek.org/>).  Once you get this working, your server should show up on metaserver1.
> 
> 
> _______________________________________________
> 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: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20200714/df297b2f/attachment-0001.htm>

From ahn at acm.org  Tue Jul 14 09:18:51 2020
From: ahn at acm.org (David Ahn)
Date: Tue, 14 Jul 2020 10:18:51 -0400
Subject: [netrek-dev] Swift IPv4/IPv6 Netrek Server Update. Request
 metaserver help
In-Reply-To: <CABt_h+e2r5CxBfabuCJSPBLNFQ9LAH_qVjAA789J-in-kjA_zA@mail.gmail.com>
References: <72FF481F-1A6D-4FD3-A1A3-DCC1B98F6F6F@mac.com>
 <CABt_h+e2r5CxBfabuCJSPBLNFQ9LAH_qVjAA789J-in-kjA_zA@mail.gmail.com>
Message-ID: <CAN=MmFppK5SWvQ1YcaCFZZgqgnn2OoKbSmSWr9kHC_K+=dvBAQ@mail.gmail.com>

On Tue, Jul 14, 2020 at 10:13 AM Dave Ahn <ahn at netrek.org> wrote:

> The better way to get listed on both metaservers is to add metaserver
> solicitation support in your server.
>

Forgot to mention that the code for this should be in the Vanilla server's
ntserv/sollcit.c.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20200714/bc4b94a0/attachment.htm>

From darrellroot at mac.com  Wed Jul 15 20:44:57 2020
From: darrellroot at mac.com (Darrell Root)
Date: Wed, 15 Jul 2020 18:44:57 -0700
Subject: [netrek-dev] Dawn of the (dumb) Swift Netrek Robots!
Message-ID: <FFA5DB26-0EA4-4506-A238-29FD96C7AF27@mac.com>

Netrek-dev,

I’m pleased to announce that netrek.networkmom.net <http://netrek.networkmom.net/> now has 16 (pretty dumb) Netrek Robots ready to shoot in your general direction!  As humans join the server, robots will logoff.  As humans leave the server, robots will join.   Only humans are counted in the metaserver submission.

Since this is the netrek-dev list, below is the Swift code for the Robot Mark 1.  I hope it is highly readable.

Stability and feature improvements to the Swift Netrek server will continue (in particular, still no genocide logic).  I also fixed a few bugs in the MacOS and iOS clients while developing the server and will push those next week.

I’m also happy to accept pull requests for better robots.  You can also suggest a “name” for your robot.  Will your robot namesake go on to achieve honor and glory?

If you login to the server, you’ll see that all four teams are active.  That’s intentional.  There’s a plan for that…

Darrell

https://github.com/darrellroot/netrek-server-swift/blob/master/Sources/netrek-server-swift/Robots/RobotModel1.swift <https://github.com/darrellroot/netrek-server-swift/blob/master/Sources/netrek-server-swift/Robots/RobotModel1.swift>


//
//  RobotModel1.swift
//  netrek-server-swift
//
//  Created by Darrell Root on 7/15/20.
//

import Foundation

class RobotModel1: Robot {
    
    enum Strategy {
        case refuel
        case repair
        case dogfight
    }
    
    var strategy: Strategy = .dogfight
    
    weak var me: Player?
    
    public let userinfo = "RobotModel1"
    public let preferredShip = ShipType.cruiser
    
    required init(player: Player, universe: Universe) {
        self.me = player
    }
    
    public func secondTimerFired() {
        guard let me = me else {
            return
        }
        switch me.status {
            
        case .free, .observe:
            //should not get here
            break
        case .outfit:
            guard me.receivedCpOutfit(team: me.team, ship: self.preferredShip) else {
                debugPrint("\(#file) \(#function) Unable to outfit ship")
                return
            }
            return
        case .explode:
            break
        case .dead:
            guard me.receivedCpOutfit(team: me.team, ship: self.preferredShip) else {
                debugPrint("\(#file) \(#function) Unable to outfit ship")
                return
            }
            return
        case .alive:
            guard let nearestEnemy = self.nearestEnemy() else {
                return
            }

            adjustShields(nearestEnemy: nearestEnemy)
            shootLaser(nearestEnemy: nearestEnemy)
            shootTorpedo(nearestEnemy: nearestEnemy)
            switch self.strategy {
                
            case .refuel:
                strategyRefuel()
            case .repair:
                strategyRepair()
            case .dogfight:
                strategyDogfight(nearestEnemy: nearestEnemy)
            }
        }
    }
    private func adjustShields(nearestEnemy: Player) {
        guard let me = me else {
            return
        }
        let enemyDistance = NetrekMath.distance(me,nearestEnemy)
        if enemyDistance < Laser.baseRange * 2 {
            //shields should be up
            if !me.shieldsUp {
                me.receivedCpShield(up: true)
            }
        } else {
            if me.shieldsUp {
                me.receivedCpShield(up: false)
            }
        }
    }
    private func shootLaser(nearestEnemy: Player) {
        guard let me = me else {
            return
        }
        let enemyDistance = NetrekMath.distance(me,nearestEnemy)
        if enemyDistance < Laser.baseRange / 2 {
            let enemyDirectionRadian = NetrekMath.angle(origin: me, target: nearestEnemy)
            let enemyDirectionNetrek = NetrekMath.directionRadian2Netrek(enemyDirectionRadian)
            me.fireLaser(direction: enemyDirectionNetrek)
        }
    }
    private func shootTorpedo(nearestEnemy: Player) {
        guard let me = me else {
            return
        }
        let enemyDistance = NetrekMath.distance(me,nearestEnemy)
        //TODO adjust to torpedo range
        if enemyDistance < Laser.baseRange {
            let enemyDirectionRadian = NetrekMath.angle(origin: me, target: nearestEnemy)
            let variance = Double.random(in: -0.3 ..< 0.3)
            me.fireTorpedo(direction: enemyDirectionRadian + variance)
        }
    }
    private func strategyDogfight(nearestEnemy: Player) {
        guard let me = me else {
            return
        }
        
        //random course toward enemy
        var directionRadian = NetrekMath.angle(origin: me, target: nearestEnemy)
        //random evasive 120 degrees each way
        directionRadian += Double.random(in: Double.pi * -0.3 ..< Double.pi * 0.3)
        me.receivedDirection(direction: directionRadian)
        //random speed
        var speed = Int(me.ship.maxSpeed / 2 - 1)
        speed += Int.random(in: -2..<2)
        me.receivedCpSpeed(speed: speed)
    }
    private func strategyRepair() {
        guard let me = me else {
            return
        }
        if let planet = me.orbit, planet.repair {
            return
        }
        if let planet = me.orbit {
            me.receivedRepair(true)
            return
        }
        if let planet = self.nearestRepairPlanet() {
            me.receivedPlanetLock(planetID: planet.planetID)
            me.receivedCpSpeed(speed: Int(me.ship.maxSpeed / 2))
            return
        } else {
            //no friendly fuel planet so we stop to repair
            me.receivedRepair(true)
        }
    }
    
    private func strategyRefuel() {
        guard let me = me else {
            return
        }
        if let planet = me.orbit, planet.fuel {
            return
        }
        if let planet = me.planetLock, planet.fuel {
            return
        }
        if let planet = self.nearestFuelPlanet() {
            me.receivedPlanetLock(planetID: planet.planetID)
            me.receivedCpSpeed(speed: Int(me.ship.maxSpeed / 2))
            return
        } else {
            //no friendly fuel planet so we stop to refuel
            me.receivedCpSpeed(speed: 0)
        }
    }
    
    private func decideStrategy() {
        guard let me = self.me else {
            debugPrint("\(#file) \(#function) Unable to identify myself")
            return
        }
        if me.damage > me.ship.maxDamage / 2 {
            self.strategy = .repair
            return
        }
        if me.fuel < me.ship.maxFuel / 3 {
            self.strategy = .refuel
            return
        }
        if self.strategy == .repair && me.damage < 10 {
            self.strategy = .dogfight
        }
        if self.strategy == .refuel && me.fuel > (me.ship.maxFuel - 500) {
            self.strategy = .dogfight
        }
    }
    
}

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20200715/1b35e71c/attachment-0001.htm>

From darrellroot at mac.com  Thu Jul 16 15:55:03 2020
From: darrellroot at mac.com (Darrell Root)
Date: Thu, 16 Jul 2020 13:55:03 -0700
Subject: [netrek-dev] How do COW and Windows clients know you are dead? (To
 pop up the "choose team" screen) (PFREFIT?)
Message-ID: <905DB070-9298-41CB-AE64-D0F5FAE963B7@mac.com>

Netrek-dev,

My Swift Netrek server has a compatibility problem with COW and Windows clients.

When a person dies, the clients do not pop up the “choose team” screen.  So people have to disconnect to respawn.
The clients also do not show the “you were killed by [WEAPON] from [PLAYER] message when connected to my server.

What message/flag sent from the server triggers that window / message?

I was assuming it was the whydead and whodead fields in the SP_YOU, but so far I haven’t been able to get it working.


Here’s a sequence of SP_YOU messages from pickled.netrek.org <http://pickled.netrek.org/>.  These can be assumed to be correct.  I’ve put the death and respan in BOLD

"Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage 64 shieldStrength 100 fuel 10000 engineTemp 0 weaponsTemp 0 whyDead 0 whodead 6"
"Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage 103 shieldStrength 100 fuel 10000 engineTemp 0 weaponsTemp 0 whyDead 2 whodead 6"
"Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage 103 shieldStrength 100 fuel 9980 engineTemp 5 weaponsTemp 0 whyDead 2 whodead 6"
"Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage 103 shieldStrength 100 fuel 9960 engineTemp 10 weaponsTemp 0 whyDead 2 whodead 6"
"Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage 103 shieldStrength 100 fuel 9940 engineTemp 15 weaponsTemp 0 whyDead 2 whodead 6"
"Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage 103 shieldStrength 100 fuel 9924 engineTemp 19 weaponsTemp 0 whyDead 2 whodead 6"
"Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage 103 shieldStrength 100 fuel 9908 engineTemp 23 weaponsTemp 0 whyDead 2 whodead 6"
"Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage 103 shieldStrength 100 fuel 9892 engineTemp 27 weaponsTemp 0 whyDead 2 whodead 6"
"Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage 103 shieldStrength 100 fuel 9876 engineTemp 31 weaponsTemp 0 whyDead 2 whodead 6"
"Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage 103 shieldStrength 100 fuel 9860 engineTemp 35 weaponsTemp 0 whyDead 2 whodead 6"
"Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage 103 shieldStrength 100 fuel 9848 engineTemp 38 weaponsTemp 0 whyDead 2 whodead 6"
"Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage 103 shieldStrength 100 fuel 9836 engineTemp 41 weaponsTemp 0 whyDead 2 whodead 6"
"Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 2049 damage 0 shieldStrength 100 fuel 10000 engineTemp 0 weaponsTemp 0 whyDead 2 whodead 6"
"Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33556481 damage 0 shieldStrength 100 fuel 10000 engineTemp 0 weaponsTemp 0 whyDead 2 whodead 6”

Here’s a sequence of SP_YOU messages from netrek.networkmom.net <http://netrek.networkmom.net/>.

"Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048 damage 78 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 0 whodead 0"
"Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048 damage 118 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 2 whodead 0"
"Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048 damage 118 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 2 whodead 0"
"Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048 damage 118 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 2 whodead 0”

…large number of identical messages deleted…

"Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048 damage 118 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 2 whodead 0"
"Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048 damage 118 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 2 whodead 0"
"Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048 damage 0 shieldStrength 100 fuel 10000 engineTemp 0 weaponsTemp 0 whyDead 0 whodead 0”

(Looks like I need to fix whodead, but 0 is valid so I don’t think that’s the cause).

Could it be PFREFIT?

For reference, here’s the p_flags fields.  While my current implementation is missing red/yellow/green, I don’t see anything relevant.

/* bit masks of p_flags */
#define PFSHIELD           0x0001 /*!< shields are up */
#define PFREPAIR           0x0002 /*!< repairing damage or shields */
#define PFBOMB             0x0004 /*!< bombing planet while orbiting */
#define PFORBIT            0x0008 /*!< orbiting planet p_planet */
#define PFCLOAK            0x0010
#define PFWEP              0x0020
#define PFENG              0x0040
#define PFROBOT            0x0080
#define PFBEAMUP           0x0100
#define PFBEAMDOWN         0x0200
#define PFSELFDEST         0x0400
#define PFGREEN            0x0800
#define PFYELLOW           0x1000
#define PFRED              0x2000
#define PFPLOCK            0x4000       /* Locked on a player */
#define PFPLLOCK           0x8000       /* Locked on a planet */
#define PFCOPILOT         0x10000       /* Allow copilots */
#define PFWAR             0x20000       /* computer reprogramming for war */
#define PFPRACTR          0x40000       /* practice type robot (no kills) */
#define PFDOCK            0x80000 /*!< docked to a base, p_dock_with valid */
#define PFREFIT          0x100000       /* true if about to refit */
#define PFREFITTING      0x200000       /* true if currently refitting */
#define PFTRACT          0x400000       /* tractor beam activated */
#define PFPRESS          0x800000       /* pressor beam activated */
#define PFDOCKOK        0x1000000       /* docking permission */
#define PFSEEN          0x2000000       /* seen by enemy on galactic map? */
/*#define PFCYBORG      0x4000000       a cyborg? 7/27/91 TC */
#define PFOBSERV        0x8000000       /* for observers */
#define PFTWARP        0x40000000       /* isae -- SB transwarp */

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20200716/95fcc244/attachment.htm>

From quozl at laptop.org  Thu Jul 16 16:19:43 2020
From: quozl at laptop.org (James Cameron)
Date: Fri, 17 Jul 2020 07:19:43 +1000
Subject: [netrek-dev] How do COW and Windows clients know you are dead?
 (To pop up the "choose team" screen) (PFREFIT?)
In-Reply-To: <905DB070-9298-41CB-AE64-D0F5FAE963B7@mac.com>
References: <905DB070-9298-41CB-AE64-D0F5FAE963B7@mac.com>
Message-ID: <20200716211943.GB17208@laptop.org>

Looking at Gytha's __init__.py which contains a paste of the protocol
definition;

	SP_PSTATUS, indicates PDEAD state
	client animates explosion

	SP_PSTATUS, indicates POUTFIT state
	clients returns to team selection window

Looking at Gytha's PhaseFlight class, the event loop exits on POUTFIT
"# no longer flying".

Looking at Gytha's nt_play_a_slot "keep playing on a server, until
user chooses a quit option, or a list option to return to the server
list", play continues until POUTFIT.

On Thu, Jul 16, 2020 at 01:55:03PM -0700, Darrell Root wrote:
> Netrek-dev,
> 
> My Swift Netrek server has a compatibility problem with COW and Windows
> clients.
> 
> When a person dies, the clients do not pop up the “choose team” screen.  So
> people have to disconnect to respawn.
> The clients also do not show the “you were killed by [WEAPON] from [PLAYER]
> message when connected to my server.
> 
> What message/flag sent from the server triggers that window / message?
> 
> I was assuming it was the whydead and whodead fields in the SP_YOU, but so far
> I haven’t been able to get it working.
> 
> Here’s a sequence of SP_YOU messages from [1]pickled.netrek.org.  These can be
> assumed to be correct.  I’ve put the death and respan in BOLD
> 
> "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage
> 64 shieldStrength 100 fuel 10000 engineTemp 0 weaponsTemp 0 whyDead 0 whodead
> 6"
> "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage
> 103 shieldStrength 100 fuel 10000 engineTemp 0 weaponsTemp 0 whyDead 2 whodead
> 6"
> "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage
> 103 shieldStrength 100 fuel 9980 engineTemp 5 weaponsTemp 0 whyDead 2 whodead
> 6"
> "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage
> 103 shieldStrength 100 fuel 9960 engineTemp 10 weaponsTemp 0 whyDead 2 whodead
> 6"
> "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage
> 103 shieldStrength 100 fuel 9940 engineTemp 15 weaponsTemp 0 whyDead 2 whodead
> 6"
> "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage
> 103 shieldStrength 100 fuel 9924 engineTemp 19 weaponsTemp 0 whyDead 2 whodead
> 6"
> "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage
> 103 shieldStrength 100 fuel 9908 engineTemp 23 weaponsTemp 0 whyDead 2 whodead
> 6"
> "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage
> 103 shieldStrength 100 fuel 9892 engineTemp 27 weaponsTemp 0 whyDead 2 whodead
> 6"
> "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage
> 103 shieldStrength 100 fuel 9876 engineTemp 31 weaponsTemp 0 whyDead 2 whodead
> 6"
> "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage
> 103 shieldStrength 100 fuel 9860 engineTemp 35 weaponsTemp 0 whyDead 2 whodead
> 6"
> "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage
> 103 shieldStrength 100 fuel 9848 engineTemp 38 weaponsTemp 0 whyDead 2 whodead
> 6"
> "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage
> 103 shieldStrength 100 fuel 9836 engineTemp 41 weaponsTemp 0 whyDead 2 whodead
> 6"
> "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 2049 damage
> 0 shieldStrength 100 fuel 10000 engineTemp 0 weaponsTemp 0 whyDead 2 whodead 6"
> "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33556481 damage
> 0 shieldStrength 100 fuel 10000 engineTemp 0 weaponsTemp 0 whyDead 2 whodead 6”
> 
> Here’s a sequence of SP_YOU messages from [2]netrek.networkmom.net.
> 
> "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048 damage
> 78 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 0 whodead 0"
> "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048 damage
> 118 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 2 whodead
> 0"
> "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048 damage
> 118 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 2 whodead
> 0"
> "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048 damage
> 118 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 2 whodead
> 0”
> 
> …large number of identical messages deleted…
> 
> "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048 damage
> 118 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 2 whodead
> 0"
> "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048 damage
> 118 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 2 whodead
> 0"
> "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048 damage 0
> shieldStrength 100 fuel 10000 engineTemp 0 weaponsTemp 0 whyDead 0 whodead 0”
> 
> (Looks like I need to fix whodead, but 0 is valid so I don’t think that’s the
> cause).
> 
> Could it be PFREFIT?
> 
> For reference, here’s the p_flags fields.  While my current implementation is
> missing red/yellow/green, I don’t see anything relevant.
> 
> /* bit masks of p_flags */
> #define PFSHIELD           0x0001 /*!< shields are up */
> #define PFREPAIR           0x0002 /*!< repairing damage or shields */
> #define PFBOMB             0x0004 /*!< bombing planet while orbiting */
> #define PFORBIT            0x0008 /*!< orbiting planet p_planet */
> #define PFCLOAK            0x0010
> #define PFWEP              0x0020
> #define PFENG              0x0040
> #define PFROBOT            0x0080
> #define PFBEAMUP           0x0100
> #define PFBEAMDOWN         0x0200
> #define PFSELFDEST         0x0400
> #define PFGREEN            0x0800
> #define PFYELLOW           0x1000
> #define PFRED              0x2000
> #define PFPLOCK            0x4000       /* Locked on a player */
> #define PFPLLOCK           0x8000       /* Locked on a planet */
> #define PFCOPILOT         0x10000       /* Allow copilots */
> #define PFWAR             0x20000       /* computer reprogramming for war */
> #define PFPRACTR          0x40000       /* practice type robot (no kills) */
> #define PFDOCK            0x80000 /*!< docked to a base, p_dock_with valid */
> #define PFREFIT          0x100000       /* true if about to refit */
> #define PFREFITTING      0x200000       /* true if currently refitting */
> #define PFTRACT          0x400000       /* tractor beam activated */
> #define PFPRESS          0x800000       /* pressor beam activated */
> #define PFDOCKOK        0x1000000       /* docking permission */
> #define PFSEEN          0x2000000       /* seen by enemy on galactic map? */
> /*#define PFCYBORG      0x4000000       a cyborg? 7/27/91 TC */
> #define PFOBSERV        0x8000000       /* for observers */
> #define PFTWARP        0x40000000       /* isae -- SB transwarp */
> 
> References:
> 
> [1] http://pickled.netrek.org/
> [2] http://netrek.networkmom.net/

> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev


-- 
James Cameron
http://quozl.netrek.org/

From darrellroot at mac.com  Thu Jul 16 17:27:18 2020
From: darrellroot at mac.com (Darrell Root)
Date: Thu, 16 Jul 2020 15:27:18 -0700
Subject: [netrek-dev] How do COW and Windows clients know you are dead?
 (To pop up the "choose team" screen) (PFREFIT?)
In-Reply-To: <20200716211943.GB17208@laptop.org>
References: <905DB070-9298-41CB-AE64-D0F5FAE963B7@mac.com>
 <20200716211943.GB17208@laptop.org>
Message-ID: <7B29B8CB-C4D5-430D-81A3-A751BC2D4C25@mac.com>

Thank you!  This bug is now resolved thanks to your help and Bill Balcerski’s bug report!

It looks like the explosion gets animated in the EXPLODE state.  Then there is a pause in the DEAD state allowing torpedoes to run out.  But then I needed to migrate the user to the OUTFIT state to get back to the “select ship/quit” screen.  I chose 1 second for each of those two states.


I think most of the “client blinking” in the x86 client (that Bill reported) is resolved.  But I’m seeing a huge quantity of “stuff blinking” on the COW client running in a Parallels VM on my Mac.

I’m not sure whether the “stuff blinking” is an artifact of the Parallels VM or a real problem.  In the x86 client case, I was sending unnecessary updates to the client, resulting in continuous redraws.

If someone could pop up a COW client on a native Linux box, point it at netrek.networkmom.net <http://netrek.networkmom.net/>, and report if they see planets/ships on the screen blinking too much, I’d appreciate it.

Darrell


> On Jul 16, 2020, at 2:19 PM, James Cameron <quozl at laptop.org> wrote:
> 
> Looking at Gytha's __init__.py which contains a paste of the protocol
> definition;
> 
> 	SP_PSTATUS, indicates PDEAD state
> 	client animates explosion
> 
> 	SP_PSTATUS, indicates POUTFIT state
> 	clients returns to team selection window
> 
> Looking at Gytha's PhaseFlight class, the event loop exits on POUTFIT
> "# no longer flying".
> 
> Looking at Gytha's nt_play_a_slot "keep playing on a server, until
> user chooses a quit option, or a list option to return to the server
> list", play continues until POUTFIT.
> 
> On Thu, Jul 16, 2020 at 01:55:03PM -0700, Darrell Root wrote:
>> Netrek-dev,
>> 
>> My Swift Netrek server has a compatibility problem with COW and Windows
>> clients.
>> 
>> When a person dies, the clients do not pop up the “choose team” screen.  So
>> people have to disconnect to respawn.
>> The clients also do not show the “you were killed by [WEAPON] from [PLAYER]
>> message when connected to my server.
>> 
>> What message/flag sent from the server triggers that window / message?
>> 
>> I was assuming it was the whydead and whodead fields in the SP_YOU, but so far
>> I haven’t been able to get it working.
>> 
>> Here’s a sequence of SP_YOU messages from [1]pickled.netrek.org <http://pickled.netrek.org/>.  These can be
>> assumed to be correct.  I’ve put the death and respan in BOLD
>> 
>> "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage
>> 64 shieldStrength 100 fuel 10000 engineTemp 0 weaponsTemp 0 whyDead 0 whodead
>> 6"
>> "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage
>> 103 shieldStrength 100 fuel 10000 engineTemp 0 weaponsTemp 0 whyDead 2 whodead
>> 6"
>> "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage
>> 103 shieldStrength 100 fuel 9980 engineTemp 5 weaponsTemp 0 whyDead 2 whodead
>> 6"
>> "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage
>> 103 shieldStrength 100 fuel 9960 engineTemp 10 weaponsTemp 0 whyDead 2 whodead
>> 6"
>> "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage
>> 103 shieldStrength 100 fuel 9940 engineTemp 15 weaponsTemp 0 whyDead 2 whodead
>> 6"
>> "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage
>> 103 shieldStrength 100 fuel 9924 engineTemp 19 weaponsTemp 0 whyDead 2 whodead
>> 6"
>> "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage
>> 103 shieldStrength 100 fuel 9908 engineTemp 23 weaponsTemp 0 whyDead 2 whodead
>> 6"
>> "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage
>> 103 shieldStrength 100 fuel 9892 engineTemp 27 weaponsTemp 0 whyDead 2 whodead
>> 6"
>> "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage
>> 103 shieldStrength 100 fuel 9876 engineTemp 31 weaponsTemp 0 whyDead 2 whodead
>> 6"
>> "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage
>> 103 shieldStrength 100 fuel 9860 engineTemp 35 weaponsTemp 0 whyDead 2 whodead
>> 6"
>> "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage
>> 103 shieldStrength 100 fuel 9848 engineTemp 38 weaponsTemp 0 whyDead 2 whodead
>> 6"
>> "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33562624 damage
>> 103 shieldStrength 100 fuel 9836 engineTemp 41 weaponsTemp 0 whyDead 2 whodead
>> 6"
>> "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 2049 damage
>> 0 shieldStrength 100 fuel 10000 engineTemp 0 weaponsTemp 0 whyDead 2 whodead 6"
>> "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 33556481 damage
>> 0 shieldStrength 100 fuel 10000 engineTemp 0 weaponsTemp 0 whyDead 2 whodead 6”
>> 
>> Here’s a sequence of SP_YOU messages from [2]netrek.networkmom.net <http://netrek.networkmom.net/>.
>> 
>> "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048 damage
>> 78 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 0 whodead 0"
>> "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048 damage
>> 118 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 2 whodead
>> 0"
>> "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048 damage
>> 118 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 2 whodead
>> 0"
>> "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048 damage
>> 118 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 2 whodead
>> 0”
>> 
>> …large number of identical messages deleted…
>> 
>> "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048 damage
>> 118 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 2 whodead
>> 0"
>> "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048 damage
>> 118 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 2 whodead
>> 0"
>> "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048 damage 0
>> shieldStrength 100 fuel 10000 engineTemp 0 weaponsTemp 0 whyDead 0 whodead 0”
>> 
>> (Looks like I need to fix whodead, but 0 is valid so I don’t think that’s the
>> cause).
>> 
>> Could it be PFREFIT?
>> 
>> For reference, here’s the p_flags fields.  While my current implementation is
>> missing red/yellow/green, I don’t see anything relevant.
>> 
>> /* bit masks of p_flags */
>> #define PFSHIELD           0x0001 /*!< shields are up */
>> #define PFREPAIR           0x0002 /*!< repairing damage or shields */
>> #define PFBOMB             0x0004 /*!< bombing planet while orbiting */
>> #define PFORBIT            0x0008 /*!< orbiting planet p_planet */
>> #define PFCLOAK            0x0010
>> #define PFWEP              0x0020
>> #define PFENG              0x0040
>> #define PFROBOT            0x0080
>> #define PFBEAMUP           0x0100
>> #define PFBEAMDOWN         0x0200
>> #define PFSELFDEST         0x0400
>> #define PFGREEN            0x0800
>> #define PFYELLOW           0x1000
>> #define PFRED              0x2000
>> #define PFPLOCK            0x4000       /* Locked on a player */
>> #define PFPLLOCK           0x8000       /* Locked on a planet */
>> #define PFCOPILOT         0x10000       /* Allow copilots */
>> #define PFWAR             0x20000       /* computer reprogramming for war */
>> #define PFPRACTR          0x40000       /* practice type robot (no kills) */
>> #define PFDOCK            0x80000 /*!< docked to a base, p_dock_with valid */
>> #define PFREFIT          0x100000       /* true if about to refit */
>> #define PFREFITTING      0x200000       /* true if currently refitting */
>> #define PFTRACT          0x400000       /* tractor beam activated */
>> #define PFPRESS          0x800000       /* pressor beam activated */
>> #define PFDOCKOK        0x1000000       /* docking permission */
>> #define PFSEEN          0x2000000       /* seen by enemy on galactic map? */
>> /*#define PFCYBORG      0x4000000       a cyborg? 7/27/91 TC */
>> #define PFOBSERV        0x8000000       /* for observers */
>> #define PFTWARP        0x40000000       /* isae -- SB transwarp */
>> 
>> References:
>> 
>> [1] http://pickled.netrek.org/ <http://pickled.netrek.org/>
>> [2] http://netrek.networkmom.net/ <http://netrek.networkmom.net/>
> 
>> _______________________________________________
>> netrek-dev mailing list
>> netrek-dev at us.netrek.org <mailto:netrek-dev at us.netrek.org>
>> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev <http://mailman.us.netrek.org/mailman/listinfo/netrek-dev>
> 
> 
> -- 
> James Cameron
> http://quozl.netrek.org/ <http://quozl.netrek.org/>
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org <mailto:netrek-dev at us.netrek.org>
> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev <http://mailman.us.netrek.org/mailman/listinfo/netrek-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20200716/331364ab/attachment-0001.htm>

From quozl at laptop.org  Thu Jul 16 18:04:45 2020
From: quozl at laptop.org (James Cameron)
Date: Fri, 17 Jul 2020 09:04:45 +1000
Subject: [netrek-dev] How do COW and Windows clients know you are dead?
 (To pop up the "choose team" screen) (PFREFIT?)
In-Reply-To: <7B29B8CB-C4D5-430D-81A3-A751BC2D4C25@mac.com>
References: <905DB070-9298-41CB-AE64-D0F5FAE963B7@mac.com>
 <20200716211943.GB17208@laptop.org>
 <7B29B8CB-C4D5-430D-81A3-A751BC2D4C25@mac.com>
Message-ID: <20200716230445.GC17208@laptop.org>

As a wild guess, you may not have disabled the Nagle algorithm on the
TCP socket?  Aggregation and delay of data in the outgoing queue does
cause an effect that can be reported as "blinking".

On Thu, Jul 16, 2020 at 03:27:18PM -0700, Darrell Root wrote:
> Thank you!  This bug is now resolved thanks to your help and Bill Balcerski’s
> bug report!
> 
> It looks like the explosion gets animated in the EXPLODE state.  Then there is
> a pause in the DEAD state allowing torpedoes to run out.  But then I needed to
> migrate the user to the OUTFIT state to get back to the “select ship/quit”
> screen.  I chose 1 second for each of those two states.
> 
> I think most of the “client blinking” in the x86 client (that Bill reported) is
> resolved.  But I’m seeing a huge quantity of “stuff blinking” on the COW client
> running in a Parallels VM on my Mac.
> 
> I’m not sure whether the “stuff blinking” is an artifact of the Parallels VM or
> a real problem.  In the x86 client case, I was sending unnecessary updates to
> the client, resulting in continuous redraws.
> 
> If someone could pop up a COW client on a native Linux box, point it at [1]
> netrek.networkmom.net, and report if they see planets/ships on the screen
> blinking too much, I’d appreciate it.
> 
> Darrell
> 
>     On Jul 16, 2020, at 2:19 PM, James Cameron <[2]quozl at laptop.org> wrote:
> 
>     Looking at Gytha's __init__.py which contains a paste of the protocol
>     definition;
> 
>     SP_PSTATUS, indicates PDEAD state
>     client animates explosion
> 
>     SP_PSTATUS, indicates POUTFIT state
>     clients returns to team selection window
> 
>     Looking at Gytha's PhaseFlight class, the event loop exits on POUTFIT
>     "# no longer flying".
> 
>     Looking at Gytha's nt_play_a_slot "keep playing on a server, until
>     user chooses a quit option, or a list option to return to the server
>     list", play continues until POUTFIT.
> 
>     On Thu, Jul 16, 2020 at 01:55:03PM -0700, Darrell Root wrote:
> 
>         Netrek-dev,
> 
>         My Swift Netrek server has a compatibility problem with COW and Windows
>         clients.
> 
>         When a person dies, the clients do not pop up the “choose team” screen.
>          So
>         people have to disconnect to respawn.
>         The clients also do not show the “you were killed by [WEAPON] from
>         [PLAYER]
>         message when connected to my server.
> 
>         What message/flag sent from the server triggers that window / message?
> 
>         I was assuming it was the whydead and whodead fields in the SP_YOU, but
>         so far
>         I haven’t been able to get it working.
> 
>         Here’s a sequence of SP_YOU messages from [1][3]pickled.netrek.org.
>          These can be
>         assumed to be correct.  I’ve put the death and respan in BOLD
> 
>         "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>         33562624 damage
>         64 shieldStrength 100 fuel 10000 engineTemp 0 weaponsTemp 0 whyDead 0
>         whodead
>         6"
>         "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>         33562624 damage
>         103 shieldStrength 100 fuel 10000 engineTemp 0 weaponsTemp 0 whyDead 2
>         whodead
>         6"
>         "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>         33562624 damage
>         103 shieldStrength 100 fuel 9980 engineTemp 5 weaponsTemp 0 whyDead 2
>         whodead
>         6"
>         "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>         33562624 damage
>         103 shieldStrength 100 fuel 9960 engineTemp 10 weaponsTemp 0 whyDead 2
>         whodead
>         6"
>         "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>         33562624 damage
>         103 shieldStrength 100 fuel 9940 engineTemp 15 weaponsTemp 0 whyDead 2
>         whodead
>         6"
>         "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>         33562624 damage
>         103 shieldStrength 100 fuel 9924 engineTemp 19 weaponsTemp 0 whyDead 2
>         whodead
>         6"
>         "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>         33562624 damage
>         103 shieldStrength 100 fuel 9908 engineTemp 23 weaponsTemp 0 whyDead 2
>         whodead
>         6"
>         "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>         33562624 damage
>         103 shieldStrength 100 fuel 9892 engineTemp 27 weaponsTemp 0 whyDead 2
>         whodead
>         6"
>         "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>         33562624 damage
>         103 shieldStrength 100 fuel 9876 engineTemp 31 weaponsTemp 0 whyDead 2
>         whodead
>         6"
>         "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>         33562624 damage
>         103 shieldStrength 100 fuel 9860 engineTemp 35 weaponsTemp 0 whyDead 2
>         whodead
>         6"
>         "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>         33562624 damage
>         103 shieldStrength 100 fuel 9848 engineTemp 38 weaponsTemp 0 whyDead 2
>         whodead
>         6"
>         "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>         33562624 damage
>         103 shieldStrength 100 fuel 9836 engineTemp 41 weaponsTemp 0 whyDead 2
>         whodead
>         6"
>         "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 2049
>         damage
>         0 shieldStrength 100 fuel 10000 engineTemp 0 weaponsTemp 0 whyDead 2
>         whodead 6"
>         "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>         33556481 damage
>         0 shieldStrength 100 fuel 10000 engineTemp 0 weaponsTemp 0 whyDead 2
>         whodead 6”
> 
>         Here’s a sequence of SP_YOU messages from [2][4]netrek.networkmom.net.
> 
>         "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048
>         damage
>         78 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 0
>         whodead 0"
>         "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048
>         damage
>         118 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 2
>         whodead
>         0"
>         "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048
>         damage
>         118 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 2
>         whodead
>         0"
>         "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048
>         damage
>         118 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 2
>         whodead
>         0”
> 
>         …large number of identical messages deleted…
> 
>         "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048
>         damage
>         118 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 2
>         whodead
>         0"
>         "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048
>         damage
>         118 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 2
>         whodead
>         0"
>         "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048
>         damage 0
>         shieldStrength 100 fuel 10000 engineTemp 0 weaponsTemp 0 whyDead 0
>         whodead 0”
> 
>         (Looks like I need to fix whodead, but 0 is valid so I don’t think
>         that’s the
>         cause).
> 
>         Could it be PFREFIT?
> 
>         For reference, here’s the p_flags fields.  While my current
>         implementation is
>         missing red/yellow/green, I don’t see anything relevant.
> 
>         /* bit masks of p_flags */
>         #define PFSHIELD           0x0001 /*!< shields are up */
>         #define PFREPAIR           0x0002 /*!< repairing damage or shields */
>         #define PFBOMB             0x0004 /*!< bombing planet while orbiting */
>         #define PFORBIT            0x0008 /*!< orbiting planet p_planet */
>         #define PFCLOAK            0x0010
>         #define PFWEP              0x0020
>         #define PFENG              0x0040
>         #define PFROBOT            0x0080
>         #define PFBEAMUP           0x0100
>         #define PFBEAMDOWN         0x0200
>         #define PFSELFDEST         0x0400
>         #define PFGREEN            0x0800
>         #define PFYELLOW           0x1000
>         #define PFRED              0x2000
>         #define PFPLOCK            0x4000       /* Locked on a player */
>         #define PFPLLOCK           0x8000       /* Locked on a planet */
>         #define PFCOPILOT         0x10000       /* Allow copilots */
>         #define PFWAR             0x20000       /* computer reprogramming for
>         war */
>         #define PFPRACTR          0x40000       /* practice type robot (no
>         kills) */
>         #define PFDOCK            0x80000 /*!< docked to a base, p_dock_with
>         valid */
>         #define PFREFIT          0x100000       /* true if about to refit */
>         #define PFREFITTING      0x200000       /* true if currently refitting
>         */
>         #define PFTRACT          0x400000       /* tractor beam activated */
>         #define PFPRESS          0x800000       /* pressor beam activated */
>         #define PFDOCKOK        0x1000000       /* docking permission */
>         #define PFSEEN          0x2000000       /* seen by enemy on galactic
>         map? */
>         /*#define PFCYBORG      0x4000000       a cyborg? 7/27/91 TC */
>         #define PFOBSERV        0x8000000       /* for observers */
>         #define PFTWARP        0x40000000       /* isae -- SB transwarp */
> 
>         References:
> 
>         [1] [5]http://pickled.netrek.org/
>         [2] [6]http://netrek.networkmom.net/
> 
>         _______________________________________________
>         netrek-dev mailing list
>         [7]netrek-dev at us.netrek.org
>         [8]http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
> 
>     -- 
>     James Cameron
>     [9]http://quozl.netrek.org/
>     _______________________________________________
>     netrek-dev mailing list
>     [10]netrek-dev at us.netrek.org
>     [11]http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
> 
> References:
> 
> [1] http://netrek.networkmom.net/
> [2] mailto:quozl at laptop.org
> [3] http://pickled.netrek.org/
> [4] http://netrek.networkmom.net/
> [5] http://pickled.netrek.org/
> [6] http://netrek.networkmom.net/
> [7] mailto:netrek-dev at us.netrek.org
> [8] http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
> [9] http://quozl.netrek.org/
> [10] mailto:netrek-dev at us.netrek.org
> [11] 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


-- 
James Cameron
http://quozl.netrek.org/

From netrek at gmail.com  Thu Jul 16 18:15:35 2020
From: netrek at gmail.com (Zachary Uram)
Date: Thu, 16 Jul 2020 19:15:35 -0400
Subject: [netrek-dev] Dawn of the (dumb) Swift Netrek Robots!
In-Reply-To: <FFA5DB26-0EA4-4506-A238-29FD96C7AF27@mac.com>
References: <FFA5DB26-0EA4-4506-A238-29FD96C7AF27@mac.com>
Message-ID: <CAPu6UvDvG_b3XpMzyJUoaD-VEvWkSwU6j5xXT6OkR=+zuwHgag@mail.gmail.com>

Neat.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20200716/4330b88e/attachment.htm>

From darrellroot at mac.com  Fri Jul 17 22:43:05 2020
From: darrellroot at mac.com (Darrell Root)
Date: Fri, 17 Jul 2020 20:43:05 -0700
Subject: [netrek-dev] How do COW and Windows clients know you are dead?
 (To pop up the "choose team" screen) (PFREFIT?)
In-Reply-To: <20200716230445.GC17208@laptop.org>
References: <905DB070-9298-41CB-AE64-D0F5FAE963B7@mac.com>
 <20200716211943.GB17208@laptop.org>
 <7B29B8CB-C4D5-430D-81A3-A751BC2D4C25@mac.com>
 <20200716230445.GC17208@laptop.org>
Message-ID: <988718CF-7A68-46A6-9164-23AAD2ACB2D6@mac.com>

James Cameron wrote:

> As a wild guess, you may not have disabled the Nagle algorithm on the TCP socket?

You scored a point by making me open up my copy of TCP/IP Illustrated volume 1 by Richard Stevens ;-)

I have not disabled it.  But I also have not gotten to a bunch of other packet optimizations.  Every function which sends data currently ends with a WriteAndFlush (guaranteeing correctness).  I’m confident I can aggregate my SP_PLAYER sends with Writes and then execute one WriteAndFlush each every 0.1 seconds.

I also haven’t checked the tcpdumps to see how many packets per second my server is sending to a client versus the existing server.

I will get to these optimizations.

For now, the COW blinking may have been CPU related.  My Linux VM is running on a 2013 iMac.  I’d love to have an observation of how well/poorly my server looks from Windows and Linux clients which are not running in VM’s.  For reference, my netrek.networkmom.net <http://netrek.networkmom.net/> server is located in the SFO region.

Good progress today on command-line-arguments and logging, which were necessary infrastructure for tomorrow's “genocide logic” and “user database” day.

Darrell

> On Jul 16, 2020, at 4:04 PM, James Cameron <quozl at laptop.org> wrote:
> 
> As a wild guess, you may not have disabled the Nagle algorithm on the
> TCP socket?  Aggregation and delay of data in the outgoing queue does
> cause an effect that can be reported as "blinking".
> 
> On Thu, Jul 16, 2020 at 03:27:18PM -0700, Darrell Root wrote:
>> Thank you!  This bug is now resolved thanks to your help and Bill Balcerski’s
>> bug report!
>> 
>> It looks like the explosion gets animated in the EXPLODE state.  Then there is
>> a pause in the DEAD state allowing torpedoes to run out.  But then I needed to
>> migrate the user to the OUTFIT state to get back to the “select ship/quit”
>> screen.  I chose 1 second for each of those two states.
>> 
>> I think most of the “client blinking” in the x86 client (that Bill reported) is
>> resolved.  But I’m seeing a huge quantity of “stuff blinking” on the COW client
>> running in a Parallels VM on my Mac.
>> 
>> I’m not sure whether the “stuff blinking” is an artifact of the Parallels VM or
>> a real problem.  In the x86 client case, I was sending unnecessary updates to
>> the client, resulting in continuous redraws.
>> 
>> If someone could pop up a COW client on a native Linux box, point it at [1]
>> netrek.networkmom.net, and report if they see planets/ships on the screen
>> blinking too much, I’d appreciate it.
>> 
>> Darrell
>> 
>>    On Jul 16, 2020, at 2:19 PM, James Cameron <[2]quozl at laptop.org> wrote:
>> 
>>    Looking at Gytha's __init__.py which contains a paste of the protocol
>>    definition;
>> 
>>    SP_PSTATUS, indicates PDEAD state
>>    client animates explosion
>> 
>>    SP_PSTATUS, indicates POUTFIT state
>>    clients returns to team selection window
>> 
>>    Looking at Gytha's PhaseFlight class, the event loop exits on POUTFIT
>>    "# no longer flying".
>> 
>>    Looking at Gytha's nt_play_a_slot "keep playing on a server, until
>>    user chooses a quit option, or a list option to return to the server
>>    list", play continues until POUTFIT.
>> 
>>    On Thu, Jul 16, 2020 at 01:55:03PM -0700, Darrell Root wrote:
>> 
>>        Netrek-dev,
>> 
>>        My Swift Netrek server has a compatibility problem with COW and Windows
>>        clients.
>> 
>>        When a person dies, the clients do not pop up the “choose team” screen.
>>         So
>>        people have to disconnect to respawn.
>>        The clients also do not show the “you were killed by [WEAPON] from
>>        [PLAYER]
>>        message when connected to my server.
>> 
>>        What message/flag sent from the server triggers that window / message?
>> 
>>        I was assuming it was the whydead and whodead fields in the SP_YOU, but
>>        so far
>>        I haven’t been able to get it working.
>> 
>>        Here’s a sequence of SP_YOU messages from [1][3]pickled.netrek.org.
>>         These can be
>>        assumed to be correct.  I’ve put the death and respan in BOLD
>> 
>>        "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>>        33562624 damage
>>        64 shieldStrength 100 fuel 10000 engineTemp 0 weaponsTemp 0 whyDead 0
>>        whodead
>>        6"
>>        "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>>        33562624 damage
>>        103 shieldStrength 100 fuel 10000 engineTemp 0 weaponsTemp 0 whyDead 2
>>        whodead
>>        6"
>>        "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>>        33562624 damage
>>        103 shieldStrength 100 fuel 9980 engineTemp 5 weaponsTemp 0 whyDead 2
>>        whodead
>>        6"
>>        "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>>        33562624 damage
>>        103 shieldStrength 100 fuel 9960 engineTemp 10 weaponsTemp 0 whyDead 2
>>        whodead
>>        6"
>>        "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>>        33562624 damage
>>        103 shieldStrength 100 fuel 9940 engineTemp 15 weaponsTemp 0 whyDead 2
>>        whodead
>>        6"
>>        "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>>        33562624 damage
>>        103 shieldStrength 100 fuel 9924 engineTemp 19 weaponsTemp 0 whyDead 2
>>        whodead
>>        6"
>>        "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>>        33562624 damage
>>        103 shieldStrength 100 fuel 9908 engineTemp 23 weaponsTemp 0 whyDead 2
>>        whodead
>>        6"
>>        "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>>        33562624 damage
>>        103 shieldStrength 100 fuel 9892 engineTemp 27 weaponsTemp 0 whyDead 2
>>        whodead
>>        6"
>>        "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>>        33562624 damage
>>        103 shieldStrength 100 fuel 9876 engineTemp 31 weaponsTemp 0 whyDead 2
>>        whodead
>>        6"
>>        "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>>        33562624 damage
>>        103 shieldStrength 100 fuel 9860 engineTemp 35 weaponsTemp 0 whyDead 2
>>        whodead
>>        6"
>>        "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>>        33562624 damage
>>        103 shieldStrength 100 fuel 9848 engineTemp 38 weaponsTemp 0 whyDead 2
>>        whodead
>>        6"
>>        "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>>        33562624 damage
>>        103 shieldStrength 100 fuel 9836 engineTemp 41 weaponsTemp 0 whyDead 2
>>        whodead
>>        6"
>>        "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 2049
>>        damage
>>        0 shieldStrength 100 fuel 10000 engineTemp 0 weaponsTemp 0 whyDead 2
>>        whodead 6"
>>        "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>>        33556481 damage
>>        0 shieldStrength 100 fuel 10000 engineTemp 0 weaponsTemp 0 whyDead 2
>>        whodead 6”
>> 
>>        Here’s a sequence of SP_YOU messages from [2][4]netrek.networkmom.net.
>> 
>>        "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048
>>        damage
>>        78 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 0
>>        whodead 0"
>>        "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048
>>        damage
>>        118 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 2
>>        whodead
>>        0"
>>        "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048
>>        damage
>>        118 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 2
>>        whodead
>>        0"
>>        "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048
>>        damage
>>        118 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 2
>>        whodead
>>        0”
>> 
>>        …large number of identical messages deleted…
>> 
>>        "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048
>>        damage
>>        118 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 2
>>        whodead
>>        0"
>>        "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048
>>        damage
>>        118 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 2
>>        whodead
>>        0"
>>        "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048
>>        damage 0
>>        shieldStrength 100 fuel 10000 engineTemp 0 weaponsTemp 0 whyDead 0
>>        whodead 0”
>> 
>>        (Looks like I need to fix whodead, but 0 is valid so I don’t think
>>        that’s the
>>        cause).
>> 
>>        Could it be PFREFIT?
>> 
>>        For reference, here’s the p_flags fields.  While my current
>>        implementation is
>>        missing red/yellow/green, I don’t see anything relevant.
>> 
>>        /* bit masks of p_flags */
>>        #define PFSHIELD           0x0001 /*!< shields are up */
>>        #define PFREPAIR           0x0002 /*!< repairing damage or shields */
>>        #define PFBOMB             0x0004 /*!< bombing planet while orbiting */
>>        #define PFORBIT            0x0008 /*!< orbiting planet p_planet */
>>        #define PFCLOAK            0x0010
>>        #define PFWEP              0x0020
>>        #define PFENG              0x0040
>>        #define PFROBOT            0x0080
>>        #define PFBEAMUP           0x0100
>>        #define PFBEAMDOWN         0x0200
>>        #define PFSELFDEST         0x0400
>>        #define PFGREEN            0x0800
>>        #define PFYELLOW           0x1000
>>        #define PFRED              0x2000
>>        #define PFPLOCK            0x4000       /* Locked on a player */
>>        #define PFPLLOCK           0x8000       /* Locked on a planet */
>>        #define PFCOPILOT         0x10000       /* Allow copilots */
>>        #define PFWAR             0x20000       /* computer reprogramming for
>>        war */
>>        #define PFPRACTR          0x40000       /* practice type robot (no
>>        kills) */
>>        #define PFDOCK            0x80000 /*!< docked to a base, p_dock_with
>>        valid */
>>        #define PFREFIT          0x100000       /* true if about to refit */
>>        #define PFREFITTING      0x200000       /* true if currently refitting
>>        */
>>        #define PFTRACT          0x400000       /* tractor beam activated */
>>        #define PFPRESS          0x800000       /* pressor beam activated */
>>        #define PFDOCKOK        0x1000000       /* docking permission */
>>        #define PFSEEN          0x2000000       /* seen by enemy on galactic
>>        map? */
>>        /*#define PFCYBORG      0x4000000       a cyborg? 7/27/91 TC */
>>        #define PFOBSERV        0x8000000       /* for observers */
>>        #define PFTWARP        0x40000000       /* isae -- SB transwarp */
>> 
>>        References:
>> 
>>        [1] [5]http://pickled.netrek.org/
>>        [2] [6]http://netrek.networkmom.net/
>> 
>>        _______________________________________________
>>        netrek-dev mailing list
>>        [7]netrek-dev at us.netrek.org
>>        [8]http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
>> 
>>    -- 
>>    James Cameron
>>    [9]http://quozl.netrek.org/
>>    _______________________________________________
>>    netrek-dev mailing list
>>    [10]netrek-dev at us.netrek.org
>>    [11]http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
>> 
>> References:
>> 
>> [1] http://netrek.networkmom.net/
>> [2] mailto:quozl at laptop.org
>> [3] http://pickled.netrek.org/
>> [4] http://netrek.networkmom.net/
>> [5] http://pickled.netrek.org/
>> [6] http://netrek.networkmom.net/
>> [7] mailto:netrek-dev at us.netrek.org
>> [8] http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
>> [9] http://quozl.netrek.org/
>> [10] mailto:netrek-dev at us.netrek.org
>> [11] 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
> 
> 
> -- 
> James Cameron
> http://quozl.netrek.org/
> _______________________________________________
> 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: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20200717/108a7991/attachment-0001.htm>

From darrellroot at mac.com  Fri Jul 17 22:59:42 2020
From: darrellroot at mac.com (Darrell Root)
Date: Fri, 17 Jul 2020 20:59:42 -0700
Subject: [netrek-dev] How do COW and Windows clients know you are dead?
 (To pop up the "choose team" screen) (PFREFIT?)
In-Reply-To: <988718CF-7A68-46A6-9164-23AAD2ACB2D6@mac.com>
References: <905DB070-9298-41CB-AE64-D0F5FAE963B7@mac.com>
 <20200716211943.GB17208@laptop.org>
 <7B29B8CB-C4D5-430D-81A3-A751BC2D4C25@mac.com>
 <20200716230445.GC17208@laptop.org>
 <988718CF-7A68-46A6-9164-23AAD2ACB2D6@mac.com>
Message-ID: <29E4FDCF-51A7-4BB5-93FD-41346015338A@mac.com>

Ok, this is bad and needs to be prioritized:

1 second of Netrek on my Swift server: 970 packets (TCP, WriteAndFlush with every function)
1 second of Netrek on pickled.netrek.org <http://pickled.netrek.org/> using UDP: 11 packets 
1 second of Netrek on pickled.netrek.org <http://pickled.netrek.org/> using TCP: 24 packets

Ouch.  I’ll get on that.

Darrell


> On Jul 17, 2020, at 8:43 PM, Darrell Root <darrellroot at mac.com> wrote:
> 
> James Cameron wrote:
> 
> > As a wild guess, you may not have disabled the Nagle algorithm on the TCP socket?
> 
> You scored a point by making me open up my copy of TCP/IP Illustrated volume 1 by Richard Stevens ;-)
> 
> I have not disabled it.  But I also have not gotten to a bunch of other packet optimizations.  Every function which sends data currently ends with a WriteAndFlush (guaranteeing correctness).  I’m confident I can aggregate my SP_PLAYER sends with Writes and then execute one WriteAndFlush each every 0.1 seconds.
> 
> I also haven’t checked the tcpdumps to see how many packets per second my server is sending to a client versus the existing server.
> 
> I will get to these optimizations.
> 
> For now, the COW blinking may have been CPU related.  My Linux VM is running on a 2013 iMac.  I’d love to have an observation of how well/poorly my server looks from Windows and Linux clients which are not running in VM’s.  For reference, my netrek.networkmom.net <http://netrek.networkmom.net/> server is located in the SFO region.
> 
> Good progress today on command-line-arguments and logging, which were necessary infrastructure for tomorrow's “genocide logic” and “user database” day.
> 
> Darrell
> 
>> On Jul 16, 2020, at 4:04 PM, James Cameron <quozl at laptop.org <mailto:quozl at laptop.org>> wrote:
>> 
>> As a wild guess, you may not have disabled the Nagle algorithm on the
>> TCP socket?  Aggregation and delay of data in the outgoing queue does
>> cause an effect that can be reported as "blinking".
>> 
>> On Thu, Jul 16, 2020 at 03:27:18PM -0700, Darrell Root wrote:
>>> Thank you!  This bug is now resolved thanks to your help and Bill Balcerski’s
>>> bug report!
>>> 
>>> It looks like the explosion gets animated in the EXPLODE state.  Then there is
>>> a pause in the DEAD state allowing torpedoes to run out.  But then I needed to
>>> migrate the user to the OUTFIT state to get back to the “select ship/quit”
>>> screen.  I chose 1 second for each of those two states.
>>> 
>>> I think most of the “client blinking” in the x86 client (that Bill reported) is
>>> resolved.  But I’m seeing a huge quantity of “stuff blinking” on the COW client
>>> running in a Parallels VM on my Mac.
>>> 
>>> I’m not sure whether the “stuff blinking” is an artifact of the Parallels VM or
>>> a real problem.  In the x86 client case, I was sending unnecessary updates to
>>> the client, resulting in continuous redraws.
>>> 
>>> If someone could pop up a COW client on a native Linux box, point it at [1]
>>> netrek.networkmom.net <http://netrek.networkmom.net/>, and report if they see planets/ships on the screen
>>> blinking too much, I’d appreciate it.
>>> 
>>> Darrell
>>> 
>>>    On Jul 16, 2020, at 2:19 PM, James Cameron <[2]quozl at laptop.org <mailto:quozl at laptop.org>> wrote:
>>> 
>>>    Looking at Gytha's __init__.py which contains a paste of the protocol
>>>    definition;
>>> 
>>>    SP_PSTATUS, indicates PDEAD state
>>>    client animates explosion
>>> 
>>>    SP_PSTATUS, indicates POUTFIT state
>>>    clients returns to team selection window
>>> 
>>>    Looking at Gytha's PhaseFlight class, the event loop exits on POUTFIT
>>>    "# no longer flying".
>>> 
>>>    Looking at Gytha's nt_play_a_slot "keep playing on a server, until
>>>    user chooses a quit option, or a list option to return to the server
>>>    list", play continues until POUTFIT.
>>> 
>>>    On Thu, Jul 16, 2020 at 01:55:03PM -0700, Darrell Root wrote:
>>> 
>>>        Netrek-dev,
>>> 
>>>        My Swift Netrek server has a compatibility problem with COW and Windows
>>>        clients.
>>> 
>>>        When a person dies, the clients do not pop up the “choose team” screen.
>>>         So
>>>        people have to disconnect to respawn.
>>>        The clients also do not show the “you were killed by [WEAPON] from
>>>        [PLAYER]
>>>        message when connected to my server.
>>> 
>>>        What message/flag sent from the server triggers that window / message?
>>> 
>>>        I was assuming it was the whydead and whodead fields in the SP_YOU, but
>>>        so far
>>>        I haven’t been able to get it working.
>>> 
>>>        Here’s a sequence of SP_YOU messages from [1][3]pickled.netrek.org <http://pickled.netrek.org/>.
>>>         These can be
>>>        assumed to be correct.  I’ve put the death and respan in BOLD
>>> 
>>>        "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>>>        33562624 damage
>>>        64 shieldStrength 100 fuel 10000 engineTemp 0 weaponsTemp 0 whyDead 0
>>>        whodead
>>>        6"
>>>        "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>>>        33562624 damage
>>>        103 shieldStrength 100 fuel 10000 engineTemp 0 weaponsTemp 0 whyDead 2
>>>        whodead
>>>        6"
>>>        "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>>>        33562624 damage
>>>        103 shieldStrength 100 fuel 9980 engineTemp 5 weaponsTemp 0 whyDead 2
>>>        whodead
>>>        6"
>>>        "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>>>        33562624 damage
>>>        103 shieldStrength 100 fuel 9960 engineTemp 10 weaponsTemp 0 whyDead 2
>>>        whodead
>>>        6"
>>>        "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>>>        33562624 damage
>>>        103 shieldStrength 100 fuel 9940 engineTemp 15 weaponsTemp 0 whyDead 2
>>>        whodead
>>>        6"
>>>        "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>>>        33562624 damage
>>>        103 shieldStrength 100 fuel 9924 engineTemp 19 weaponsTemp 0 whyDead 2
>>>        whodead
>>>        6"
>>>        "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>>>        33562624 damage
>>>        103 shieldStrength 100 fuel 9908 engineTemp 23 weaponsTemp 0 whyDead 2
>>>        whodead
>>>        6"
>>>        "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>>>        33562624 damage
>>>        103 shieldStrength 100 fuel 9892 engineTemp 27 weaponsTemp 0 whyDead 2
>>>        whodead
>>>        6"
>>>        "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>>>        33562624 damage
>>>        103 shieldStrength 100 fuel 9876 engineTemp 31 weaponsTemp 0 whyDead 2
>>>        whodead
>>>        6"
>>>        "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>>>        33562624 damage
>>>        103 shieldStrength 100 fuel 9860 engineTemp 35 weaponsTemp 0 whyDead 2
>>>        whodead
>>>        6"
>>>        "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>>>        33562624 damage
>>>        103 shieldStrength 100 fuel 9848 engineTemp 38 weaponsTemp 0 whyDead 2
>>>        whodead
>>>        6"
>>>        "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>>>        33562624 damage
>>>        103 shieldStrength 100 fuel 9836 engineTemp 41 weaponsTemp 0 whyDead 2
>>>        whodead
>>>        6"
>>>        "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags 2049
>>>        damage
>>>        0 shieldStrength 100 fuel 10000 engineTemp 0 weaponsTemp 0 whyDead 2
>>>        whodead 6"
>>>        "Received SP_YOU 12 1 hostile 13 war 0 armies 0 tractor 0 flags
>>>        33556481 damage
>>>        0 shieldStrength 100 fuel 10000 engineTemp 0 weaponsTemp 0 whyDead 2
>>>        whodead 6”
>>> 
>>>        Here’s a sequence of SP_YOU messages from [2][4]netrek.networkmom.net <http://netrek.networkmom.net/>.
>>> 
>>>        "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048
>>>        damage
>>>        78 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 0
>>>        whodead 0"
>>>        "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048
>>>        damage
>>>        118 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 2
>>>        whodead
>>>        0"
>>>        "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048
>>>        damage
>>>        118 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 2
>>>        whodead
>>>        0"
>>>        "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048
>>>        damage
>>>        118 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 2
>>>        whodead
>>>        0”
>>> 
>>>        …large number of identical messages deleted…
>>> 
>>>        "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048
>>>        damage
>>>        118 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 2
>>>        whodead
>>>        0"
>>>        "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048
>>>        damage
>>>        118 shieldStrength 100 fuel 9460 engineTemp 5 weaponsTemp 0 whyDead 2
>>>        whodead
>>>        0"
>>>        "Received SP_YOU 12 16 hostile 14 war 14 armies 0 tractor 0 flags 2048
>>>        damage 0
>>>        shieldStrength 100 fuel 10000 engineTemp 0 weaponsTemp 0 whyDead 0
>>>        whodead 0”
>>> 
>>>        (Looks like I need to fix whodead, but 0 is valid so I don’t think
>>>        that’s the
>>>        cause).
>>> 
>>>        Could it be PFREFIT?
>>> 
>>>        For reference, here’s the p_flags fields.  While my current
>>>        implementation is
>>>        missing red/yellow/green, I don’t see anything relevant.
>>> 
>>>        /* bit masks of p_flags */
>>>        #define PFSHIELD           0x0001 /*!< shields are up */
>>>        #define PFREPAIR           0x0002 /*!< repairing damage or shields */
>>>        #define PFBOMB             0x0004 /*!< bombing planet while orbiting */
>>>        #define PFORBIT            0x0008 /*!< orbiting planet p_planet */
>>>        #define PFCLOAK            0x0010
>>>        #define PFWEP              0x0020
>>>        #define PFENG              0x0040
>>>        #define PFROBOT            0x0080
>>>        #define PFBEAMUP           0x0100
>>>        #define PFBEAMDOWN         0x0200
>>>        #define PFSELFDEST         0x0400
>>>        #define PFGREEN            0x0800
>>>        #define PFYELLOW           0x1000
>>>        #define PFRED              0x2000
>>>        #define PFPLOCK            0x4000       /* Locked on a player */
>>>        #define PFPLLOCK           0x8000       /* Locked on a planet */
>>>        #define PFCOPILOT         0x10000       /* Allow copilots */
>>>        #define PFWAR             0x20000       /* computer reprogramming for
>>>        war */
>>>        #define PFPRACTR          0x40000       /* practice type robot (no
>>>        kills) */
>>>        #define PFDOCK            0x80000 /*!< docked to a base, p_dock_with
>>>        valid */
>>>        #define PFREFIT          0x100000       /* true if about to refit */
>>>        #define PFREFITTING      0x200000       /* true if currently refitting
>>>        */
>>>        #define PFTRACT          0x400000       /* tractor beam activated */
>>>        #define PFPRESS          0x800000       /* pressor beam activated */
>>>        #define PFDOCKOK        0x1000000       /* docking permission */
>>>        #define PFSEEN          0x2000000       /* seen by enemy on galactic
>>>        map? */
>>>        /*#define PFCYBORG      0x4000000       a cyborg? 7/27/91 TC */
>>>        #define PFOBSERV        0x8000000       /* for observers */
>>>        #define PFTWARP        0x40000000       /* isae -- SB transwarp */
>>> 
>>>        References:
>>> 
>>>        [1] [5]http://pickled.netrek.org/ <http://pickled.netrek.org/>
>>>        [2] [6]http://netrek.networkmom.net/ <http://netrek.networkmom.net/>
>>> 
>>>        _______________________________________________
>>>        netrek-dev mailing list
>>>        [7]netrek-dev at us.netrek.org <mailto:netrek-dev at us.netrek.org>
>>>        [8]http://mailman.us.netrek.org/mailman/listinfo/netrek-dev <http://mailman.us.netrek.org/mailman/listinfo/netrek-dev>
>>> 
>>>    -- 
>>>    James Cameron
>>>    [9]http://quozl.netrek.org/ <http://quozl.netrek.org/>
>>>    _______________________________________________
>>>    netrek-dev mailing list
>>>    [10]netrek-dev at us.netrek.org <mailto:netrek-dev at us.netrek.org>
>>>    [11]http://mailman.us.netrek.org/mailman/listinfo/netrek-dev <http://mailman.us.netrek.org/mailman/listinfo/netrek-dev>
>>> 
>>> References:
>>> 
>>> [1] http://netrek.networkmom.net/ <http://netrek.networkmom.net/>
>>> [2] mailto:quozl at laptop.org <mailto:quozl at laptop.org>
>>> [3] http://pickled.netrek.org/ <http://pickled.netrek.org/>
>>> [4] http://netrek.networkmom.net/ <http://netrek.networkmom.net/>
>>> [5] http://pickled.netrek.org/ <http://pickled.netrek.org/>
>>> [6] http://netrek.networkmom.net/ <http://netrek.networkmom.net/>
>>> [7] mailto:netrek-dev at us.netrek.org <mailto:netrek-dev at us.netrek.org>
>>> [8] http://mailman.us.netrek.org/mailman/listinfo/netrek-dev <http://mailman.us.netrek.org/mailman/listinfo/netrek-dev>
>>> [9] http://quozl.netrek.org/ <http://quozl.netrek.org/>
>>> [10] mailto:netrek-dev at us.netrek.org <mailto:netrek-dev at us.netrek.org>
>>> [11] http://mailman.us.netrek.org/mailman/listinfo/netrek-dev <http://mailman.us.netrek.org/mailman/listinfo/netrek-dev>
>> 
>>> _______________________________________________
>>> netrek-dev mailing list
>>> netrek-dev at us.netrek.org <mailto:netrek-dev at us.netrek.org>
>>> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
>> 
>> 
>> -- 
>> James Cameron
>> http://quozl.netrek.org/ <http://quozl.netrek.org/>
>> _______________________________________________
>> 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: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20200717/68198183/attachment-0001.htm>

From habig at neutrino.d.umn.edu  Fri Jul 17 23:07:39 2020
From: habig at neutrino.d.umn.edu (Alec Habig)
Date: Fri, 17 Jul 2020 23:07:39 -0500
Subject: [netrek-dev] How do COW and Windows clients know you are dead?
 (To pop up the "choose team" screen) (PFREFIT?)
In-Reply-To: <988718CF-7A68-46A6-9164-23AAD2ACB2D6@mac.com>
References: <905DB070-9298-41CB-AE64-D0F5FAE963B7@mac.com>
 <20200716211943.GB17208@laptop.org>
 <7B29B8CB-C4D5-430D-81A3-A751BC2D4C25@mac.com>
 <20200716230445.GC17208@laptop.org>
 <988718CF-7A68-46A6-9164-23AAD2ACB2D6@mac.com>
Message-ID: <20200718040739.GA18469@neutrino.d.umn.edu>

Darrell Root writes:
> 
> You scored a point by making me open up my copy of TCP/IP Illustrated
> volume 1 by Richard Stevens ;-)

Netrek made me read a lot of his "Unix Network Programming" book!

Paid off nicely in my research, though, or that's always been my
excuse.  :)

-- 
			       Alec Habig
		     University of Minnesota Duluth
		     Dept. of Physics and Astronomy
			     ahabig at umn.edu
		   http://neutrino.d.umn.edu/~habig/

From netrek at gmail.com  Sat Jul 18 14:46:58 2020
From: netrek at gmail.com (Zachary Uram)
Date: Sat, 18 Jul 2020 15:46:58 -0400
Subject: [netrek-dev] How do COW and Windows clients know you are dead?
 (To pop up the "choose team" screen) (PFREFIT?)
In-Reply-To: <20200718040739.GA18469@neutrino.d.umn.edu>
References: <905DB070-9298-41CB-AE64-D0F5FAE963B7@mac.com>
 <20200716211943.GB17208@laptop.org>
 <7B29B8CB-C4D5-430D-81A3-A751BC2D4C25@mac.com>
 <20200716230445.GC17208@laptop.org>
 <988718CF-7A68-46A6-9164-23AAD2ACB2D6@mac.com>
 <20200718040739.GA18469@neutrino.d.umn.edu>
Message-ID: <CAPu6UvAa1daAb2h1Mm+oidiX6xKqQS0uP+NB-Ln+ZJS_N2=WNg@mail.gmail.com>

Good to hear from you Alec!

Zach

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sat, Jul 18, 2020 at 1:00 AM Alec Habig <habig at neutrino.d.umn.edu> wrote:

> Darrell Root writes:
> >
> > You scored a point by making me open up my copy of TCP/IP Illustrated
> > volume 1 by Richard Stevens ;-)
>
> Netrek made me read a lot of his "Unix Network Programming" book!
>
> Paid off nicely in my research, though, or that's always been my
> excuse.  :)
>
> --
>                                Alec Habig
>                      University of Minnesota Duluth
>                      Dept. of Physics and Astronomy
>                              ahabig at umn.edu
>                    http://neutrino.d.umn.edu/~habig/
> _______________________________________________
> 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: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20200718/9e151475/attachment.htm>

From darrellroot at mac.com  Sat Jul 18 21:29:14 2020
From: darrellroot at mac.com (Darrell Root)
Date: Sat, 18 Jul 2020 19:29:14 -0700
Subject: [netrek-dev] Announcing Netrek Empire mode! (Beta) Early adopter
 test Tuesday 7/21 6PM Pacific.
Message-ID: <AFD71B01-7F27-4E9B-95EC-1B9E2D3C4135@mac.com>

Update: I solved the network performance problem.  I’m currently running ~43 packets per second between my Swift client and the Swift server.

News: I’m pleased to announce a new Netrek game mode: Empire!

Uses standard Bronco clients
All 4 teams active.
Sufficient robots for minimum of 28 players (robots logoff as humans join).
When you join, you are randomly assigned a “home planet”.
You spawn on whatever team controls the planet (if the planet is Indi, then you spawn on the original owner’s team).
When one empire controls 75% of the planets, they win.
If you want to refit ships, you need to do it at your assigned home planet.

As an empire gains planets, it gets more ships/players.  But it might be possible for the 3 other empires to stop a large team from becoming dominant.
Due to the random assignment of players to planets, there in no guarantee that teams will start out even.

I’ve tested that the following clients handle 28 players successfully:

MacOS-Swift
Linux-COW (although the full player list may not be visible)
Windows-x86

Server is netrek.networkmom.net <http://netrek.networkmom.net/>

Feel free to login and try it out anytime (warning: I’m restarting the server periodically as I push new features/bugfixes).  I continue to appreciate feedback on the server.

We will have an early adopter test game Tuesday 7/21 6PM Pacific.

Thursday 7/23 is hockey.  We will have a full game Tuesday 7/30 6PM Pacific.


My Swift server is open source at https://github.com/darrellroot/netrek-server-swift <https://github.com/darrellroot/netrek-server-swift>
The server also supports bronco mode with a command-line argument (not yet feature complete)


Major known server issues:

Still no user database / ranks.
Server does not yet implement proper “visibility” rules for distant or cloaked ships.
Missing some starbase features/restrictions
Bronco mode does not have game timers.
Robots are ok dogfighters, but do not currently bomb or capture planets.

Metaserver: For now my server is still reporting server type “B” for bronco.  I will change it to “E” at some point, but I need to push a new MacOS client before I do so.  I might look at COW source and see if I can generate a pull request to handle the E in the metaserver report.  Right now other clients report the server type as “unknown” if it sees an E in the metaserver report.

Darrell


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20200718/65faebb4/attachment.htm>

From quozl at laptop.org  Sun Jul 19 15:40:40 2020
From: quozl at laptop.org (James Cameron)
Date: Mon, 20 Jul 2020 06:40:40 +1000
Subject: [netrek-dev] Announcing Netrek Empire mode! (Beta) Early
 adopter test Tuesday 7/21 6PM Pacific.
In-Reply-To: <AFD71B01-7F27-4E9B-95EC-1B9E2D3C4135@mac.com>
References: <AFD71B01-7F27-4E9B-95EC-1B9E2D3C4135@mac.com>
Message-ID: <20200719204040.GA12572@laptop.org>

Re: no guarantee that teams will start out even.

There's an algorithm in ntserv/balance.c that will use player stats to
even up two teams.  It is activated by vote.  You might do something
similar.

(In daily workplace games, we found an engineer would game this by
dying a lot long term, such that the algorithm would undervalue them;
then their balanced team always won.  People lost faith in the idea.)

On Sat, Jul 18, 2020 at 07:29:14PM -0700, Darrell Root wrote:
> Update: I solved the network performance problem.  I’m currently running ~43
> packets per second between my Swift client and the Swift server.
> 
> News: I’m pleased to announce a new Netrek game mode: Empire!
> 
> Uses standard Bronco clients
> All 4 teams active.
> Sufficient robots for minimum of 28 players (robots logoff as humans join).
> When you join, you are randomly assigned a “home planet”.
> You spawn on whatever team controls the planet (if the planet is Indi, then you
> spawn on the original owner’s team).
> When one empire controls 75% of the planets, they win.
> If you want to refit ships, you need to do it at your assigned home planet.
> 
> As an empire gains planets, it gets more ships/players.  But it might be
> possible for the 3 other empires to stop a large team from becoming dominant.
> Due to the random assignment of players to planets, there in no guarantee that
> teams will start out even.
> 
> I’ve tested that the following clients handle 28 players successfully:
> 
> MacOS-Swift
> Linux-COW (although the full player list may not be visible)
> Windows-x86
> 
> Server is [1]netrek.networkmom.net
> 
> Feel free to login and try it out anytime (warning: I’m restarting the server
> periodically as I push new features/bugfixes).  I continue to appreciate
> feedback on the server.
> 
> We will have an early adopter test game Tuesday 7/21 6PM Pacific.
> 
> Thursday 7/23 is hockey.  We will have a full game Tuesday 7/30 6PM Pacific.
> 
> My Swift server is open source at [2]https://github.com/darrellroot/
> netrek-server-swift
> The server also supports bronco mode with a command-line argument (not yet
> feature complete)
> 
> Major known server issues:
> 
> Still no user database / ranks.
> Server does not yet implement proper “visibility” rules for distant or cloaked
> ships.
> Missing some starbase features/restrictions
> Bronco mode does not have game timers.
> Robots are ok dogfighters, but do not currently bomb or capture planets.
> 
> Metaserver: For now my server is still reporting server type “B” for bronco.  I
> will change it to “E” at some point, but I need to push a new MacOS client
> before I do so.  I might look at COW source and see if I can generate a pull
> request to handle the E in the metaserver report.  Right now other clients
> report the server type as “unknown” if it sees an E in the metaserver report.
> 
> Darrell
> 
> References:
> 
> [1] http://netrek.networkmom.net/
> [2] https://github.com/darrellroot/netrek-server-swift

> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev


-- 
James Cameron
http://quozl.netrek.org/

From kevinz5000 at gmail.com  Wed Jul 22 00:09:33 2020
From: kevinz5000 at gmail.com (Kevin Zheng)
Date: Tue, 21 Jul 2020 22:09:33 -0700
Subject: [netrek-dev] Announcing Netrek Empire mode! (Beta) Early
 adopter test Tuesday 7/21 6PM Pacific.
In-Reply-To: <AFD71B01-7F27-4E9B-95EC-1B9E2D3C4135@mac.com>
References: <AFD71B01-7F27-4E9B-95EC-1B9E2D3C4135@mac.com>
Message-ID: <8268ee41-50b7-e7b9-e3b7-ffcc60966ad2@gmail.com>

Interesting to see that another implementation of the server "works!"
But there seem to be many rough edges for me.

I can't put my finger on exactly what it is, but compared to the vanilla
Netrek server, the animation feels "jagged".

The wall clock blinks about once per second, which is the same rate
where I see torpedoes that shouldn't be there blink in and out.

Do all bots fire on some global clock?

-- 
Kevin Zheng
kevinz5000 at gmail.com | kevinz at berkeley.edu
XMPP: kevinz at eecs.berkeley.edu

From darrellroot at mac.com  Wed Jul 22 12:04:31 2020
From: darrellroot at mac.com (Darrell Root)
Date: Wed, 22 Jul 2020 10:04:31 -0700
Subject: [netrek-dev] Announcing Netrek Empire mode! (Beta) Early
 adopter test Tuesday 7/21 6PM Pacific.
In-Reply-To: <8268ee41-50b7-e7b9-e3b7-ffcc60966ad2@gmail.com>
References: <AFD71B01-7F27-4E9B-95EC-1B9E2D3C4135@mac.com>
 <8268ee41-50b7-e7b9-e3b7-ffcc60966ad2@gmail.com>
Message-ID: <14FE35FC-C90B-4FF8-9DDD-AADD62179A56@mac.com>


> On Jul 21, 2020, at 10:09 PM, Kevin Zheng <kevinz5000 at gmail.com> wrote:
> 
> Interesting to see that another implementation of the server "works!"
> But there seem to be many rough edges for me.

Thanks for trying it out.  I’ll improve it as much as I can before the Thursday July 30th game.  What client were you using?
> 
> I can't put my finger on exactly what it is, but compared to the vanilla
> Netrek server, the animation feels "jagged".

Server is currently running at 10FPS.  I’ll eventually get this to 20FPS, which I think is the “smooth spot” ;-)

> The wall clock blinks about once per second, which is the same rate
> where I see torpedoes that shouldn't be there blink in and out.

I saw the wall clock blinking on the COW client.  I have no idea what causes that, but I do send a bunch of updates once per second.

> 
> Do all bots fire on some global clock?

Bots decide whether to fire once per second, on the second.

The following are executed once per second:

Alert condition checked
Direction changes if planet lock or player lock enabled

Full updates of the following once per second:

Sp_Pl_Login
SpHostile
SpPlayerInfo
SpKills
SpPlayerStatus
SpFlags

Presumably, one of the above is causing the COW client clock to blink

Other observations from the early adopter game:

“Detted torp damage seems high”
Add armies to kill report if dying player was carrying
Inconsistent use of slot numbers versus letters versus hex
Torp vector needs correction
No torp wobble
Turn radius for cruiser at speed 9 seems too lenient
Bug: possible to repair after engine failure

> 
> -- 
> Kevin Zheng
> kevinz5000 at gmail.com | kevinz at berkeley.edu
> XMPP: kevinz at eecs.berkeley.edu
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev


From netrek at gmail.com  Wed Jul 22 12:18:27 2020
From: netrek at gmail.com (Zachary Uram)
Date: Wed, 22 Jul 2020 13:18:27 -0400
Subject: [netrek-dev] Announcing Netrek Empire mode! (Beta) Early
 adopter test Tuesday 7/21 6PM Pacific.
In-Reply-To: <14FE35FC-C90B-4FF8-9DDD-AADD62179A56@mac.com>
References: <AFD71B01-7F27-4E9B-95EC-1B9E2D3C4135@mac.com>
 <8268ee41-50b7-e7b9-e3b7-ffcc60966ad2@gmail.com>
 <14FE35FC-C90B-4FF8-9DDD-AADD62179A56@mac.com>
Message-ID: <CAPu6UvAc1LBDbHX-npa4DrzbrMSJnkKYn7r8z5O9YMxVK8vchQ@mail.gmail.com>

Can you reduce the number of bots per team before the game next week? There
are so many bots I wouldn't be able to see all the player names.

Zach


<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Wed, Jul 22, 2020 at 1:04 PM Darrell Root <darrellroot at mac.com> wrote:

>
> > On Jul 21, 2020, at 10:09 PM, Kevin Zheng <kevinz5000 at gmail.com> wrote:
> >
> > Interesting to see that another implementation of the server "works!"
> > But there seem to be many rough edges for me.
>
> Thanks for trying it out.  I’ll improve it as much as I can before the
> Thursday July 30th game.  What client were you using?
> >
> > I can't put my finger on exactly what it is, but compared to the vanilla
> > Netrek server, the animation feels "jagged".
>
> Server is currently running at 10FPS.  I’ll eventually get this to 20FPS,
> which I think is the “smooth spot” ;-)
>
> > The wall clock blinks about once per second, which is the same rate
> > where I see torpedoes that shouldn't be there blink in and out.
>
> I saw the wall clock blinking on the COW client.  I have no idea what
> causes that, but I do send a bunch of updates once per second.
>
> >
> > Do all bots fire on some global clock?
>
> Bots decide whether to fire once per second, on the second.
>
> The following are executed once per second:
>
> Alert condition checked
> Direction changes if planet lock or player lock enabled
>
> Full updates of the following once per second:
>
> Sp_Pl_Login
> SpHostile
> SpPlayerInfo
> SpKills
> SpPlayerStatus
> SpFlags
>
> Presumably, one of the above is causing the COW client clock to blink
>
> Other observations from the early adopter game:
>
> “Detted torp damage seems high”
> Add armies to kill report if dying player was carrying
> Inconsistent use of slot numbers versus letters versus hex
> Torp vector needs correction
> No torp wobble
> Turn radius for cruiser at speed 9 seems too lenient
> Bug: possible to repair after engine failure
>
> >
> > --
> > Kevin Zheng
> > kevinz5000 at gmail.com | kevinz at berkeley.edu
> > XMPP: kevinz at eecs.berkeley.edu
> > _______________________________________________
> > 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
>


-- 
http://www.fidei.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20200722/900e1f41/attachment.htm>

From darrellroot at mac.com  Wed Jul 22 16:42:02 2020
From: darrellroot at mac.com (Darrell Root)
Date: Wed, 22 Jul 2020 14:42:02 -0700
Subject: [netrek-dev] Announcing Netrek Empire mode! (Beta). Next Empire
 game Thursday 6/30 6PM Pacific
In-Reply-To: <CAPu6UvAc1LBDbHX-npa4DrzbrMSJnkKYn7r8z5O9YMxVK8vchQ@mail.gmail.com>
References: <AFD71B01-7F27-4E9B-95EC-1B9E2D3C4135@mac.com>
 <8268ee41-50b7-e7b9-e3b7-ffcc60966ad2@gmail.com>
 <14FE35FC-C90B-4FF8-9DDD-AADD62179A56@mac.com>
 <CAPu6UvAc1LBDbHX-npa4DrzbrMSJnkKYn7r8z5O9YMxVK8vchQ@mail.gmail.com>
Message-ID: <529BE4C7-73F7-4F3C-8759-A89A6DF1F6C9@mac.com>


A productive programming day so far.  Updates to netrek.networkmom.net <http://netrek.networkmom.net/> Empire server:

Zach wrote:

> Can you reduce the number of bots per team before the game next week? There are so many bots I wouldn't be able to see all the player names.

That goes against one goal of Empire mode, which is to have a BIG game with 4 full teams (of course we’d prefer 28-32 humans).

I’ve made robots take the higher numbered slots.  Human players take the lower numbered slots.  That way the human player list will be visible on all clients until ~20 human players, at which point some clients (COW) have them scroll off the bottom.

> “Detted torp damage seems high”

Fixed

> Add armies to kill report if dying player was carrying

Fixed

> Inconsistent use of slot numbers versus letters versus hex

Server now consistently uses decimal.  Some clients still use letters a-v for players 10-32.

> Torp vector needs correction

Fixed.  Torp/ship vector now affects torp speed (butt-torping is slower) but not aim direction, consistent with Vanilla.

> No torp wobble

Fixed.  Torps now wobble

> Turn radius for cruiser at speed 9 seems too lenient

Fixed.

> Bug: possible to repair after engine failure

Fixed

Outstanding issues:

> I can't put my finger on exactly what it is, but compared to the vanilla
> Netrek server, the animation feels "jagged”.

(Goal: increase to 20 fps)

> The wall clock blinks about once per second, which is the same rate
> where I see torpedoes that shouldn't be there blink in and out.

I saw the wall clock blinking on the COW client.  I have no idea what causes that, but I do send a bunch of updates once per second.  Will investigate.

Darrell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20200722/3a644ea7/attachment.htm>

From darrellroot at mac.com  Sun Jul 26 21:47:48 2020
From: darrellroot at mac.com (Darrell Root)
Date: Sun, 26 Jul 2020 19:47:48 -0700
Subject: [netrek-dev] Netrek Empire game Thursday 6PM Pacific,
 netrek.networkmom.net now at 20FPS
Message-ID: <970E8F9C-8EA2-4058-AFF5-0051540E96E9@mac.com>

What: Netrek Empire Game
When: Thursday July 30th @ 6PM Pacific / 9PM Eastern
Where: netrek.networkmom.net <http://netrek.networkmom.net/>

Backup server in case of instability: pickled.netrek.org <http://pickled.netrek.org/> (Bronco)

Netrek Empire mode:

Uses standard Bronco clients
All 4 teams active
Sufficient robots for minimum of 28 players (robots logoff as humans join)
When you join, you are randomly assigned a “home planet”
You spawn on whatever team controls the planet
When one empire controls 75% of the planets, they win.
If you want to refit ships, you need to do it at your assigned home planet.

As an empire gains planets, it gets more ships/players.  But it might be possible for the 3 other empires to stop a large empire from becoming dominant.
Due to the random assignment of players to planets, there is no guarantee that teams will start out even.


Other dev news:

Solved “blinking” in COW.  Many server updates are now only sent when needed, rather than once per second

netrek.networkmom.net <http://netrek.networkmom.net/> is now operating at 20FPS!

The MacOS client is now version 2.3.  That includes performance improvements to handle 20FP.  Should be an automatic update, but check your version in the MacOS AppStore and update if needed.

iOS client version 1.4 is submitted for review, including the same performance improvements.  Hopefully will be approved by late Monday.

I am suffering occasional crashes on the server and have had trouble getting a stacktrace.  The server is currently running inside an lldb session. If you see behavior that causes an apparent ghostbust, please email me.  One prior crash inducer was phasering off the top or left of the map.

Darrell
feedback at networkmom.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20200726/6c6e3715/attachment.htm>

From darrellroot at mac.com  Thu Jul 30 10:57:40 2020
From: darrellroot at mac.com (Darrell Root)
Date: Thu, 30 Jul 2020 08:57:40 -0700
Subject: [netrek-dev] Netrek Empire game Thursday 7/30 (Today!) 6PM Pacific
Message-ID: <69102FD7-45EC-4BC9-A870-27F21D3136C4@mac.com>

What: Netrek Empire Game
When: Thursday July 30th @ 6PM Pacific / 9PM Eastern (Today!)
Where: netrek.networkmom.net <http://netrek.networkmom.net/>

Backup server in case of instability: pickled.netrek.org <http://pickled.netrek.org/> (Bronco)

Netrek Empire mode:

Uses standard Bronco clients
All 4 teams active
Sufficient robots for minimum of 28 players (robots logoff as humans join)
When you join, you are randomly assigned a “home planet”
You spawn on whatever team controls the planet
If you want to refit ships, you need to do it at your individually assigned home planet.
When one empire controls 75% of the planets, they win.

As an empire gains planets, it gets more ships/players.  But it might be possible for the 3 other empires to stop a large empire from becoming dominant.
Due to the random assignment of players to planets, there is no guarantee that teams will start out even.


Windows issue:

Had a user running a Windows client last night who suffered client crashes every ~10 minutes.  I’d love to hear whether other Windows users also suffer that problem.  A stacktrace identifying the type of netrek packet which triggers the crash would be very helpful.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20200730/856ddfa8/attachment.htm>

From darrellroot at mac.com  Thu Jul 30 22:45:41 2020
From: darrellroot at mac.com (Darrell Root)
Date: Thu, 30 Jul 2020 20:45:41 -0700
Subject: [netrek-dev] Thank you for playing Netrek Empire!
In-Reply-To: <69102FD7-45EC-4BC9-A870-27F21D3136C4@mac.com>
References: <69102FD7-45EC-4BC9-A870-27F21D3136C4@mac.com>
Message-ID: <3F0436AF-D268-4ABD-87FF-63D435FE04C8@mac.com>

Thank you for playing Netrek Empire mode via the new Swift Netrek server this evening!

We had ~8 players (plus 20 robots) for the first game.  Another half-dozen went off to Pickled due to lag.  Orions captured 30 planets to conquer the galaxy.  ~4 players for the second game.  Had about 90 minutes of solid play.

No server crashes, but we found a bunch of bugs, which will help make the server better:

Windows XP client intermittently crashed when using pressors/tractors.  Bill fired up a debugger and identified the line of code that my (presumably incorrect) server update was triggering.

Cloaking device immediately used all fuel (I introduced this bug today…oops)

Server saw “invalid speed 255” error (presumably maxwarp on a specific client)

Issues with team message (going to all?) may be related to “unexpected group 66” error.

Saw an “unexpected ship type 11” error.

Several players reported substantial lag.  Possible causes:
  1) 20 updates per second impacted server cpu (which went up to the 50-90% range with remote players on)
  2) 20 updates per second impacting some clients
  3) TCP-only can make lag seem bad
  4) Server is currently compiled in “debug” mode

I’d appreciate any other feedback by email.  Especially if people were not able to connect with specific clients.  Please make sure to identify your client.

Darrell
darrellroot AT mac.com

> On Jul 30, 2020, at 8:57 AM, Darrell Root <darrellroot at mac.com> wrote:
> 
> What: Netrek Empire Game
> When: Thursday July 30th @ 6PM Pacific / 9PM Eastern (Today!)
> Where: netrek.networkmom.net <http://netrek.networkmom.net/>
> 
> Backup server in case of instability: pickled.netrek.org <http://pickled.netrek.org/> (Bronco)
> 
> Netrek Empire mode:
> 
> Uses standard Bronco clients
> All 4 teams active
> Sufficient robots for minimum of 28 players (robots logoff as humans join)
> When you join, you are randomly assigned a “home planet”
> You spawn on whatever team controls the planet
> If you want to refit ships, you need to do it at your individually assigned home planet.
> When one empire controls 75% of the planets, they win.
> 
> As an empire gains planets, it gets more ships/players.  But it might be possible for the 3 other empires to stop a large empire from becoming dominant.
> Due to the random assignment of players to planets, there is no guarantee that teams will start out even.
> 
> 
> Windows issue:
> 
> Had a user running a Windows client last night who suffered client crashes every ~10 minutes.  I’d love to hear whether other Windows users also suffer that problem.  A stacktrace identifying the type of netrek packet which triggers the crash would be very helpful.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20200730/ee61247c/attachment.htm>

From darrellroot at mac.com  Fri Jul 31 14:47:28 2020
From: darrellroot at mac.com (Darrell Root)
Date: Fri, 31 Jul 2020 12:47:28 -0700
Subject: [netrek-dev] Netrek Empire humor of the day
Message-ID: <B3BF9A61-1EA7-448E-8139-1838AD74AACA@mac.com>


Someone figured out that if they captured the 28 planets that were “homeworlds” for the bots, they could have all the bots on one team without genociding the galaxy (30 planet threshold), resulting in a huge fleet pursuing my ship.

Reminds me of the ST TNG episode with Riker from the alternate “Borg won” universe.   “The Borg are everywhere!   I’m not going back!”

;-)

Darrell

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20200731/d9b3e774/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2020-07-31 at 12.45.03 PM.png
Type: image/png
Size: 258202 bytes
Desc: not available
URL: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20200731/d9b3e774/attachment-0001.png>

From darrellroot at mac.com  Fri Jul 31 14:37:17 2020
From: darrellroot at mac.com (Darrell Root)
Date: Fri, 31 Jul 2020 12:37:17 -0700
Subject: [netrek-dev] Netrek Empire humor of the day
Message-ID: <C5855E11-A5AC-4DB6-A850-23473DA65AA0@mac.com>


Someone figured out that if they captured the 28 planets that were “homeworlds” for the bots, they could have all the bots on one team without genociding the galaxy, resulting in a huge fleet pursuing my ship.

Reminds me of the ST TNG episode with Riker from the alternate “Borg won” universe.   “The Borg are everywhere!   I’m not going back!”

;-)

Darrell


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20200731/121541e3/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2020-07-31 at 12.32.45 PM.png
Type: image/png
Size: 1451240 bytes
Desc: not available
URL: <http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20200731/121541e3/attachment-0001.png>