~ywang

~ywang/misc

Last active 1 year, 6 months ago
View more

Recent activity

Re: [PATCH] French update a month ago

From Y. Wang to ~gpcf/advtrains-devel

I have applied the patch. Thank you.

> +Perpendicular Diamond Crossing Track=Croisement  perpendiculaire
> +Diagonal Diamond Crossing Track=Croisement diagonal
> +90+Angle Diamond Crossing Track=Croisement perpendiculo-diagonal
> +Y-turnout=Embranchement en Y
> +3-way turnout=Embranchement triple

I would like to take this chance to point out a few things regarding
turnout/crossing items (this is _not_ specific to this patch, but mainly
for other people working on l10n who happen to come across this section
and find it confusing):

- The "90+angle diamond crossing track" is a type of crossing where one

Re: LZB Stopping trains at green signals after interlocking database wipes 2 months ago

From Y. Wang to ~gpcf/advtrains-discuss

> An image of the problem is linked below (ignore the
> terminology on the banners, the signal is green despite the train UI's delusions):
>
> https://i.imgur.com/Zk7r8qi.png

The signal on the image does not allow shunt operations.

Re: TCB : Break or Block ? 2 months ago

From Y. Wang to ~gpcf/advtrains-discuss

> Being currently writing an advtrains tutorial in french, I have a
> doubt about the actual meaning of the "TCB" acronym (and how to
> translate it).
>
> The most common full name I read in advtrains docs is "Track Circuit Break".

Yes, this is the device that marks the border of a track section.

Perhaps "track section border marker" would make more sense for l10n.

> But a search on internet for this acronym leads to, for example, :
>
> https://safety.networkrail.co.uk/jargon-buster/tcb/
>

Re: [Meta] Notabug.org mirror and bug tracker 3 months ago

From Y. Wang to ~gpcf/advtrains-discuss

> I have added gpcf, Montandalar and Maverick2797 to the Advtrains
> organization and to a team that has write access to the 3 mirror
> repositories. This should allow you to file, modify and label
> issues. I don't know the notabug accounts of others, especially ywang,
> so please kindly let me know so I can add you as well.

My username on Notabug is y5nw.

> As for the issue migration: please just migrate what you think is worth migrating.

I have mostly worked on certain features instead of fixing bugs, so I do
not think there is much (if anything) to migrate from Hempitera in terms
of things related to what I work on.

Re: Ghost train mitigation 3 months ago

From Y. Wang to ~gpcf/advtrains-discuss

> Ah, the savefiles were taken from my sever around a week before the data was
> lost.
>
> What has changed was (obviously) the positions of the trains on the server,
> meaning that there were trains on a different part of the map than where they
> were saved.
>
> Another thing that changed was a few junctions were added and bypassed aspects
> of the train network which were no good (like trains going underground to a
> junction to go back up again, which only existed because a now-derelict tunnel
> was at the same level, so i bypassed that with a viaduct and slope). I also
> interlocked an entire new tram system which was lost because of the
> interlocking data being lost.

Re: Ghost train mitigation 3 months ago

From Y. Wang to ~gpcf/advtrains-discuss

> After a serious interlocking data loss, a lot of routes on my
> server work absolutely fine, setup correctly, but are blocked by
> ghost trains.

- Are you using savefiles from the same backup?
- How much does the world differ from the data in the backup? (i.e. how
much have you changed since the backup was created?)

> I propose a simple fix: Whenever a train stops at a signal at
> danger, check if the occupied section is //really// occupied or
> it's just a ghost being annoying again.
>
> Also, the same check occurs whenever right-clicking a signal or
> a TCB.

Re: Train Fuel and limitations for realism 3 months ago

From Y. Wang to ~gpcf/advtrains-discuss

> Every term (configurable amount of time), a train in every x (configurable)
> breaks down and needs to be maintained. You can send them to a depot using
> LuaATC, maybe a function `needs_fixing()`, which returns the type of error if
> there is one, false if there isn't.

Please consider looking into OpenTTD's vehicle breakdown mechanism[1].

> Maybe instead, the texture is darkened and has a tranperent black layer applied
> on top of it, similar to the way Theatere Halogen Bulbs fail, with black spots.

You may want to ask for advice from Blockhead.

[1] https://github.com/OpenTTD/OpenTTD/blob/master/src/vehicle.cpp

Re: Train Fuel and limitations for realism 3 months ago

From Y. Wang to ~gpcf/advtrains-discuss

While the features mentioned here are quite interesting, IMO these are,
unfortunately, unlikely to be implemented in the short term.

Regardless of what type of fuel/power source, adding this feature means
that we need to implement physics and, in particular, friction and
gravity (among other things), as it would otherwise be hard, if not
impossible, to accurately calculate the amount of energy (and,
subsequently, fuel and electricity) needed to reach a certain velocity
or acceleration. Mechanical efficiency may need to be considered as
well.

For electricity, the implementation can be further complicated by trams
powered by supercapacitors, where the rate of recharging and
regenerative braking (the latter is not specific to such trams) need to

Re: [Meta] Notabug.org mirror and bug tracker 3 months ago

From Y. Wang to ~gpcf/advtrains-discuss

> #11 - I would file this to NotABug and assign ywang

Now that I think about it, I still need to add documentation on certain
behavior (especially with settings).

In addition, I would appreciate it if maintainer(s) of certain modules
could document the corresponding API themselves and send it as a
patch. It is a lot of work for me to document everything, and it is hard
for me to verify the correctness of such API documentation on my
own. At the moment, I am unlikely going to change the LaTeX internals
too much as it would mean a lot of work to update everything.

I could consider making a presentation on this topic.

Re: [PATCH] Add a config to destroy autombiles like OpenTTD 3 months ago

From Y. Wang to ~gpcf/advtrains-devel

> In testing, you may find the rear two seated passengers die much less often,
> but I assume it's ok to let at least somebody walk away from the crash
> sometimes..

I suppose (from what I understand from the patch) that the players are
simply dropped and left to be (possibly) killed by the train in the next
step? Then the passengers at the rear seat may be left outside the
collision area for the code that kills the players.

Perhaps it would make sense to allow choosing from one of the behaviors:

- Do nothing in particular (as in the upstream version)
- Drop the players as-is. They may be killed if they are close enough to
the train (and the train is fast enough, of course)