MULTIPLE FIELDS (Was: Animation for fields)

[VS]

Would it be possible to extend field objects so that they can be animated?

After talking with vilvoh about the solar power plant we realized this would be nice and does not exist yet. Apart from solar collectors, pak128.Britain has oil derricks that could profit from this, too...

[vilvoh]

Not only for solar power plants, but also for wind farms, animated cotton fields, etc.. The idea has lots of possibilities. 

[Fabio]

Another, similar: multiple fields for the same industry (field1, field2, field3, etc...)
This, used wisely, could have astounding results.

[prissi]

Use buildings for this. Animations are the most time consuming activity now, since the routing was optimized. Any animated opbeject consumes about half as much power as a vehicle. Same goes for multiple fields.

[Fabio]

Use buildings for this. Animations are the most time consuming activity now, since the routing was optimized. Any animated opbeject consumes about half as much power as a vehicle. Same goes for multiple fields.

The powerful thing about (multiple) fields is that they could allow all unique factories, because every individual factory would assemble the fields/parts in an unique way.

[prissi]

Then use multiple factories. Otherwise there would be additional logic needed, what kind of field are to be built when. For eyecandy a little too much effort for me at least.

[knightly]

I think Fabio's suggestion is quite good. So I have written a patch for it.

As an example, below is a farm with various different fields (compiled from Pak128.Britain sources) :
us (site down, do not visit) ]/image/show/w5K0DmSqMh/manor.png]Demo image

Sample dat file definitions :

Code Select Expand


probability_to_spawn=30
max_fields=300
min_fields=50
fields[0]=CattleField
has_snow[0]=0
production_per_field[0]=3
storage_capacity[0]=4
spawn_weight[0]=100
fields[1]=GrainField
has_snow[1]=0
production_per_field[1]=5
storage_capacity[1]=8
spawn_weight[1]=400


I have added storage capacity for fields, as it is not reasonable that we keep increasing production base without any increase in storage space to cope with the increased throughput. This value is distributed evenly among the raw material and finished product storages.

With this new feature, you can create a barn or a dumping ground for storage. Any field can contribute to production and/or storage, or even neither of them, as in the case of decorative trees. The default value for storage capacity is 0 to avoid breaking existing pakset balance.

There is also a spawn weight value. Firstly, the probability_to_spawn value will be used to decide whether we will create a new field. Once it is decided that we will create one, the spawn weights will be used to determine which of the available fields will be created.

For instance, fields A, B and C have spawn weights W_a, W_b and W_c respectively. So the chances of creating each are :
   Field A :  W_a / ( W_a + W_b + W_c )
   Field B :  W_b / ( W_a + W_b + W_c )
   Field C :  W_c / ( W_a + W_b + W_c )

Testing and comments are welcome

[Dwachs]

  thumbs up!

[knightly]

Thanks, Dwachs

[prissi]

I still think, different fields would be only for different goods. Sheep fields for cotton and grain fields for grain.

And imho the image shows, that there is additional logic needed to cluster the fields more. This random assignement looks wierd to me.

[VS]

Thanks a lot, the demo looks very nice - I can't wait to see what will come out of this

prissi: You are right, but one could use this to add more subtle variety [than in demo], which would help break the grid. Not fields, barns, and trees, but 3 types of trees for example...

[knightly]

@Prissi

The demo image is just for illustration only -- sure you won't expect me to actually paint something just for the sake of illustration ? I think the painters should be wise enough to use it in the right way.

As for field clustering, I have also thought about it, but has not come up with an efficient approach yet.

[VS]

I'd simply let it be and have the authors live with random distribution, constrained only by chances.

[Fabio]

prissi: You are right, but one could use this to add more subtle variety [than in demo], which would help break the grid. Not fields, barns, and trees, but 3 types of trees for example...

Exactly my point: Different trees or (for forest plantation) trees with different age; 4-7-8 sheeps and standing in different position, 3-4 barns with different colour...

[prissi]

I get your points; in that case it would make sense (and do not forget to step up makeobj to 51 ... )

[Fabio]

Renamed topic and moved to considered -Fabio

[prissi]

While I am not basically against it, moving patches here should be done after basic code review. This is the task of any developer (and only developer only). It would strongly wish to keep it that way (even though Knightly is a developer member). For instance this patch lacks stepping up the makeobj revision number.

[knightly]

Prissi,

I think the version problems can be considered after this patch has undergone enough testing for it to be ready for incorporation. Even the save game version checking for fields loading and saving may need to be changed, as the stable branch may need version stepping? Besides, I would like to incorporate the following makeobj-related patch alongside with the multiple fields patch, provided that there is no objection :
http://forum.simutrans.com/index.php?topic=4203.0

[prissi]

Well, this is already in considerate.

Back to this patch. I am naerly 80% convinced, that it help simutrans. How does an old version work with this: Does it do a reasonable error message (like version mismatch?) or just crshes. If this is the case, it can go in. Otherwise the factory_besch version needs to be stepped. (I think it is, but honestly I just forgot. YOu know better anyway ... )

[knightly]

How does an old version work with this: Does it do a reasonable error message (like version mismatch?) or just crshes. If this is the case, it can go in. Otherwise the factory_besch version needs to be stepped. (I think it is, but honestly I just forgot. YOu know better anyway ... )

Sorry, Prissi, but by "an old version", which thing -- game engine? pak file? save game? -- are you referring to?

As for stepping besch version, I have done it for the factory field only. If you open a factory (with fields) pak file created after applying this patch with an old version game, there will be version mismatch while reading the factory field node, and the following is executed :

dbg->fatal("factory_field_reader_t::read_node()","unknown version %i", v&0x00ff );

Is this what you are asking about?

[prissi]

Yes; I was unsure, since you also introduced a new class, which would have been read first. Unknow class given an error message of a broken file, if I remember correctly. ANd testing, i mean with an old version (i.e. the "stable" simutrans executable.)

[knightly]

The new besch type is the child of the original field besch, and will always be written/read after the field besch itself. Since an "old" stable version will halt with a version mismatch error at the field besch node, nothing further will be read and the unknown class error that you are worrying about will never happen.

To be sure, I have just tested a stable with the demo pak file -- only version mismatch message is shown and exit upon key press.

[prissi]

Well, this is now in considered, so go ahead.

[knightly]

Just want to make sure -- can I commit the patch for the image writer/reader too? As that also involves makeobj. Save you from asking , the image node is already properly stepped, and an "old" stable will show version mismatch.

[prissi]

Just do it.