News:

Use the "Forum Search"
It may help you to find anything in the forum ;).

a long-standing problem; smoke at factories

Started by Frank, July 22, 2018, 12:45:15 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Frank

For a long time it has been the case that smoke is not properly positioned at factories if the factory has multiple orientations.
The problem also exists when rotate the map.

Especially for factories with larger areas than 1x1, this is negatively noticeable.

In the picture as an example a factory with 3x2 area and 4 alignments.



Definition in the Dat
Smoke=Steam_2
SmokeTile=0,1
SmokeOffset=5,-70
SmokeSpeed=43


Dwachs

Can you please send me the dat/png of this factory? Will give it a try. There one needs another z-offset parameter.
Parsley, sage, rosemary, and maggikraut.

Leartin

Quote from: Dwachs on July 22, 2018, 05:43:11 PMThere one needs another z-offset parameter.
When the factory is not rendered but drawn, there are often no real rotations, but rather a mirrored image. In other cases, while there are "rotations", they are not necessarily precise in how they are placed on the tile.
So I would argue for manual placement akin to images.

Smoke[0][0][1][0][0][0]=Steam_2,5,-70
Smoke[1][1][0][0][0][0]=Steam_2,?,?
Smoke[2][0][0][0][0][0]=Steam_2,?,?
Smoke[3][0][0][0][0][0]=Steam_2,?,?

I think its self-explanatory for anyone who writes building dats. Besides the freedom to place the smoke wherever you want, this could also allow to place multiple smokes on the same building (but no more than one per tile) and change the smoke based on seasons (larger smoke-objects in winter). Since Shorthand-dats are a thing, it's simple to have smoke span multiple rotations or seasons as well:

Smoke[0-3][0][1][0][0][0]=Steam_2,5,-70
or, if there were seasons
Smoke[0-3][0][1][0][0][0-4]=Steam_2,5,-70

would cause the old behaviour for buildings that were planned to rotate around the chimney.

Dwachs

@Leartin: sounds like a reasonable suggestion. Will take longer to implement :)
Parsley, sage, rosemary, and maggikraut.

Leartin

Quote from: Dwachs on July 23, 2018, 05:02:20 AMWill take longer to implement :)
Sure, but it's not a new bug and does not affect gameplay, so there is no need for speed, quality is more important.

Vladki

I have partially implemented a patch for this, see this topic https://forum.simutrans.com/index.php/topic,16619.0.html
I just did not have time to finalize it. Now it is in working state (for pakBritain-128-ex), but needs some more config options, which are now hardcoded...
I also did not test with pakset that does not have rotated images for many buildings (like pak64/pak128)

The problem is that to get proper rotations, pakset designer has to specify 3D coordinates of the chimney exhaust. Xoffset/Yoffset is the base of chimney and the third coordinate is height.
Thus all paksets would need to redo the smoke offsets. I do not think that it is a big problem, as they are wrong anyway...

Patched code is available at https://github.com/vladki77/simutrans-extended/tree/smoke-improvements

Also there is a problem that the offsets have higher granularity than pixels, so precise smoke placement is not always possible. Another problem might be if the rotated images are not rotated precisely, and the chimney is at wrong position in some rotations.

Ters

Quote from: Vladki on July 24, 2018, 01:49:01 PMThe problem is that to get proper rotations, pakset designer has to specify 3D coordinates of the chimney exhaust. Xoffset/Yoffset is the base of chimney and the third coordinate is height.

Not really. One could alternatively specify the 2D coordinate of the chimney top in each image of it. I believe that is what Leartin is demonstrating.

Quote from: Vladki on July 24, 2018, 01:49:01 PMAlso there is a problem that the offsets have higher granularity than pixels, so precise smoke placement is not always possible. Another problem might be if the rotated images are not rotated precisely, and the chimney is at wrong position in some rotations.

This would not be a problem then. It needs more writing, but should be pixel perfect in every situation.

With some special non-values, one might even have smoke that only appear is certain seasons.

Leartin

Quote from: Ters on July 24, 2018, 06:34:56 PM
I believe that is what Leartin is demonstrating. [...] With some special non-values, one might even have smoke that only appear is certain seasons.
Exactly. Treat smoke object references as if they were image references, since smoke acts as animated images.

prissi

However, smoke is not an animated image, and it will be difficult to work it as that, especially if a factory has already an animation. THis would require a new building model. Currently smoke is a completely different object.

What would be much easier is something like
smoke[0]=20,7
smoke[1]=40,7
smoke[2]=20,27
smoke[3]=40,27
i.e. just explicity specify the offsets (and use pixel not itnernal units).

It would be quick and very easy to maintan backward compatibility.

Leartin

