The International Simutrans Forum

 

Author Topic: New system for elevated ways (inc. half height and uneven terrain)  (Read 5694 times)

0 Members and 1 Guest are viewing this topic.

Offline Sirius

  • Devotee
  • *
  • Posts: 1657
  • Languages: DE, EN
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #70 on: January 14, 2022, 06:19:26 PM »
In any event, I should be very interested in any other players' feedback on the pier system, including but not limited to the issues raised above.
I had been ocupied for a while.

16. Future treatment of elevated ways (New)
At least in the long-term, i.e. when most active paksets have adapted their graphics, elevated ways in old savegames should be converted to elevated way supports + way.
In the short term, it seems preferable to convert existing elevated way objects into elevated way support + way using the elevated way graphics.
As to the lack of proper graphics and additional dat file definitions, these could not support the whole feature set of elevated way supports.
I see that this conversion might not be quite trivial, so this is of rather low priority.

The reason for this is because some objects in the simuworld interact with elevated ways in a specific way and there are still some bugs around elevated ways, which retains complexity to maintain.
Converting these surely adds some complexity as well, but it's all in a single place and such conversion bugs will be much easier to detect.

In any case, I don't think it's a good idea to maintain elevated way construction for the public player. I see the merit in this as to allow "fixing" accidentally deleted elevated ways, but is this really that useful?
There already exist many cases where constrcution of elevated ways had one day been possible but is not anymore. E.g. when a large building has spawned underneath afterwards or elevated ways that have been constructed over airports or public buildings in an old version.
If we want public service to allow for some "cheating", we should instead disable some collision or constraint checks of the new elevated way support system when using public player.
Disabling such checks, the new system can offer all use cases that the old elevated way system has offered (and which are intentionally restricted by the new system) and even more!


I should be interested in others' views on this - certainly, I should find it much easier if one could build continuations of piers in the same way as one could build continuations of ways.
It is not quite clear which exact behavior you mean by this.
Relevant advantages of the new system over the old one are handling of uneven terrain as well as the ability to build at any height, not only one tile above ground.
When building elevated structured, I don't think the old behavior of following ground level is desirable in most cases, so in these points it is quite good that the new tool behaves differently.

In other points, I'd prefer a more consistent behavior as well, but I understand that it might not be quite simple to achieve.
I'd prefer junction/crossing construction to be just as simple as building those on elevated ways. Use any way of the same type, connect adjacent grounds, done.
Also I'd pferer slope adjustments to be as simple as on ways. Simply raise or lower an end-tile to alter the slope.
Furthermore, I'd like to see the two-click tool construction style here, just as in usual ways.
But again, I see why these might be rather difficult to implement and I don't think this consistency is mandatory at any cost.


10. The way of building slopes in different directions is inconsistent with the system in the landscape tools: in the landscape tools, there is one button for each direction, whereas for the piers, there is a single button, which brings up a submenu of the different directions. Ideally, the landscape tool would work as the pier tool does, but failing this, a tooltip explaining to the player that the direction can be selected by CTRL+clicking is necessary to prevent confusion, I think.
A combination of both feels most user freindly to me:
One icon per direction will mess up the menu quite much.
Using ctrl to get a submenu is not intuitive at all. You'll always need a description of this behavior.

There is no sensible definition of a "default direction" for slopes. You always want to build slopes in a specific direction.
So why don't you open a submenu when clicking on the slope icon? Just as default behavior without ctrl involved?
Might even put both slopes in the submenu: single and double.
« Last Edit: January 14, 2022, 07:31:38 PM by Sirius »

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 21026
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #71 on: January 14, 2022, 10:41:36 PM »
Attempting to test this on my Windows system at home, I am getting a compile error. When first merging, a reference to a file called sys\simsys_w32_png.cc is added to the Visual Studio project file, but, in fact, no such file exists. I cannot find it in your Github repository, nor the latest Standard Github repository.

If I remove this file I get linker errors: the compiler expects raw_image_t::raw_image_t(), raw_image_t::~raw_image_t() and raw_image_t::write_png() to be defined, but they are not.

