Re: [Freeciv-Dev] Freeciv-web update
Good news! Which part (web client or server) is consuming the most resources, and is it CPU or RAM-limited? - Per On Mon, May 13, 2013 at 6:32 PM, Andreas Røsdal wrote: > Hi all Freeciv developers! > > It has now been about a week since Freeciv-web became playable on > http://play.freeciv.org/ so I thought that I should post an update. > > 13,688 people visited play.freeciv.org accoding to Google Analytics. > > "Worldwide productivity has plummeted", accoding to pcgamer.com: > http://www.pcgamer.com/2013/05/10/freeciv-available-in-html5-browsers-worldwide-productivity-plummets/ > > As you can see from the Freeciv-web metaserver, there is quite a lot of > activity: > http://play.freeciv.org/freecivmetaserve/metaserver.php > > In fact, there is so much activity that the server is running on very high > load, and isn't able to accept more players into games at times. So at the > moment we already could use more server resources. > > Here's more background information about the Freeciv-web client: > http://freeciv.wikia.com/wiki/FreecivWebClient > > Here's the source code on github: > https://github.com/andreasrosdal/freeciv-web > https://github.com/cazfi/freeciv-web > (fork us on github!) > > I would still really like to engage more developers in Freeciv-web > development. So if you are interested, then I can help you setup the > development environment if you need any help. Also, developers testing the > game on http://play.freeciv.org and reporting bugs would be very useful! > > Andreas ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] [bug #13848] [Patch] More detailed coding style guidelines
While on the topic of asserts, I recommend using a macro similar to the ASSERT_OR_RETURN that I wrote for Warzone2100 -- http://warzone2100.svn.sourceforge.net/viewvc/warzone2100/trunk/lib/framework/debug.h?revision=7821&view=markup The reason for this is that 1) you avoid having to do such double evaluations, and 2) you quickly get into the (addictive) habit of writing defensive code that fails softly for non-debug builds. Also a more descriptive ASSERT() macro with comments (see above link) helps when debugging. Feel free to copy & paste this code ;) - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] [PATCH] Agent calls are never equal if they are to different agents
Just to echo what was said earlier - the idea of client side agents is fundamentally a bad one because it requires too much information to be kept and sent to the clients. Only on the server can you access the amount of game state required for such agents without running head first into race conditions and then deadlocks when try to fix that because data has to be distributed over the network link and goes out of sync. It took CMA a very long time and a lot of work to reach its present state of stability. And CMA "only" does city tile management. I have also changed my mind about the desirability of a computational game AI. The amounts of CPU time required to compute best outcomes increases in such a dramatic fashion when the game rules are generalized, that it is simply not worth it. Good rules of thumb that can be written as AI scripts specifically for each ruleset will be faster, easier to write and maintain, and (therefore) probably even lead to better outcomes. This was not an easy conclusion for me to reach, because I spent a lot of time on the current computational AI. Hindsight is nice. If you want to throw computations at Freeciv AI problems, I recommend writing a program that analyses a ruleset then generating script rules that can be used later for a game AI. That way you can use as many CPU cycles as you want without anyone complaining. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#2581) Patch: layered combat
On Sun, Apr 12, 2009 at 1:57 AM, Madeline Book wrote: > In online multiplayer games this is considered a feature, and is a commonly > occuring strategy. When a tactic is commonly occurring and there is no recourse, no counter-tactic, then it is pretty much by definition unbalanced. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] DNS problem and access to resources
On Wed, Apr 1, 2009 at 4:45 PM, Christian Prochaska wrote: > I can't tell for sure, since I don't have an account on the real > machine, but from my little experience with the VirtualBox clone I > created, the apache server for the forum gets restarted every monday > by the logrotate program, but the apache startup fails if the hostname > of the machine it is running on (in this case "rt.freeciv.org") cannot > be resolved. So it might help to add "207.158.49.132 rt.freeciv.org" > to /etc/hosts on the server, too and then try to start the apache > server again (/etc/init.d/httpd start). I tried that, and it did not seem to help much. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] music
On Fri, Jan 2, 2009 at 12:15 AM, Brandon Van Every wrote: > I was made aware of various FTP resources. I noticed there's a > ftp://ftp.freeciv.org/freeciv/contrib/audio/music/ directory with a > lot of tunes that I've never heard in a Freeciv game. Were these > intended to get into the game somehow? What happened? The various artists never finished a complete series of tunes for the ages, and I never wrote the music manager code as I had planned (and never will). - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] freeciv 2.1.8
On Tue, Dec 30, 2008 at 4:06 AM, Auel Neider wrote: > hi, im very like with your game. but unfortunately, freeciv 2.1.8 made my > system crashed. im using mandriva 2009.0 and i downloaded freeciv from > official source (RPM). the crashed system happened after i played for hours, > when the crash almost same with when you logged out (x server restarted), > then want to log in again, its happen repeatedly so i have no choice than to > ¨hard-shutdown¨ it. then i played the autosave again. one day my system cant > recover after the crash so it wont boot. i reinstall my system again. so i > would be pleased if this dont happened again. tx for your attention. It seems rather unlikely that Freeciv would have anything to do with such a crash. The window system and the kernel would not permit Freeciv to take down the rest of the system in the event of a failure inside Freeciv itself. The only issue could be if you play in fullscreen mode, and somehow it gets stuck in that state in the event of an error, but I do not know much about that since I never play in fullscreen mode. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40407) Wishlist for Freeciv
http://bugs.freeciv.org/Ticket/Display.html?id=40407 > On Wed, Aug 13, 2008 at 1:01 AM, Nicolas R. Wadhwani <[EMAIL PROTECTED]> wrote: > This get_best_defender function comes up with quite a lot of odd results > that are puzzling me as a former payciv gamer, no matter if this feature > here is implemented or not. For example it lets me kill non military > units before any strong unit in a city if I attack with something > rediculus strong like an howitzer. Once the non military units are gone > and you continue attacking with the strong units it lets the howitzer > sink an aircraft carrier before a marines unit which is... well just > imagine if you'd read this in an history book about the battle of Iwo > Jima... > > Maybe there should be another option letting the get_best_defender > function return the strongest units of the same type (ground/naval/air) > first just like the payciv city attacks were handled? The get_best_defender() function does have some odd quirks, but most of all the problem is that it does not make a difference between the case where you would lose your entire stack if the defender dies, and the case where you don't. In the former case, a tiny improvement of our chances to survive are worth risking the neck of even the most expensive unit, but in the latter case this is not so. One thing that surprises the players the most, I think, is that Settlers are often chosen to defend cities. This is because they have a huge amount of hit points compared to other early game units, and the function to pick the defender does not care that it costs a population point to lose it. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40407) Wishlist for Freeciv
http://bugs.freeciv.org/Ticket/Display.html?id=40407 > On Sun, Aug 10, 2008 at 11:28 PM, Nicolas R. Wadhwani <[EMAIL PROTECTED]> wrote: > Attached patch is one way of how this feature could be implemented in current > trunk version. I created two new options in the game for this: one on the > server side called "seecitydefender", which is disabled by default. Once > enabled the server will send the info about the strongest unit occupying any > city within vision so it can be displayed. The problem with this idea is that "strongest unit" is a relative term. Which unit is chosen as defender depends on which unit is used as the attacker. So this patch would often give the player false information, which is, IMHO, worse than no information. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] borders and fog of war
On Tue, Jul 29, 2008 at 10:11 PM, Jason Dorje Short <[EMAIL PROTECTED]> wrote: > Some games give the option of showing enemy start positions. This > would potentially show the enemy's first city as fogged terrain, for > instance. I think that would be a good idea. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] borders and fog of war
2008/7/25 Madeline Book <[EMAIL PROTECTED]>: >> > There was a suggestion some years(?) ago that players should have full >> > vision inside their borders, to offset such information leakage. I >> > think that is a reasonable idea. > > It might be interesting to try this out, but it does not address the > problem that when someone finds the border edge, they get > extra information that someone has a city near there. I realize > this is hardly significant when playing with AIs or novice players, > but knowning where your opponent is (and without him knowing > that you know that) can be the difference between a win and a > loss for two expert human players. Sounds like a feature to me. Current Freeciv multi-player is too much of a hide-and-seek, where the chance event of discovery of another player while he is still busy expanding without considering defence often decides the game. Instead of hiding players even more, we should make it even more obvious for all players. > There is also the issue that players can essentially see through > the fog since border information is sent even when a tile is > fogged. So for example they can see when a city changes owner > by the changing of the border around the city tile. Well, I'm not really sure why fog of war should hide city changes in the first place. Cities are huge, and trade has in all times been prevalent, diffusing knowledge of the immediate geography around nations. So it is not at all strange that this information is 'leaked'. Restricting knowledge of the map strictly to a player's vision gives the game a little too much myopia, reducing the interaction. > This is one way it could be handled I suppose. My own idea would > be to only send updated border information when the unit sees the > source of that border (a city or fortress I presume). This would avoid > the "visual mess" of partial seen borders (at least to the granularity > of sources rather than individual tiles) and not give extra hints to > attackers. Then you wouldn't know that you have crossed into another player's territory until well after the fact... This is one other reason why we need omniscient borders: The current diplomacy model pretty much depends on it. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] borders and fog of war
On Thu, Jul 24, 2008 at 6:34 PM, Madeline Book <[EMAIL PROTECTED]> wrote: > I disagree with this game rule, it is not good for gameplay. > The reason being is that it would make sneaking up on cities > easier. An example would be a trireme that only has to see a > worked ocean tile to find where the city is located, in essence > giving it a larger vision radius near a city. This is also the > reason why almost all 2.0 multiplayer games disable borders; > it gives too much information to attackers and unbalances the > game. There was a suggestion some years(?) ago that players should have full vision inside their borders, to offset such information leakage. I think that is a reasonable idea. > (Also, I would like borders to be fogged like units and cities > too, but that is an issue for another ticket...) You mean last seen borders would be "remembered" by the player, instead of being given as it really is? IIRC, and this starts being quite a while ago, the first borders implementation was like this. It was a horrible mess. I do not think you want to go back there. What problem would this solve, in any case? - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] pubserver/publite
On Sun, May 25, 2008 at 12:07 AM, Andreas Røsdal <[EMAIL PROTECTED]> wrote: > I'm wondering if the current Freeciv servers on the metaservers > are running pubserver, publite or some other custom software. It is running pubserver. > Where can I find publite? It was lost in a disk crash. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40184) [editor] Toolbar GUI front-end preliminary work
On Fri, Apr 4, 2008 at 10:45 AM, Daniel Markstedt <[EMAIL PROTECTED]> wrote: > > http://bugs.freeciv.org/Ticket/Display.html?id=40184 > > > Very nice, Madeleine! I'm thinking of starting a forum thread to > attract the attention of Freeciv's creative minds. :) Yes, really awesome. I am happy to see that someone is working on the editor again. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] FreeCiv Source Documentation
On Tue, Mar 25, 2008 at 9:25 PM, felipe lopez <[EMAIL PROTECTED]> wrote: > My Name is Felipe Lopez and I'm currently studying MCS (Master in Comp. > Science in PUPR.edu) as one of the courses is Software Architecture we have > to perform a reverse engineering, and I choose FreeCiv because is a Great > Game. > > I'm asking if any of you could provide source code documentation and compare > it to the UML that I just ran using Visual Paradigm Enterprices (Try out). > I would really appreciate, and if I found something that doesn't match with > the paper I will let you know. The only source code documentation that exists is in the doc/ directory in the source code. It is not much. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] freeciv as programming game
On Sun, Feb 24, 2008 at 1:28 AM, Philipp Hofmann <[EMAIL PROTECTED]> wrote: > i really would like to write my own client for the game. and i very > much would like to do that in my currently favorite scripting > language. i guess it would be possible to use SWIG to make the client > api written in c available to scripting languages like python, perl or > ruby. I would recommend writing a server-side AI plugin, rather than a client-side AI. A lot of people have tried to implement a client-side AI, and no-one has succeeded. It is just a different category of difficult. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#16811) Re: (PR#39854) Change bug tracking system
http://bugs.freeciv.org/Ticket/Display.html?id=16811 > On Nov 11, 2007 5:43 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > From the hosting standpoint, if freeciv.org becomes a 401c3, then it > could collect donations so that it could pay for its own hosting if it > had to. The problem has always been to find someone who could host it with an absolutely minimum of work needed to maintain it from our end. Registering and maintaining a charity is almost a full time job. > Has anyone looked into sourceforge? Last I checked, it could not run bugzilla. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39830) 2.1.0 border expansion acquires destroyed city
http://bugs.freeciv.org/Ticket/Display.html?id=39830 > On 11/5/07, William Allen Simpson <[EMAIL PROTECTED]> wrote: > The server "knows" the city isn't there anymore. It expands the border, > but doesn't update the vision. Probably, send_map_is_known_and_seen() > needs to return TRUE when the tile is owned by the player. Easy enough. > > Meanwhile, the server "knows" the client "knows" the city is there. The > border code currently has (at least) two potentially conflicting values: > >struct player *owner; /* Player owning this tile, or NULL. */ >struct tile *owner_source; /* what makes it owned by owner */ > > The latter isn't actually pointing to the source, it's pointing to the > tile of the source. That tile no longer really has the source on it in > the server view, but has it in the client view! But why is this a problem? The vision code and the border code should not interact at all in the current design. > Moreover, the savegame map_load should run map_calculate_borders(). Is > there a reason it was only done between turns? Because running it causes borders to expand, and saving then loading should not change game state. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39826) edit/remove Eifell Tower for 2.1
http://bugs.freeciv.org/Ticket/Display.html?id=39826 > On 11/2/07, <> wrote: > with reputation gone from freeciv, the Eiffel tower's role in the game > is diminished as of the moment > > "Your reputation and goodwill among other nations is increased while > you possess this wonder. Reputation is recovered twice as fast as > it would otherwise. Maybe it is diminished, and maybe the helptext should be changed, but it does have its primary purpose intact: AI players will become more friendly over time with the owner of the Eiffel Tower. I think it is a nice wonder for new players who want to cuddle up to the AI players instead of making war on them. It is of course useless for aggressively minded, experienced players, but it was never meant for them in the first place. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39787) Ubuntu don't redistribute stdsounds
http://bugs.freeciv.org/Ticket/Display.html?id=39787 > On 10/21/07, William Allen Simpson <[EMAIL PROTECTED]> wrote: > let's make sure the sound packages have the correct license clearly listed. > They are all > GPL, aren't they? Yes, with the caveat above, and the one that comes in the COPYING.README file in Warzone: Concerning the license on the original data files: (basically everything in data/) The literal meaning of the release statement is ambiguous in the case of the original data that is included in the released package. Despite several attempts to get a clarification, we have received no response. We have chosen to interpret the original release statement as putting the original data under a GPL license. Since in the absence of a license the released data could not be distributed, we find that interpreting the license for the data as being under the same license as the source to be the best interpretation to fit the intention behind the release. > Why aren't sounds in the main package? size? I think size was the problem back when it was originally considered. I doubt that is really a problem anymore. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39624) [Patch] group unit selection
http://bugs.freeciv.org/Ticket/Display.html?id=39624 > On 10/18/07, William Allen Simpson <[EMAIL PROTECTED]> wrote: > Yes, it was. Thank you for making a note of it. However, it is > considered very, VERY bad form to close a developer's ticket. It > disappears off the list of open tickets, and thus is not there to > prompt the developer to test it upon a release. Hey, Keeping fixed tickets open until release has never been done by anyone around here before, and your fixed-but-open tickets really did confuse me sometimes too, so please be civil on people who misunderstand your new, until now unannounced way of working with the ticket system. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] I'm retiring from the project
Hello all, I guess this should not be much of a surprise, but my attention and motivation has not been on this project for a while, and I do not think that will change any time soon. I do not wish to hang on to titles without putting in any work, so I am retiring from being a Freeciv maintainer. As I think you all know, I have long wanted the game to depart from its origins as a multiplayer hack inspired deeply by the commercial civ games, and instead streamline the rules and interface to make it one, good single-player game, similar to how Battle for Wesnoth did it. This proved to be very difficult, time consuming and exhausting to convince people of and implement without hurting multiplayer, and may therefore have been a mistake. In any case, working with you all have been, on the whole, a wonderful and magnificent learning experience, and I have had much fun programming with such a talented, forgiving and kind crew. My virtual hat off to you all, and best of luck to the future. I will still be around, and do not hesitate to ask for directions or a hand with code that I may have written or have some semblance of experience with, and that, for some strange reason, is not yet perfect. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] Sid Meier comments on Freeciv...
This is from an interview with the registration-required game developer site Gamasutra (http://www.gamasutra.com/view/feature/1523/the_history_of_civilization.php?page=9): ... Have you heard of the open source clone of Civilization called FreeCiv? Sid: I have heard of it. I don't know much about it at all. You've never played it? Sid: I have not played it, no. Do you purposely avoid it, just because... Sid: No. There are so many good games out there, and I've played the original Civilization plenty, and I still like Civilization in general. I still have ideas, and we're still working with new stuff, but the first game was a while ago, and we're looking more forward than back. Do you find it flattering or more annoying that they cloned it? Sid: No, I find it flattering. To see the forums, Apolyton, places like that. To see people doing stuff with it: keeping it alive and really putting their energy into playing it, maintaining it, coming out with mods; all the stuff out there. I think that's great. The whole community aspect of it really keeps it alive. The community can do so much more than we can on our own. We try to plant the seed and provide the tools and let people do great things with it. ... - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] Map generator broken in trunk
Looks like the map generator is badly broken in svn trunk, generating mountains and hills in the ocean. Why is this? - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] trunk lua mess
On Fri, 22 Jun 2007, William Allen Simpson wrote: > Finally, could somebody explain why lua is important? It's hardly used! That is something we hope to change. lua is important for increased configurability, and making more advanced modpacks. The tutorial, for example, is made in lua. I hope to commit a patch that moves configuration of huts into lua files soon. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] trunk lua mess
On 6/18/07, William Allen Simpson <[EMAIL PROTECTED]> wrote: > 1) install the latest lua. Make sure it works. Surely the latest lua will > still work with the older tolua! No, tolua 5.0 does not work with lua 5.1, unfortunately. And there is no more recent version of tolua, hence the use of tolua++, a more up to date derivative version. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] trunk lua mess
I tried unsucessfully to update trunk to latest lua and tolua versions. For some reasons I could not figure out, tolua generated a bad api_gen.c, and the makefile did not regenerate this file for me and thus alert me to the problems before I had already committed the changes. Even 'make maintainer-clean' did not clean out these files. So I had to roll back the repository to the state before I started the upgrade. This generates some unfortunate svn noise, and William's r13000 is gone. I am really sorry about that. Speaking of r1300, I would very much like to see it go in in smaller chunks which are easier to manage when debugging using svn. Also, while on the topic of api_gen.c|h, I do not see why these automatically generated source files are in the repository? All the tools required to generate them are already in the repository. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39342) 2.1.0-beta4 border vs. fog of war
http://bugs.freeciv.org/Ticket/Display.html?id=39342 > On 5/16/07, William Allen Simpson <[EMAIL PROTECTED]> wrote: > > Given how much FoW you usually have, this will make your real borders > > really hard to visualize and plan with respect to. > > > > I do not really see a good and simple fix to this issue. We need to change > > the way either borders or the problematic map updates are done to make > > them consistent with each other. > > > Now, I have run into this problem, too. > > Here's my suggestion: > > 1. Foreign borders aren't "tile features" of the map, they are political. > > 2. When near a border with a unit, the border will appear, even when > you haven't seen the city that created it. It's not the place itself, > it's the workers, travelers, and minstrels that tell you about it. > > 3. When the border is no longer near, it should disappear after some > number of turns (1 turn would be very easy to code). So this is like today, only that you forget borders after a turn if you do not see the border source? It is actually rather complicated, and it does not answer my worry above that it will make borders hard to visualize, due to the prevalence of FoW. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] The new bug submission address
Just a reminder that the new bug submission address is [EMAIL PROTECTED] and anything sent anywhere else will (hopefully) bounce. It has been working very well so far - I have seen no new spam in RT yet. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39126) Nuke bug
http://bugs.freeciv.org/Ticket/Display.html?id=39126 >
On 5/12/07, Per Inge Mathisen <[EMAIL PROTECTED]> wrote:
> I do not think the "Explore Nuke" command is not meant to be a goto
> command. You can use the normal goto command for nukes. The cursor
> that appears on "Explore Nuke" is a cosmetic bug. It should just nuke
> at once when this command is given. In 2.1 and up there might be a
> problem using goto properly for nukes, though.
On a second thought, it seems clear that someone thought it should be
implemented this way, and I do not know how long it has been
implemented that way before it was broken. So I committed the patch,
and made the attached patch for 2.1.
- Per
Index: client/control.c
===
--- client/control.c (revision 12931)
+++ client/control.c (working copy)
@@ -1352,6 +1352,7 @@
if (can) {
set_hover_state(punits, HOVER_NUKE, ACTIVITY_LAST, ORDER_LAST);
update_unit_info_label(punits);
+enter_goto_state(punits);
} else {
create_event(offender, E_BAD_COMMAND,
_("Only nuclear units can do this."));
@@ -1834,7 +1835,7 @@
if (!possible) {
create_event(offender, E_BAD_COMMAND, _("Too far for this unit."));
} else {
- do_unit_goto(ptile);
+do_unit_goto(ptile);
if (!pcity) {
unit_list_iterate(punits, punit) {
/* note that this will be executed by the server after the goto */
@@ -1855,6 +1856,7 @@
do_unit_patrol_to(ptile);
break;
}
+
set_hover_state(NULL, HOVER_NONE, ACTIVITY_LAST, ORDER_LAST);
update_unit_info_label(get_units_in_focus());
}
@@ -2035,7 +2037,7 @@
{
struct tile *dest_tile;
- if (hover_state != HOVER_GOTO) {
+ if (hover_state != HOVER_GOTO && hover_state != HOVER_NUKE) {
return;
}
@@ -2047,8 +2049,6 @@
create_event(ptile, E_BAD_COMMAND,
_("Didn't find a route to the destination!"));
}
-
- set_hover_state(NULL, HOVER_NONE, ACTIVITY_LAST, ORDER_LAST);
}
/**
Index: client/goto.c
===
--- client/goto.c (revision 12931)
+++ client/goto.c (working copy)
@@ -752,6 +752,8 @@
connect_initial++;
}
} /* otherwise moves_left_initially = punit->moves_left (default) */
+ } else if (hover_state == HOVER_NUKE) {
+parameter->is_pos_dangerous = NULL; /* nuclear safety? pwah! */
}
if (is_attack_unit(punit) || is_diplomat_unit(punit)) {
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39126) Nuke bug
http://bugs.freeciv.org/Ticket/Display.html?id=39126 > I do not think the "Explore Nuke" command is not meant to be a goto command. You can use the normal goto command for nukes. The cursor that appears on "Explore Nuke" is a cosmetic bug. It should just nuke at once when this command is given. In 2.1 and up there might be a problem using goto properly for nukes, though. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] New bug submission address
In an attempt to stem the tide of spam that is making RT near unusable, I have changed the submission address for tickets to RT to [EMAIL PROTECTED] instead of [EMAIL PROTECTED] Please do not post this new address anywhere in plain text where spam bots can find it. It does not work yet, so if you need to create new tickets or respond to older ones, do it through the web interface for now. - Per "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] Re: (PR#37820) Patch: Use PF distance in waste by distance calcs
On Fri, 9 Mar 2007, (Eddie_Anderson) wrote: This is an experimental patch. It replaces "real map distance" (RMD) with pathfinder (PF) distance in the calculation of "waste / corruption by distance from the capital". I like the idea, but the implementation (or any implementation) has these problems: - It is strongly tied to a unit type, and changes to this unit type will create colossal changes to waste levels, which may not be obvious or desirable. - Changing roads does not recalculate waste levels until end of turn, which changes the way this has been handled up until now. Currently we guarantee that what you see in the city dialog as you press end turn is what you will get on turn end. There are no surprises, which is probably a good thing. We could recalculate all city distances every time a road is built, but it would also be affected by moving units and their ZoC, and we can't recalculate city distances for each unit movement. Possible solutions: * Perhaps a "standard unit" should be created for tracing distances, which could be amphibious, now that we have such units. I do not see how to solve the changing roads / moving units problem. Perhaps the biggest question I still have about this code is about the form of the PF search. AIUI the method used here is an outward search of surrounding tiles that looks for cities. But since the locations of cities are *known*, wouldn't a PF search for a path (between two known points) be more efficient? IIRC, no. Remember that the straight path may not be the longest, so we need to do an exhaustive search to find the guaranteed shortest path. But let us take a step back and look at why there is waste in the first place. I think the point is to give a penalty for building cities wide apart - but why? It punishes bigpox much harder than smallpox, since bigpox cities are generally further apart. Since there is less tiles between smallpox cities, it will be far easier to connected smallpox cities by road and avoid the waste distance penalty. Though, it is good that there is an incentive to build a cohesive empire, rather than just a loose collection of cities around the globe, but this can be accomplished in different ways. We could just retire the distance based waste penalty. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#38029) City refresh without side effects
http://bugs.freeciv.org/Ticket/Display.html?id=38029 >
I was looking to test some experimental code, and needed to fix the
generic_city_refresh() mess, where refreshing one city can lead to the
side effects of units being changed and other cities being changed and
refreshed in turn. Not to mention passing in a function point to send
out network data. So I came up with the following patch that makes
generic_city_refresh() entirely without side effects, and as long as
it is called with different cities, it should also be re-entrant.
The big change is that trade routes are no longer calculated from the
trade output, but rather from city size and real map distance. This
means there are now very few cases where trade routes actually change,
as opposed to now, where any city operation is likely to impact trade
routes and cause changes in several cities.
It also makes the city code make use of the "amount" field of
EFT_MAKE_CONTENT_MIL_PER which is now ignored, and "FieldUnit" units
now cause happy upkeep amount of unhappiness when in a city instead of
1, which is how you would expect it to work.
On the code side, this fixes some ugliness in savegame.c where we
would update cities' trade route info when some trade partners may yet
be uninitialized (see PR#12498). Since we no longer send upkeep by the
unit to the client, but rather require the client to calculate it on
its own, the amount of network data transmitted has been reduced, at
the cost of some more client computation.
The only "problem" with this is that the server's idea of "which unit
is causing unhappiness" and "which unit is paying upkeep" may differ
from the client's. However, the idea of appointing certain units as
paying and causing unhappiness makes no sense in the first place,
since units falling in under free quotas are just as much to blame for
the upkeep as are those that are randomly appointed as paying the
cost. It only makes a bit of difference to players who may think they
know which units the server will disband if you run out of gold to pay
for maintenance. I actually look at this as an accidential feature ;-)
- Per
PS If you want to only check out the trade route change, I attached
this as a separate patch.
Index: server/cityturn.c
===
--- server/cityturn.c (revision 12804)
+++ server/cityturn.c (working copy)
@@ -88,7 +88,7 @@
**/
void city_refresh(struct city *pcity)
{
- generic_city_refresh(pcity, TRUE, send_unit_info);
+ generic_city_refresh(pcity, TRUE);
/* AI would calculate this 1000 times otherwise; better to do it
once -- Syela */
pcity->ai.trade_want
@@ -389,6 +389,8 @@
**/
bool city_reduce_size(struct city *pcity, int pop_loss)
{
+ int i;
+
if (pop_loss == 0) {
return TRUE;
}
@@ -436,6 +438,16 @@
auto_arrange_workers(pcity);
sync_cities();
}
+
+ /* Update cities that have trade routes with us */
+ for (i = 0; i < NUM_TRADEROUTES; i++) {
+struct city *pcity2 = find_city_by_id(pcity->trade[i]);
+
+if (pcity2) {
+ city_refresh(pcity2);
+}
+ }
+
sanity_check_city(pcity);
return TRUE;
}
@@ -460,7 +472,7 @@
{
struct player *powner = city_owner(pcity);
bool have_square;
- int savings_pct = granary_savings(pcity), new_food;
+ int i, savings_pct = granary_savings(pcity), new_food;
bool rapture_grow = city_rapture_grow(pcity); /* check before size increase! */
if (!city_can_grow_to(pcity, pcity->size + 1)) { /* need improvement */
@@ -514,6 +526,15 @@
city_refresh(pcity);
+ /* Update cities that have trade routes with us */
+ for (i = 0; i < NUM_TRADEROUTES; i++) {
+struct city *pcity2 = find_city_by_id(pcity->trade[i]);
+
+if (pcity2) {
+ city_refresh(pcity2);
+}
+ }
+
notify_player(powner, pcity->tile, E_CITY_GROWTH,
_("%s grows to size %d."), pcity->name, pcity->size);
script_signal_emit("city_growth", 2,
Index: server/unittools.c
===
--- server/unittools.c (revision 12804)
+++ server/unittools.c (working copy)
@@ -274,14 +274,22 @@
void pay_for_units(struct player *pplayer, struct city *pcity)
{
int potential_gold = 0;
+ int free_upkeep[O_COUNT];
+ memset(free_upkeep, 0, O_COUNT * sizeof(*free_upkeep));
+ free_upkeep[O_GOLD] = get_city_output_bonus(pcity, get_output_type(O_GOLD),
+ EFT_UNIT_UPKEEP_FREE_PER_CITY);
+
built_impr_iterate(pcity, pimpr) {
potential_gold += impr_sell_gold(pimpr);
} built_impr_iterate_end;
unit_list_iterate_safe(pcity->units_supported, punit) {
+int upkeep[O_COUNT];
-if (pplayer->economic.gold + potential_gold < punit->upkeep[O_GOLD]) {
+city_unit_upkeep(punit, upkeep, free_upkeep);
+
+if (pplaye
[Freeciv-Dev] Crossporting changes from the war client
The last four emails I have sent on this topic have mysteriously disappeared before arriving at the list. Maybe they were thought to be spam? Please read it in RT instead: http://bugs.freeciv.org/Ticket/Display.html?id=35691 I really do not like overzealous spam filters :( - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#35641) Unit transport loading cleanup
http://bugs.freeciv.org/Ticket/Display.html?id=35641 >
On 2/10/07, Marko Lindqvist <[EMAIL PROTECTED]> wrote:
> I think you cannot check for is_native_tile() in could_unit_load()
> (this was probably bug already in find_transport_from_tile()) It means
> that you cannot load to boat in coastal city.
Fixed. New patch attached. I have tested boarding transports in
cities. It works now, at least.
> You could check that transport can_unit_exist_at_tile(), but I don't
> think that is necessary. can_unit_exist_at_tile() would return FALSE
> only if we attempt recursive transportation, which is prohibited by
> other means already. Assert, maybe?
I think you got some functions mixed up above.
- Per
Index: server/unittools.c
===
--- server/unittools.c (revision 12614)
+++ server/unittools.c (working copy)
@@ -2844,7 +2844,7 @@
/* Special checks for ground units in the ocean. */
if (!can_unit_survive_at_tile(punit, pdesttile)) {
-ptransporter = find_transporter_for_unit(punit, pdesttile);
+ptransporter = find_transporter_for_unit(punit);
if (ptransporter) {
put_unit_onto_transporter(punit, ptransporter);
}
Index: common/unit.c
===
--- common/unit.c (revision 12614)
+++ common/unit.c (working copy)
@@ -543,22 +543,15 @@
}
/
- Return TRUE iff the given unit can be loaded into the transporter.
+ Return TRUE iff the given unit could be loaded into the transporter
+ if we moved there.
/
-bool can_unit_load(const struct unit *pcargo, const struct unit *ptrans)
+bool could_unit_load(const struct unit *pcargo, const struct unit *ptrans)
{
- /* This function needs to check EVERYTHING. */
-
if (!pcargo || !ptrans) {
return FALSE;
}
- /* Check positions of the units. Of course you can't load a unit onto
- * a transporter on a different tile... */
- if (!same_pos(pcargo->tile, ptrans->tile)) {
-return FALSE;
- }
-
/* Double-check ownership of the units: you can load into an allied unit
* (of course only allied units can be on the same tile). */
if (!pplayers_allied(unit_owner(pcargo), unit_owner(ptrans))) {
@@ -576,16 +569,37 @@
}
/* Make sure this transporter can carry this type of unit. */
- if(!can_unit_transport(ptrans, pcargo)) {
+ if (!can_unit_transport(ptrans, pcargo)) {
return FALSE;
}
+ /* Transporter must be native to the tile it is on. */
+ if (!can_unit_exist_at_tile(ptrans, ptrans->tile)) {
+return FALSE;
+ }
+
/* Make sure there's room in the transporter. */
return (get_transporter_occupancy(ptrans)
< get_transporter_capacity(ptrans));
}
/
+ Return TRUE iff the given unit can be loaded into the transporter.
+/
+bool can_unit_load(const struct unit *pcargo, const struct unit *ptrans)
+{
+ /* This function needs to check EVERYTHING. */
+
+ /* Check positions of the units. Of course you can't load a unit onto
+ * a transporter on a different tile... */
+ if (!same_pos(pcargo->tile, ptrans->tile)) {
+return FALSE;
+ }
+
+ return could_unit_load(pcargo, ptrans);
+}
+
+/
Return TRUE iff the given unit can be unloaded from its current
transporter.
@@ -1392,9 +1406,10 @@
/
Find a transporter at the given location for the unit.
/
-struct unit *find_transporter_for_unit(const struct unit *pcargo,
- const struct tile *ptile)
-{
+struct unit *find_transporter_for_unit(const struct unit *pcargo)
+{
+ struct tile *ptile = pcargo->tile;
+
unit_list_iterate(ptile->units, ptrans) {
if (can_unit_load(pcargo, ptrans)) {
return ptrans;
Index: common/unit.h
===
--- common/unit.h (revision 12614)
+++ common/unit.h (working copy)
@@ -216,6 +216,7 @@
bool unit_can_airlift_to(const struct unit *punit, const struct city *pcity);
bool unit_has_orders(const struct unit *punit);
+bool could_unit_load(const struct unit *pcargo, const struct unit *ptrans);
bool can_unit_load(const struct unit *punit, const struct unit *ptrans);
bool can_unit_unload(const struct unit *punit, const struct unit *ptrans);
bool can_unit_paradrop(const struct unit *punit);
@@ -297,8 +298,7 @@
void free_unit_orders(struct unit *punit);
int get_transporter_occupancy(const struct unit *ptrans);
-struct unit *find_transporter_for_unit(const struct unit *pcargo,
-
[Freeciv-Dev] Question about find_transport_{from_tile|for_unit}
Can someone please explain to me the intended difference between find_transport_from_tile() and find_transporter_for_unit()? They seem intended to do the same to me. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] Aircraft and fuel
I have been looking at the goto issues with aircraft, and I think we have been approaching this problem in the totally wrong way. The aircraft model with "fuel" was always just a neat hack, but not a good design. Attempting to solve goto for aircraft, for client, for AI and for automatic return, turned out to be extremely complicated. It is a problem that, I think, screams for redesign rather than a solution. The whole "dangerous tiles" path finding for triremes and aircraft should be removed. It was just too hard. For triremes it can be done either with deep ocean tiles (how far did we get here?) that are impassable for triremes, or just making a movement rule that they cannot stray from land. For aircraft, we would need to abolish the concept of fuel. I suggest instead of fuel, we add the rule that all aircraft automatically return to the airfield/city/carrier that the unit visited last at the start of your turn. That is, when you use an aircraft, it stays in the air until your next turn/phase, allowing other players a chance to shoot it down (of course, this is exploitable by attacking in the last second in simultaneous movement mode, but I have given up trying to make that mode fair). This return is done with teleport and no movement points are required - no need to fuss about counting tiles for return. If you use goto, you can designate a new landing site if it is within (movement points remaining + max movement points) tiles, and the aircraft will land there instead, allowing aircraft to move a maximum of 2xMP each turn. The teleport method is already used for airlift, so it has precedent for air movement. Opinions? - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] this is a test
I just want to see what happens if I try to email this list from the outside. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] Missing features for scenario creation
On Sat, 27 Jan 2007, Daniel Markstedt wrote: Managed to figure that out the other day. > ~Event upon the death of a unique unit. > ~Event upon the conquest of a specific city. Should be possible with scripts. I see it isn't there yet. Should be easy to add. With a caveat that there may issues with doing things within deeply recursed loops. I do not remember how the scripting code deals with this any longer. - Per "The world owes you nothing. It was here first." -- Mark Twain ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#33568) freeciv, gcc 4.1.1 and --enable-debug=yes (fwd)
(Resending to list since bugs@ ate my email and refused to add it to RT.)
On Sun, 14 Jan 2007, Egor Vyscrebentsov wrote:
Line is:
if (fwrite(buf, 1, result, scan->meta.fp) < 0) {
so I can't decide is this freeciv problem or gcc.
fwrite returns a size_t, which is unsigned. It makes no sense to check if it is
below zero, so I am guessing the compiler optimized away the check.
Perhaps this should be a check of equal to zero instead?
- Per
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] Test post
Please ignore. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
