~ywang

~ywang/misc

Last active 2 years ago
View more

Recent activity

[PATCH] Fix incorrect speed indicator; include routing info in text HUD 23 hours ago

From Y. Wang to ~gpcf/advtrains-devel

---
 advtrains/texture.lua  |  6 +++---
 advtrains/trainhud.lua | 12 ++++++++++++
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/advtrains/texture.lua b/advtrains/texture.lua
index 1ecc91b..e6d83b0 100644
--- a/advtrains/texture.lua
+++ b/advtrains/texture.lua
@@ -125,12 +125,12 @@ local function add_segmentbar(n, self, x, y, w, h, m, c, ...)
	local bs = ss - m
	for k = 1, argc, 3 do
		local lower, upper, fill = argv[k], argv[k+1], argv[k+2]
		lower = math.max(0, math.floor(lower)+1)
[message trimmed]

[PATCH] Rework graphical train HUD code a day ago

From Y. Wang to ~gpcf/advtrains-devel

- A basic texture manipulation API is added; currently this is only a
  (selected) subset of texture modifiers provided by MT; the goal is to
  avoid writing (potentially incorrect) texture strings by hand;
- The graphical HUD code is cleaned up; in particular, most code used
  for generating texture patterns are moved to texture.lua so that the
  code can be used outside of the HUD;
- Inactive elements are given the darkslategray background.

A basic unittest is added; however, it needs to be expanded for better
coverage.

Reported-by: Lars Müller <appgurulars@gmx.de>
---
 advtrains/init.lua              |   1 +
[message trimmed]

Re: [PATCH] Fix texture modifiers relying on undocumented behavior a day ago

From Y. Wang to ~gpcf/advtrains-devel

> The Lua API states:
> 
> /Modifiers that accept texture names (e.g. //|[combine|//) accept
> escaping to allow passing complex texture names as arguments. Escaping
> is done with backslash and is required for //|^|//, //|:|//and //|\|//./

Ah, I overlooked the part that escaping is required for carets and 
simply thought you were referring to the parentheses. Thanks for 
pointing it out.

> (that said, I am considering relaxing my parser since
> using parentheses instead of properly escaping carets seems to have come
> up a few times and is not that far off-spec / unreasonable).

Re: [PATCH] Fix texture modifiers relying on undocumented behavior 2 days ago

From Y. Wang to ~gpcf/advtrains-devel

I would like a bit of clarification here, as I do not see how the use of 
(x^y) is undocumented ("texture grouping"); the documentation for the 
[combine modifier also does not state that () can not be used in the 
texture string(s) to combine.

That said, the changes do make the texture strings look cleaner.

Regardless of the texture strings, I have to admit that the code was put 
together in a relatively short amount of time, so I (or someone else) 
would need to rework the code anyway.

Re: [Discussion] [API] advtrains.get_wagon_at_pos(pos) 7 days ago

From Y. Wang to ~gpcf/advtrains-devel

> Just noticed you added a patch here an hour ago... Which means we were
> working in parallel.
> 
> My remark still holds though, and I believe my implementation is
> correct.

Agreed. I put together that patch based on reading some existing code 
and my (limited) knowledge of the path system.

Anyway, I wrote that function as an auxiliary function for 
occ.get_wagon_at(pos) since Maverick2797 wanted to get the wagon at a 
speicific position; the idea is to use occ.get_trains_at(pos) and remap 
the returned table to wagons (instead of trains).

[PATCH] Add API to get wagons at a specific position 7 days ago

From Y. Wang to ~gpcf/advtrains-devel

---
 advtrains/occupation.lua | 14 ++++++++++++++
 advtrains/trainlogic.lua | 17 +++++++++++++++++
 2 files changed, 31 insertions(+)

diff --git a/advtrains/occupation.lua b/advtrains/occupation.lua
index db39991..18e3f2b 100644
--- a/advtrains/occupation.lua
+++ b/advtrains/occupation.lua
@@ -186,6 +186,20 @@ function o.get_trains_at(ppos)
	return r
end

-- Gets a mapping of wagon id's to offsets of wagons that stand or drive over;
[message trimmed]

Re: [Discussion] [API] advtrains.get_wagon_at_pos(pos) 7 days ago

From Y. Wang to ~gpcf/advtrains-devel

> Is there an easy way to check whether there's a wagon at <pos>?

You can check for the trains at a position using 
advtrains.occ.get_trains_at(pos). The returned value is in the form of 
{[id] = path_index}, so you can probably find the specific wagon by 
iterating through train.trainparts until you find the wagon whose offset 
(range) includes the particular index. Something along the lines of:

function get_wagon_at(pos)
	local t = {}
	for id, idx in pairs(advtrains.occ.get_trains_at(pos)) do
		local bp, p
		for _, wid in ipairs(advtrains.trains[id].trainparts) do
			local w = advtrains.wagons[wid]

Re: [PATCH] fix uv on signal 2 months ago

From Y. Wang to ~gpcf/advtrains-devel

Hi mbb,

Is this a follow-up of your previous patch ("change models on rotate")?

If you send a series of patches, it would be nice if you would add the 
message ID of the previous email as the In-Reply-To field (NOT Reply-To) 
of the new patch. This would make the patches appear as a thread and 
make it obvious that the newer one depends on the older one.

ywang

Re: [PATCH] replace model for retro signal 2 months ago

From Y. Wang to ~gpcf/advtrains-devel

The textures look quite nice. However, is it intended to have some 
pixels with other colors between the white and red parts (especially in 
the circle)? That looks IMO a bit weird.

Re: train.door_open documentation where? 5 months ago

From Y. Wang to ~gpcf/advtrains-discuss

>> The search box has a dropdown beside
>> it that says "log msg" by default,
>> so I am not sure why you are
>> surprised about this.
> 
> I did use it, but even the one most
> likely, "range" seems to search
> commits.

It seems like "range" searches for commits that belong to a branch or up 
to a tag.
>> Considering that, on the same
>> discussion page, you mentioned "[a]
>> simple