# User talk:Ywang

## Ocean City Problem

Ywang pls come back... Sorry if I do something wrong but we start this city together and pls.. come back Sorry if I was an egoist with you((( pls come back

ARSE7,
I understand your current feelings, as I was also rejected before. However, when people make decisions, they assume that they will accept the consequences. Now I do accept what I have after resignation.
I feel sorry that I didn't take screenshots of the chat between me and User:Smacker, but one thing I do remember is that Ocean City is not a city - it has no public facilities and is badly designed.
Ever since you started to take fares in Mushroom Market, I realized that it would fall because of not being competitive enough - who would buy a stand if there is a free one in Spawn? Who would go to a place with such high living cost and the requirement for building materials when they could choose freely in other places? The only reason that appears to attract people is the MV supply.
That only showed that you have taken too much from the people of Ocean City, and someday you will pay for it - at the cost that this city falls. And what about me? Financial fraud is no joke at all, and I do take it seriously.
I understand that you may not realize the consequence(s) of doing so, but this is too much to be forgiven, and I will not go back to Ocean City.
--User:Ywang
Ok, I acept it. Now in OC all is free, only 5mg for living cost in Capital, Dis One free. Tomorrow i ll back money to OC players.
--User:ARSE7
ARSE7,
I do understand that you are trying to fix the problem that I have pointed put, but this is simply part of the problem. Another problem is that Ocean City needs more public facilities. Consider building a hotel, a tech station (chargers and tool workshops), and a larger market
I hope my suggestion can help you, but I'm not going back. "Good luck with Ocean City".
--User:Ywang
Ywang,
I appreciate your help, thanks )
--User:ARSE7
ARSE,
It's ok. I simply hope that you can do it better.
--User:Ywang
Ywang, I hope we could remain the same friends.
--User:ARSE7
ARSE,
I need to think about it.
--User:Ywang

## ARSE7's Old Luacontroller

ywang,
About the Lua problem: now i know how use it, i didnt knowed this first (frequency) , i hope that this incident dont cause me too much troubles... --User:ARSE7

ARSE,
I used 4Hz Luacontrollers before, but the results were same as 1Hz ones, and I was warned that I could be banned for 4Hz Luacontrollers. I haven't finished setting up my tree machine yet, but I used 0.2Hz Luacontrollers before they were moved.
--User:Ywang

Ywang,
Its nice that you build your city)
--User:ARSE7

Thanks.
There is just one problem: some basic facilities appear to be missing, and line 1 comes once in about 106 seconds. I'll finish this as soon as possible, and then you will notice a new Wiki page that is in the "Cities" list.
--User:Ywang on 8 April 2019 at 20:42 CST

if you want a bad photo to put on there, use this one File:Ywangcity.png

Lucasburlingham,
• Wiki talk page is not a place where you send PMs. Please format your message properly and sign with --~~~~. I am tired of checking the edit history only to know who wrote me the message.
--Ywang (talk) 15:58, 16 April 2019 (CEST)

## BS routemaps

Good to see you adding some routemaps to the wiki but please include tunnel portals in your routemaps:

• tSTRa - tunnel start
• tSTRe - tunnel end

See the BSicon Catalogue for a good catalogue of the icons. --Blockhead (talk) 02:23, 7 August 2019 (CEST)

Blockhead: thanks. I'll add the tunnel portals. --Yw05 (talk) 15:39, 7 August 2019 (CEST)
Update: Sorry, I wrote that using my alt account so the signature is yw05. --Ywang (talk) 18:11, 7 August 2019 (CEST)

Also, your turnouts [places where the track diverges] seem to be only facing to the right. This is bad, and inaccurate. Use "l" instead of "r" in the second to last character to fix this. Also, maybe these turnouts should be labeled like the mainlines (example, E1 to Personhood) for consistency. --Nanepiwo (talk) 00:40, 12 August 2019 (CEST)

## Station names on the wiki

I appreciate your attempt to distinguish stations that are in crossroads from others but please use a more standard naming scheme. Wikipedia always uses suffixes, like "Station <(Placename)>" or "Station, <Placename>"

References:

I'd prefer the brackets suffix as it is already on used on this wiki to denote different modes like:

--Blockhead (talk) 04:55, 13 September 2019 (CEST)

Blockhead, I guess I would keep my current naming scheme because it's easier for me to sort the station codes in my LuaATC environment, which also use prefixes for places (i.e. cr* instead of *cr), and I think this is the influence from the station names here IRL, which also uses prefixes like:

• Heidelberg-Kirchheim/Rohrbach
• Heidelberg, Rohrbach Süd
• Leimen, Friedhof
• Leimen, Zementwerk

(Although in most cases only "Rohrbach Süd", "Zementwerk", etc. are written)
For stations serving multiple types of trains, I would usually use different names (except for North/East/South/West/Central/Main Station), like IRL ("HD-Kirchheim/Rohrbach" and "S-Bahnhof Kirchheim/Rohrbach").
However, I would also keep the brackets ("(Subway)", "(Express)", "(Regional)", etc) to distinguish stations that are served by different types of trains and use the same name, but I don't think I need them at the moment.
--Ywang (talk) 14:27, 13 September 2019 (CEST)

Ywang, you have missed the point. This has nothing to do with the station codes. This has to do with consistent style for an English wiki. The way you are naming your wiki pages on stations is not fluent in English. Yes I understand you may want to write these pages in "big-endian" kind of order where the general area comes before the less specific one, but this is where your convenience comes at the cost of user comprehension.

I can see you have made some pages with commas in them like Silver Coast, Central Station. I am not sure of the rules about commas in German but in English this is an unnecessary and frankly annoying comma. An English speaker does not pause at all when saying Silver Coast Central Station, but wherever there is a comma there is supposed to be a brief pause in speech. This is just as annoying to read as it is to say aloud.

Consider some more examples: Ref: Central railway station, Brisbane [1]

Equivalently to "Central railway station, Brisbane" you could write "Brisbane central railway station" and be well-understood in English. But if you wrote "Brisbane, central railway station", you would not be writing in fluent English; a native speaker/writer of English would never write or say that. Key word here: English, not German. I am not going to dictate what convention the wiki might follow if it were written in German.

"South Brisbane railway station" is a name that stands on its own without commas or brackets. Now here comes the weirdness with English place names: There is no hard and fast rule about whether you should call a place "<Direction> <Place>" or "<Place Direction>". South Brisbane and Brisbane South are equivalent; but in every case one variation dominates and is the one written down as the official name. Coming back to pages you have wikified, you can fluently write "Silver Coast North Station"; but please don't write "Silver Coast, North Station" as it's an unnecessary comma. It is well understood to anybody fluent in English that "Silver Coast North Station" is a station in the north of Silver Coast. I can only imagine the annoyance of having to remember where the unnecessary comma goes as well.

I don't see a need for a correlation between your station codes and wiki page names - in fact they probably ought to be different as they are applied in very different contexts. Users want information in accessible and well-written format that is consistent with what they are used to - like English wikipedia. Railway operators want station codes to be internally ordered and consistent in scheme but there is a high level of assumed knowledge in the encoding and it is up to the operator to assign codes as they see fit. I won't dictate to you how to assign your station codes at all, but I want the wiki to be both self-consistent and consistent with Wikipedia to an extent.

Also, afaik commas in German aren't used like this either, but it appears that (at least) some bus companies would do this as a separation. German Main/East/etc stations odn't use commas or '-' either (i.e. "Heidelberg Hbf" instead of "Heidelberg, Hauptbahnhof" or "HD-Hauptbahnhof").
--Ywang (talk) 09:17, 14 September 2019 (CEST)

## Tmppe

As the discussion is closed I answer here: I don't want to freely open my link shortener
--Och Noe (talk) 12:09, 20 November 2019 (CET)

## Recent changes to advtrains - H#137

Thanks for your contributions. I hope that we can increase the performance by this.

Do you mind testing a possible corner case that could probably occur in some setups? The original algorithm did handle this case: Imagine you have two LZB control points directly adjacent to each other, like

===Train>>======|12|==|2|

What happens then? My current impression suggests that the train will have braked to 12 at the |12| control point, but then encounters the |2| and can't brake in the short distance between.

A way to possibly overcome this, that I had thought of some time ago, would be to have a table index -> maximum speed permitted at each index, and flood-fill this table when setting LZB control points. When done this way, we wouldn't need to calculate brake distances every step, but only once.

Example:

MaxSpd:13  12  12  11  11  10   9  --  --  --  --
Track :>> Train>>  ==  ==  ==  |9| ==  ==  ==  ==
Index :10  11  12  13  14  15  16  17  18  19  20

MaxSpd: 8   8   7   7   6   5   4   3   2  --  --
Track :>> Train>>  ==  ==  ==  |9| ==  |2| ==  ==
Index :10  11  12  13  14  15  16  17  18  19  20


--Orwell (talk) 10:01, 4 December 2019 (CET)

I'm also considering this. However, my current (local) edits have turned my local copy of the mod into garbage.

I have also become aware of the case you mentioned, so I'm also thinking about how to do with this. My current idea is to split the train - LZB area to the following sections:

LZB Length Acceleration Starting speed Speed after leaving the area Time
nil $\displaystyle s_{1}$ $\displaystyle a_{1}$ $\displaystyle v_{0}$ $\displaystyle v_{1} = \sqrt{2a_{1}s_{1}+v_{0}^{2}}$ $\displaystyle t_{1} = \frac{v_{1}-v_{0}}{a_{1}}$
3 $\displaystyle s_{2}=$ params.ZONE_HOLD$\displaystyle =5$ $\displaystyle a_{2} = 0$ $\displaystyle v_{1}$ $\displaystyle v_{2} = v_{1}$ $\displaystyle t_{2} = \frac{s_{2}}{v_{1}}$
2 $\displaystyle s_{3}=$ params.ZONE_ROLL$\displaystyle =2$ $\displaystyle a_{3} = -0.5$ $\displaystyle v_{2}$ $\displaystyle v_{3} = \sqrt{2a_{3}s_{3}+v_{2}^{2}}$ $\displaystyle t_{3} = \frac{v_{3}-v_{2}}{a_{3}}$
1 $\displaystyle s_{4}=\frac{v_{4}^{2}-v_{3}^{2}}{2a_{4}}$ $\displaystyle a_{4} = -3$ $\displaystyle v_{3}$ $\displaystyle v_{4}$ $\displaystyle t_{4} = \frac{v_{4}-v_{3}}{a_{4}}$

--Ywang (talk) 17:32, 4 December 2019 (CET)

Hm, in my opinion we should give up the lzb control via the train.ctrl.lzb field entirely and weave LZB and the train moving system tighter together, since 99% of all trains are using it somehow. The whole LZB system needs a bit of rework.
gabriel and me did some profiling today (here), and apparently the most time-intensive calculation is the LZB system. A major cost factor in there appears to be the advtrains.path_get_index_by_offset function.
We can make a major optimization in this function by storing not individual distances in path_dist but the total distance from path item 0 (absolute). Then we won't need to iterate and sum up, but only have a while loop that continously advances until the path_dist is greater. This is something I'm going to do next (means next week probably :/).
--Orwell (talk) 14:22, 5 December 2019 (CET)

My current idea is to map LZB entries to a table that is specialized to store LZB control information (i.e. switch to lever $\displaystyle l$ at the index $\displaystyle i$ , which is $\displaystyle t$ seconds later), and then make train_step_b determine what to do based on train control. I'm aware that this may cause more lag, but first I should get the new system up and working (i.e. make users unaware of the new train logic system). Anyway, dropping train.ctrl.lzb and related functions are also something that I'm doing at the moment, and it should (hopefully) reduce some lag at the same time.

As I haven't looked into the path system very much, I can't tell what should be done to optimize it. I will, however, consider optimizations to my code as soon as the new trainlogic function is working.

--Ywang (talk) 19:36, 5 December 2019 (CET)

Update: It seems like train.ctrl.lzb is still needed for the train HUD, so I'm keeping it until we find a way to show the HUD without that value.
My current LZB code doesn't seem to be working at all - the test train still runs over the off the track.
--Ywang (talk) 22:46, 5 December 2019 (CET)

I just optimized said path_get_index_by_offset() function. Profiling results show that it now runs 3x as fast as before. gabriel will deploy it on the server soon. This optimization should also greatly speed up LZB.
Are you directly accessing train.path_dist in any of your changes? if so, I changed its semantics (see path.lua)

--Orwell (talk) 12:06, 6 December 2019 (CET)

No, I only use path_get_index_by_offset(), but I seem to call it more often than before. As I'm currently thinking about how to make the new LZB-/trainlogic system work, my current task is to make sure that the thing works.
--Ywang (talk) 13:42, 6 December 2019 (CET)

I expect to fix #135 along with this bug, since both are very much related. --Ywang (talk) 15:30, 6 December 2019 (CET)

Here is my model for calculating train movement (sorry for my handwriting):

Corrections are here.
--Ywang (talk) 15:59, 11 December 2019 (CET)

Hi again,

I found a bug in your new movement logic: look here [2]. The rail there is a simple ATC rail with "B0WORD10OCD1SM". In the moment the train passes the atc rail, it teleports 2 nodes back, executes its command sequence, and when it departs, hits the rail again.

I haven't tried to understand your code yet, maybe you have an idea.

--Orwell (talk) 09:58, 19 December 2019 (CET)

Thanks for the information, and I'll look into the problem ASAP.
However, I accidentally lost my SSH key, and I'll try to find a way (e.g. Testdisk) to recover it. Otherwise I'll notify gabriel if I can't find it and have to generate a new one.
--Ywang (talk) 18:04, 19 December 2019 (CET)

Update: Testdisk doesn't seem to be working. I have generated a new keypair.

Update 2: I have generated my new key pair and sent it to gabriel, and I'm back from Christmas holiday. I didn't manage to solve the equations that I mentioned here, so I used an algorithm similar to the current one, except it "predicts" possible overrun. I'm aware that the braking problem happens somewhere in that part of the code.

Update 3: I still have no idea what's wrong with my code, and the bug you mentioned doesn't reproduce in my case.

The World: [3]
Log in as singleplayer, a train exhibiting the behavior is right in front of you. Also the train on the reversing track appears to be immovable.
--Orwell (talk) 16:37, 12 January 2020 (CET)

Thanks. The problems were:

• Something in the Point Restriction Rail caused the train to move backward, so it appears as if the ATC rail was causing the problem. As I didn't use PSR rail when braking, it didn't reproduce in my case. Fixed: s = math.max(s,0)
• For the train at the reversing track, the train at the front did not touch the LuaATC rail at all because of params.ZONE_ROLL and params.ZONE_HOLD are always taken into consideration when accelerating. Fixed: wrap that part of the code inside if v0 >= params.ZONE_VSLOW ... end to ignore the two parameters when the train is moving slowly.

--Ywang (talk) 18:25, 12 January 2020 (CET)

Update: tolerating acceleration at v0 < ZONE_VSLOW seems to cause the "overrun red signal" problem. --Ywang (talk) 14:44, 25 January 2020 (CET)

Update 2: it seems like trains move too far on a single step in a high-lag environment. Although the train logic code has been rewritten in favor of LZB, it does cause trains to skip tracks with non-LZB feature (e.g. ATC and LuaATC). --Ywang (talk) 20:52, 25 January 2020 (CET)

Update 3: The problem should (hopefully) be fixed during the Easter holiday. --Ywang (talk) 19:44, 1 April 2020 (CEST)

## Generated service infoboxes

As I have recently edited pages to include the track gauge, and some of those were the crossroads transport pages with geneated infobox, can you please add the track gauge to the output of your script that generates those, so that these manual changes won't be lost if/when those infobox change?

--Blockhead (talk) 06:23, 1 March 2020 (CET)

The script I wrote didn't turn out to work as well as I expected, and I accidentally lost it (not joking). I will add the "track gauge" field when I have time to write it again. --Ywang (talk) 19:44, 1 April 2020 (CEST)

You might take this opportunity to write it is a lua module on the wiki this time, where it definitely won't be lost!

--Blockhead (talk) 02:27, 2 April 2020 (CEST)

## MediaWiki Stuff

Some days ago, you created this query to get all pages with coordinates: https://wiki.linux-forks.de/mediawiki/api.php?action=query&format=json&list=search&redirects=1&converttitles=1&srsearch=%7B%7BCo%7C&srlimit=max&srwhat=text&srprop=snippet Is it possible to include the categories the page belongs to in the search results? I've tried a few things but couldn't get it to work. Thanks! -- M42uko

srprop=snippet makes the Wiki only include the parts containing {{Co. If you want it to include categories, you probably need to change srpprop= to include the category that the pages belong to (I haven't found that in srprop yet), or make separate requests to get the categories of these pages. --Ywang (talk) 09:35, 27 April 2020 (CEST)

## Ocean City ATL-Z/B Junction

Hi, I would just like to point out if you want to re-do the junction near Ocean City, you could build it like this instead:

orange = TCB