Re: [Freeciv-Dev] freeciv as programming game
On Sun, Feb 24, 2008 at 1:28 AM, Philipp Hofmann [EMAIL PROTECTED] wrote: i really would like to write my own client for the game. and i very much would like to do that in my currently favorite scripting language. i guess it would be possible to use SWIG to make the client api written in c available to scripting languages like python, perl or ruby. I would recommend writing a server-side AI plugin, rather than a client-side AI. A lot of people have tried to implement a client-side AI, and no-one has succeeded. It is just a different category of difficult. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40111) Diplomatic immunity
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40111 Per I. Mathisen wrote: It is not a bug. Also, making diplomats partially invisible would upset a game balanced already tilted too much in favour of diplomats and spies as it is. Madeline didn't write that. I did. And we already know your opinion about diplomats, and the crippling code you've added to trunk. So, somebody deliberately removed the partial invisibility of diplomats? Where is this documented? Why isn't there a compatible flag in data/civ2/units.ruleset? (I was assuming poor file maintenance, not deliberate error) Definitely a bug! ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40113) civclient: player.c:293: player_number: Assertion `pplayer' failed.
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40113
Now that I've had some sleep
Madeline Book wrote:
Yes, I was afraid of something like that. So what are the
semantics of client.playing?
It is set from game.info.player_idx -- exclusively.
Is it supposed to be NULL
when the client is an observer (unlike aconnection.player
apparently) and during pregame before the user has picked
his nation and set his player name?
Had never noticed aconnection.player, and have no idea about its purpose.
Certainly, aconnection.player is a bad idea. That isn't properly updated
as players are removed (before start) -- unlike client.playing.
Yet Another Data Duplication headache.
What then is supposed
to be passed to popup_races_dialog?
Heck, you shouldn't be able to select a race before player is assigned.
Compare XAW:
if (client.playing) {
popup_races_dialog(client.playing);
}
With GTK2:
if (aconnection.player) {
popup_races_dialog(client.playing);
} else if (game.info.is_new_game) {
send_chat(/take -);
popup_races_dialog(client.playing);
}
I added the last call in PR#39927 back in December, both 2.1 and 2.2, so
that's not within the past 2 weeks:
send_chat(/take -);
+popup_races_dialog(game.player_ptr);
This aconnection.player change appeared in PR#16459, so perhaps Per can
explain:
static void pick_nation_callback(GtkWidget *w, gpointer data)
{
- if (game.player_ptr) {
+ if (aconnection.player) {
popup_races_dialog(game.player_ptr);
+ } else if (game.info.is_new_game) {
+send_chat(/take -);
}
}
For connection dialog, another call to popup_races_dialog() with another
parameter was added even earlier in PR#15688, so perhaps Jason can explain:
+static void conn_menu_nation_chosen(GtkMenuItem *menuitem, gpointer data)
+{
+ popup_races_dialog(conn_menu_player);
+}
So, a third static copy of player, always a joy to debug! :-(
Yet Another Data Duplication headache.
No, I just connected to a server running on my local
machine and tried to start the game (incidentally doing
it this way the Start button is also inactive, which
might indicate that there is some deeper problem).
Probably just sensitive to whether you've picked a Nation yet.
1. Start a server process (e.g. with ./ser in the build
directory).
2. Start a client process (e.g. with ./civ -a
in the build directory).
3. Client started in (2) connects to the server started
in (1).
Not on my setup. It hangs in some silly reverse DNS lookup, because I'm
running behind a firewall -- as all good developers always do!
Depending on a reverse DNS lookup is a bad idea, as there are many users
that run NAT with RFC-1918 addresses, and it is an unreasonable load on
(wearing another hat) our root servers.
Depending on a DNS lookup of any kind completing is a terrible idea
But that's another ticket. I'm pretty sure there's an existing one.
4. Now as the client, press the button labelled Pick Nation.
Sounds like that should be sensitive to whether you have a player yet.
5. The races (a.k.a. nations) dialog pops-up.
6. Click any nation in the list (e.g. Assyrian).
7. The button labelled Ok becomes active.
8. Press the button labelled Ok.
9. The assertion failure occurs.
A few weeks ago branch S2_2 did not experience this assertion
failure. As I was using it in this exact manner for working
on the editor.
Since it doesn't occur with the more usual New Game page, I suggest that
you try it for your Editor experiments, until this is tracked down.
Or you could try checking out earlier revisions by binary search until you
find the revision number that caused the problem
Until somebody does that, it's unlikely to be fixed.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40111) Diplomatic immunity
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40111 [per - Mon Feb 25 06:50:49 2008]: On Sun, Feb 24, 2008 at 6:46 PM, Madeline Book [EMAIL PROTECTED] wrote: This is a bug. These units should not show up until adjacent to cities, and should be completely invisible to passing units. It is not a bug. Also, making diplomats partially invisible would upset a game balanced already tilted too much in favour of diplomats and spies as it is. I concur that giving diplomatic units Partial_Invis would be unbalancing for gameplay, based on my multiplayer experience. There is no compelling reason why they should have this perk in the default ruleset. As for emulation of the other civ versions, I checked the civ1 manual and my own recall and it does not indicate that diplomats behave this way (spies do not exist in civ1). I further checked the rules.txt file for civ2 (and the manual) and it does not appear to me that spies (and certainly not diplomats) have a submarine-like invisibility (i.e. the Partial_Invis flag in freeciv or unit flag 0001000 in civ2 rules.txt parlance). But it is possible that it is hardcoded into the civ2 program and not documented anywhere that I looked. Finally I perused the civ3 manual and found that to be, in terms of diplomacy and espionage, a very different game entirely. ;) So I would conclude that diplomatic units must not have the Partial_Invis flag in the default ruleset (for gameplay balancing considerations and preserving the status quo), and neither should they have this flag in the civ1,2,3 emulation rulesets. If anyone has verifiable sources or reasonable arguments to contest these conclusions, please share. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40113) civclient: player.c:293: player_number: Assertion `pplayer' failed.
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40113
[wsimpson - Mon Feb 25 13:02:09 2008]:
Now that I've had some sleep
Madeline Book wrote:
Yes, I was afraid of something like that. So what are the
semantics of client.playing?
It is set from game.info.player_idx -- exclusively.
So I supposed it should be set for clients connecting to
a server somewhere remotely (e.g. a to play a game online).
Is it supposed to be NULL
when the client is an observer (unlike aconnection.player
apparently) and during pregame before the user has picked
his nation and set his player name?
Had never noticed aconnection.player, and have no idea about
its purpose.
I thought you were intending to use client.playing to replace
it. The question is now why prefer client.playing over
aconnection.player? Maybe adding client.playing was not
necessary to begin with (as opposed to just improving
the use of aconnection.player)?
Certainly, aconnection.player is a bad idea. That isn't
properly updated
as players are removed (before start) -- unlike client.playing.
Yet Another Data Duplication headache.
YADDH(tm). ;)
What then is supposed
to be passed to popup_races_dialog?
Heck, you shouldn't be able to select a race before
player is assigned.
What about when connecting to a remote server? Newly
connected clients should have a player. It seems that
there is just a problem in this case of client.playing
not being set to the client's player pointer.
Maybe it would be a good idea to include a multiplayer
connection scenario when testing changes to the server's
multiplayer data structures (as opposed to only testing
with AIs and the fork'd server).
Compare XAW:
if (client.playing) {
popup_races_dialog(client.playing);
}
With GTK2:
if (aconnection.player) {
popup_races_dialog(client.playing);
} else if (game.info.is_new_game) {
send_chat(/take -);
popup_races_dialog(client.playing);
}
It would seem to make more sense to change aconnection
.player to client.playing in the above (or the converse
;)). It looks like some incomplete conversion when both
occur in the code like this.
I added the last call in PR#39927 back in December, both 2.1
and 2.2, so that's not within the past 2 weeks:
send_chat(/take -);
+popup_races_dialog(game.player_ptr);
Hmm, so there it was assumed that game.player_ptr would
already be a pointer to a valid player (i.e. not NULL).
This aconnection.player change appeared in PR#16459, so perhaps
Per can
explain:
static void pick_nation_callback(GtkWidget *w, gpointer data)
{
- if (game.player_ptr) {
+ if (aconnection.player) {
popup_races_dialog(game.player_ptr);
+ } else if (game.info.is_new_game) {
+send_chat(/take -);
}
}
I agree this is a curious change. What is the intended
difference in use of aconnection.player and game.player_ptr?
Is game.player_ptr only valid after the game starts (or
more precisely after the client's player has been fixed
after final nation selection)? This would seem to imply
that client.playing is not right to be passed to
popup_races_dialog in pregame, it should be aconnection
.player. But I'm just guessing.
For connection dialog, another call to popup_races_dialog()
with another parameter was added even earlier in PR#15688,
so perhaps Jason can explain:
+static void conn_menu_nation_chosen(GtkMenuItem *menuitem,
gpointer data)
+{
+ popup_races_dialog(conn_menu_player);
+}
So, a third static copy of player, always a joy to debug! :-(
The global (static) variables are a pain; I agree a better
programming style should be used if possible (e.g. gtk
gives you a userdata pointer that you can use to pass
arbitrary data to callbacks).
No, I just connected to a server running on my local
machine and tried to start the game (incidentally doing
it this way the Start button is also inactive, which
might indicate that there is some deeper problem).
Probably just sensitive to whether you've picked a Nation yet.
But if I use the main page's Start New Game button it
is sensitive. As I understand it, pressing Start without
having picked your nation makes the server automatically
assign you a nation at random (when the game starts).
So Start should be sensitive in all player cases (i.e.
not for observers or detached connections).
1. Start a server process (e.g. with ./ser in the build
directory).
2. Start a client process (e.g. with ./civ -a
in the build directory).
3. Client started in (2) connects to the server started
in (1).
Not on my setup. It hangs in some silly reverse DNS lookup,
because I'm
running behind a firewall -- as all good developers always do!
A reverse DNS lookup for 127.0.0.1 ? ;)
But anyway I find it hard to believe you would have such trouble
running a server first and then separately running a client to
connect to it on the same machine. Perhaps you
[Freeciv-Dev] (PR#40110) tile_info worked, enum known_type, city_can_work_tile(), and invisible cities
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40110 [wsimpson - Mon Feb 25 03:32:06 2008]: Madeline Book wrote: Unfortunately for you, posting a comment about a side-effect of your patch does not imply that the person posting the comment tested your patch. But never fear, there is PR#40113. Unfortunately for all of us, posting a comment about a side-effect of a patch *DOES* imply the person has tested the patch! The policy of posting patches here is not just for the keyboard exercise Your bundled gamerule change was the only thing I was replying to as I have made clear. It is a pity that you continue to assume that I looked at your code in any detail, but if it gives you such enjoyment to continue to make this claim, who am I to correct you? ;) Moreover, PR#40113 is not reproducible on my machine(s). That's a shame. Maybe you could try a little harder? Maybe run a server one of your machines, then run a client on another machine, and have the client connect to the server and try to start a game? It is fairly complicated, but I think a freeciv user should be able to accomplish it. Hopefully, you will find the problem. I'm not sure if I am good enough! :( But I supposed I will try, for the sake of people running freeciv in a multiplayer context. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40113) civclient: player.c:293: player_number: Assertion `pplayer' failed.
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40113 [wsimpson - Mon Feb 25 22:15:57 2008]: Madeline Book wrote: So I supposed it should be set for clients connecting to a server somewhere remotely (e.g. a to play a game online). It should be set by the server and sent to the client after the client has been selected for a player slot. So in establish_new_connection in server/connecthand.c ? I thought you were intending to use client.playing to replace it. The question is now why prefer client.playing over aconnection.player? Maybe adding client.playing was not necessary to begin with (as opposed to just improving the use of aconnection.player)? Had you actually read and understood PR#39872, you would have noticed that client.playing was not *added*, it was a fairly straightforward replacement of the existing game.player_ptr, moved out of common/game.h into client/civclient.h, as the existing comments already specified it was client-only. Oh dear, you are right, I completely missed that when I was replying about the naming of client.playing in PR#39872! How unsuprisingly stupid of me. Could you also give me the PR# of the ticket where struct civclient was introduced? Previous programmers added it in the full knowledge of the existing game.player_ptr. I'm assuming it has some special purpose. I've told you the PR#s, please study them and form your own conclusions. If only I knew of some way to find the relevant PR#s (besides PR#39872)! How do you suggest I go about doing that? I am not very good yet with RT's search capabilities. Maybe you could just tell me the ones you are looking at as the basis for your claims? Or I have to grep through svn logs or search through posts to freeciv-commits? :( What about when connecting to a remote server? Newly connected clients should have a player. ... No, they should not. AFAICT, they only have a player after selecting a player, and before selecting a nation. So they are detached when they connect, is that how you see it? It doesn't look that way in establish_new_connection in server/connecthand.c. Maybe it would be a good idea to include a multiplayer connection scenario when testing changes to the server's multiplayer data structures (as opposed to only testing with AIs and the fork'd server). Why? There's no such thing as multi-player data structures, the entire game is multiplayer from the ground up. It would be good then to once in while test out remote server connection, e.g. starting a server process, then starting a separate client and connecting to it, rather than only running via Start New Game. I know this is impossible for you because of your setup (reverse DNS lookup and all that), so I leave this as a reminder to those who able to accomplish such things. It is an artifact that the connection dialog is separate (in the GTK2 client only). You are testing something only rarely used for GTK2. I don't quite understand. Are you saying that using the Connect to Network Game button (and resulting pages) to connect to a remote (or in fact local) server, or equivalently using the -a and -s options in the civclient, are rarely used? You are the person that can check out previous revisions and tell us which check-in caused the problem. Isolate the problem, don't guess. Oh sorry, I thought you would immediately know how to fix the problem (thanks to your work on the relevant code when you updated to client.playing). But I see we are both in the dark on this one. ;) It would seem to make more sense to change aconnection .player to client.playing in the above (or the converse ;)). It looks like some incomplete conversion when both occur in the code like this. And yet Per chose to split the functionality. I agree this is a curious change. What is the intended difference in use of aconnection.player and game.player_ptr? Until he tells us, we don't know his intended difference. But it was obviously deliberate. Hi Per, can you help us to understand? (I know you are reading this :. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
