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

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

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

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.

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

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

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

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

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.

>> 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