The International Simutrans Forum

 

Author Topic: Add parameter in .dat to force platform endings when mixing platforms  (Read 6250 times)

0 Members and 1 Guest are viewing this topic.

Offline Ves

  • Devotee
  • *
  • Posts: 1675
  • Languages: EN, SV, DK
Dear all dev's

With the intruduction of alpha blending for all graphics (a BIG thank you!!) new and more interresting graphics coming from that presents some new difficulties. I am in the process of painting some platforms, and these particular platforms are covered with a big arch roof. On top of the roof there are windows so you can view down into the platform, and at the ends of the roof there is a big glass wall.
I am coding the platform with dims=1,1,16 in order for the "end caps" on the big roof only to be painted at the actual ends of the platforms, since it would otherwise be visible through the roof windows if they where repeated every tile.
However, the player might not want to cover the entire platform with this roof, as in reality only half the platform is actually covered, and the rest is bare.
But if you try to do that in Simutrans you would get the result as pictured below:


The two leftmost roof's have had their endcaps removed due to the platform thinking that it continues. The platforms to the right is showing how it is supposed to look.

So I would like to ask you to consider add a .dat parameter to platforms called keep_integrity=1 (in lack of better naming) that would treat the covered platform as its own unit. It would thereby always draw the end tiles if it senses that its neighbor platform has another name. Also, if it where to be a single tile platform with keep_integrity=1 surrounded by alien platforms, it would draw its stand-alone graphic.
The platform without keep_integrity=1 would behave like normal and "connect" to all platforms like it usually does (including the ones with keep_integrity=1), which means that there should be no downfalls I believe. Since no existing platforms would have that particular parameter by default they would fall back to the original rules and connect to everything as usual.

Would there be any interest, and would this be doable?

Offline gauthier

  • Devotee
  • *
  • Posts: 3628
    • SNFOS'website (in both FR and EN)
  • Languages: FR, EN, JP
Re: Add parameter in .dat to force platform endings when mixing platforms
« Reply #1 on: March 10, 2019, 07:53:36 PM »
Sounds not so difficult to do though I don't know this part of the code.
To go further, separating platforms from roofs would be nice too  ;D

Offline Leartin at

  • Devotee
  • *
  • Posts: 1264
  • PAK-DEV P192C
  • Languages: DE, EN
Re: Add parameter in .dat to force platform endings when mixing platforms
« Reply #2 on: March 11, 2019, 05:22:05 AM »
To go further, separating platforms from roofs would be nice too  ;D
A similar thing was suggested for wayobjects. Though not directly related, there are parallels, and if either gets into the game, the other should follow suit in how it works.

Tough I'm not sure if this isn't more of an arguement for two other suggestions:  Stop cutting stuff under elevated ways and directional/assymetric way graphics (which pop up at least in every discussion about functional oneway-roads, but also as purely decorative element) - Essentially, you'd create station roofs as elevated ways, which means you can easily drag and drop them over any platform, and they would only connect to other roofs. Of course, you also need a free waytype.

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2703
    • My addons, mostly roadsigns
  • Languages: EN, CS
Re: Add parameter in .dat to force platform endings when mixing platforms
« Reply #3 on: March 11, 2019, 07:42:31 AM »
But how could such elevated way affect station capacity? Sounds quite like a nasty hack... Like what I did to build a funicular few years ago.

Offline Ves

  • Devotee
  • *
  • Posts: 1675
  • Languages: EN, SV, DK
Re: Add parameter in .dat to force platform endings when mixing platforms
« Reply #4 on: March 11, 2019, 01:55:52 PM »
Well, those suggestions/extension requests are also usefull indeed, however it is easily wandering away from what this is about. For the design I have painted, the example is with the covered arch, but it could be something else that the painter thinks should keep its own integrity, for instance smaller platform buildings. The covered arch in my design is not purely a cosmetic thing, since it should be expensive to build and have a higher capacity, compared to an uncovered platform.

Although very interresting and intriguing, I do not believe that the idea of overlaying the platform with the arch is the correct solution, first since it is quite a fundamental change, especially if you want the arch to have economic effect too. Second, that would create difficulties with the integration between the arch and the platform. Now the arch might be easy because it is only tiny legs that connect it to the ground, and potential graphics mismatch wont be too bad, but what if it where to be used as buildings along the platform? Then you would risc that the buildings float or sinc into the platform dependent on how they have been painted and the alignment between the platform (which may vary in height) and the building. That could be solved with datfile offsets that determine how high a platform is, but the complexity just grows on and on......
If Simutrans where to be developed from scratch today, I would argue much strongly for that idea, but instead, I believe that potential archs, buildings, benches etc should be painted together with their platforms to always ensure that there are no graphic conflicts. And hence a need for more tools, and in this case, a tool to keep the integrity of the platform (structures).

I also had a brief look in the code at
Code: [Select]
// build all types of stops but sea harbours
const char *tool_build_station_t::tool_station_aux(player_t *player, koord3d pos, const building_desc_t *desc, waytype_t wegtype, sint64 cost, const char *type_name )
which appears to localize what layout surrounding station tiles has,
as well as
Code: [Select]
void gebaeude_t::cleanup(player_t *player)which appears to be doing something with the layout of buildings.