This appears to be associated with this change from Standard from February 2021, which I assume that Ranran must have merged at some point recently.

I should be grateful if you could look into this so that I can compile and test this on Windows. Thank you.

Offline Roboron

  • Devotee
  • *
  • Posts: 440
    • Las Galácticas Aventuras de Komoyo Diga
  • Languages: ES, EN
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #72 on: January 15, 2022, 12:18:58 AM »
If I remove this file I get linker errors: the compiler expects raw_image_t::raw_image_t(), raw_image_t::~raw_image_t() and raw_image_t::write_png() to be defined, but they are not.

I'm afraid that is my fault. When working on porting the CMake improvements from Standard, I incorporated those files as part of the changes. However, I forgot to add them to the makefile/vsproject. Since the CMake implementation itself was not "completed" because of the failing zstd build, I did not test the other build systems. I believe Sirius noticed and assigned itself such task, but it is still not done obviously. 

Luckily, I found the fix for the failing zstd two days ago and already was planning on a new PR with both of those things fixed, finally completing the port https://github.com/simutrans/simutrans-extended/pull/11

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 21026
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #73 on: January 15, 2022, 12:34:09 AM »
I'm afraid that is my fault. When working on porting the CMake improvements from Standard, I incorporated those files as part of the changes. However, I forgot to add them to the makefile/vsproject. Since the CMake implementation itself was not "completed" because of the failing zstd build, I did not test the other build systems. I believe Sirius noticed and assigned itself such task, but it is still not done obviously. 

Luckily, I found the fix for the failing zstd two days ago and already was planning on a new PR with both of those things fixed, finally completing the port https://github.com/simutrans/simutrans-extended/pull/11

Thank you. Can I clarify - is that a pull request for the master branch or the piers branch?

Offline Roboron

  • Devotee
  • *
  • Posts: 440
    • Las Galácticas Aventuras de Komoyo Diga
  • Languages: ES, EN
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #74 on: January 15, 2022, 01:12:52 AM »
That is a pull request to the master branch of simutrans/simutrans-extended, which is the fork where work started on the new nightly build system. In the middle of this process, the the pier system branch was created from this fork, and not from jamespett/simutrans-extended. So that explains why you have two open PRs with the same issue.

I am also getting a bit lost at this point with that many forks, but I guess that currently the order of procedure would be:

1. Merge my PR for simutrans/simutrans-extended.
2. Merge the Nightly Builds PR for jamespett/simutrans-extended (which will be updated after my PR is incorporated).
3. Merge the Pier system PR for jamespett/simutrans-extended (which at this point should be able to be compiled without using CMake).

Offline PJMack

  • *
  • Posts: 81
  • Languages: EN
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #75 on: January 15, 2022, 01:42:44 AM »
However, I forgot to add them to the makefile/vsproject.
I had noticed the makefile stopped working during a merge, but thought it was only a merge error for the pier branch.  I made the corrections during the merge, but for some reason the history in gitk is not showing all of the changes I made.  I do remember having to add libpng to the linking flags and change the source listing to comply with the changes in commit number 3685abc444b26b084710a6f8b4a748aedac9bf66.

For visual studio, I would imagine that the procedure would be similar.

Offline Roboron

  • Devotee
  • *
  • Posts: 440
    • Las Galácticas Aventuras de Komoyo Diga
  • Languages: ES, EN
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #76 on: January 15, 2022, 02:23:34 PM »
I think you refer to this merge https://github.com/jamespetts/simutrans-extended/commit/c2347e71d6550d87cc3351a201f849dbf99037f9#diff-76ed074a9305c04054cdebb9e9aad2d818052b07091de1f20cad0bbac34ffb52

Well if you made parallel changes, then that should be solved too.

I'm also getting compilation errors on raw_image.bmp when trying to compile on MSVC that I can't reproduce with CMake + MSVC, so someone please tell the PR first.
« Last Edit: January 15, 2022, 02:52:31 PM by Roboron »

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 21026
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #77 on: January 16, 2022, 12:31:36 AM »
That is a pull request to the master branch of simutrans/simutrans-extended, which is the fork where work started on the new nightly build system. In the middle of this process, the the pier system branch was created from this fork, and not from jamespett/simutrans-extended. So that explains why you have two open PRs with the same issue.

