peer-to-peer relay server

[JoshPettus]

I remember another program a few years ago, I used to play with my cousin, that did the same job, but this is a lot better. And it's nice to have it for osx and linux too!

[hgm]

Seems to work great on my network with direct ip. Although, I was using v .3 on a windows computer and so couldn't test the relay system, but I assume it works.

You should be able to test the relay system if you let the 0.5 version connect first. (Because the first one is the only one that would have to wait; the second one would never see any difference, as it is immediately wired through.) I am not even sure that it would not work with 0.3 on both ends. It is just that 0.5 is aware that it should wait, and warns the user for it with a popup.

Of course for Chess something like this is hardly needed, as one can use FICS. But the big thing is that you can use it for any variant, even for variants that you define yourself, making use of XBoard 4.8's engine-defined-variants concept. E.g. if you would make a file custom.dat in the p2p folder that contains

Code: Select all

setup (PNBRQ..C.WKpnbrq..c.wk) 12x12+0_elven w**********w/*crnbqkbnrc*/*pppppppppp*/*10*/*10*/*10*/*10*/*10*/*10*/*PPPPPPPPPP*/*CRNBQKBNR*/W**********W w KQkq - 0 1
piece P& fmWfceFifmW3
piece C& WAD
piece W& FC

and select variant 'custom' from the New Variant menu, you can use it to play Omega Chess!

[JoshPettus]

Great, seems to work well, though .3 has to use the ip address and doesn't have custom, but I'm sure it all works. It's all fairly easy to use, but some reading should be involved and people would want to put in their own custom.dat files. Perhaps I won't put it in the .app bundle after all, but just have a separate download on the Forum Page.

Besides, people would have to remove their user config anyway or put it in themselves.

Before I go ahead with 4.8.0c, did you check my patch on the xboard-devel list?

[hgm]

No I haven't had time to check the patch yet. I will do it soon.

With 'user config' you mean the 'custom.dat' file?

[JoshPettus]

no I mean ~/Library/Preferences/xboardosx.conf

If it's already generated adding engines in the master conf inside the app won't effect it.

it was just xboard.conf but for 4.8.0 I changed the name for that very reason, as any one generated by a 4.7.3 app would be completely broken with all the rearranging we did.

[JoshPettus]

There isn't a way for the engine to modify the GUI clock is there?

It would be nice if there were some sort of timestamp in place. Especially as it can take time for the opponent to configure their machine to the settings you propose. Otherwise this is really only useful with autoflag off.

Also I wonder if there is a way we can have it so rather then the second player reconfiguring their machine to the settings proposed, if there could be an OK button and the engine will do that for them, and a No so that they can configure for the counter proposal.

[hgm]

But XBoard 4.8 should have a solution for that problem. There is a new option -installEngine, which operates on -firstChessProgramNames, but not by replacing it, but by appending it as an extra line. By including such an option in the master settings file that comes with the new install, after the point where it orders reading of the user settings file, you could add an extra line to the user's list.

There was some additional complexity, however, to prevent the line is added each time you restart XBoard, which I now have difficulty recalling. (Well, part of it was easy; it just checks if the line is already there. But I also considered it too annoying that when users don't want that engine, and delete the line, it would be immediately put back...) So it does put time-stamps in the settings file (as -date options?), and only adds the line if the -date read from the master settings file is more recent than the date it read from the user settings file (meaning it sees the -installEngine for the first time).

There even is an option -addMasterOption, that automatically adds something to the master settings file. The idea was that you could run

xboard -addMasterOption {-installEngine "xxx"} -autoClose

from an engine install script to make XBoard add the lines

-date tttttt
-installEngine "xxx"

to the end of the master settings file, so that any user that sees them for the first time (i.e. whose user settings date is older than tttttt) would get the line "xxx" added to his engine list. This way the information would trickle into all the user's settings file at its own pace.

[JoshPettus]

Oh ok! That's good to know. Maybe I'll put it in the bundle after all.

[JoshPettus]

So it should be in the master conf:

-installEngine {"Peer2Peer" -fcp "./p2p" -fd "~~/../../bin/p2p"
}
-date 061114

?
Doesn't seem to add the engine.

[hgm]

The -date should preceed the -installEngine, and it should be given in seconds since the 'epoch' (the way Unix measures time). It is not supposed to be human readable. And the closing } can be on the same line; XBoard will add the linefeed by itself.

To get an idea of how the date looks, you can look in the user settings file for the -saveDate option somewhere at the top. The best way to get the -date right is to let XBoard add the line to the master settings file itself, by calling it with the -installMasterOption option. That automatically adds the -date stamp.

The reason the -date has to come first is that after multiple engine installs the master settings file would look like

-date xxxx
-installEngine {engine1}
-date yyyy
-installEngine {engine2}
-date zzzz
-installEngine {engine3}

and as the options are processed top to bottom the -date value would be xxx at the moment the -installEngine for engine1 is processed, (and then compared to the value of -saveDate retrieved from the user settings file), etc.