Sometimes convois do not fit into a station of the right length. I found this with PakBritain road trains with 4 trailers. all have length=4, hence the vehicle should fit into one tile stations. However, this is not the case if the convoi goes north or west.
The patch fixes this. If a convoi enters a station it now drives until the first vehicle arrives at the station end. The routine was right if the first vehicle has length=8, but for shorter vehicles the first vehicle did not drive to the end of the tile, but stops before.
Screenshot 1: old behavior, the tile before the station is occupied by the last vehicle in the convoi
Screenshot 2: patched, now the vehicle alignment is broken, which imho was tuned to the old but buggy routine
Screenshot 1 - old behavior
Screenshot 2:patched
Did I mention that I have no idea how to shrink the images? I hate gimp :P
Quote from: Dwachs on September 23, 2009, 08:24:59 PM
Did I mention that I have no idea how to shrink the images? I hate gimp :P
Maybe there is a talk about Gimp at the FEM Symposia in Oberwiesenthal? Otherwise I will tell you.. :D
Then pak128.britain vehicles are wrongly aligned. They shoudl start in the middle of the tile to avoid graphcis errors and have a consistent alignment. Or you break all pak64 vehicles.
The loading issue shoudl not depend on the actual vehicle position, see void convoi_t::hat_gehalten(). A convoi of length of exactly 16 should load on a single tile, a longer one won't load the last car.
Quote from: Dwachs on September 23, 2009, 08:24:59 PM
Did I mention that I have no idea how to shrink the images? I hate gimp :P
Image > Scale image
Quote from: prissi on September 23, 2009, 09:31:55 PM
Then pak128.britain vehicles are wrongly aligned. They shoudl start in the middle of the tile to avoid graphcis errors and have a consistent alignment. Or you break all pak64 vehicles.
Yes they are wrongly aligned - but I suspect they are so aligned to circumvent the bug I tried to describe.
The convoi in the picture has length 16, so it should fit in one tile, which is
not the case. Due to 'wrong' alignment it seems that the convoi is perfectly inside the station, which is not the case. It blocks the tile before the station.
With the patch, the convoi is inside the station, but its graphic not.
The routine that handles convois going N or W at their target station was made for vehicle lengt=8. If the first vehicle of a convoi is shorter (here: len=4), then it will not advance as much as needed but stop 64 internal steps too early. This is fixed with the patch. I hope this explanation was clearer.
So how should the alignment of vehicles be? Currently they are all aligned so that the front end of any vehicle is in the same place in the png file. Is this right? Or should the centre of the vehicles be in the same place?
Does this bug/issue/feature/patch affect just road vehicles or trains and trams as well?
It affects everything as far as I see and thus trains will drive out of the station or stop too early in said directions and planes will drive into the buildings to load or stop too early (depending what length is given to them).
Applying the patch way requires a good amount of realigning all vehicles size smaller than 8 (and also a provision to keep it the current way for vehicles size>8). When all pakset author agrees to that, (or a least pak128 and pak64) then we can do this. Otherwise I would strongly advice agains it.
Currently the front should be on the same place, that is the indended alignment.
This is one of the prices on have to pay for Sprite based engine.
Currently pak128.Britain alignments are all to the front, so it looks like this will affect other paks too (just I think pak128.Britain makes more use of varying length vehicles).
If this will affect everything, then maybe a graphical offset could be universally applied to all vehicles dependent on their length (so len=8 would get no offset, len=7 would get a small offset, len=6 slightly more etc) to correct for the change in behaviour resulting from this pak? Then that would remove the need for changing the alignments of every single vehicle in the game...
Obviously as a pakset maintainer I would rather have such a fix than having to change the alignments of every single vehicle in my pakset - I'd rather spend the little time I have drawing new stuff!
I could probably provide a tool that would realign everything (given that everybody found their correct new alignment themselves!). However, I can't really grant the same output format as input.
Pak128 vehicles and houses have been split this way, so the basis is more or less ready.
Only vehicles with length<8 would need realignment, the other would be fine.
Another possibility would be an wutomatic realignment for said vehicles. (Hopefully none of those short ones use large offsets already.)
I hope this patch can go in; I've found the "accidental blocking" annoying.
Since this breaks all graphics and display routines, this will not go in until a better system to display the sprites is implemented.
Quote from: prissi on October 23, 2009, 09:32:47 AM
Since this breaks all graphics and display routines, this will not go in until a better system to display the sprites is implemented.
OK, reading through the topic it seems:
(1) There is a major gameplay bug present which Dwachs's patch fixes.
(2) There are graphics bugs introduced by fixing the gameplay bug.
(3) The graphics bugs should be fixable by realigning the images in some automated fashion.
I have to figure out what needs to be done in order to realign them however. I'm somewhat confused by the entire display scheme. Is this bug related at all to the fact that vehicles which are "spread across" two tiles visually are usually "located" on the first tile, not the second one -- and sometimes vehicles which are graphically located on one tile are actually entirely located on the previous tile? What's up with the "north or west" specific code?
Maybe Dwachs could help explain to me what's going on in this code.
But also for signals and a lot of other situations the alignment would need a change. Especially curves would look ugly. There is a reason for this positioning.
Quote from: prissi on May 12, 2010, 09:10:35 PM
But also for signals and a lot of other situations the alignment would need a change. Especially curves would look ugly. There is a reason for this positioning.
Well, perhaps if I could figure out what the graphics updates are *doing* in the first place... it's a little cryptic. The gameplay bug is really quite serious and affects pak balancing as it creates a pointless need for longer platforms (& longer signal spacing too I believe).
Platform length is not affected. All vehicles will be loaded, independent of their position.
Quote from: prissi on May 13, 2010, 09:14:47 PM
Platform length is not affected. All vehicles will be loaded, independent of their position.
Well, it creates a need for a blank straight tile in front of platforms.
I'd like to recall this eye candy offset into your Simutrans Standard developer minds.
Currently I'm extending the Simutrans Experimental physics code. Now it simulates not only accelerating, but also braking depending on vehicle figures, which means I have to calculate the position at which the convoy must start braking. This works fine for destinations in directions south and east, but in directions north and west convoys abruptly stop at a speed of about 16-20km/h. Shortly before I despaired of it, I found this offset in the code and this topic in the forum. If the code respects the too early stopping and there is an exit signal on the same last tile of the station, convoys accelerate a little an stop again due to the signal.
Wouldn't it be great to find a solution to get rid of this source of blocking convoys while they are waiting for load?
Any new ideas with least effort and most benefit?
I started work on one idea to eliminate this N||W special case a while ago, but it's sitting in some dark corner of my hard drive somewhere...
As the special case applies only for stopping in stations, ugliness abounds at road intersections where stopped vehicles are halfway into the intersection. Removing the special case makes the stopping position consistent for stations, signals, and intersections.
This makes cornering vehicles look bad with the back end snapping out as it enters a tile headed in a new direction. So for why not continue moving in the old direction for half a vehicle length in the new tile before changing the image? Turning vehicles now appear to pivot about their center - much better looking IMHO.
All images would require realignment such that they're in the stopped position when the convoi has moved all the way to the edge of the tile. i.e. front of the vehicle is aligned with the tile edge rather than halfway into the next tile. Can be easily automated assuming all existing images are aligned 'correctly' for the current system.
I think the only proper way of doing this is keep the current tile alignement and shift vehicles at load time and get rig of the extra offset internally. If Dwachs code really is not affected by the vehicle in other position entring the tile.