Quote from: prissi on July 25, 2018, 09:22:14 PMHowever, smoke is not an animated image, [...] smoke is a completely different object.
That's not even up for debate. A smoke is a seperate object that will spawn at a specific location on the screen. All that's questioned here is how to tell the game which position that is supposed to be. (and which, and how often, and...)

Quote from: prissi on July 25, 2018, 09:22:14 PMWhat would be much easier is something like
smoke[0]=20,7
smoke[1]=40,7
smoke[2]=20,27
smoke[3]=40,27
i.e. just explicity specify the offsets (and use pixel not itnernal units).
That's incomplete though. Unless you allow a thousend pixels offset, you'd need at least the tile information. With the old setup, that would mean:

SmokeTile[0]=0,1
SmokeTile[1]=1,1
SmokeTile[2]=1,0
SmokeTile[3]=0,0

And this does not tell you yet which smoke object is supposed to spawn.

My suggestion is basically the same, comparison:
Smoke=Steam_2
smoke[0]=20,7
smoke[1]=40,7
smoke[2]=20,27
smoke[3]=40,27

SmokeTile[0]=0,1
SmokeTile[1]=1,1
SmokeTile[2]=1,0
SmokeTile[3]=0,0

SmokeSpeed=43
vs:
Smoke[0]
  • [1][/color]
    • [/color]
      • [/color]=Steam_2,20,7
        Smoke[1][1][1]
        • [/color]
          • [/color]=Steam_2,40,7
            Smoke[2][1][0]
            • [/color]
              • [/color]=Steam_2,20,27
                Smoke[3]
                • [/color]
                  • [/color]
                    • [/color]=Steam_2,40,27
                      SmokeSpeed=43

                      How exactly the information is written in the dat doesn't affect how the game works. This only matters for makeobj - both writing styles could output the very same pak-file. However, mine has some benefits:
                      1.) It's exactly the same as for images, hence easy to understand for pak devs.
                      2.) It requires less lines, which is relevant if you write several buildings in the same dat file
                      3.) It's more flexible, allowing for seasons and multiple smokes in the same building. Of course, that's something the game would need to support first, rather than a matter of makeobj interpretation.

prissi

First, I was really thinking in coords, i.e. allowing 32000 pixel offsets for the smoke origin, measured from the left border. Simutrans would itself found the right tile below on loading the graph.

I found Smoke[0][0][1][0][0][0]=Steam_2,20,7 quite irritating. First the [0][0][0] part is useless. Also, without some larger changes, there is only one smoke type per building, so specifzing more will not give the desired result. Also the tile is an input parameter, not output, hence it must be on the right side of the "=" or it would break the logic of makeobj.

But it is debateable if Smoke[0]=0,1,20,7 or Smoke[0]=52,23 is easier for the painter. Since you paint more, well, I think your preference matters.

Leartin

Quote from: prissi on July 26, 2018, 08:27:17 PM
First, I was really thinking in coords, i.e. allowing 32000 pixel offsets for the smoke origin, measured from the left border. Simutrans would itself found the right tile below on loading the graph.
I see. Possible, but I don't like it, since everywhere else you'd work with tile coordinates and a limited offset.

Quote from: prissi on July 26, 2018, 08:27:17 PMFirst the [0 ][0 ][0 ] part is useless.
It absolutely is, but wouldn't it be like with image definitions, so if they are dropped they are zero? So you wouldn't actually have to write them, but I'd have them for clarity so people understand easier that it is just like images. (I'm not sure if it would break anything if there were more [0 ] than makeobj would expect, so I opted for including them, even if they do nothing)
On the other hand, different smokes depending on seasons could be a thing and would require the last slot. The animation slot could be used for new features as well, eg. syncing smoke to a building's animation.

Quote from: prissi on July 26, 2018, 08:27:17 PMAlso, without some larger changes, there is only one smoke type per building, so specifzing more will not give the desired result. Also the tile is an input parameter, not output, hence it must be on the right side of the "=" or it would break the logic of makeobj.
Those are not two seperate issues though. Since there is only one smoke for the building, it only asks where it is - hence it should be right of the "=". If there was one smoke per tile, you'd have to specify which smoke you want to activate, hence it's left of "=".

If anyone is willing to adapt the smoke code, I feel like it makes sense to improve it at the same time, especially if said improvements would make any band-aid-approach obsolete. As DWachs said, it would take longer - but  that shouldn't be an issue with an ancient bug like that.

prissi

The six brakets with images indicate pointer to pointer to pointer to pointer to pointer to lists. No exactly an efficient way of storage ...

Smoke would exactly inherent nothing of that, the brakets are unique for each thing. Also trying various numbers just to get the input is just unlelegant. Input should be input.

Seasonal dependent smoke is as unlikely/difficult as more than one smoke type per building.