Offline Leartin at

  • Devotee
  • *
  • Posts: 1264
  • PAK-DEV P192C
  • Languages: DE, EN
Re: Add parameter in .dat to force platform endings when mixing platforms
« Reply #5 on: March 11, 2019, 03:46:34 PM »
But how could such elevated way affect station capacity?
Not at all, why would a roof affect capacity anyway?

It wouldn't make too much sense for both platform and roof to affect capacity, and the amount of possibilities surely are not required for the gameplay. Therefore, this would make perfect sense to me as a purely decorative element. Even if it was implemented in any other way, not both platform AND roof should affect capacity, but only one. Though in that case, I'd go for stations being defined by their roof, with different options what the platform underneath should look like, instead of the other way around.


Ves, I'm not sure if your suggestion even works the way you want unless there is a destinction between roof and platform. It seems as if your platform is one with only four rotations, so just think about what would happen if it had 16 rotations by itself, with a visible edge? You'd have that edge in the middle of the platform, where the roof ends.
While the roof should not try to connect, the platform should. In your specific case here, you might not care about it, but I can assure you that pak192.comic would be very interested in something similar to that, but it wouldn't work for us due to platforms being 16-rotational by themself, even without roof.
PERHAPS you could circumvent it if platforms without integrity still connected to those with integrity, and the integrity-platform would simply not have a platform end. Though that would mean it would look wrong if the user wouldn't build another platform at the end, and you can expect most users to simply not do that.

So if there was a vote, I'd vote against your suggestion the way you present it, but if the platforms could connect while the roof wouldn't, I'd vote for it. And I guess that either works by seperating roof and platform (allowing other tricks), or by implementing "32-rotational" which has a different connection to other platforms than to itself...

Offline Ves

  • Devotee
  • *
  • Posts: 1675
  • Languages: EN, SV, DK
Re: Add parameter in .dat to force platform endings when mixing platforms
« Reply #6 on: March 11, 2019, 04:22:36 PM »
Ves, I'm not sure if your suggestion even works the way you want unless there is a destinction between roof and platform. It seems as if your platform is one with only four rotations, so just think about what would happen if it had 16 rotations by itself, with a visible edge? You'd have that edge in the middle of the platform, where the roof ends.
I did indeed write in my OP that platforms with dims=1,1,16 without keep_integrity=1 should connect to anything as they already does, also platforms WITH keep_integrity=1, although I was perhaps not very clear with my writing. The naked platform in the picture actually is also coded with dims=1,1,16 and are planned to have a nice ending, but I have not come around to do that yet.

Quote
While the roof should not try to connect, the platform should. In your specific case here, you might not care about it, but I can assure you that pak192.comic would be very interested in something similar to that, but it wouldn't work for us due to platforms being 16-rotational by themself, even without roof.
PERHAPS you could circumvent it if platforms without integrity still connected to those with integrity, and the integrity-platform would simply not have a platform end. Though that would mean it would look wrong if the user wouldn't build another platform at the end, and you can expect most users to simply not do that.

So if there was a vote, I'd vote against your suggestion the way you present it, but if the platforms could connect while the roof wouldn't, I'd vote for it. And I guess that either works by seperating roof and platform (allowing other tricks), or by implementing "32-rotational" which has a different connection to other platforms than to itself...
I see your point on this. Yes my approach was to make the covered platform look good by it self as well when connected to other platforms, but I can understand that might not be enough in some cases. It would only demand four extra tiles of platforms (one for each direction) but perhaps the internal workings are quite different than what it appears to be? What does people with code insight say on the matter, is it doable?

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2703
    • My addons, mostly roadsigns
  • Languages: EN, CS
Re: Add parameter in .dat to force platform endings when mixing platforms
« Reply #7 on: March 11, 2019, 06:28:15 PM »
What about having another set of images (dim=24) for transition between different platform types. Those that have 16 or less would use the normal "middle" image.

However the problem Ves is having will happen also for dead end platform that connects to station building or stop on different way type.


Offline Isaac.Eiland-Hall us

  • Benevolent Dictator
  • Administrator
  • *
  • Posts: 3651
  • PanamaCityPC.com/support/
    • Facebook Profile
  • Languages: EN
Re: Add parameter in .dat to force platform endings when mixing platforms
« Reply #8 on: March 11, 2019, 09:18:34 PM »
why would a roof affect capacity anyway?

It should limit capacity as you can't stack things as high any more. ;-)

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2703
    • My addons, mostly roadsigns
  • Languages: EN, CS
Re: Add parameter in .dat to force platform endings when mixing platforms
« Reply #9 on: March 11, 2019, 09:28:39 PM »
It should limit capacity as you can't stack things as high any more. ;-)
Uhm, thinking about Indian railways, removing roof from their coaches, would reduce the capacity... As nobody could ride on the roof.

Offline wlindley us

  • Devotee
  • *
  • Posts: 978
    • Hacking for fun and profit since 1977
  • Languages: EN, DE
Re: Add parameter in .dat to force platform endings when mixing platforms
« Reply #10 on: March 12, 2019, 01:37:15 AM »
If station buildings could have this too, things like the Pak128.Britain stone station could keep the proper parapet borders even when combined with other buildings.