News:

The Forum Rules and Guidelines
Our forum has Rules and Guidelines. Please, be kind and read them ;).

New system for elevated ways (inc. half height and uneven terrain)

Started by PJMack, October 06, 2021, 10:33:51 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Mariculous

Quote from: jamespetts on January 02, 2022, 01:46:57 PMIn 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, but there is my feedback now.

Quote from: jamespetts on January 02, 2022, 01:46:57 PM16. 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!


Quote from: jamespetts on January 02, 2022, 01:46:57 PMI 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.


Quote from: jamespetts on December 29, 2021, 12:28:51 AM10. 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.

jamespetts

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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Roboron

Quote from: jamespetts on January 14, 2022, 10:41:36 PMIf 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

jamespetts

Quote from: Roboron on January 15, 2022, 12:18:58 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?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Roboron

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).

PJMack

Quote from: Roboron on January 15, 2022, 12:18:58 AMHowever, 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.

Roboron

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.

jamespetts

Quote from: Roboron 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).

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:


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
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Roboron

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.

QuoteCannot 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.

prissi

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.

Roboron

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...

jamespetts

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:


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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

jamespetts

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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Roboron

Quote from: jamespetts on January 16, 2022, 01:31:05 PMAs 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 🟩


jamespetts

Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

PJMack

Quote from: jamespetts on January 16, 2022, 05:08:22 PMNow 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.


Ranran(retired)

Quote from: jamespetts on January 16, 2022, 01:31:05 PMOddly, 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...

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 件の未解決の外部参照
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

wlindley

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.

PJMack

Quote from: wlindley on January 16, 2022, 09:11:12 PMConfirm 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.

Roboron

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.

Quote from: Ranran on January 16, 2022, 09:09:33 PMhttps://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:
Quote from: jamespetts on January 16, 2022, 01:31:05 PMOddly, 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   

jamespetts

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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

PJMack

I have attached some screenshots of the graphics that are working on my machine.  I do not know why it is doing that on your machine, but I suspect for some reason there is an issue with loading (or generating) the pakset as the automated build tool has redundant checks in it (the build restrictions are taken into account for route finding and checked again during building).  Makeobj passed with Valgrind.  I put the Valgrind errors for simutrans-extend below (while building a steel pier), which contains no errors relevant to the pier system.  At this point, I am not sure quite what to do.  Has anyone else tested this?

