Recent posts

#71

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.

#72

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.

#73

Extension Requests / Re: Wish: Diagonal graphics fo...

Last post by makie - August 18, 2026, 07:36:31 AM

That looks very good. 

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.

#74

Incorporated Patches and Solved Bug Reports / Re: squirrel script - build br...

Last post by Andarix - August 18, 2026, 05:56:11 AM

thank you

[Tunnel case:]

#75

Incorporated Patches and Solved Bug Reports / Re: squirrel script - build br...

Last post by victor_18993 - August 18, 2026, 12:27:37 AM

Hi Andarix,
I've finished investigating the

Code Select Expand

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

Code Select Expand

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
  
  Code Select Expand
  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
  
  Code Select Expand
  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,

Code Select Expand

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

[Traffic lights:]

#76

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

Code Select Expand

makeobj still does not recognize the new diagonal/front/left-hand image keys. That is why the current objects are ignored with

Code Select Expand

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:
   
  
  Code Select Expand
  Image[dir][1],
   
  
  Code Select Expand
  Diagonal[0..7][1],
   
  
  Code Select Expand
  FrontImage[dir][0..1],
   
  
  Code Select Expand
  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
  
  Code Select Expand
  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.
• Code Select Expand
  offset_left: I have not made it automatically switch to zero when left-hand graphics are present. Makie's current
  
  Code Select Expand
  .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

#77

Forum / Re: Tutorial Underground railw...

Last post by Isaac Eiland-Hall - August 17, 2026, 11:28:27 PM

oh, I bet I know what it is. I'd had a task to reload apache every hour, but during the last problems I increased that since it was failing. I bet it's still reloading every five minutes and I haven't caught a page load error somehow myself........ maybe this will be solved. Thank you for the report

#78

Incorporated Patches and Solved Bug Reports / Re: squirrel script - build br...

Last post by Andarix - August 17, 2026, 09:54:36 PM

Code
https://github.com/Andarix/simutrans-scenarios/blob/54ad3bfedc2779bf06470abedb27d29cccd6a7b3/ai/sqai/astar.nut#L676

#79

Forum / Re: Tutorial Underground railw...

Last post by Andarix - August 17, 2026, 08:50:49 PM

It simply states rather tersely that the page could not be loaded.

Refreshing the page immediately afterwards loads it successfully.

#80

Patches & Projects / [Script API] Add convoy has_no...

Last post by victor_18993 - August 17, 2026, 06:17:30 PM

Two new Script API methods for convoys have been added to trunk in r12171:

    convoy_x.has_no_route()
    convoy_x.is_stuck()

They expose conditions that Simutrans already tracks internally and already shows in the GUI, but that scenario and AI scripts could not query directly before.

`has_no_route()` returns true only when the convoy is in the engine's NO_ROUTE state.

`is_stuck()` uses the same definition as the GUI and convoy list filter: it returns true only for the two long-wait states that represent a convoy blocked for roughly two months.

This deliberately differs from `is_waiting()`:

- `is_waiting()` can be true for a normal temporary wait, such as waiting at a signal.
- `has_no_route()` identifies a convoy for which route calculation has failed.
- `is_stuck()` identifies a convoy that has remained blocked long enough for the game itself to classify it as stuck.

This allows scenario and AI authors to detect operational convoy problems directly instead of trying to infer them from waiting state, timers or other indirect information.

The implementation is read-only and uses the existing synchronized convoy state. There are no changes to simulation behaviour, savegames or the network protocol.

A permanent regression test also drives a real running convoy into NO_ROUTE by redirecting it to an unreachable road and verifies the new public API.

Integrated in:

    SVN r12171
    ADD: script API predicates for convoy no-route and stuck state

Full regression after integration:

    286 / 286 PASS

Related discussion / original request:
https://forum.simutrans.com/index.php?topic=13473.0