<This might be a specification, not a bug.>
As we can build both road and tram in one tile, we can build way-objects of both road and tram.
Usually, the order of drawing objects is decided and not changeable.
Example : (BACK) way(backImg) - stop(backImg) - way-object(backImg) - vehicle - (frontImgs) (FRONT)
However, when it comes to way-objects of road and tram, the order is uncertain and changeable.
Road's way-object(backImage) sometimes hide tram's way-object(backImage), and vice versa.
There seem to be some rules about this issue.
1. The backimage of what has been built the earlier hides the backimage of the later.
2. The order is reversed when a saved data is reloaded.
3. The order of frontimages is opposite to that of backimages.
I suggest that we decide which to be drawn front, because the uncertainty will bring us nothing good, and if we decide it, we will be able to make more orderly worlds.
I hope that way-objects of tram are drawn on the inside(which means backimages of them hide those of road, and frontimages are hidden), but it's an issue the developers should decide that which should be drawn front.
Simutrans version: 120.2 r8077
Actually it was never foreseen to have more than one wayobj on a tile. So it is no surprise that double wayobj are buggy. (Also the drawing of trams together with long trucks makes artefacts.)
Could you show an image, because I have some problem to imagine wayobj where the drawing order matters?
(http://simutrans-germany.com/files/upload/Problem_of_drawing_order_1.PNG)
The two ways look very similar, but there are some differences.(You would get it by looking at the pillars)
As for the left, I built tram's way-object first and then built road's.
As for the right, I built road's first.
Topic: (wishful thinking) two way_objects on one tile (http://forum.simutrans.com/index.php?topic=13788.0)
Why not change it to generally allow two way_objects per waytile, which are predefined as "inner" and "outer" one, and in turn disallow a road with tram to have two 'random' ones? IIRC, either electrification works for both waytypes anyway, and if there is work put into a correct drawing order, it would be more beneficial if all ways can use it, not just the special case of road+tram.
So far the code enforced one wayobj for waytype. That you could two on trams was rather more an accident than planning, which you can tell by the random drawing order. It would be very easy the order by waytype. i.e. rail first then road in this case. Allow two different wayobjs for all tiles will un in all sorts of usability troubles, like the need to strip the outer wayobj before the inner and so on, on not clear at the end of a wayobj which connects to which.
Thank you for your reply, prissi!
I was amazed to know that double wayobj is like an accident, and now I'm afraid that you might want to delete this 'accidental' function and that we would be perhaps not able to build two wayobjs on one tile, even there are both road and tram. That's because there is an addon which takes advantage of tram's 'double wayobj', and I like it.
If it is easy, could you fix the random drawing order?
QuoteAllow two different wayobjs for all tiles will un in all sorts of usability troubles, like the need to strip the outer wayobj before the inner and so on
Indeed we already have troubles like this quote.
I've thought I'll make a new topic about this trouble, but I'm telling it here.
We can remove either road's and tram's way-objects with 'Remove wayobj road' tool, and that of tram can remove both, too.
Sometimes road's tool doesn't remove road's wayobj, but removes tram's wayobj. The same thing occurs to tram's tool.
And it seems that which to remove depends on the drawing order.
I disagree with Leartin's idea because the system would be more complex, as prissi told.
I'm sorry to have written too many unnecessary things in my previous post.
Most importantly, random drawing order is a problem, right?
So could you fix the problem?
Check r8126 please
Thank you!
Has it not released yet?
There is yet r8125 on the following page.
https://nightly.simutrans.com/en/ (https://nightly.simutrans.com/en/)
The nightly builds are are all dated 07:00 UTC. That is still over half an hour away. (Apparently, they are nightly according to Americans.)
Wow, I've heard it for the first time, thank you for telling!
Then I'll try it a few hours later.
Especially since it is now later afternoon in Japan ...
Yeah, we Japanese perhaps should call it 'afternoon version.'
I tried the new one, and the drawing order problem seems to be fixed well.
But it has another problem: the tram's removing wayobj tool doesn't work at all.
I tested it with pak128 britain and it worked. Which pak did you use?
I usually use my original pak based on pak128.
And with pak128, it didn't work well either.
I got the reason and I could solve this problem.
In menuconf in pak128, the following is written as the default.
# tramtools (waytype 7)
toolbar[5][0]=ways(7,0)
toolbar[5][1]=ways(2,7)
toolbar[5][2]=wayobjs(7)
toolbar[5][3]=signs(7)
toolbar[5][4]=general_tool[17],16,,2
toolbar[5][5]=general_tool[33],,,2
toolbar[5][6]=buildings(33,7)
toolbar[5][7]=buildings(34,7)
So I changed it to the following
# tramtools (waytype 7)
toolbar[5][0]=ways(7,0)
toolbar[5][1]=ways(2,7)
toolbar[5][2]=wayobjs(7)
toolbar[5][3]=signs(7)
toolbar[5][4]=general_tool[17],16,,2
toolbar[5][5]=general_tool[33],,,7
toolbar[5][6]=buildings(33,7)
toolbar[5][7]=buildings(34,7)
Then it worked well.