Makeobj overrides image coordinates in dat-file

[vorlon]

I have been lately experimenting different highway entrance and exit ramp designs, and came across this weird problem while making in-game tests. It appears that no matter the coordinate value set in the dat file, makeobj makes curved roads going from west to north have the graphic in square 0.0. See the example below:



There are the source files, yet this is what it looks in simutrans after being paked (makeobj 55.2):



I can also upload the sources and the pak-file, if necessary.

[Sarlock]

At first glance, don't you also need:

Code Select Expand


Diagonal[NE][0]=image_name.y.x
Diagonal[SE][0]=image_name.y.x
Diagonal[NW][0]=image_name.y.x
Diagonal[SW][0]=image_name.y.x


in your .DAT file settings?

Give it a try and see if that solves it.

[vorlon]

The problem still persists.

I thought those parametres were optional, like winter and front images. If no separate diagonal graphics are assigned the game uses the standard curve images. And even if those lines were needed, the resulting glitch should be more systematic instead of just one curve being the wrong one.

[Ters]

Have you confirmed that it's makeobj that makes the pak wrong, and not Simutrans that uses it wrong?

[vorlon]

No, that thought never occoured to me. But how could that even be tested? If it is an unknown bug, it must be in the nightly builds as well, and as far as I know, older versions of simutrans are incompatible with paks made by later makeobj versions.

[Ters]

No, that thought never occoured to me. But how could that even be tested? If it is an unknown bug, it must be in the nightly builds as well, and as far as I know, older versions of simutrans are incompatible with paks made by later makeobj versions.

If the bug is in Simutrans, it would likely affect all paks loaded with that version of Simutrans. If the bug is in makeobj, it would affect all paks made with that version of makeobj, whereas older paks work just fine.

I also have a program that reads pak files and shows me its contents.

[Sarlock]

Trying to work with your source material and there's a missing aspect:

Do you have 4 different .DAT (and .PAK) files to create the 4 directions of exits?  The included .DAT file information only seems to create proper exits for 2 of the 8 possible directions.

Can you include the sources?

[vorlon]

Yes, I indeed have 4 different exit/entrance paks plus two additional roads to get all possible combinations working. And the funny thing is, all of these work properly...  Except for the north-west-curve. In every single pak the north-west curve only is shown wrong. The complete sources and paks are here.

[Sarlock]

Can you also supply your sample save game?  I'm trying to assemble this all to look right but it's very confusing as to which pieces belong where... it would be easier to use the existing setup that you used for your image.

[prissi]

You must define empty Frontimages "-" for all directions, if you want to use this feature.

[vorlon]

Here is the save. You're right, the construction can be a bit puzzling, but I hope that it will be worth it once this issue is solved 

You must define empty Frontimages "-" for all directions, if you want to use this feature.

So do I have to write "-" to the coordinate section (FrontImage[SW][0]=image_name.-.-) or how is this done? Or does it work properly if I make the frontimages I don't need simply transparent?

[Dwachs]

Code Select Expand


frontimage[bla]=-

Just '-' as filename

[vorlon]

Just '-' as filename

Thank you - that clarified it.

Is there any idea as to what could be the cause of this bug? Having intersection graphics in corners really negates my attempt to make highway ramps look more realistic.

[prissi]

Please define empty frontimages and then, I hope, it may work.

[vorlon]

This gets more and more interesting: now that I added the empty frontimages, more corner graphics are drawn wrong. Once again a different way graphic than the one assigned in the dat file is shown, but it now affects also SW and NE- curves. I can say for sure that this isn't caused only by the frontimages, as also files without them are drawn wrong.

[prissi]

It would be helpful to get the source to debug this.

[vorlon]

Of course - here are the updated sources: https://www.dropbox.com/s/j8xzt84eckas1qv/simutrans%20%282%29.zip

[Ters]

Of course - here are the updated sources: https://www.dropbox.com/s/j8xzt84eckas1qv/simutrans%20%282%29.zip

The contents of the pak file looks right to me. There are no diagonals defined (or to be more precise, there are 0 sized images for them), but as far as I can see, there is no difference between a turn and a diagonal in this pak, and the turn slots contain the diagonal images, so I think that's right.

What strikes me is that the image used is index 15, in other words the last and the one with all ribis set.

[Dwachs]

There is a line-break at an uncomfortable location:

Code Select Expand


Image[NW]=highway_ramps.
5.3

Removing the linebreak will fix this issue.

[vorlon]

It works fine now, thanks to everyone for your help. The linebreak being copied to all of the dat-files caused the problem, and the frontimages were also fixed when I defined previously forgotten empty FrontImage[-]. I guess that makes this a solved bug report... 

[Ters]

I shouldn't be looking at lists late in the evening I guess.

But I suggest that makeobj should give a parse error in cases like this. Even if not specifying a coordinate is valid syntax for cases where the input image isn't an atlas, "5.3" on it's own line means nothing.

[greenling]

Hello Vorlon
Your idea it´s to big for one pakfile.
You must be splitt your idea  in more than one Pakfile.