==258325== Memcheck, a memory error detector
==258325== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==258325== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==258325== Command: ./simutrans/simutrans-extended
==258325==
Parsed simuconf.tab for directory layout; multiuser = 1
Pak found: pak128.Britain-Ex/
==258325== Conditional jump or move depends on uninitialised value(s)
==258325==    at 0x53D4565: pa_shm_cleanup (in /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-13.99.so)
==258325==    by 0x53D47A1: pa_shm_create_rw (in /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-13.99.so)
==258325==    by 0x53C44B6: pa_mempool_new (in /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-13.99.so)
==258325==    by 0x51539B1: pa_context_new_with_proplist (in /usr/lib/x86_64-linux-gnu/libpulse.so.0.21.2)
==258325==    by 0x4C72D5E: ??? (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.10.0)
==258325==    by 0x4C7365A: ??? (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.10.0)
==258325==    by 0x4BC5D9B: ??? (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.10.0)
==258325==    by 0x4BC1906: ??? (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.10.0)
==258325==    by 0x2BBF97: UnknownInlinedFun (sdl2_sound.cc:119)
==258325==    by 0x2BBF97: UnknownInlinedFun (sdl2_sound.cc:110)
==258325==    by 0x2BBF97: UnknownInlinedFun (simmain.cc:1173)
==258325==    by 0x2BBF97: sysmain(int, char**) (simsys.cc:1097)
==258325==    by 0x489F0B2: (below main) (libc-start.c:308)
==258325==
==258325== Conditional jump or move depends on uninitialised value(s)
==258325==    at 0x367FF1: fabrik_t::calc_operation_rate(signed char) const [clone .part.0] (simfab.cc:4118)
==258325==    by 0x377836: UnknownInlinedFun (simfab.cc:4106)
==258325==    by 0x377836: fabrik_t::rdwr(loadsave_t*) (simfab.cc:1726)
==258325==    by 0x2C9B47: UnknownInlinedFun (simfab.cc:835)
==258325==    by 0x2C9B47: karte_t::load(loadsave_t*) (simworld.cc:9727)
==258325==    by 0x2CF045: karte_t::load(char const*) (simworld.cc:9135)
==258325==    by 0x2B932D: UnknownInlinedFun (simmain.cc:1493)
==258325==    by 0x2B932D: sysmain(int, char**) (simsys.cc:1097)
==258325==    by 0x489F0B2: (below main) (libc-start.c:308)
==258325==
==258325== Conditional jump or move depends on uninitialised value(s)
==258325==    at 0x367FF9: fabrik_t::calc_operation_rate(signed char) const [clone .part.0] (simfab.cc:4127)
==258325==    by 0x377836: UnknownInlinedFun (simfab.cc:4106)
==258325==    by 0x377836: fabrik_t::rdwr(loadsave_t*) (simfab.cc:1726)
==258325==    by 0x2C9B47: UnknownInlinedFun (simfab.cc:835)
==258325==    by 0x2C9B47: karte_t::load(loadsave_t*) (simworld.cc:9727)
==258325==    by 0x2CF045: karte_t::load(char const*) (simworld.cc:9135)
==258325==    by 0x2B932D: UnknownInlinedFun (simmain.cc:1493)
==258325==    by 0x2B932D: sysmain(int, char**) (simsys.cc:1097)
==258325==    by 0x489F0B2: (below main) (libc-start.c:308)
==258325==
==258325== Conditional jump or move depends on uninitialised value(s)
==258325==    at 0x352E7D: simline_t::recalc_status() (simline.cc:744)
==258325==    by 0x35545C: simline_t::create_schedule() (simline.cc:181)
==258325==    by 0x355C3A: UnknownInlinedFun (simline.cc:96)
==258325==    by 0x355C3A: simlinemgmt_t::rdwr(loadsave_t*, player_t*) (simlinemgmt.cc:133)
==258325==    by 0x41D77E: player_t::rdwr(loadsave_t*) (simplay.cc:916)
==258325==    by 0x2CAEBC: karte_t::load(loadsave_t*) (simworld.cc:9809)
==258325==    by 0x2CF045: karte_t::load(char const*) (simworld.cc:9135)
==258325==    by 0x2B932D: UnknownInlinedFun (simmain.cc:1493)
==258325==    by 0x2B932D: sysmain(int, char**) (simsys.cc:1097)
==258325==    by 0x489F0B2: (below main) (libc-start.c:308)
==258325==
==258325== Conditional jump or move depends on uninitialised value(s)
==258325==    at 0x352EDD: simline_t::recalc_status() (simline.cc:756)
==258325==    by 0x35545C: simline_t::create_schedule() (simline.cc:181)
==258325==    by 0x355C3A: UnknownInlinedFun (simline.cc:96)
==258325==    by 0x355C3A: simlinemgmt_t::rdwr(loadsave_t*, player_t*) (simlinemgmt.cc:133)
==258325==    by 0x41D77E: player_t::rdwr(loadsave_t*) (simplay.cc:916)
==258325==    by 0x2CAEBC: karte_t::load(loadsave_t*) (simworld.cc:9809)
==258325==    by 0x2CF045: karte_t::load(char const*) (simworld.cc:9135)
==258325==    by 0x2B932D: UnknownInlinedFun (simmain.cc:1493)
==258325==    by 0x2B932D: sysmain(int, char**) (simsys.cc:1097)
==258325==    by 0x489F0B2: (below main) (libc-start.c:308)
==258325==
==258325== Conditional jump or move depends on uninitialised value(s)
==258325==    at 0x352EF9: simline_t::recalc_status() (simline.cc:762)
==258325==    by 0x35545C: simline_t::create_schedule() (simline.cc:181)
==258325==    by 0x355C3A: UnknownInlinedFun (simline.cc:96)
==258325==    by 0x355C3A: simlinemgmt_t::rdwr(loadsave_t*, player_t*) (simlinemgmt.cc:133)
==258325==    by 0x41D77E: player_t::rdwr(loadsave_t*) (simplay.cc:916)
==258325==    by 0x2CAEBC: karte_t::load(loadsave_t*) (simworld.cc:9809)
==258325==    by 0x2CF045: karte_t::load(char const*) (simworld.cc:9135)
==258325==    by 0x2B932D: UnknownInlinedFun (simmain.cc:1493)
==258325==    by 0x2B932D: sysmain(int, char**) (simsys.cc:1097)
==258325==    by 0x489F0B2: (below main) (libc-start.c:308)
==258325==
==258325== Conditional jump or move depends on uninitialised value(s)
==258325==    at 0x352FDE: simline_t::recalc_status() (simline.cc:769)
==258325==    by 0x35545C: simline_t::create_schedule() (simline.cc:181)
==258325==    by 0x355C3A: UnknownInlinedFun (simline.cc:96)
==258325==    by 0x355C3A: simlinemgmt_t::rdwr(loadsave_t*, player_t*) (simlinemgmt.cc:133)
==258325==    by 0x41D77E: player_t::rdwr(loadsave_t*) (simplay.cc:916)
==258325==    by 0x2CAEBC: karte_t::load(loadsave_t*) (simworld.cc:9809)
==258325==    by 0x2CF045: karte_t::load(char const*) (simworld.cc:9135)
==258325==    by 0x2B932D: UnknownInlinedFun (simmain.cc:1493)
==258325==    by 0x2B932D: sysmain(int, char**) (simsys.cc:1097)
==258325==    by 0x489F0B2: (below main) (libc-start.c:308)
==258325==
==258325== Thread 39:
==258325== Conditional jump or move depends on uninitialised value(s)
==258325==    at 0x59CCB1: wayobj_t::get_image() const (wayobj.h:59)
==258325==    by 0x5A8039: obj_t::display(int, int, signed char) const (simobj.cc:210)
==258325==    by 0x600F2C: UnknownInlinedFun (objlist.cc:1128)
==258325==    by 0x600F2C: UnknownInlinedFun (objlist.cc:1144)
==258325==    by 0x600F2C: grund_t::display_obj_bg(short, short, bool, bool, bool, signed char) const (grund.cc:1763)
==258325==    by 0x60515E: grund_t::display_obj_all(short, short, short, bool, signed char) const (grund.cc:1674)
==258325==    by 0x335C6C: planquadrat_t::display_obj(short, short, short, bool, signed char, signed char, signed char) const (simplan.cc:547)
==258325==    by 0x20087D: main_view_t::display_region(koord, koord, short, short, bool, bool, signed char) [clone .constprop.0] (simview.cc:576)
==258325==    by 0x58D4B6: display_region_thread(void*) (simview.cc:77)
==258325==    by 0x4B1C608: start_thread (pthread_create.c:477)
==258325==    by 0x499A292: clone (clone.S:95)
==258325==
==258325== Conditional jump or move depends on uninitialised value(s)
==258325==    at 0x59CCB1: wayobj_t::get_image() const (wayobj.h:59)
==258325==    by 0x5A8039: obj_t::display(int, int, signed char) const (simobj.cc:210)
==258325==    by 0x600F2C: UnknownInlinedFun (objlist.cc:1128)
==258325==    by 0x600F2C: UnknownInlinedFun (objlist.cc:1144)
==258325==    by 0x600F2C: grund_t::display_obj_bg(short, short, bool, bool, bool, signed char) const (grund.cc:1763)
==258325==    by 0x604721: grund_t::display_obj_all(short, short, short, bool, signed char) const (grund.cc:1633)
==258325==    by 0x335C6C: planquadrat_t::display_obj(short, short, short, bool, signed char, signed char, signed char) const (simplan.cc:547)
==258325==    by 0x20087D: main_view_t::display_region(koord, koord, short, short, bool, bool, signed char) [clone .constprop.0] (simview.cc:576)
==258325==    by 0x58D4B6: display_region_thread(void*) (simview.cc:77)
==258325==    by 0x4B1C608: start_thread (pthread_create.c:477)
==258325==    by 0x499A292: clone (clone.S:95)
==258325==
==258325== Conditional jump or move depends on uninitialised value(s)
==258325==    at 0x59CCB1: wayobj_t::get_image() const (wayobj.h:59)
==258325==    by 0x5A8039: obj_t::display(int, int, signed char) const (simobj.cc:210)
==258325==    by 0x600F2C: UnknownInlinedFun (objlist.cc:1128)
==258325==    by 0x600F2C: UnknownInlinedFun (objlist.cc:1144)
==258325==    by 0x600F2C: grund_t::display_obj_bg(short, short, bool, bool, bool, signed char) const (grund.cc:1763)
==258325==    by 0x60507E: grund_t::display_obj_all(short, short, short, bool, signed char) const (grund.cc:1682)
==258325==    by 0x335C6C: planquadrat_t::display_obj(short, short, short, bool, signed char, signed char, signed char) const (simplan.cc:547)
==258325==    by 0x20087D: main_view_t::display_region(koord, koord, short, short, bool, bool, signed char) [clone .constprop.0] (simview.cc:576)
==258325==    by 0x58D4B6: display_region_thread(void*) (simview.cc:77)
==258325==    by 0x4B1C608: start_thread (pthread_create.c:477)
==258325==    by 0x499A292: clone (clone.S:95)
==258325==
==258325== Conditional jump or move depends on uninitialised value(s)
==258325==    at 0x59CAD1: wayobj_t::get_front_image() const (wayobj.h:69)
==258325==    by 0x5A7E3E: obj_t::display_after(int, int, signed char) const (simobj.cc:285)
==258325==    by 0x600A2C: UnknownInlinedFun (objlist.cc:1105)
==258325==    by 0x600A2C: UnknownInlinedFun (objlist.cc:1073)
==258325==    by 0x600A2C: grund_t::display_obj_fg(short, short, bool, unsigned char, signed char) const (grund.cc:1789)
==258325==    by 0x604D8A: grund_t::display_obj_all(short, short, short, bool, signed char) const (grund.cc:1731)
==258325==    by 0x335C6C: planquadrat_t::display_obj(short, short, short, bool, signed char, signed char, signed char) const (simplan.cc:547)
==258325==    by 0x20087D: main_view_t::display_region(koord, koord, short, short, bool, bool, signed char) [clone .constprop.0] (simview.cc:576)
==258325==    by 0x58D4B6: display_region_thread(void*) (simview.cc:77)
==258325==    by 0x4B1C608: start_thread (pthread_create.c:477)
==258325==    by 0x499A292: clone (clone.S:95)
==258325==
==258325== Thread 1:
==258325== Conditional jump or move depends on uninitialised value(s)
==258325==    at 0x2957A5: road_vehicle_t::enter_tile(grund_t*) (road_vehicle.cc:1105)
==258325==    by 0x28B039: vehicle_t::hop(grund_t*) (vehicle.cc:1685)
==258325==    by 0x293D4A: road_vehicle_t::hop(grund_t*) (road_vehicle.cc:1141)
==258325==    by 0x28F03D: vehicle_base_t::do_drive(unsigned int) (vehicle.cc:332)
==258325==    by 0x28F20C: road_vehicle_t::do_drive(unsigned int) (road_vehicle.cc:1042)
==258325==    by 0x39E109: UnknownInlinedFun (simconvoi.cc:1333)
==258325==    by 0x39E109: convoi_t::sync_step(unsigned int) (simconvoi.cc:1226)
==258325==    by 0x2DBE3D: karte_t::sync_list_t::sync_step(unsigned int) (simworld.cc:4864)
==258325==    by 0x2DBFC8: karte_t::sync_step(unsigned int, bool, bool) (simworld.cc:4937)
==258325==    by 0x201F38: UnknownInlinedFun (simintr.cc:111)
==258325==    by 0x201F38: interrupt_check(char const*) [clone .constprop.0] (simintr.cc:91)
==258325==    by 0x2D7DFC: karte_t::step() (simworld.cc:5699)
==258325==    by 0x345745: UnknownInlinedFun (simmain.cc:268)
==258325==    by 0x345745: modal_dialogue(gui_frame_t*, long, karte_t*, bool (*)()) (simmain.cc:200)
==258325==    by 0x2BAB31: UnknownInlinedFun (simmain.cc:1617)
==258325==    by 0x2BAB31: sysmain(int, char**) (simsys.cc:1097)
==258325==
==258325== Conditional jump or move depends on uninitialised value(s)
==258325==    at 0x2957A5: road_vehicle_t::enter_tile(grund_t*) (road_vehicle.cc:1105)
==258325==    by 0x39EE53: convoi_t::move_to(unsigned short) (simconvoi.cc:478)
==258325==    by 0x399BCA: UnknownInlinedFun (simconvoi.cc:3486)
==258325==    by 0x399BCA: convoi_t::step() (simconvoi.cc:2224)
==258325==    by 0x2D7F6D: karte_t::step() (simworld.cc:5807)
==258325==    by 0x2C474D: karte_t::interactive(unsigned int) (simworld.cc:11425)
==258325==    by 0x2BA9FE: UnknownInlinedFun (simmain.cc:1644)
==258325==    by 0x2BA9FE: sysmain(int, char**) (simsys.cc:1097)
==258325==    by 0x489F0B2: (below main) (libc-start.c:308)

