geologist on one point

[LAZA]

I normally send 4 to 6 geologist to search for ore.
At the search for the ores sometimes 2, 3 geologist search at the same point. And if the first has finished the search and placed a sign the other still search on...

Either the search at one point should end, if the first geologist was successfull or it should be impossible to stay on the same point together.

Windows 7 with Widelands 5891

[Hans Joachim Desserud (hjd)]

I normally send all my geologist to one mountain at a time too. I've tried to observe them from time to time, but they seem to leave already marked areas alone. I have not seen them gather in the same place to search either.

I have not been able to reproduce this issue. If you are still seeing this, could you please attach a replay?

[LAZA (laza74)]

Ok, i was able to reproduce this.

Fresh installed Windows 7 and Widelands build-16.

- send some (i normally us 5, 6) geologists to a flag
- geologist1 begins search at point y,z for ore (where surely no sign is)
- geologist2 begins also search at point y,z for ore (still no sign, but geologist1)
- geologist1 finishes his search, leave a sign (whatever he found or not found), walks for another search
- geologist2 is still searching on...

I also made some screen shots if they are required

[Hans Joachim Desserud (hjd)]

Could you please attach the corresponding .wgf-file as well? It looks like I need both files to watch the replay.

[LAZA (laza74)]

I hope this works cause i played the mission till the end...

[Hans Joachim Desserud (hjd)]

Thanks for providing the requested information. Unfortunately the replay was from a campaign map, so I was unable to load it due to bug 647522. I realize this isn't your fault though. :)

Therefore I briefly played the second barbarian tutorial and expanding until I reached the mountain then sent out all my geologists. And yes, I could see them overlapping from time to time. The geologists should probably have some check if the area is occupied by another geologist or a search is in progress. This may actually be the case as I haven't looked at the code, so if two geologists decide to go to the same spot when they are elsewhere they will both see it as unoccupied but arrive there at different times. Perhaps they should claim the different spots so that the other geologists will know that someone will deal with that spot?

[LAZA (laza74)]

Sorry, i knew until now the bug before.

This is what i exactly mean:
The spot, where an geologist is searching should be 'blocked' by code of other geologists, at the moment he decides to search exactly there.
An alternative behavior would be (like in Settler 1) that they must return after the search to the flag (they where send out) and "leave there a message" where he would search in the next turn and no other goes to this spot.

[cghislai (charlyghislain)]

I think that for foresters there is already a 'book that spot' feature that was relased some builds ago. This could be used in more places, i also think of fishers/breeders, farms, ...

[SirVer (sirver)]

Setting to incomplete for bug sweeping.

[Hans Joachim Desserud (hjd)]

If foresters are indeed booking their spots ahead of time, we should look into whether this would make sense to do for other worker types too. If they aren't we should discuss how hard it would be to add such a feature and whether it would have a noticable impact.

Someone needs to check the code though...

[Launchpad Janitor (janitor)]

[Expired for widelands because there has been no activity for 60 days.]

[Jens Beyer (qcumber-some)]

No, foresters are not booking their places ahead of time. The current implementation does not do that.

Lumberjacks do that. They are marking the trees they are about to cut down.

Spots are not "bookable", the implementation is in Immovable. I don't know if it would be possible to create an invisible immovable at the place, maybe a new command is necessary (createobject at the place of the space found), which then could be the target to run to.

A fix inbetween those solutions would be that a forester/geologist runs to a spot, sets an invisible immovable and reserves it, and other foresters/geologists check upon arrival on their predetermined spot if in the mean time another forester/geologist reserved the space.
Please note that this type of "blocking" should be used for all workers equally, also between different jobs (otherwise a forester may still dig out a field, or a geologist puts a sign where a forester just planted a seedling).

[wl-zocker (wl-zocker)]

Wouldn't it be easier to change to booking to a field (for lumberjacks, too)? Two workers (even of different types) would then never work on the same spot.

I would also like to mention bug 1407418 (Multiple hunters hunt for same animal), maybe there is something useful.

[GunChleoc (gunchleoc)]

I don't think we can easily have a common solution for hunters and other workers, because fields aren't MapObjects. I like the idea of booking a field. Invisible immovable should also work; that's how ship construction works.

[Jens Beyer (qcumber-some)]

We have at least four different types of "working places" by worker programs:

- hunters:
find_object, they do not need to reserve a place, but reserve a bob

- lumberjacks, stonemason, gamekeepers:
find_object, they do not need to reserve a place (because their place is obstructed anyway for any other interaction by the immovable), but reserve an immovable

- foresters, farmers:
find_place, they need to reserve a place

- geologist:
completely own program, need to be able to reserve a place like foresters/farmers

I don't currently know in which type the shipwright belongs, I would guess foresters/farmers.

What we see is: the current "object tagging" can not be given up for a more general "place tagging", because of the hunters. We will probably need both mechanisms, and I currently don't know if they even need interaction between each other, but I would tend to no.

[wl-zocker (wl-zocker)]

Gamekeepers also use findspace, not findobject.

Shipwrights could use the construction site as an immovable, it is visible (and has a small size, I think).

I see three ways:
1) MapObjects and fields can be tagged. Use any of them for lumberjacks/stonemasons.
2) Bobs and fields can be tagged. Tag the field of a tree/rock.
3) Only tag MapObjects, and use invisible MapObjects for findspace.

When an object/field is tagged, no other worker is allowed to use it.

The only problem might be that hunted animals run on a tagged field, and then the hunter and the farmer work on the same field. But we can't predict where animals run, so just ignore it.

[Jens Beyer (qcumber-some)]

Regarding gamekeepers:

Strange, looking at the code you are right, but I seem to remember (long ago) gamekeepers searched for a tree, walked there, then searched for a near free space, walked there, and then released the animal. Or am I now mixing in an idea I had about "more fun gamekeepers"?
Still, I always place gamekeepers near lumberjack/ranger spots, and now learn that is totally useless... ;-)

Regarding hunted animals:

Yes, ignoring that would be spot on. The animal can run around a tree/field anyway one second later.

[wl-zocker (wl-zocker)]

> Strange, looking at the code you are right, but I seem to remember (long ago) gamekeepers searched for a tree, walked there, then searched for a near free space, walked there, and then released the animal. Or am I now mixing in an idea I had about "more fun gamekeepers"?
> Still, I always place gamekeepers near lumberjack/ranger spots, and now learn that is totally useless... ;-)

You are not the only one. In the forums, there are from time to time people who think that gamekeepers must (or should) be placed near trees. I do not know whether that has ever been like that, or whether someone had this idea and it spread.

[GunChleoc (gunchleoc)]

Migrated to https://github.com/widelands/widelands/issues/1288