[Freeciv-Dev] [bug #14118] wish: AI treaties with allies proposed last
URL: http://gna.org/bugs/?14118 Summary: wish: AI treaties with allies proposed last Project: Freeciv Submitted by: kudra Submitted on: Thursday 08/13/2009 at 11:28 Category: ai Severity: 1 - Wish Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: With 2.1 the following can happen before the user gains control for the turn: (1) your ally proposes an exchange, (2) you meet your ally's ally and instantly go to war; your ally cancels the treaty, (3) your ally's ally proposes a ceasefire. In this situation, you cannot conclude the treaty with your former ally. I've also found that sometimes, you cannot conclude the ceasefire either, but need to close both proposals and then initiate your own cease-fire proposal. The only way the ally's proposal will ever be possible to conclude is if you conclude a cease-fire, then propose a new alliance, and then return to the original treaty--but I've found this often doesn't work. One partial solution would be for the ally's proposal to be the last action taken before control is given to the user, so that it will be made in light of any other diplomatic actions taken in the turn. In the situation described above, this means that the ally simply wouldn't make the proposal at all. However, it's also possible for the player to gain control, then move and discover another player, before addressing the outstanding treaties. I would expect the AI to then cancel any treaties which it proposed but is no longer willing to agree with, or else to modify them (by adding a proposal of alliance to the top) to make them acceptable. This is the only situation I can think of where the AI proposes a treaty and then doesn't want to conclude it, so there's not really much reason to leave it open for negotiations. ___ Reply to this item at: http://gna.org/bugs/?14118 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1188] proposed menu and command key revamp
Follow-up Comment #16, patch #1188 (project freeciv): I use the new menu structure. It is a little bit strange first - I expect tax setting in the game menu. I can understand the initial confusion. I'd agree to an extent, since I myself am still not sure this is the most optimal structure - but I think some of the strange feeling comes from previous experience (Tax Rates were in Edit previously, also not optimal). The idea is to separate actions that affect the game structure (i.e. preferences, etc.) and the game in progress (city list, tax rates, etc). Hence, your civilization (the overarching condition of the collection of cities, etc). I laid out my reasons much better before, but I also would like to repeat that if this set of patches are accepted, they'd be the basis for future evolution rather than the end-all be-all. Which would include integrating feedback from users like that. One message I get: Can't set sensitivity for non-existent menu main/Civilization/Tax Rates. It is repeated quit often for the client OK, I'll take a look into that and make a revised patch. I was going to make one other revision to bring it in line with the patches I submitted for other clients anyway. ___ Reply to this item at: http://gna.org/patch/?1188 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1188] proposed menu and command key revamp
Follow-up Comment #17, patch #1188 (project freeciv): I use the new menu structure. It is a little bit strange first - I expect tax setting in the game menu. Speaking of my incorporating feedback, I'd definitely like to take the opportunity to learn your other feelings. This first round was very focused on the unit selection and manipulation (and hopefully that shows up well :-) ). So I'm curious to hear if there were problems, suggestions, etc for those. Or anything else - user testing is iterative, and it's always good to hear feedback even if it's only testing on a small group... :-) (Note that there is one additional patch that I need to make for drop paratrooper/clean pollution, but I was waiting to do that until I had a better feeling of whether this patch would be accepted. I'm at least feeling hopeful, so I'll add that one as well this weekend.) ___ Reply to this item at: http://gna.org/patch/?1188 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #14122] Civclient Crash
URL: http://gna.org/bugs/?14122 Summary: Civclient Crash Project: Freeciv Submitted by: None Submitted on: Thursday 08/13/2009 at 19:36 CEST Category: client-gtk-2.0 Severity: 4 - Important Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: v. 2.1.9 attached is large bug report generated by gnome (too large to post here) ** Gtk **: gtk_tree_view_set_cursor_on_cell: assertion `tree_view-priv-tree != NULL' failed civclient: city.c:553: city_owner: Assertion `((void *)0) != pcity ((void *)0) != pcity-owner' failed. ___ File Attachments: --- Date: Thursday 08/13/2009 at 19:36 CEST Name: civclient-bugreport.txt Size: 343kB By: None http://gna.org/bugs/download.php?file_id=6442 ___ Reply to this item at: http://gna.org/bugs/?14122 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #13946] Wish: Ability to escort units automatically
Follow-up Comment #4, bug #13946 (project freeciv): Ann, I think you've hit upon the can of worms that may have prevented this feature coming to fruition yet. I see these as separate concerns that might be addressable the same way, but let's identify them, because I think the best solution could turn out to be separate ones: 1. Escort weak units. (my top priority) In this situation, a chain is overkill and inappropriate. I merely want to do something like assign a musketeer to each worker in a war zone so I don't get 43 automated workers butchered because they keep getting sniped by weak units. 2. Send groups of units (armies, fleets, squadrons) places together as if they were one unit. (also important to me) With this ability, you could have an offensive group, a defensive group, and a fort-building group, and have only three groups to move for a fully decked out, well-defended strike force, for example. Move your alpine troops to Point X and fortify them. Move your Cannons to Point X, confident that their defense is better than 1. ...and that's for when you're feeling fancy. Once you get enough military momentum, you can just barrel over the globe with offensive units. Again, I don't think chains are necessary here. I think we really just want to group some units and move the group as if it were a unit. I think your suggested restriction of same-medium units is very appropriate in both cases, of course. Weird Worlds: Return to Infinite Space, another favorite game, makes use of escort during combat, and it allows you to chain them. The practical application of it is not really to escort a unit as much as it is to manage a formation. The default is that the fleet has a leader, and everyone else escorts that leader; however, units faster than the leader match the leader's speed, and slower units just fall behind. Sometimes you want to split the formation into smaller formations, and that works just fine. Chaining is rarely (if ever) useful, but it's sometimes fun. Due to the placement of most ships' firing arcs, a fluid chain of ships is simply less effective in most situations Nonetheless, I will have to see how they chose to deal with the user trying to set the leader of the convoy to escort the trailer. (Some research is very fun - hee hee.) Thank you for keeping this discussion interesting! I look forward to this leading to another very cool feature or two appearing in the fabulous Freeciv! ___ Reply to this item at: http://gna.org/bugs/?13946 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] Scriptable client
Although I made a brief wiki post at http://freeciv.wikia.com/wiki/User_talk:Cazfi, I figured it'd be best to post more here. I would like to be able to run scripts on the client. It would allow a user controlled auto-settler, explore, patrol(and improve to do something more than just move), and more and take some of the burden off of the server. Part of the inspiration is managing a large army of units, such as when winning the giant earth map. I'd like a miniature AI, or General, to do the attacking an conquering for me, and perhaps another AI for defense(and auto attack). All that would really need to be done is add lua(or anything) to the client to allow scripting, an ability to add units and cities to groups, and some user IO method, even a kludgy one. With what I've seen in the server scripting capabilities, there's sufficient back work to overcome the initial hurdles. But here's what's probably the best part, with enough development, and switching the server-ai code to the script(at least temporarily), it'd be possible to run 8 different AI's with different code and different preferences on one server to test superiority, and superiority on different map types so code could be added to make the AI as hard as possible for each map. If people are using the General idea enough and tweaking it enough for their liking it could make the AI better than what's currently used. Here's some of my idea. Player AI: Manages cities and improvements, orders the AI's, switching unit's between itself and the attack and defense AI's May split an AI into two if the forces are large enough, and for defense, if there's enough of a split to prevent ferrying units across wide area's that would make the transport's vulnerable Attack AI: Instructed to attack a city/continent/player and how determined to attack(kamikaze to near guaranteed success) based on some want level May attack just to conquer, or attack to weaken the enemy for a later invasion May ask the player for a delay if it would prefer or need time for units such as transports, or to group units better, but of course can be overridden Only really cares about patrolling/conquering so assumes the player knows the rest Defense AI: Protects designated cities, moves units around based on apparent threat(how many enemy units have been spotted recently, how close to border, etc) Attack incoming enemy units(submarines and stealth bombers are great for this). An AI may ignore a new order if the 'want' of the new order is low enough compared to a previous order to allow the AI a little more ability to follow through on it's actions. Also, if the militaristic units are split off from the player and managed as such, the AI may commit more units(like every unit the attack AI has) for a particular attack instead of petty skirmishes. This combined with the attack and defense being client side and scriptable(so faster and easier to edit, and more likely to be tweaked by various poeple), could make the AI far stronger than it is now, so that perhaps there could just be games of seeing who's made the strongest AI. And by being client sided easier to directly compare different AI strength's. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
