News:

Simutrans Sites
Know our official sites. Find tools and resources for Simutrans.

Recent posts

#61
Simutrans Help Center / Re: Cityhouses with FrontImage
Last post by Sylph (Leartin) - August 18, 2026, 08:50:02 PM
The coords are the same.

I used a lot of offsets in P192C - this means you can have frontimages higher up. I don't think that's enough for these buildings, but often you might have windows that fit in a single squaee if you move them
#62
Patches & Projects / Re: [PATCH] Vehicle-specific s...
Last post by maxim13 - August 18, 2026, 07:55:31 PM
I have attached the SVN patch prepared against trunk revision r12173.
vehicle-speed-bonus-svn-r12173.diff
#63
Simutrans Help Center / Re: Cityhouses with FrontImage
Last post by prissi - August 18, 2026, 07:44:37 PM
You could use a larger pak size. I think one radio tower in pak96.comic or pak192.comic used this.
#64
Simutrans Help Center / Re: Cityhouses with FrontImage
Last post by Václav - August 18, 2026, 05:29:52 PM
Quote from: Sylph (Leartin) on August 18, 2026, 04:50:30 PMIIRC, citybuildings only support frontimages at ground level.
Oh, no. It would explain why those glasses appear only on few bottom floors.

What about coords? Are they the same like in case of BackImage or different?

Quote from: Sylph (Leartin) on August 18, 2026, 04:50:30 PMAlso, I'm just on the phone and can't check, but don't you lose transparency because of the blueish background? You don't need that, just have it transparent.
Yes, I used blue background - and after its removing it became transparent. But however, I will have to play with transparency, itself, because even if glasses became transparent, they don't light at night.
#65
Simutrans Help Center / Re: Cityhouses with FrontImage
Last post by Sylph (Leartin) - August 18, 2026, 04:50:30 PM
IIRC, citybuildings only support frontimages at ground level. In P192C, we used frontimages to add animated chimney smoke and do other animation tricks (moving crane or window cleaner, the animations in most monuments)

But I distinctly remember that I also used what you describe in a gas station. I set part of the backimage to black or white and used semitransparent light color on top. Thus, during the day, it was light green or dark green depending on the sunlight, but at night only the light color is visible.

Also, I'm just on the phone and can't check, but don't you lose transparency because of the blueish background? You don't need that, just have it transparent.
#66
Simutrans Help Center / Cityhouses with FrontImage
Last post by Václav - August 18, 2026, 03:50:55 PM
When I was preparing latest cityhouses, I got idea - to have balconies closed by (reflexive) glass. But when I prepared it as I originally wanted, nothing lit at night. So, I separated (reflexive) glass closing balconies to they would be used as FrontImage.

But I did not find how to correctly use FrontImage. I used it like BackImage is used - but I found that it does not run correctly (front part does not covers all windows as it should).


Minor problem is with transparency of those reflexive glasses. I thought that it could be interesting to do them transparent and let windows be visible (through them). But something goes wrong and transparency is lost. So, I will have to make some glasses missing instead transparent.
#67
Extension Requests / Re: Wish: Diagonal graphics fo...
Last post by makie - August 18, 2026, 07:36:31 AM
That looks very good.  8)

Little change on the autobahn sign need.
https://makie.de/p128_sign_road_autobahn.zip

Just download again.

Would like to have the code was incorporated.
Then I will revise all the traffic signs in pak128 and pak128.german. ;D
#68
thank you
#69
Hi Andarix,
I've finished investigating the
First click has side effects issue, and the two reported cases are now understood and fixed in trunk.
They turned out to be two different
sqai_rail call-path edge cases that happened to trigger the same Script API guard:
  • Tunnel case: the tunnel tool was being called with two coordinates, but for surface tunnel construction the tool already acts on the first click. The Script API therefore correctly rejected the two-coordinate call. The fix is now using the one-position
    work(player, pos, param) form while keeping the tunnel descriptor.
  • Bridge case: the error occurred when the starting tile was already a bridge with the requested waytype. In that situation the normal two-click assumption no longer applies. The fix now skips that invalid tool call and lets the recovery logic already present in
    sqai_rail handle the route normally.
So this was not a Squirrel 3.2 regression, and the Script API guard itself is working correctly.
The fix has been integrated into trunk as r12172.
Validation performed before integration:
  • Squirrel syntax/import check: PASS
  • targeted tests: 3/3 PASS
  • full Simutrans regression suite: 286/286 PASS
  • 0 new assertions
  • 0 new script errors
One practical detail for tunnels: if the AI needs to know where the tunnel will emerge before building it,
tunnel_planner_x.find_end(...) can be used to obtain the calculated exit portal first.
Thanks for reporting it and for providing the screenshots and code paths — they made it much easier to isolate both cases.
Regards
#70
Extension Requests / Re: Wish: Diagonal graphics fo...
Last post by victor_18993 - August 18, 2026, 12:18:55 AM
Hi,
I went through the whole thread again and reproduced the current problem against trunk r12171.
The main issue is simply that the signal code discussed earlier in the thread was never actually incorporated into trunk, so current
makeobj still does not recognize the new diagonal/front/left-hand image keys. That is why the current objects are ignored with
check spelling warnings and why the expected result is not visible when testing them.
I have prepared one updated patch against current trunk that contains:
  • the previously agreed 8-slot diagonal image support;
  • the later extension discussed in posts #39–#44:
     
    Image[dir][1],
     
    Diagonal[0..7][1],
     
    FrontImage[dir][0..1],
     
    FrontDiagonal[0..7][0..1].
The implementation keeps the normal image list unchanged, so the existing traffic-light detection by image count is preserved. The new image lists are stored separately and are only used when the pak provides them.
I also kept the fallback behaviour conservative: if a specialised image is missing, it falls back step by step to the normal image instead of making the sign disappear.
Validation performed:
  • all three current objects from makie compile without warnings with the patched
    makeobj;
  • legacy signs without the new keys produce byte-identical output;
  • right-hand and left-hand traffic variants were both tested;
  • diagonal and straight fallback behaviour was tested;
  • full Simutrans regression suite passes 286/286;
  • no new compiler warnings were introduced. 
There are two design points I have deliberately left visible rather than deciding them silently:
  • Traffic lights: in #41 Prissi mentioned a special flag because traffic lights are identified by image count. With this implementation the flag does not appear to be necessary, because all new variants live in separate child nodes and the main image list is untouched. If an explicit flag is still preferred, I can add it.
  • offset_left: I have not made it automatically switch to zero when left-hand graphics are present. Makie's current
    .dat already sets it explicitly, so I left that behaviour unchanged pending a decision. 
The patch is attached. It is against current trunk r12171 and contains only the signal/roadsign changes discussed in this thread.
If the overall shape is acceptable, I can adjust either of those two points before integration.
Regards