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]
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]
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).
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.
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).
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]
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]
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
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.
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