jamespetts

That is very odd. It was working when I was compiling on Linux on the computer that I was using visiting my parents - I am now at home on my Windows machine, compiling with Visual Studio.

Can I check whether you are using Linux or Windows to compile the versions with which you are testing?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

PJMack

I am using Linux, more specifically XUbuntu 20.04 with gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 and GNU Make 4.2.1.  (I did at one point test a cmake build)  I have tested this with a debugging build and with optimization maxed out.  As far as I am aware of, all the code written is compliant with C++ standards.  As is does not appear to be working in Windows, this is now a nightmare scenario.

jamespetts

Quote from: PJMack on January 18, 2022, 05:21:35 PM
I am using Linux, more specifically XUbuntu 20.04 with gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 and GNU Make 4.2.1.  (I did at one point test a cmake build)  I have tested this with a debugging build and with optimization maxed out.  As far as I am aware of, all the code written is compliant with C++ standards.  As is does not appear to be working in Windows, this is now a nightmare scenario.

This is indeed unfortunate. May I suggest testing using Visual Studio Community Edition in a Virtualbox instance? Also, would it help if I were to upload somewhere my pakset (perhaps just the piers part of it) as compiled with this branch with the Windows Visual Studio makeobj so that you can narrow the problem down to either the reading or the writing code?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