I am also getting a bit lost at this point with that many forks, but I guess that currently the order of procedure would be:

1. Merge my PR for simutrans/simutrans-extended.
2. Merge the Nightly Builds PR for jamespett/simutrans-extended (which will be updated after my PR is incorporated).
3. Merge the Pier system PR for jamespett/simutrans-extended (which at this point should be able to be compiled without using CMake).

Thank you for this.

I have merged from your master branch into my nightly-builds branch (which I have pushed), but, unfortunately, I get the following compile errors:

Code: [Select]
Severity Code Description Project File Line Suppression State
Error C2059 syntax error: 'constant' Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\io\raw_image_bmp.cc 57
Error C2143 syntax error: missing ';' before '}' Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\io\raw_image_bmp.cc 60
Error C2059 syntax error: '}' Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\io\raw_image_bmp.cc 60
Error C1083 Cannot open include file: 'miniupnpc/miniupnpc.h': No such file or directory Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\network\network.cc 890

Offline Roboron

  • Devotee
  • *
  • Posts: 440
    • Las Galácticas Aventuras de Komoyo Diga
  • Languages: ES, EN
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #78 on: January 16, 2022, 01:03:17 AM »
The syntax errors are exactly the errors I was referring to in my last message. It also happens to me. However, it is unlikely that they are truly syntax errors, because:
1) the raw_image_bmp.cc is a verbatim copy from Standard
2) make (and msbuild when called using CMake) don't throw any errors
What is the root cause then? I don't have idea. I can have a second look, but I don't have much hope.

Quote
Cannot open include file: 'miniupnpc/miniupnpc.h'

I had to change the miniupnpc includes because otherwise the automated build would fail with the default installation of the miniupnpc library (vcpkg and linux repositories). This error is unrelated with the previous, but it indicates that you don't have miniupnpc in a standard include directory.

=> https://github.com/Roboron3042/simutrans-extended/commit/dbc5612725ee9d690e01fc06083a40869e0b5114

You should probably look at your miniupnpc include path, specially if it is a custom installation.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 11060
  • Languages: De,EN,JP
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #79 on: January 16, 2022, 01:14:54 AM »
MSVC often complains about totally unrelated things if a semicolon or something is missing way above the offinding line or a missing include. Thus got really annoying in the newest MSVC. The real syntax error is  usually way up (an may be even a warning, like statement does not evaluate or so). Please look for warnings in the same file above this offinding line. It will be often cause by a semi-legal statement.

cmake msvc may using clang for building, which can generate different error messages, depending on you setting. I think clang is default for CLI use.

Offline Roboron

  • Devotee
  • *
  • Posts: 440
    • Las Galácticas Aventuras de Komoyo Diga
  • Languages: ES, EN
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #80 on: January 16, 2022, 04:53:19 AM »
First, in the process of trying to fix this I incorporated the rest of the r9620. Well, it didn't fix the issue, and it caused other builds to fail when I pushed the changes, so I reverted it for now.

Second, renaming the "constants" allowed me to compile without errors. This may indicate that there is a library being imported somewhere that already define constants with those names. Since not CMake nor the Makefile had such problem, it is probably a missconfiguration in the Simutrans-Extended.vcxproj. Furthermore, it probably has something to be with simsys_w.cc since one of the constants also appears there.

However, the Simutrans-Extended.vcxproj is a labyrinth to navigate for me. And if I pushed for CMake was precisely to avoid it. So I'll stop here. You can look at the configurations and try to fix it, or you can embrace the rename fix which is not the correct solution but it will do the trick...

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 21026
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #81 on: January 16, 2022, 01:31:05 PM »
Thank you for this. I did indeed have a clashing miniupnpc directory - I think that I have fixed this issue with a custom preprocessor definition to revert to the old locations if specified or else use your new locations.

Oddly, initially, I got linker errors:

