[Freeciv-Dev] (PR#40202) RFC: Command parsing
http://bugs.freeciv.org/Ticket/Display.html?id=40202 > At the start of handle_stdin_input, parse the inputline into a vector of dynamically allocated strings (or I suppose there could be constants MAX_LEN_ARGUMENT and MAX_NUM_ARGUMENTS for auto arrays...). The first element of the vector gives the command name; in case of a comment or empty line, the vector is empty. If the command name start with "/", it should be removed. All elements of the vector are parsed assuming that they may be quoted, and internal quotes must be escaped. Unquoted arguments are separated by whitespace; quoted arguments need not be. Examples (quote character is "'"): Inputline: "# blah blah" Vector: (empty) Inputline: "/" Vector: [0]="" Inputline: " /start " Vector: [0]="start" Inputline: "set timeo 56 # a comment" Vector: [0]="set" [1]="timeo" [2]="56" Inputline: "metam 'some message'" Vector: [0]="metam" [1]="some message" Inputline: "/wall 'internal \'quotes\''" Vector: [0]="wall" [1]="internal 'quotes'" Inputline: "/take 'foo' 'bar baz'" Vector: [0]="take" [1]="foo" [2]="bar baz" Inputline: "'/quit'" Vector: [0]="quit" Inputline: "/'debug'" Vector: [0]="" [1]="debug" Inputline: "''a'b'''c''" Vector: [0]="" [1]="a" [2]="b" [3]="" [4]="c" [5]="" Inputline: "'" Vector: NULL (i.e. parse/syntax error: unterminated quote) So a possible function signature could be: string_vector *parse_inputline(const char *inputline, char *errbuf, int errbuflen); where errbuf could be used to give a helpful description and explanation of any error encountered. Now when the full command name is looked up, the first argument is replaced by it. Similarly, the *_command functions should replace partial arguments with the full strings. So for example [0]="se" [1]="timeo" [2]="120" becomes [0]="set" [1]="timeout" [2]="120" so that when the command line is echoed back or presented in a vote, it is clear what is happening. Thus commands would need to changed to something like bool foo_command(string_vector *args, bool check); though perhaps some care would need to be taken not to re- replace arguments needlessly the second time around (i.e. when check is FALSE)... -- ちょっと面倒くさい事です。しかし、誰もしなければいけません ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40167) Client crash on scenario load
http://bugs.freeciv.org/Ticket/Display.html?id=40167 > On 10/04/2008, Ulrik Sverdrup wrote: > data/scenario/hagworld-120x60-v1.2.sav:server_state=2 This means that hargworld is not scenario at all (in the Freeciv internal terminology) > That is about as much of a clue I have. It seems this issue is pretty tricky I think there's several bugs involved. All players being set under AI is no way restricted to scenario games. Not sending enough information for detached players is second problem. It seems that main bug here is that (correct) rulesets are not sent when loading scenario game. Sending of rulesets was recently reduced, and I'm afraid it took away some necessary sends: 1. Long time ago rulesets were loaded and sent when game started. At this point we know which rulesets game is going to use, so we can send *correct* rulesets. 2. At some point another ruleset loading was added to server start and rulesets were sent to client when they connect. I'm not aware of the exact reasons for this change. Presumably there was some problems when server/client had no rulesets at all. This uses default ruleset, which often is correct one but not always. I call these rulesets *dummies* 3. It seems that recent change took away sending of the *correct* rulesets (When that change was discussed, I assumed it would take away sending of the dummies) - ML ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] I'll be away from my development machine
I'll be away from my Freeciv development machine several days. I'll try to read email and look (but not test) some of the recent patches. - ML ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39614) client connection list in start page
http://bugs.freeciv.org/Ticket/Display.html?id=39614 > On 09/04/2008, Pepeto _ wrote: > Agreed, that's why I was asking. So maybe an other ticket would be needed? #40202 > Isn't the first patch of this ticket a good first step? It's adding tokenization separately for several commands. I don't see how such code duplication in middle-layer would work toward single high-level tokenization. Current lowlevel implementation at least avoids duplicate code. - ML ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40202) RFC: Command parsing
http://bugs.freeciv.org/Ticket/Display.html?id=40202 > Related to discussions in a couple of other tickets, I'm creating separate ticket for rewriting command parsing / handling. Command lines should be tokenized before handle_stdin_input() calls command -specific functions. Token lists can then be passed to these command-specific functions. This would make user interface more uniform. Quotes would work around any parameter (user is not expected to know which seemingly arbitrary commands and parameters support it) It would also reduce duplicate code as tokenization would be in one place only, and not separately for each command. - ML ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40167) Client crash on scenario load
http://bugs.freeciv.org/Ticket/Display.html?id=40167 > Hello Marko and Pepeto Ticket #40083 seems to have more info http://bugs.freeciv.org/Ticket/Display.html?id=40083 Even though it curiously predates the server-side fix? I can at least reproduce the backtrace there with curren trunk. When it crashes, the server is still up, so you can connect back to it and it won't crash. There you'll see that every single player is set to AI, that's why the explorer moves as soon as the game starts. The linked ticket also gives another clue: hagworld aka earth medium/classic won't crash but all the others do. The reason is of course that hagworld is in a different "format", just grep server_state in the scenarios: data/scenario/british-isles-85x80-v2.80.sav:server_state=0 data/scenario/earth-160x90-v2.sav:server_state=0 data/scenario/earth-80x50-v2.sav:server_state=0 data/scenario/europe-200x100-v2.sav:server_state=0 data/scenario/hagworld-120x60-v1.2.sav:server_state=2 data/scenario/iberian-peninsula-136x100-v1.0.sav:server_state=0 data/scenario/tutorial.sav:server_state=0 That is about as much of a clue I have. It seems this issue is pretty tricky Regards Ulrik ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39821) Global Lists Bug... Can't Add to top of list?
http://bugs.freeciv.org/Ticket/Display.html?id=39821 >
The worklist editor assumes that if ptr->pcity is NULL, you can't edit
the worklist. This reverses that to allow the global worklist editor
to enable all buttons.
The original reporter only mentions the prepend button but the append
button should also have been affected.
Attached simple patches to trunk and 21 branches that fix this by
modifying the sensitivity check.
Old check:
client can issue commands AND pcity not NULL AND player owns pcity
New check
client can issue commands AND ( (pcity not NULL AND player owns pcity)
OR pcity is NULL)
The "extra" null check is so that we don't get a crash on looking up
an owner for city NULL, of course.
Can someone test this? I can't find any other case than the global
worklist editor where pcity is NULL.
Ulrik
>From 32957c4d9520d8363ae891c18b9bb4fe7427586a Mon Sep 17 00:00:00 2001
From: Ulrik Sverdrup <[EMAIL PROTECTED]>
Date: Thu, 10 Apr 2008 17:41:50 +0200
Subject: [PATCH] (PR#39821) Global Lists Bug... Can't Add to top of list?
The global worklist editor would not allow the < buttons (prepend and
append) to become sensitive, since ptr->pcity is NULL for global
worklits. This fixes that case.
This is a patch for S2_1 branch
---
client/gui-gtk-2.0/wldlg.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/client/gui-gtk-2.0/wldlg.c b/client/gui-gtk-2.0/wldlg.c
index 29cccdc..4b4d133 100644
--- a/client/gui-gtk-2.0/wldlg.c
+++ b/client/gui-gtk-2.0/wldlg.c
@@ -898,7 +898,9 @@ static void src_selection_callback(GtkTreeSelection *selection, gpointer data)
/* update widget sensitivity. */
if (gtk_tree_selection_get_selected(selection, NULL, NULL)) {
if (can_client_issue_orders()
- && ptr->pcity && city_owner(ptr->pcity) == game.player_ptr) {
+ && ( (ptr->pcity && city_owner(ptr->pcity) == game.player_ptr)
+ || !ptr->pcity )) {
+ /* if ptr->pcity is NULL, this is a global worklist */
gtk_widget_set_sensitive(ptr->change_cmd, TRUE);
gtk_widget_set_sensitive(ptr->prepend_cmd, TRUE);
gtk_widget_set_sensitive(ptr->append_cmd, TRUE);
--
1.5.4.4
>From 425efab7beb72aec45daccad3ac03f1ddf20c110 Mon Sep 17 00:00:00 2001
From: Ulrik Sverdrup <[EMAIL PROTECTED]>
Date: Thu, 10 Apr 2008 17:41:50 +0200
Subject: [PATCH] (PR#39821) Global Lists Bug... Can't Add to top of list?
The global worklist editor would not allow the < buttons (prepend and
append) to become sensitive, since ptr->pcity is NULL for global
worklits. This fixes that case.
---
client/gui-gtk-2.0/wldlg.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/client/gui-gtk-2.0/wldlg.c b/client/gui-gtk-2.0/wldlg.c
index a3373d1..6f39638 100644
--- a/client/gui-gtk-2.0/wldlg.c
+++ b/client/gui-gtk-2.0/wldlg.c
@@ -873,7 +873,9 @@ static void src_selection_callback(GtkTreeSelection *selection, gpointer data)
/* update widget sensitivity. */
if (gtk_tree_selection_get_selected(selection, NULL, NULL)) {
if (can_client_issue_orders()
- && ptr->pcity && city_owner(ptr->pcity) == client.conn.playing) {
+ && ( (ptr->pcity && city_owner(ptr->pcity) == client.conn.playing)
+ || !ptr->pcity )) {
+ /* if ptr->pcity is NULL, this is a global worklist */
gtk_widget_set_sensitive(ptr->change_cmd, TRUE);
gtk_widget_set_sensitive(ptr->prepend_cmd, TRUE);
gtk_widget_set_sensitive(ptr->append_cmd, TRUE);
--
1.5.4.4
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40138) Assert in exchange of city in v 2.1.3
http://bugs.freeciv.org/Ticket/Display.html?id=40138 > Was this crash fixed by ticket #40185: [Patch] Fix AI crash when city destroyed during trade negotiation ? http://bugs.freeciv.org/Ticket/Display.html?id=40185 ulrik ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39938) paratroopers disappear
http://bugs.freeciv.org/Ticket/Display.html?id=39938 >
Trivial patch looks like this. Tested on trunk but is probably
harmless on any branch, including 2.1
ulrik
>From c8c28d54c5e6fa266a045a6cf78555abc54ec036 Mon Sep 17 00:00:00 2001
From: Ulrik Sverdrup <[EMAIL PROTECTED]>
Date: Thu, 10 Apr 2008 16:15:42 +0200
Subject: [PATCH] (PR#39938) paratroopers 'disapear' when dropped on protected city
Make sure the "paratroopers killed when dropped on city"-message is
displayed by default, by changing its message category to
Unit: Defender destroyed (E_UNIT_LOST), just like paradrops into the
ocean.
---
server/unittools.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/server/unittools.c b/server/unittools.c
index 1ac2fdf..cd5ad7a 100644
--- a/server/unittools.c
+++ b/server/unittools.c
@@ -2199,7 +2199,7 @@ bool do_paradrop(struct unit *punit, struct tile *ptile)
|| is_non_allied_unit_tile(ptile, pplayer)) {
map_show_circle(pplayer, ptile, unit_type(punit)->vision_radius_sq);
maybe_make_contact(ptile, pplayer);
-notify_player(pplayer, ptile, E_UNIT_LOST_ATT,
+notify_player(pplayer, ptile, E_UNIT_LOST,
_("Your %s was killed by enemy units at the "
"paradrop destination."),
unit_name_translation(punit));
--
1.5.4.4
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40201) #39938 : Paratroopers disappear
http://bugs.freeciv.org/Ticket/Display.html?id=40201 > There is a message, but this bug is due to that message being turned off by default. When a paratrooper is killed at its destination, a message of type Unit: Attack failed is sent, which is turned off by default. However, paradropping into the ocean (due to unnoticed terraforming), sends a message of type Unit: Defender destroyed, which is shown by default. Notice that these categories only affect the filtering and not the actual content of the messages. One easy solution is to use Unit: Defender destroyed (called E_UNIT_LOST in the code) for the KIA case as well. Otherwise we could create a new paratrooper category, or turn on more messages by default. Ulrik ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