PJMack

Quote from: jamespetts on January 18, 2022, 07:11:17 PMAlso, would it help if I were to upload somewhere my pakset (perhaps just the piers part of it) as compiled with this branch with the Windows Visual Studio makeobj so that you can narrow the problem down to either the reading or the writing code?
Yes please.  This would be helpful.

jamespetts

Quote from: PJMack on January 18, 2022, 08:21:14 PM
Yes please.  This would be helpful.

I have put a zipped version of my piers directory here for your analysis. I hope that this helps.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

PJMack

Quote from: jamespetts on January 19, 2022, 12:08:59 AMI have put a zipped version of my piers directory here for your analysis. I hope that this helps.
The dat files and images in zip file does match what I have (except for yours has DOS line endings and mine has Unix line endings), however the piers.pak file is not in it.  Could you please transmit that file.  Thank You.

jamespetts

Thank you for checking that. Here is the .pak file (zipped). I hope that this helps.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

PJMack

Thank you for the pak file.  When using it, it does produce results consistent to your images.  Upon further inspection, the pak file was created with an older version of makeobj-extended (from before October 11th) that predated some of the features that the automated build tools use.  Could you please rebuild makeobj-extended and rebuild the pakset using that?

jamespetts

Thank you for checking. This is very odd: I have tried this, verifying that I am using the latest version of makeobj, but I am still getting the same results. I am using makeobj compiled from my pier_system branch.

