Client : need a shortcut Key_E for connect_maglev
alain_bkr Agreed. I also maybe missed something and find it painful.
Maglev is a ruleset defined Road type, and currently rulesets have no way to assign/reserve keys. That's a long standing issue.
In S3_1 & master Shift+M is taken for Plant activity (As 'm' is for Mine, and Plant is related).
alain_bkr I don't really care for the letter's choice, P M or Whatever , short cut could also be SHIFT+CTRL+...
For the fun, I m trying to write this patch , and duplicate connect_railways , but i understand mostly nothing as you may notice :-) Nothing happens (it compiles and run as before)
There are comment about compatibily ROad COmpat (ROCO_RAILROAD ...)
Any advice, hint or comment is welcome.
alain_bkr Reply To alain_bkr
Nothing happens (it compiles and run as before)
Have you also updated your ruleset so that some road type is marked as being compatibility version of Maglev special (that's what compat_special is supposed to mean; compatibility with older freeciv version where the road types were specials)?
alain_bkr 1/ CTRL V is available , V for magleV
2/ Reply To cazfi
Reply To alain_bkr
Nothing happens (it compiles and run as before)
Have you also updated your ruleset so that some road type is marked as being compatibility version of Maglev special (that's what compat_special is supposed to mean; compatibility with older freeciv version where the road types were specials)? "
In ruleset.c i copy/pasted a bloc and substituted rail for maglev I did not touch any*.ruleset , only .c
3/ I found that the callback is not reached when the keys are pressed (but it is ok for for road or rail).
in menu.c
static void connect_rail_callback(GtkMenuItem *action, gpointer data) Rail is OK
static void connect_maglev_callback(GtkMenuItem *action, gpointer data) We never get here
4/ I added an entry in the Work menu, and it shown disabled, in light-grey so i cannot test like this.
alain_bkr Reply To alain_bkr
I did not touch any*.ruleset , only .c
So you have no road type for which this would apply.
alain_bkr alain_bkr alain_bkr I don't understand what i should do to *.ruleset or anything else. maglev is already defined in civ2civ3/terrain.ruleset
I don't get how GUI_gkt3.22 works, and how KEY_E should call the callback i added.
alain_bkr Reply To alain_bkr
I don't understand what i should do to *.ruleset or anything else. maglev is already defined in civ2civ3/terrain.ruleset
alain_bkr ok, thanks, i missed this.
A patch, for gtk_3.22 , with Key_E for connect_maglev , and an entry in the menu "Work"
It works for me, either on a fresh land or one with mixed nothing/road/rails.
It seems the save/load can handle this without problem , i used a previous game for the tests.
alain_bkr alain_bkr Your patch applies, compiles and works sweetly. I see why you couldn't use shift-E (airbases). It even has a menu entry and control help (E). And maglev waypoints work too. Cool! One thing it's missing is two more lines of text in Help->Controls.
I'm definitely switching back to gtk client when I've got large maglev instructions to issue - which is now in this current game. Any plans to port your code to qt and sdl2 clients?
Word of warning: While the patch should be fine for anyone's private use, it's unlikely to make it to official freeciv distribution. It's extending backward compatibility hack we should be getting rid of instead, to something where it's not even about backward compatibility any more. It's specific to some rulesets with specific road type (it handles Maglev in some rulesets, but what about Canals and Highways seen in some of the existing rulesets, not to mention several alien ruleset road types, or any other road types in any potential rulesets?)
That said, we have a real issue to solve, and if we can't get come up with any proper solution (ruleset specific keys development has been on hold for years), we may need to compromise and adopt solution a bit like this.
Reply To cazfi
it's unlikely to make it to official freeciv distribution.
Such a shame. Now it's painful building maglevs a tile-at-a-time, again. I shouldn't have tried that patch.
alain_bkr Just a word to refresh the ticket.
What is needed ?
Is it possible to have one solution for 3.0 (= the patch) and another solution for 3.1 and later ?
Reply To alain_bkr
What is needed ?
An idea how to do that properly would be a good start.
I should find some jtn's old draft patches about generic / customizable keybindings for an inspiration.
Well, making some decisions about this is really urgent at the moment. We've just entered S3_1 semi-d3f, and about any solution to this would require adding something to ruleset format.
- I dislike proposed patch in that it just adds bandaid for one road type and not overall solution for all of them, is extending a concept that we should be deprecating instead, and is likely to cause problems (how to migrate away from it) in the future
- However, that one road type is more important in current real-life rulesets (even in supplied ones) than any other one suffering from the same problem, so having special support for it would make sense
- We're certainly not getting any better solution in time to 3.1 (as we are in semi-d3f, one could say that deadline was last week), so it's either we take this solution or leave the problem in to freeciv-3.1
- Taking it in at this point would require reopening semi-d3f. Alpha3 is not yet out, so we have not yet published current formats as the d3f proposal. Some test runs towards alpha3 have been running already, and those may need to be rerun if we do the change
So, yeah, I'm at least preparing for the chance that we take it to S3_1 (will make a bit more in-depth review of the patch during this weekend)
Investigating it more, my dislike about adding something that's neither former special, nor has anything to do with comp)atibility with then, to "compat_special" list has only increased.
So I'm for making a bit bigger change after all, though I'm not sure if this new plan is future-proof either. Add new gui_type (base types already have similar concept) field for roads -> #44539
Reply To cazfi
Add new gui_type (base types already have similar concept) field for roads -> #44539
So now that ruleset change is in (so d3f is not blocked any more), but client functionality to handle the new "Maglev" gui_type (this ticket) has not been added. Parts of the existing patch are likely still usable for this implementation.
Reply To alain_bkr
A patch
Can you rework this to use the new road gui_type? The "Maglev" value for it already exist, so only the client part should be needed.
It would be nice to have this implemented and tested before S3_1-d3f, so that we see that the the ruleset format part used has no issues.
About the key selection: #45797
Key selection ticket that is direct dependency for this functionality: #45800
Attached patch implements this with <ctrl>m for gtk3.22-client, qt-client, and in case of S3_1 also for gtk3-client.
3.0.beta1 , client gtk3.22
Maybe i missed something, but it seems that maglev must be done one by one (each turn give the order to an ingeneer on a new tile) , which is very painful.
i expected shift-M to do maglev path (like shift-R for Roads, or shift-L for rails )
Edited: