ADD: noise barrier based on gauthier's "palissade" fence

[pipcet]

James,
this is the wooden palisade fence repackaged as a noise barrier. The .dat file needs calibration (I think cost and maintenance are approximately right, but the introduction year of 1968 is probably far too late), but for testing things this should work.

One problem with moving the fences to the edge of their tile is that four-way intersections have no visible indication of whether they have a noise barrier. That could be changed if we were to move the fences a little towards the centre of the tile, but that requires adjusting the base image quite a bit, and at some point it would probably be faster to use Blender.

Philip

[jamespetts]

Philip,

thank you for that. May I check: did you update makeobj for this
requiring a makeobj recompile? I have for some reason that I currently
cannot fathom lost my .vcxproj file for Makeobj, and, bizarrely,
checking, it does not appear to be anywhere on Github. My NAS backup
device is currently in storage owing to my temporary housing situation,
so I cannot without a great amount of work build makeobj at present.
When I tried to compile the pakset using the existing version of makeobj
that I most recently compiled, running Simutrans-Experimental failed on
loading the pakset thus compiled, complaining that there were no roads
(i.e., makeobj had failed on attempting to compile the ways).

Any light that you might be able to cast on this issue would be most
welcome. Thank you again for your work on this;

James.

On 07/09/2014 20:22, pipcet wrote:

James,
this is the wooden palisade fence repackaged as a noise barrier. The
.dat file needs calibration (I think cost and maintenance are
approximately right, but the introduction year of 1968 is probably far
too late), but for testing things this should work.

One problem with moving the fences to the edge of their tile is that
four-way intersections have no visible indication of whether they have
a noise barrier. That could be changed if we were to move the fences a
little towards the centre of the tile, but that requires adjusting the
base image quite a bit, and at some point it would probably be faster
to use Blender.

Philip

---

    You can merge this Pull Request by running

git pull https://github.com/pipcet/simutrans-pak128.britain noise-barrier-palisade

Or view, comment on, or merge it at:

#25

    Commit Summary

• ADD: noise barrier based on gauthier's "palissade" fence

  File Changes
  

• A ways/images/palisade-nb.png
  https://github.com/jamespetts/simutrans-pak128.britain/pull/25/files#diff-0
  (0)

• A ways/palisade-nb.dat
  https://github.com/jamespetts/simutrans-pak128.britain/pull/25/files#diff-1
  (58)

  Patch Links:
  

• https://github.com/jamespetts/simutrans-pak128.britain/pull/25.patch

• https://github.com/jamespetts/simutrans-pak128.britain/pull/25.diff

—
Reply to this email directly or view it on GitHub
#25.

[pipcet]

James,
yes, indeed, I added the way type to the makeobj code, which might cause the problems you describe (though I wouldn't have expected it to fail on all ways, just the newly-added ones).

I have a file called Makeobj.vcxproj here, with a capital M (maybe that's the problem, git sorts by case first, then by letter). It's at https://github.com/pipcet/simutrans-experimental/blob/clean/Makeobj.vcxproj

Philip

[jamespetts]

Philip,

hmm - that does not seem to work for me, as I get build errors (such as
"cannot open png.h" and "debuglevel: undeclared identifier"). I shall
have to try to find my makeobj project when I am able to get my backup
drive out of storage. In the meantime, do you have a binary makeobj for
the way-imrpovements branch that I can use to test?

James.

On 07/09/2014 22:09, pipcet wrote:

James,
James,
yes, indeed, I added the way type to the makeobj code, which might
cause the problems you describe (though I wouldn't have expected it to
fail on all ways, just the newly-added ones).

I have a file called Makeobj.vcxproj here, with a capital M (maybe
that's the problem, git sorts by case first, then by letter). It's at
https://github.com/pipcet/simutrans-experimental/blob/clean/Makeobj.vcxproj

Philip

—
Reply to this email directly or view it on GitHub
#25 (comment).

[pipcet]

James,
I'm sorry, but I don't currently have access to a Windows machine and haven't set up a cross-compiling environment. Do you have a Linux virtual machine set up?
Philip

[jamespetts]

Philip,

hmm - I don't think that I have a full VM setup, but I do have some
actual Linux machines in the place where I am staying temporarily. Can
you perhaps send me the full ways .pak file so that I can test the
executable at least?

James.

On 07/09/2014 23:05, pipcet wrote:

James,
I'm sorry, but I don't currently have access to a Windows machine and
haven't set up a cross-compiling environment. Do you have a Linux
virtual machine set up?
Philip

—
Reply to this email directly or view it on GitHub
#25 (comment).

[pipcet]

James,
I've uploaded (and tested, which took a while) the PAK file for the noise barrier to https://github.com/pipcet/simutrans-pak128.britain/blob/b1bb45fc114953eec15ccb676d77fcd9f2b6ee0b/ways/way-object.NoiseBarrier.pak ; I'm not quite sure whether that's what you meant.
Philip

[jamespetts]

Philip,

ah, what I needed was the .pak file with all of the ways, since,
whenever Makeobj encounters an object that it does not understand, it
stops the build entirely, so it will not have built any ways, with the
result that I now need a pak file with all of the ways in order to be
able to load the pakset and test the noise barriers;

James.

On 08/09/2014 00:02, pipcet wrote:

James,
I've uploaded (and tested, which took a while) the PAK file for the
noise barrier to
https://github.com/pipcet/simutrans-pak128.britain/blob/b1bb45fc114953eec15ccb676d77fcd9f2b6ee0b/ways/way-object.NoiseBarrier.pak
; I'm not quite sure whether that's what you meant.
Philip

—
Reply to this email directly or view it on GitHub
#25 (comment).

[pipcet]

James,
Oh, I was assuming you could just use a full pre-built PAK directory and copy in that one file.

By the way, have you attempted building a clean checkout of the way-improvements branch makeobj? Obviously if it's my patch that's the problem it shouldn't go in until compiling makeobj works again, though I don't recall doing anything that I would have expected to break things like that. It's quite possible we need to define LOCAL to build dr_rdpng.cc, or that the #include must happen after the #ifndef LOCAL in dr_rdpng.cc.
Philip

[jamespetts]

Philip,

I could have done that temporarily for testing purposes had I known in
advance that it would fail if I tried to use the current Makeobj, but
having now overwritten the previous pak files with the new (and
corrupt/incomplete) ones generated by the older Makeobj, this is no
longer possible (at least without disabling the new files from building,
rebuilding it without them, and then adding the additional .pak file;
but it would seem more efficient to use the time that would be spent
doing that restoring Makeobj building to working order, the best place
to start which is the backup file which is on my NAS device buried
somewhere in the temporary place where I am currently living).

What normally happens is that the scripts use Makeobj to build a single
.pak file for each category of item (ways, stops, road vehicles,
grounds, etc.), and these are placed into a directory strucutre by those
scripts together with the configuration files, and then transferred /en
bloc/ to the correct directory for running Simutrans. Whenever there is
a change in the pakset, I simply recompile the whole thing and overwrite
the previous binary files in the pakset.

In any event, thank you again for your contribution;

James.

On 08/09/2014 15:56, pipcet wrote:

James,
Oh, I was assuming you could just use a full pre-built PAK directory
and copy in that one file.

By the way, have you attempted building a clean checkout of the
way-improvements branch makeobj? Obviously if it's my patch that's the
problem it shouldn't go in until compiling makeobj works again, though
I don't recall doing anything that I would have expected to break
things like that. It's quite possible we need to define LOCAL to build
dr_rdpng.cc, or that the #include must happen after the #ifndef LOCAL
in dr_rdpng.cc.
Philip

—
Reply to this email directly or view it on GitHub
#25 (comment).

[pipcet]

Oh! I didn't realize there were different make processes for Pak128.Britain, one using makeALL.mos and one using the (GNU) Makefile. The latter generates thousands of individual PAK files, and I created the ways.pak file by merging some of them, but forgetting about the sidewalks. I will build a proper BritWay.pak momentarily, but uploading it is going to take a while.

Sorry, again, for that confusion,
Philip

[jamespetts]

Ahh, I do not use the makefile, so I did not realise that it worked in a
different way: that seems inefficient. There is much to be said for
making that work in the same way as the Python script. Apologies for the
confusion;

James.

On 08/09/2014 16:41, pipcet wrote:

Oh! I didn't realize there were different make processes for
Pak128.Britain, one using makeALL.mos and one using the (GNU)
Makefile. The latter generates thousands of individual PAK files, and
I created the ways.pak file by merging some of them, but forgetting
about the sidewalks. I will build a proper BritWay.pak momentarily,
but uploading it is going to take a while.

Sorry, again, for that confusion,
Philip

—
Reply to this email directly or view it on GitHub
#25 (comment).

[pipcet]

James,
Hmm. The first idea that springs to mind is to simply remove the Makefile and ask people to use the .mos script instead. However, I've modified makeobj to output proper dependency information (so only the changed parts of the PAK set are rebuilt), and I think that would integrate well with automated Blender invocations to rebuild the pak directly from .blend sources (which would take far longer as it invokes Blender for thousands of scenes), so maybe it would be best to deliberately break it/make it output a message asking people to use MOSE, but keep it around for now.

I've uploaded (and shared, this time) a new ZIP file that I've confirmed actually works as a replacement for BritWays.pak. Sorry again for that confusion, and thank you for taking so much time to test things (though of course if you prefer to wait until you get your drive back, that's perfectly okay, it's not an urgent matter).

Philip

[jamespetts]

Philip,

thank you for that. May I ask how I can find the new .pak file that you
have uploaded? The original link still points to the original ways.pak
file, I think;

James.

On 08/09/2014 17:26, pipcet wrote:

James,
Hmm. The first idea that springs to mind is to simply remove the
Makefile and ask people to use the .mos script instead. However, I've
modified makeobj to output proper dependency information (so only the
changed parts of the PAK set are rebuilt), and I think that would
integrate well with automated Blender invocations to rebuild the pak
directly from .blend sources (which would take far longer as it
invokes Blender for thousands of scenes), so maybe it would be best to
deliberately break it/make it output a message asking people to use
MOSE, but keep it around for now.

I've uploaded (and shared, this time) a new ZIP file that I've
confirmed actually works as a replacement for BritWays.pak. Sorry
again for that confusion, and thank you for taking so much time to
test things (though of course if you prefer to wait until you get your
drive back, that's perfectly okay, it's not an urgent matter).

Philip

—
Reply to this email directly or view it on GitHub
#25 (comment).

[pipcet]

James,
the link should be https://drive.google.com/file/d/0B1BzInLP7rTKYU5fTnIyZXVrTzA/edit?usp=sharing . Does that work for you? I think it should have sent you a notification email, but that might not have gone to your primary email account. Sorry about that,
Philip

[jamespetts]

Philip,

ah, splendid, thank you. Your notification, I think, did go to a
non-standard e-mail address: I did not realise that it was a
notification giving me a link that I did not otherwise have.

Having tested that briefly, it seems to work rather well, thank you:
this does helpfully solve an issue with roads that we have had for some
time in Simutrans, so this is very useful. That really is most helpful;

James.

On 09/09/2014 21:14, pipcet wrote:

James,
the link should be
https://drive.google.com/file/d/0B1BzInLP7rTKYU5fTnIyZXVrTzA/edit?usp=sharing
. Does that work for you? I think it should have sent you a
notification email, but that might not have gone to your primary email
account. Sorry about that,
Philip

—
Reply to this email directly or view it on GitHub
#25 (comment).