|
|
| (3 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| − | == Feature Requests ==
| |
| | | | |
| − | * Path finder, something like: wesnoth.find_path(loc1, loc2), and it would return a list of all locations in between, or just the first step.. whatever the C++ API has
| |
| − | :Gonna wrap a_star_search (in pathfind.hpp) [[User:Ryo|Ryo]] 19:44, 8 December 2005 (CET)
| |
| − | :Actually it's gonna be unit.find_path() since it depends on a unit. [[User:Ryo|Ryo]] 19:53, 8 December 2005 (CET)
| |
| − | :Done, experimental though :) [[User:Ryo|Ryo]] 20:09, 8 December 2005 (CET)
| |
| − |
| |
| − | * Persistent variables. Right now, the script state isn't reset, so all variables are already persistent. But for the final version, there should be real persistent variables, which can also be stored to WML, and reloaded. An AI would use it to e.g. store a path, or some other state.
| |
| − | :Probably with the Object -> String Python conversion. Will look at that [[User:Ryo|Ryo]] 19:44, 8 December 2005 (CET)
| |
| − |
| |
| − | * Something like wesnoth.get_possible_moves(loc) - it would return all possible moves for the unit at the given location. It seems, right now, I make a lot of mistakes because the info of wesnoth.get_src_dst or wesnoth.get_units gets outdated after I move a unit. (Not really sure about this one, better planning out of the algorithm might make this function un-necessary.)
| |
| − | :Yes, you need to grab again the array after moving. What happens is that you get a "snapshot" copy, which isn't updated when you move a unit - thus your "obsolete" copy can contain now invalid destinations. I'm not sure of a fix for that apart getting again the array. [[User:Ryo|Ryo]] 19:44, 8 December 2005 (CET)
| |
| − |
| |
| − | * Having access to the properties 'HP' and 'Poisonned' of a unit. [[User:Viorc|Viorc]]
| |
| − |
| |
| − | :added ''hitpoints'', ''max_hitpoints'' and ''poisoned'', thanks for the patch :)
| |
| − | :[[User:Ryo|Ryo]] 22:22, 2 March 2006 (CET)
| |
| − |
| |
| − | == chance to kill ==
| |
| − |
| |
| − | Can I get a chance_to_kill(wesnoth.location)? And it would tell me the chance to kill the unit at the given location, using terrain modifiers and everything.. I assume, the C++ AI has something like it available. [[User:Allefant|Allefant]] 22:39, 10 January 2006 (CET)
| |
| − |
| |
| − | :I'll check what the C++ has, and export it. [[User:Ryo|Ryo]] 09:24, 11 January 2006 (CET)
| |
| − |
| |
| − | :Ok, there is a structure/function associated, <code>attack_analysis</code>. Gonna try to export it, but may be a mess :)
| |
| − | :[[User:Ryo|Ryo]] 11:29, 15 January 2006 (CET)
| |
| − |
| |
| − | == usage pattern ==
| |
| − |
| |
| − | I'm not sure it would be really useful, since a good AI would probably derive the usage of a unit out of its properties - but maybe there could be a way to query the usage pattern of a unit? Like "scout" or "fighter".. --[[User:Allefant|Allefant]] 22:35, 13 January 2006 (CET)
| |
| − |
| |
| − | == minor API cleanup ==
| |
| − |
| |
| − | * properties or methods? E.g. why '''wesnoth.unit.type()''' but '''wesnoth.unit.name'''? Same or wesnoth.get_map() or wesnoth.get_gamestatus(), and others.. The rule behind it is not clear. One way could be, make everything that can change inside a turn a method, everything else a property. Or just make everything methods/properties, since it doesn't seem to matter much in the Python-C-API..
| |
| − |
| |
| − | * '''unit.movement_cost''' - why does it need the wesnoth.gamemap parameter? Since you don't have a lot of choice what to pass there (or do I have it? could i modify the map returned by get_map?), I think the parameter could go. Same for defense_modifier.
| |
| − |
| |
| − | * '''unit.movement_left''' - it seems that this data is not present in 'unit' interface. It should either be added or removed from ReferencePythonAPI (but could be useful later).
| |
| − |
| |
| − | * '''wesnoth.attack_unit(attacker,defender,weapon)''' - how can we related the integer weapon with a attack as the one retrieved from unit.attacks() ? Couldn't we use this attack_type as parameter of attack_unit function ?
| |
| − |
| |
| − | :You're right, property/method should be coherent. I'll do:
| |
| − | :*property => simple type, no argument
| |
| − | :*method => complex type or argument
| |
| − | :For the gamemap, I'm not sure, I merely mapped the function :) But I'll change the API to not use map anymore and use current one.
| |
| − | :movement_left does indeed exist in unit.
| |
| − | :Attack weapon is the index of the weapon in the list from attacks( ).
| |
| − | :[[User:Ryo|Ryo]] 22:27, 2 March 2006 (CET)
| |
| − |
| |
| − | == Cheating ==
| |
| − |
| |
| − | Should the Python AI be allowed to cheat? I'd like if it couldn't,
| |
| − | since then I could concentrate on the strategy in the AI script I'm
| |
| − | playing with, and wouldn't need to check for violated rules myself.
| |
| − | (So far, my AI attacks multiple times with one unit, and also moves
| |
| − | after capturing villages or attacking..)
| |
| − |
| |
| − | OTOH, if the Python AI is meant to later allow scenario scripting,
| |
| − | it probably will be wanted to just modify things. But I think, that
| |
| − | could be done with an alternate API. Something like:
| |
| − | wesnoth.remove_unit(), wesnoth.place_unit().. and the current ones
| |
| − | still could have anti-cheat checks.
| |
| − |
| |
| − | :I don't think AI should be able to cheat. AI is like a player (ok, maybe no fog of war, but still, unit moves should be legal).
| |
| − | :I'll check how to enforce the same rules than for players.
| |
| − | :[[User:Ryo|Ryo]] 22:29, 2 March 2006 (CET)
| |
| − |
| |
| − | == Information Requests ==
| |
| − |
| |
| − | * How to get new versions of the API ?
| |
| − | : I have figured out that it is in the "trunk" branch not available through viewcvs. --[[User:Viorc|Viorc]] 03:51, 15 March 2006 (CET)
| |
| − |
| |
| − | * I have created a page [[GetDestinationsByUnitQuestion]] where I describe a question I am having on the function wesnoth.get_destinations_by_units(). Could you check and help me find an explanation to the observed behaviour. Thanks. --[[User:Viorc|Viorc]] 04:03, 14 March 2006 (CET)
| |
| − | : It seems there is already a fix around this function in the svn version. I will try to move to it to check if this problem is still relevant. --[[User:Viorc|Viorc]] 03:55, 15 March 2006 (CET)
| |
| − |
| |
| − | == How would you pit two different Python AIs against each other? ==
| |
| − |
| |
| − | Like the subject line says. Or is this limited to one Python AI at a time? :( --[[User:Irrevenant|Irrevenant]] 09:54, 15 May 2006 (CEST)
| |