Code: [Select]
Severity   Code   Description   Project   File   Line   Suppression State
Error   LNK2001   unresolved external symbol "public: static unsigned char __cdecl raw_image_t::bpp_for_format(enum raw_image_t::format_t)" (?bpp_for_format@raw_image_t@@SAEW4format_t@1@@Z)   Simutrans-Extended   C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\raw_image_png.obj   1   
Error   LNK2001   unresolved external symbol "public: __cdecl raw_image_t::raw_image_t(unsigned int,unsigned int,enum raw_image_t::format_t)" (??0raw_image_t@@QEAA@IIW4format_t@0@@Z)   Simutrans-Extended   C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\simgraph16.obj   1   
Error   LNK2001   unresolved external symbol "public: __cdecl raw_image_t::~raw_image_t(void)" (??1raw_image_t@@QEAA@XZ)   Simutrans-Extended   C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\simgraph16.obj   1   

I had to compile raw_image.cc individually in Visual Studio to make these go away. That is rather odd, but in any case, this is solved now and this is now on the master branch.

As to the other nightly builds fix, can I check whether you mean this pull request? If so, it is showing with merge conflicts in a file whose syntax and function is not known to me, so I do not know how they ought to be resolved.

Thank you very much for your work on this.
Edit: Now having merged this into the pier-system branch, I am also able to get that to compile, too.
« Last Edit: January 16, 2022, 04:30:07 PM by jamespetts »

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 21026
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #82 on: January 16, 2022, 05:08:22 PM »
Now that I have been able to compile this on my Windows machine and test it, I find that I am now getting some weird behaviour with the latest version of this. Using the automatic build tool with the brick elevated way supports, I get something that looks like this:



whereas using the automatic build tool on the metal structure will not build at all, claiming that it cannot find a valid route. I am not sure what has gone wrong, but I should be grateful if you could look into this. Thank you.

Offline Roboron

  • Devotee
  • *
  • Posts: 440
    • Las Galácticas Aventuras de Komoyo Diga
  • Languages: ES, EN
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #83 on: January 16, 2022, 05:40:45 PM »
As to the other nightly builds fix, can I check whether you mean this pull request? If so, it is showing with merge conflicts in a file whose syntax and function is not known to me, so I do not know how they ought to be resolved.

Seems that the CMake source list was the cause of conflict. I solved it it in this pull request https://github.com/jamespetts/simutrans-extended/pull/467

After that, the automated builds should be green again 🟩


Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 21026
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #84 on: January 16, 2022, 08:33:36 PM »
Splendid, thank you; now incorporated.

Offline PJMack

  • *
  • Posts: 81
  • Languages: EN
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #85 on: January 16, 2022, 08:39:30 PM »
Now that I have been able to compile this on my Windows machine and test it, I find that I am now getting some weird behaviour with the latest version of this. Using the automatic build tool with the brick elevated way supports, I get something that looks like this: whereas using the automatic build tool on the metal structure will not build at all, claiming that it cannot find a valid route. I am not sure what has gone wrong, but I should be grateful if you could look into this. Thank you.

I have not seen anything like that before and it is working fine on my computer.  I can think of a few causes it could be:

(A) A strange merge error.  Unlikely as the code file to do the routing is unique to the pier system.
(B) A build/compile/linking error.  Also unlikely, but a clean build may be in order.
(C) The pakset was generated with an older version of makeobj.  I have made that mistake a couple times.  You may want to recompile makeobj and regenerate the pakset.
(D) A memory error.  I really hope this is not the issue.

From my end, (D) is the only thing I can test. For (C), I did have a chance to update the brick graphics and create the stone ones and have pushed the changes.

Edit: Valgrind found no errors during pier construction.
« Last Edit: January 16, 2022, 08:51:14 PM by PJMack »

Offline Roboron

  • Devotee
  • *
  • Posts: 440
    • Las Galácticas Aventuras de Komoyo Diga
  • Languages: ES, EN

Offline Ranran

  • Devotee
  • *
  • Posts: 1723
  • 今日は兎汁よー
  • Languages: ja
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #87 on: January 16, 2022, 09:09:33 PM »
Oddly, initially, I got linker errors:
I got the same kind of errors when I tried to test the master branch.

