[Freeciv-Dev] [bug #20544] Sea units benefitting from City Walls
Update of bug #20544 (project freeciv): Category:None = general Status:None = Ready For Test Planned Release: = 2.5.0 ___ Follow-up Comment #3: Attached patch adds unit class property non_native_def_pct, defaulting to 100%. Units defending on non-native terrain (ships in harbour in classic rulesets) get only that percentage of their defense power applied. (file #17381) ___ Additional Item Attachment: File name: NonNatDefPct.patch Size:9 KB ___ Reply to this item at: http://gna.org/bugs/?20544 ___ 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 #3469] Get rid of most deprecated warning
Follow-up Comment #90, patch #3469 (project freeciv): To avoid the risk of accidentally introducing changes that didn't go through Gna, it's probably best to backport from trunk svn. I plan to do this; I've got a shortlist of changes to backport already. They don't cherry-pick trivially but I think the conflicts will be easy to resolve. Next step is to post a massive patch stack from git here for review, and test it a bit. ___ Reply to this item at: http://gna.org/patch/?3469 ___ 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] Client-side scripting (was: [bug #20489] Explorers shouldn't stop exploring)
Imhotep writes: Marko Lindqvist wrote: As of 2.4 there *is* client side scripting support - or at least framework for it. I still have found no time to properly test it myself, but it's said to be quite limited at the moment. Would it take much time for you to present us (me!) some kind of hello world-like script example, something like take this unit and move it one tile to the north? (With a hint on how to make it go.) That's the thing -- the client-side scripting has no way to affect the game world at the moment; that's its major limitation. http://www.freeciv.org/wiki/NEWS-2.4.0 sums it up: | * (Gtk) The client now has a Lua scripting console. GNAPATCH#2515 | | - This is currently something of a proof of concept rather than a | finished feature, as a comprehensive API suitable for the | client-side has not been provided. Notably, there are not yet any | signals from which client-side scripts can be triggered. | | - However, client scripts do have access to the client's view of | most of the same game data that server-side ruleset scripts do | (map, units, cities etc); see the Lua reference manual[*]. This | should be sufficient for some useful work. For example, it should | in principle be possible to implement an on-demand optimal trade | route calculator with these facilities (although we haven't | tried). [*] http://www.freeciv.org/wiki/Lua_reference_manual David Lowe writes: That's an interesting idea, but i don't know who would have the time and talent to submit such a patch. In order to be truly useful, it would have to enable the given unit to do almost anything the player could tell it to do - and prevent the script from having the unit do things the player couldn't tell it to do. It seems like that would require lots of hooks to accomplish all that. Permissions won't be a problem -- we already don't trust the client, so a client-side script won't be able to do anything the player can't. But, yes, there is a fair amount of work required to define the actions for client-side scripting to affect the game world. They can't all be straight copies of the server methods (e.g. 'edit' module), because the client doesn't get instant feedback; e.g. on the server, edit.unit_move() returns whether the unit died; on the client, it will merely trigger the dispatch of a network packet requesting that the unit move, and in the natural implementation, when that returns to the script we won't know if the move was even allowed; if the script wants to know what happened to the unit it will have to watch for a signal triggered by news of the unit's fate from the server (and in any case can't know for sure that e.g. the unit's death was triggered by the script's action). So client-side scripts are going to have to be written in a much more open-loop style. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3743] /delegate tidy-up
Update of patch #3743 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3743 ___ 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 #3768] [RFC]
URL: http://gna.org/patch/?3768 Summary: [RFC] Project: Freeciv Submitted by: syntron Submitted on: Fri 01 Mar 2013 09:58:04 PM CET Category: client Priority: 3 - Low Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: ___ Details: In bug #20489 the possibilities of client side lua script is discussed (auto exploring). I through about this. Given the current state I could image the following algorithm: - for each unit there is the possibility to assign a lua script controlling the unit. It could be accessed / changed via a keyboard shortcut which in turn proposes possible lua functions in the client lua script. The script name is saved in the unit structure (first only in the client) - after turn change the client iterates over all units and, if a lua script is set, executes it with option 'turn change'. This would execute _one_ command for the unit (i.e. go left) - if the unit data changes due to a server response, the client calls the lua script again at the end of the handling of the server data (in the example with option 'moved'). If move points are left, the next command can be requested by the lua script. - on a later step, the lua function could be send to the server at the time it is set. Thus, it could be saved if the game is saved and restored on game load (if the lua function is still available; else there should be an error message). - within the client lua environment, the function could save data about the job for the unit. But this information would be lost if the client is closed. Thus, a small data packet (32 byte?) could be allowed to be transferred to the server to save some data in the savegame (i.e the current job of the unit or the goto tile) - using this things like exploring or connect by road could be done on client side For this to work, several things are to be done: - lua functions to request all possible (simple) (player) commands for a unit (move, settler actions, ...) - hocks back to the lua code at the end of all possible unit action send by the server (wakeup, moved, successful attack, ...) ___ Reply to this item at: http://gna.org/patch/?3768 ___ 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 #3768] [RFC] client side lua script for unit actions
Update of patch #3768 (project freeciv): Summary: [RFC] = [RFC] client side lua script for unit actions ___ Reply to this item at: http://gna.org/patch/?3768 ___ 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 #20489] Explorers shouldn't stop exploring
Follow-up Comment #7, bug #20489 (project freeciv): Yes, client side lua script is limit. There are no callbacks into the lua environment. I did a prove of concept (see patch #2519). Thinking about this discussion I wrote a possible algorithm for the unit handling by the client as RFC in patch #3768 ___ Reply to this item at: http://gna.org/bugs/?20489 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
