Started by An_dz, March 07, 2017, 08:32:13 PM
0 Members and 1 Guest are viewing this topic.
QuoteBut I'm ashamed to say that I don't know how to use .patch file.
QuoteDownload from the SVN then apply the patch to the SVN then build. On Windows I recommend TotoiseSVN to download and then apply the patch as it has a UI.
Quote from: An_dz on March 07, 2017, 08:32:13 PM1) the wrong crossing graphic might be chosen in crossings between two different way types (e.q. A road+rail crossing and you build the 255 over both)
Quote from: An_dz on March 07, 2017, 08:32:13 PM2) If you create an electrified waytype 255 it wrongly shows in the way info as being electrified, though it's not.
Quote from: Leartin on March 08, 2017, 06:39:48 AMCould you implement a check to see on which bordering tiles a 255-waytype exists to circumvent that?
Quote from: Leartin on March 08, 2017, 06:39:48 AMDoes the same problem arise with trams on roads?
Quote from: Leartin on March 08, 2017, 06:39:48 AMIsn't the bug that it's not electrified, rather than that it's shown as electrified?
Quote from: Leartin on March 08, 2017, 06:39:48 AMIs the drawing order between this generic wayobj and the specific wayobj set? If not already, it probably works same as with road&tram - please place the generic wayobj outside.
Quote from: An_dz on March 08, 2017, 02:07:04 PMYou are comparing oranges with apples, tram ways surely don't make any check as to which track is beneath them. But a wayobj does.
Quote[...]like a rail electrification does not give energy to the road it's crossing.
Quote from: Leartin on March 08, 2017, 02:16:39 PMI was not clear on that: I meant 255-wayobj placed on tiles where both road and tram already exist. Since a tram curve can be on a straight road and vice versa, it seems to have the potential for the same issues you get with crossings, but a bit more complicated.
Quote from: Leartin on March 08, 2017, 02:16:39 PMWhat's the harm? It's not like any vehicles require non-electrified ways, so if something becomes electrified accidentially, it's not a big issue.
Quote from: prissi on March 09, 2017, 12:29:46 AMI think, if you electrify wayobj 255, it should be rather count as a power line. So you can route power lines through ciies ...
Quote from: prissi on March 09, 2017, 12:29:46 AMI think, if you electrify wayobj 255, it should be rather count as a power line. So you can route power lines through cities ...
Quote from: Leartin on March 09, 2017, 06:14:31 AMI would rather have electrification electrify all ways on a tile.
Quote from: Ters on March 09, 2017, 04:50:54 PMThat was my first thought as well, but trams run in the middle and trolley buses run on the sides, so the wires for each would be in different places. One could of course just let players who cares about such things have three variants of each overhead wire style, and have them enforce the right use on themselves.
Quote from: THLeaderH on March 25, 2017, 02:40:05 AMCan I use decoration way as a marker of overtaking_info? (in OTRP project)
Quote from: An_dz on March 23, 2017, 05:35:35 AMHere's an update where it electrifies both tracks now, previously it was electrifying only one.
QuoteNo, that would be a terrible implementation. I'm already looking in creating a new type or subtype for OTRP.
Quote from: THLeaderH on March 26, 2017, 01:26:42 AMOh, that's great. Though I already released v9, it's not a integration candidate. When a new type is added, I'll fix OTRP so that it'll match with this patch.
Quote from: Dwachs on April 04, 2017, 06:19:47 AMDefining decoration_wt as 255 is a source of potential errors: When converted to 8 bit integer types this will be equal to invalid_wt. Can this happen somewhere? Edit: I would like to change this value to something like 230. any objections?
Quote from: Vladki on April 04, 2017, 06:48:40 AMWouldn't there be the same problem with already existing walls that are rails with subtype 255?