Multi tree-cuts

[a-non-ymous]

I noted that 3 lumberjacks were working on the same tree..
they keep working yet when the first one brings the trunk to home.

[Jens Beyer (qcumber-some)]

This also applies to stonemasons

[Jens Beyer (qcumber-some)]

This can be done with lots of changes in worlds files, a good share of additions, and a few in tribes, also for quarries.

I guess this might break savegames, or not (depends if we need to remove programs or just add new ones).

Might be worth trying a more advanced approach with changing source code.

[Nicolai Hähnle (nha)]

I have a suggested fix in my fixes branch. Since it changes behavior, it should be merged after the build-15 release.

[SirVer (sirver)]

I reviewed your changes nicolai and want to propose another solution: extending the attrib properties of immovables. I am not sure how they are implemented, but I remember that they are not as flexible as they could be. I know that an attrib "tree" exists that markes an immovable a tree. I suggest adding another attrib "claimed" or "reservered" that is set by a worker program. It would be the best if the name of attribs could be assigned freely.

Those attribs could then also be sensed by Lua scripts and allow easier identification of various things. Also Lua scripts could put attribs on objects to "mark" them for the game.

[Jens Beyer (qcumber-some)]

When tinkering with the attribs, please be aware that it is possible to rip a lumberjack's house just in the ten seconds while he chops that tree. I had the same issue with my solution with changing the world files, they also depended on changing attribs. Result was, if not done cautiously, immortal trees which were never again touched by a lumberjack :-)
This is solvable though, just a note that this is necessary to check/test.

[Nicolai Hähnle (nha)]

#4: I think the attributes you are referring to are the ones realized by Map_Object::has_attribute. They are not per-Map_Object, but per Map_Object_Descr. So all instances of a certain object type always have the same attributes.

I briefly considered changing this or adding an additional per-instance attribute scheme to Map_Object instead of the current solution. The reason why I didn't do this were:
1. I didn't want to put too much data into Map_Object that is only used by a fraction of the objects.
2. Integrating this so that load/save works properly is nasty because there are still many object types that don't use the new style load/save infrastructure (and the old load/save infrastructure doesn't nicely reflect inheritance).
3. I couldn't imagine an actual use case for a more flexible attribute system.

Since you invalidate number 3, I believe that also number 1 isn't such a big deal anymore. How many attributes are we talking about, typically? Perhaps it would be sufficient to use a 32-bit bit field. As for number 2, that's still an issue. However, I was looking at converting more classes to the new load/save system anyway. So in the long run, sure, this could be changed.

#5: True. I believe the current implementation is safe against that, due to safe guards e.g. in Worker::program_pop.

[Samith Sandanayake (samithdisal)]

What about linking the tree to the hut if possible :)

[SirVer (sirver)]

#6: I thought about giving full flexibility, so that map designers could use every name for an attribute they like. As I have no use case atm, I'd suggest to use your current solution which is easy to extend. When designing the API to handle attributes, I make sure to keep it extendable to such a scheme without breaking compatibility.

[Nicolai Hähnle (nha)]

I agree. I was thinking of using numerical attributes internally for smaller storage and efficiency, combined with a global string to attribute map. So map designers could use any name, and the name would transparently be translated into an ID for the purpose of storing attributes inside Map_Objects.

#7: The tree is implicitly linked to the worker right now, which should be more or less the same thing :)

[SirVer (sirver)]

Nicolai, but there is no use case for such a feature at the moment. I would implement it as soon as a scenario asks for it.

[Andi Hotz (andi-hotz)]

As mentioned above this applies also to stone masons but as well forester, fisher, fish breeder, hunter and game keeper.
Revision 5778.

[SirVer (sirver)]

Released in build16-rc1