Would it help if I were to upload the executable?
Edit: I have tried cleaning the build and totally rebuilding and also pulling the latest code from your branch, but this makes no difference.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

PJMack

The minor adjustment I made last night was for the wrought iron piers (I am still working on the graphics) and should not effect the stone, masonry (AKA brick), or steel piers. 

I double checked the pak file you sent my by viewing it in a hex viewer.  The version number of the pier node is C109, whereas the code in pier_writer.cc (lines 66-70) write a value of C309 for the latest version.  The node length is also the same as when the pier node version number was C109 (if it was not, reading would have caused a crash).  Still, the only conclusion is that somehow or other, the old makeobj-extended executable stuck around after the clean build.  The only thing I can think of is to try cleaning the build, then doing a general file search for makeobj-extended.

jamespetts

Quote from: PJMack on January 22, 2022, 08:47:21 PM
The minor adjustment I made last night was for the wrought iron piers (I am still working on the graphics) and should not effect the stone, masonry (AKA brick), or steel piers. 

I double checked the pak file you sent my by viewing it in a hex viewer.  The version number of the pier node is C109, whereas the code in pier_writer.cc (lines 66-70) write a value of C309 for the latest version.  The node length is also the same as when the pier node version number was C109 (if it was not, reading would have caused a crash).  Still, the only conclusion is that somehow or other, the old makeobj-extended executable stuck around after the clean build.  The only thing I can think of is to try cleaning the build, then doing a general file search for makeobj-extended.

I do not think that this can be the problem, since I did not build the piers branch at all until December, and then only on my Linux machine: I first compiled the piers branch on the computer that I am using now earlier this month. Also, I checked the file modification date for the executable, and it was dated to-day.

Can you check that my pier_system branch on Github is up to date with the correct code?

Edit

For reference, the version code in my pier_writer.cc is:


uint16 version = 0x8009;

version |= EX_VER;

version += 0x300; //Version number of node times 0x100
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

jamespetts

Hmm - the problem appears to have been solved after some further testing, although I am not entirely sure what it was that did it. It may be that the makefile is ambiguous in the name of makeobj to which it refers when in a Windows environment. In any event, this now does appear to be working - apologies for having taken your time with this.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.