bugFreeciv - Bugs: bug #20489, Explorers shouldn't stop exploring

 
 
Show feedback again

bug #20489: Explorers shouldn't stop exploring

Submitted by:  None
Submitted on:  Sat 09 Feb 2013 06:44:56 PM UTC  
 
Category: clientSeverity: 1 - Wish
Priority: 5 - NormalStatus: None
Assigned to: NoneOriginator Email: -unavailable-
Open/Closed: OpenRelease: 
Operating System: NonePlanned Release: 

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Fri 01 Mar 2013 09:00:59 PM UTC, comment #7:

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

Matthias Pfafferodt <syntron>
Project Member
Mon 11 Feb 2013 06:32:47 PM UTC, comment #6:

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.

Marko Lindqvist <cazfi>
Project Administrator
Mon 11 Feb 2013 06:30:11 PM UTC, comment #5:

> With it automatically determining mode, it could end to new mode when I wanted old one.


So instead of 'x', how about 'X' for the new mode? I think that key combination isn't in use yet...

David Lowe <doctorjlowe>
Mon 11 Feb 2013 12:41:15 AM UTC, comment #4:

> If we're going to have such a mode, possibly the unit should
> stop and wait for orders the first time it runs out of unknown
> territory to explore, and pressing X again will instruct it to
> go into this new mode (which will never terminate).


I were considering that too, but from my own autoexplorer using experience I think it's not good enough. I often press 'x' just to see if autoexplorer would still find some work. With it automatically determining mode, it could end to new mode when I wanted old one. Such situations arise as new units are acquired by any means (could this new unit explore?) or enemy units move to open passage to new areas for autoexplorers already finished with old areas.

Marko Lindqvist <cazfi>
Project Administrator
Mon 11 Feb 2013 12:20:24 AM UTC, comment #3:

Re patrol: remember that you can force a particular route by typing Q extra times. But, yeah, micromanagement.

As long as auto-explore is implemented on the server, we could steer auto-explore toward areas we haven't seen recently, since this is tracked in (struct player_tile).last_updated.

If we're going to have such a mode, possibly the unit should stop and wait for orders the first time it runs out of unknown territory to explore, and pressing X again will instruct it to go into this new mode (which will never terminate).

Jacob Nevins <jtn>
Project Administrator
Sun 10 Feb 2013 11:37:38 PM UTC, comment #2:

"Patrol" requires far too much micromanagement to be useful. The primary issue is that the pathfinder keeps steering the unit onto any available road/river/etc and the unit never gets close to areas that aren't adjacent to such. I second the original poster in that it would be better if we had a mode that would 'pull' units towards tiles that currently aren't seen.

David Lowe <doctorjlowe>
Sun 10 Feb 2013 01:14:33 AM UTC, comment #1:

There is "Patrol" command you can use to set route for units to constantly move. Isn't that sufficient for you?

Marko Lindqvist <cazfi>
Project Administrator
Sat 09 Feb 2013 06:44:56 PM UTC, original submission:

When I set explorers to auto-explore, I get nervous when they stop exploring just because they walked through the whole map. I want they to continue explore map, so that my map can get continously updated (new cities founded, etc.)
There should be some way of "forgeting" the known map, so that explorers could explore again same tiles.

Anonymous

 

(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by syntron (Posted a comment)
  • -unavailable- added by jtn (Posted a comment)
  • -unavailable- added by doctorjlowe (Posted a comment)
  • -unavailable- added by cazfi (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    No Changes Have Been Made to This Item
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup