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
- 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.
- 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.
- 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".
- I appreciate your help, thanks )
- It's ok. I simply hope that you can do it better.
- Ywang, I hope we could remain the same friends.
- I need to think about it.
ARSE7's Old Luacontroller
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
- 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.
Its nice that you build your city)
- 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
- The link you posted is a dead link. Please check if the filename is correct and update the link.
- 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)
Good to see you adding some routemaps to the wiki but please include tunnel portals in your routemaps:
tSTRa- tunnel start
tSTRe- tunnel end
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,
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>"
I'd prefer the brackets suffix as it is already on used on this wiki to denote different modes like:
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, 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.
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.
Blockhead, I think I got your point now. Thanks.
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)
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
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
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|
- 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 :/).
My current idea is to map LZB entries to a table that is specialized to store LZB control information (i.e. switch to lever at the index , which is 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.
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)
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 found a bug in your new movement logic: look here . 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.
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: 
- 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_HOLDare always taken into consideration when accelerating. Fixed: wrap that part of the code inside
if v0 >= params.ZONE_VSLOW...
endto ignore the two parameters when the train is moving slowly.