Scout program does not run

[Chuck Wilder]

Since trunk rev5287 at least, the scouts for all of the tribes do not consume wares nor leave their houses until house is demolished.

[SirVer (sirver)]

same here.

[Timowi (timo-wingender)]

For me scouts still work. I have only problems if I have them near military buildings with high vision. A scout needs a black node relatively near.

[Chuck Wilder (chuckw20)]

Yes. This looks like a "user error". I find that if I place (or re-place)
a scout's hut close to a frontier it does work for me (Windows & linux).

Urban sprawl looks like the culprit. Guess I'll have to learn to keep
moving my scouts to the "suburbs" to get them to work. :)

I'm now convinced this bug report of mine is not valid.

On Tue, May 11, 2010 at 3:07 PM, Timowi <email address hidden> wrote:

> For me scouts still work. I have only problems if I have them near
> military buildings with high vision. A scout needs a black node
> relatively near.
>
> --
> Scout program does not run
> https://bugs.launchpad.net/bugs/573863
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Widelands: Confirmed
>
> Bug description:
> Since trunk rev5287 at least, the scouts for all of the tribes do not
> consume wares nor leave their houses until house is demolished.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/widelands/+bug/573863/+subscribe
>

[Victor Pelt (victor-pelt)]

actually i think it is a valid bug. since scouts will move quite a large distance if a 'black node' is near they should work as long as any node in their max range is black, not just the near ones

[Chuck Wilder (chuckw20)]

And I was ready to write off my problem as a loose nut between the keyboard and the chair. So, what is the scout's maximum range?

[Timowi (timo-wingender)]

The scout has only one parameter: The time the scout program runs. This is 75s (as far as I remember correctly). This counts as soon as the scout leaves his hut. This affects the maximum distance the scout runs. And then there is (somewhere hard coded) a distance at which the scout looks from his hut for black areas. This maximum sight of the scout is lower than the maximum vision range (actually the maximum difference between conquer and vision range) of some military buildings.

I proposed some time ago to increase at least this "initial vision range" of the scout so it works even near to towers and similar military buildings. I am for increasing both this initial range and the running time to make the scout actually useful.

[Chuck Wilder (chuckw20)]

One question:

Why shouldn't the scout's knowledge of the geography (i.e. black areas) be the same as the player's? Must the scout rely solely on his own capabilities to gather information? Doesn't anyone talk to the little guy? :( Black areas that are out of the scout's traveling range could of course be ignored.

And why couldn't the scout "make note of" black areas he has traveled past on previous missions as targets for future missions?

Okay, so that's FOUR questions. :D

[Timowi (timo-wingender)]

The map functions do not work this way. You can search the whole map for areas the player can not see that that is ineffective. So you search for unseen nodes in an area (a certain radius) around a node for black area. You mostly search in a radius around a node. Searching the whole map for something is too slow. This radius is just too small for some circumstances.

The scout have to rely on this information. They do not talk much. The scout have to ask. ;) "All the player can see" or not see in this case equals to searching the whole map and that is not necessary in this case. Actually the scout can know everything the player knows. It's only a question how far search the information.

As far as I know the scout keeps a list of interesting places to explore them later. But I do not know much about the scouting code. The problems with the scout are not how it is implemented but the parameters of this implementation. In my opinion both parameters (initial search range and scouting time) are to low for the scouting feature to be useful. It is more a question of adjusting these to improve the scouting feature.

[Chuck Wilder (chuckw20)]

Your description makes a lot of sense from a coding perspective and I would have been surprised if it had been implemented differently.

You can include me as also in favor of increasing the scout's operating parameters. The scout's current effectiveness is borderline at best and unreliable or non-functional at worst. It is very satisfying to open the map viewer and see the trails that the scout has blazed through the black areas (earning his keep). ;)

[Nasenbaer (nasenbaer)]

I worked a bit on a patch by cghislai he posted in bug #583985 - the scout seems to work very nice and smoothly now - but unfortunally WIdelands desyncs now in Multiplayer games. Anyone an idea?
The code can be found in lp:~nasenbaer/widelands/scout-fix

[SirVer (sirver)]

I took a look at your patch and the only thing that I see that I find strange is in run_scout a:

 ++state.ivar1;

that is not there in the trunk version and which sense I do not understand. Maybe that is a bug that leads to some randomness? Otherwise the patch look deterministic to me.

[Nasenbaer (nasenbaer)]

unfortunally not - without that part it does not crash, BUT it will run forever - actually the code in the repository is quite hacky and it's some kind of a wonder, that it works at all (see Nicolais Comments in bug #583985 )

the ++state.ivar1; tells the act engine, that the next step is reached, so this is a must. However I am not sure, whether it belongs on that point . perhaps it should be highered shortly before pop_task(game) in scout update. ???

[Nasenbaer (nasenbaer)]

okay at least the desync I had all the time is gone after rewrite of some code. Committed to trunk :)

[SirVer (sirver)]

Released in build16-rc1