https://github.com/Ranran-the-JuicyPork/simutrans-extended/commit/5b8a71741609d81d6109edeeb60a36171aa57a56
I found one what seemed to be an error, but fixing it did not solve the problem...
Code: [Select]
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_create_read_struct が関数 "private: bool __thiscall raw_image_t::read_png_data(struct _iobuf *)" (?read_png_data@raw_image_t@@AAE_NPAU_iobuf@@@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_create_write_struct が関数 "public: bool __thiscall raw_image_t::write_png(char const *)const " (?write_png@raw_image_t@@QBE_NPBD@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_set_longjmp_fn が関数 "public: bool __thiscall raw_image_t::write_png(char const *)const " (?write_png@raw_image_t@@QBE_NPBD@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_create_info_struct が関数 "public: bool __thiscall raw_image_t::write_png(char const *)const " (?write_png@raw_image_t@@QBE_NPBD@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_write_info が関数 "public: bool __thiscall raw_image_t::write_png(char const *)const " (?write_png@raw_image_t@@QBE_NPBD@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_read_info が関数 "private: bool __thiscall raw_image_t::read_png_data(struct _iobuf *)" (?read_png_data@raw_image_t@@AAE_NPAU_iobuf@@@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_set_expand が関数 "private: bool __thiscall raw_image_t::read_png_data(struct _iobuf *)" (?read_png_data@raw_image_t@@AAE_NPAU_iobuf@@@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_set_strip_alpha が関数 "private: bool __thiscall raw_image_t::read_png_data(struct _iobuf *)" (?read_png_data@raw_image_t@@AAE_NPAU_iobuf@@@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_set_filler が関数 "private: bool __thiscall raw_image_t::read_png_data(struct _iobuf *)" (?read_png_data@raw_image_t@@AAE_NPAU_iobuf@@@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_set_packing が関数 "private: bool __thiscall raw_image_t::read_png_data(struct _iobuf *)" (?read_png_data@raw_image_t@@AAE_NPAU_iobuf@@@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_set_strip_16 が関数 "private: bool __thiscall raw_image_t::read_png_data(struct _iobuf *)" (?read_png_data@raw_image_t@@AAE_NPAU_iobuf@@@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_read_update_info が関数 "private: bool __thiscall raw_image_t::read_png_data(struct _iobuf *)" (?read_png_data@raw_image_t@@AAE_NPAU_iobuf@@@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_read_image が関数 "private: bool __thiscall raw_image_t::read_png_data(struct _iobuf *)" (?read_png_data@raw_image_t@@AAE_NPAU_iobuf@@@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_write_row が関数 "public: bool __thiscall raw_image_t::write_png(char const *)const " (?write_png@raw_image_t@@QBE_NPBD@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_write_end が関数 "public: bool __thiscall raw_image_t::write_png(char const *)const " (?write_png@raw_image_t@@QBE_NPBD@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_read_end が関数 "private: bool __thiscall raw_image_t::read_png_data(struct _iobuf *)" (?read_png_data@raw_image_t@@AAE_NPAU_iobuf@@@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_destroy_read_struct が関数 "private: bool __thiscall raw_image_t::read_png_data(struct _iobuf *)" (?read_png_data@raw_image_t@@AAE_NPAU_iobuf@@@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_destroy_write_struct が関数 "public: bool __thiscall raw_image_t::write_png(char const *)const " (?write_png@raw_image_t@@QBE_NPBD@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_init_io が関数 "public: bool __thiscall raw_image_t::write_png(char const *)const " (?write_png@raw_image_t@@QBE_NPBD@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_get_valid が関数 "private: bool __thiscall raw_image_t::read_png_data(struct _iobuf *)" (?read_png_data@raw_image_t@@AAE_NPAU_iobuf@@@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_get_rowbytes が関数 "private: bool __thiscall raw_image_t::read_png_data(struct _iobuf *)" (?read_png_data@raw_image_t@@AAE_NPAU_iobuf@@@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_get_IHDR が関数 "private: bool __thiscall raw_image_t::read_png_data(struct _iobuf *)" (?read_png_data@raw_image_t@@AAE_NPAU_iobuf@@@Z) で参照されました。
1>raw_image_png.obj : error LNK2019: 未解決の外部シンボル _png_set_IHDR が関数 "public: bool __thiscall raw_image_t::write_png(char const *)const " (?write_png@raw_image_t@@QBE_NPBD@Z) で参照されました。
1>.\simutrans\Simutrans-Extended-debug.exe : fatal error LNK1120: 23 件の未解決の外部参照

Offline wlindley

  • Devotee
  • *
  • Posts: 1094
    • Simutrans fan since 2009
  • Languages: EN, DE
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #88 on: January 16, 2022, 09:11:12 PM »
Confirm linker errors on Linux compile.  This seems to be because libpng is only linked when building makeobj -- it was not formerly a dependency of the main program... not sure when/what changed.

Offline PJMack

  • *
  • Posts: 81
  • Languages: EN
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #89 on: January 16, 2022, 09:57:40 PM »
Confirm linker errors on Linux compile.  This seems to be because libpng is only linked when building makeobj -- it was not formerly a dependency of the main program... not sure when/what changed.
The change was in commit number 3685abc444b26b084710a6f8b4a748aedac9bf66.  For Linux, the line "LDFLAGS += -lpng" can be added to the makefile (or the config file) if not using cmake.  (And libpng needs to be installed properly)  This line was added to the pier system PR.

Offline Roboron

  • Devotee
  • *
  • Posts: 440
    • Las Galácticas Aventuras de Komoyo Diga
  • Languages: ES, EN
Re: New system for elevated ways (inc. half height and uneven terrain)
« Reply #90 on: January 16, 2022, 11:42:19 PM »
libpng is indeed now needed by the main program. However, when testing in MSVC the library was already part of the configuration (Debug, x64), so I assumed that it was true for others as well. Well I see now that some configuration have it and others don't (¿?). It should be added to any configuration missing it. And the makefile, if merging of the pier branch is not happening anytime soon.

https://github.com/Ranran-the-JuicyPork/simutrans-extended/commit/5b8a71741609d81d6109edeeb60a36171aa57a56
I found one what seemed to be an error, but fixing it did not solve the problem...

This is indeed what caused jamespett's issue, thank you for spotting it:
Oddly, initially, I got linker errors:

Error   LNK2001   unresolved external symbol "public: static unsigned char __cdecl raw_image_t::bpp_for_format(enum raw_image_t::format_t)" (?bpp_for_format@raw_image_t@@SAEW4format_t@1@@Z)   Simutrans-Extended   C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\raw_image_png.obj   1   
Error   LNK2001   unresolved external symbol "public: __cdecl raw_image_t::raw_image_t(unsigned int,unsigned int,enum raw_image_t::format_t)" (??0raw_image_t@@QEAA@IIW4format_t@0@@Z)   Simutrans-Extended   C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\simgraph16.obj   1   
Error   LNK2001   unresolved external symbol "public: __cdecl raw_image_t::~raw_image_t(void)" (??1raw_image_t@@QEAA@XZ)   Simutrans-Extended   C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\simgraph16.obj   1   
« Last Edit: Yesterday at 10:07:32 AM by Roboron »

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 21026
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Thanks to Roboron's assistance, I have managed to get this compiling again in Visual Studio, as well as fixing the problem with the master branch on the server, so we can return to focussing on the elevated way support system itself.

I can confirm that deleting a new elevated way support with parapets now automatically deletes both parapet and deck as intended - this is helpful. I have now merged in PJMack's latest pakset build.

However, we still get this odd form of support when building the structures:



and the steel (iron?) type still refuses to build at all, claiming that it cannot find a valid route. I am not sure why this is. This appears to be a special type of support that allows ways to run underneath the structure - is this correct? Do we have any historical examples of this in a brick arch structure? The height above the road below appears very low - I assume that vehicles marked "is_tall" would not be able to pass underneath?

I can confirm that the parapets are now no longer present on depots and stations, although this leaves 'bus stops on top of these elevated ways looking very odd:



I am not sure what is best to do about this, but it merits further consideration in any event.

Thank you again for all your work on this.
« Last Edit: Today at 12:45:48 AM by jamespetts »