pak64 tutorial - changes to multipak

[Andarix]

This is the first step to using the tutorial directly for pak64.german.

The save has not yet been adapted and pak64.german also needs to be changed because there is no material wholesale. No other industry currently accepts boards as an end product either.

Unfortunately, the patch also includes some formatting changes regarding spaces and tabs.

[Yona-TYT]

This is the first step to using the tutorial directly for pak64.german.

The save has not yet been adapted and pak64.german also needs to be changed because there is no material wholesale. No other industry currently accepts boards as an end product either.

Unfortunately, the patch also includes some formatting changes regarding spaces and tabs.

Can you share your branch on github?, so I can follow the development more closely.

[Andarix]

I don't have a branch on github yet

[Yona-TYT]

By just updating the id list the menus already look better, additional adjustments still need to be made to remove tools that are not currently used.

Code Select Expand

// placeholder for some menus icon
t_icon <- {road = 0x800e, rail = 0x800a, ship = 0x800f, plane = 0x8010, other = 0x8005, slope = 0x8001, tram = 0x800d, build = 0x8002, stats = 0x8003, exted = 0x8004 }


[Andarix]

Can you share your branch on github?, so I can follow the development more closely.

And which repo should I fork then?

Yours or that of simutrans organization

[Andarix]

Apparently you can't access the station extensions in the tools without waytype.

[Yona-TYT]

And which repo should I fork then?

Yours or that of simutrans organization

The Simutrans organization is always at the forefront.

[Yona-TYT]

Apparently you can't access the station extensions in the tools without waytype.

I created a function so that menus (without waytype) can be displayed, it works with a list of waytypes and another of tools, for all waytypes the value 0 is used.

Edit.
The rules are filtering that menu, I'll investigate.

Edit2
I need to make some modifications to the pak64 script to resolve all this, I'll upload it to github in a moment.

Edit3.
This should work better with pak64.german menus
https://github.com/simutrans/tutorial_pak64/commit/d8ee302cc7449bb18ba8eecf540fe8056269062d

[Andarix]

The error is in scenario.nut line 707 (function is_tool_allowed(pl, tool_id, wt)).

There t_icon.tram is not used but the id directly.

Code Select Expand

Suche nach "8004" in Verzeichnis "F:\simutrans\124-2\pak64.german_4\scenario\tutorial" (2 Fundstellen in 1 Dateien)

F:\simutrans\124-2\pak64.german_4\scenario\tutorial\scenario.nut(107):       t_icon <- {road = 0x800e, rail = 0x800a, ship = 0x800f, plane = 0x8010, other = 0x8009, slope = 0x8002, tram = 0x800d, build = 0x8002, stats = 0x8003, exted = 0x8004}
F:\simutrans\124-2\pak64.german_4\scenario\tutorial\scenario.nut(707):   else if (tool_id == 0x8004) return false  //Tramsway Tools


[Yona-TYT]

The error is in scenario.nut line 707 (function is_tool_allowed(pl, tool_id, wt)).

There t_icon.tram is not used but the id directly.

Code Select Expand

Suche nach "8004" in Verzeichnis "F:\simutrans\124-2\pak64.german_4\scenario\tutorial" (2 Fundstellen in 1 Dateien)

F:\simutrans\124-2\pak64.german_4\scenario\tutorial\scenario.nut(107):       t_icon <- {road = 0x800e, rail = 0x800a, ship = 0x800f, plane = 0x8010, other = 0x8009, slope = 0x8002, tram = 0x800d, build = 0x8002, stats = 0x8003, exted = 0x8004}
F:\simutrans\124-2\pak64.german_4\scenario\tutorial\scenario.nut(707):   else if (tool_id == 0x8004) return false  //Tramsway Tools


I had forgotten that was there, those ids must be different in pak.german.

This used to be used to remove specific menus, but I don't think it's necessary anymore.

Edit:
It seems that these are necessary, since some of them prevent switching between players.

Code Select Expand

    if (tool_id == 0x2005) return false
    else if (tool_id == 0x4006) return false
    else if (tool_id == 0x4029) return false
    else if (tool_id == 0x401c) return false
https://github.com/simutrans/tutorial_pak64/commit/0cfb175a2e18d76e74412d8bd7c9f14f597a438d#diff-3568f64b9cd2f0a269e9320c00f268f721bf2dc5f7ba8c8514b3060c6b1f2df7

[Andarix]

Sorry, merging is not my strong point. Especially when there are simultaneous changes.

scenario.nut probably still has a conflict at t icon above.

[Yona-TYT]

Sorry, merging is not my strong point. Especially when there are simultaneous changes.
scenario.nut probably still has a conflict at t icon above.

If you share the script with me I can fix the icon conflicts.

[Andarix]

https://github.com/simutrans/tutorial_pak64/pull/26

ADD pak128

Not correct work.

There is a problem with tunnel construction. Since it is not possible to build on the slope, it is not possible to subsequently connect the rails to the tunnel due to tool limitations.

The same behavior should apply here as with bridges, which automatically connect to the track.

However, the automatic step works.



The second tunnel construction is not working yet either.

[Yona-TYT]

I did a test and I had no problems with the tunnel, I don't understand why it doesn't work for you.

Are you using the automated commands?.

[Andarix]

I did a test and I had no problems with the tunnel, I don't understand why it doesn't work for you.

...

It is difficult to see from this view that the route is interrupted.

Did you rotate the map and look or did you let a train drive?

[Yona-TYT]

It is difficult to see from this view that the route is interrupted.

Did you rotate the map and look or did you let a train drive?

I never rotated the map, I haven't tried with a train either, but I'm sure the track connected fine.

Edit
I didn't make any changes to the map either.

[Andarix]

I never rotated the map, I haven't tried with a train either, but I'm sure the track connected fine.

Sorry if I don't believe you.

Please post the information window from the tile in front of the tunnel. It should say 10, but it doesn't.

[Yona-TYT]

Sorry if I don't believe you.

Please post the information window from the tile in front of the tunnel. It should say 10, but it doesn't.

Edit:
Savegame: tutorial_pak128-test.zip

[Andarix]

Did you load the 64 tutorial map or the converted one from the PR?

If you only load the 64 map via combat.tab, then height_conversion_factor = 1 is set and there are no problems. You can build on the slope.

The map in the PR is however changed to height_conversion_factor = 2, which corresponds to the setting for pak128. You can not build on the slope.

[Yona-TYT]

Did you load the 64 tutorial map or the converted one from the PR?

If you only load the 64 map via combat.tab, then height_conversion_factor = 1 is set and there are no problems. You can build on the slope.

The map in the PR is however changed to height_conversion_factor = 2, which corresponds to the setting for pak128. You can not build on the slope.

Just load the pak64 map as is, so it does allow building on slope.

[Andarix]

https://github.com/simutrans/tutorial_pak64/pull/26

@Yona

Would you like to check the PR again or should I merge it?

[Yona-TYT]

https://github.com/simutrans/tutorial_pak64/pull/26
@Yona
Would you like to check the PR again or should I merge it?

I thought you had already merged it.

[Yona-TYT]

Have you thought about using:

Code Select Expand

settings::get_way_height_clearance
settings::has_double_slopes
For multipak compatibility?.

[Andarix]

Have you thought about using:

Code Select Expand

settings::get_way_height_clearance
settings::has_double_slopes
For multipak compatibility?.

This could be used for the different texts for bridges and tunnels as well as slopes.

Then these texts would have to be written neutrally and not mention the pakset.

[Yona-TYT]

https://github.com/simutrans/tutorial_pak64/commit/a1d77448073564ab5d49cd4b5b45d05a5f96bf90
https://github.com/simutrans/tutorial_pak64/commit/bef32e551f255aa0be5b738e2f7573a32e4c2fd2
https://github.com/simutrans/tutorial_pak64/commit/120e3aa4608492905b1d8582df4b9797a6166a53

• Added systemtype checking to ways tools.
• Rewrote logic for underground constructions in CHP3 H .
• Now a text label indicates that the Ctrl key must be pressed for tunnel entry.
• Some menu modifications for pak128 night

There are several changes that need to be tested in the German pak, and the menus in pak128 have changed significantly (pending work.)

[Yona-TYT]

I wanted to remove all the cacti from the map in pak128, as they are out of place climatically.

I tried this:

Code Select Expand

for(local x = 0; x < map_siz.x; x++){
for(local y = 0; y < map_siz.y; y++){
local t = square_x(x, y).get_ground_tile()
if(t.find_object(mo_groundobj)){
t.remove_object(player_x(1), mo_groundobj)
}
}
}

but it doesn't work, I suspect a bug.

[Andarix]

Take the pak files from the set and write a replacement in the combat.tab.

To delete, simply remove the pak files.

Load -> Save = done

I wanted to remove all the cacti from the map in pak128, as they are out of place climatically.

I tried this:

for(local x = 0; x < map_siz.x; x++){
        for(local y = 0; y < map_siz.y; y++){
            local t = square_x(x, y).get_ground_tile()
            if(t.find_object(mo_groundobj)){
                t.remove_object(player_x(1), mo_groundobj)           
            }
        }
    }

but it doesn't work, I suspect a bug.

Is object tree not groundobj.

And your code would remove all objects because you don't use a filter on the object name.

The automatic replacement had selected the wrong option when converting the map and I didn't pay attention to it.

Furthermore, you would also need a loop when removing, since there can be multiple tree objects on a tile. I assume that the function only removes one object.

[Yona-TYT]

Is object tree not groundobj.

And your code would remove all objects because you don't use a filter on the object name.

The automatic replacement had selected the wrong option when converting the map and I didn't pay attention to it.

Captus in pak128 are not trees (for some reason).

Edit
The error message says: Requested object not found.

[prissi]

I think for a map to be shared among paksets, removing all groundobj and movingobj might be sensible. Trees are replaced by whatever tree matches, and same for residential buildings and do not require a compat.tab unless some special things are wanted.

[Yona-TYT]

https://github.com/simutrans/tutorial_pak64/commit/9b8566afe8945807df748066a45399897dc59cad

I have added dynamic values for shortcut keys names in silced view mode.


But it seems that by modifying the German text I have accidentally damaged the text encoding (Maybe it's github).


I also need to update the texts in simutralator

[Andarix]

mo_groundobj is not implemented in remove_object

https://dwachs.github.io/simutrans-sqapi-doc/group__game__cmd.html#ga89fc4097e502862e9efb0a7c726da383

...
Remove object of given type from the tile. Type type must be one of the following: mo_label, mo_pedestrian, mo_city_car, mo_powerline, mo_transformer_s, mo_transformer_c, mo_signal, mo_roadsign, mo_wayobj, mo_tunnel, mo_bridge, mo_field, mo_building, mo_depot_rail. Setting type to mo_depot_rail deletes depots of every type.
...

[prissi]

r11521 tries harder to remove a given type.

[Yona-TYT]

r11521 tries harder to remove a given type.

my script: test-tools.zip

savegame: tutorial128.sve

There is a bug

Code Select Expand

Thread 1 "simutrans" received signal SIGSEGV, Segmentation fault.
0x00005555559e1441 in tool_remover_t::tool_remover_intern(player_t*, koord3d, signed char, char const*&) ()
(gdb) where
#0  0x00005555559e1441 in tool_remover_t::tool_remover_intern(player_t*, koord3d, signed char, char const*&) ()
#1  0x00005555559e2643 in tool_remover_t::work(player_t*, koord3d) ()
#2  0x0000555555a48659 in karte_t::call_work_api(tool_t*, player_t*, koord3d, bool&) ()
#3  0x0000555555891c52 in script_api::param<script_api::call_tool_work>::push(SQVM*, script_api::call_tool_work) ()
#4  0x000055555594f8b5 in long long script_api::generic_squirrel_callback<script_api::call_tool_work (*)(grund_t*, player_t*, obj_t::typ)>(SQVM*) ()
#5  0x0000555555a99034 in SQVM::CallNative(SQNativeClosure*, long long, long long, SQObjectPtr&, int, bool&, bool&) ()
#6  0x0000555555a9afab in SQVM::Execute(SQObjectPtr&, long long, long long, SQObjectPtr&, unsigned long long, SQVM::ExecutionType, unsigned long long) ()
#7  0x0000555555a9dbfa in SQVM::Call(SQObjectPtr&, long long, long long, SQObjectPtr&, unsigned long long, unsigned long long) ()
#8  0x0000555555a69ea2 in sq_call ()
#9  0x0000555555a5aa11 in sq_call_restricted(SQVM*, long long, unsigned long long, unsigned long long, long long) ()
#10 0x000055555597110f in script_vm_t::intern_call_function(SQVM*, script_vm_t::call_type_t, int, bool) ()
#11 0x0000555555971b06 in script_vm_t::intern_finish_call(SQVM*, script_vm_t::call_type_t, int, bool) ()
#12 0x00005555556ad4ea in scenario_t::init(char const*, char const*, karte_t*) ()
#13 0x00005555559d284e in tool_load_scenario_t::init(player_t*) ()
#14 0x000055555583e12a in nwc_tool_t::do_command(karte_t*) ()
#15 0x0000555555a50b72 in karte_t::interactive(unsigned int) ()
#16 0x00005555559ae118 in simu_main(int, char**) ()
#17 0x00005555559b80f9 in sysmain(int, char**) ()
#18 0x00007ffff7529248 in __libc_start_call_main (main=main@entry=0x555555641ad0 <main>, argc=argc@entry=1, argv=argv@entry=0x7fffffffdc08)
    at ../sysdeps/nptl/libc_start_call_main.h:58
#19 0x00007ffff752930b in __libc_start_main_impl (main=0x555555641ad0 <main>, argc=1, argv=0x7fffffffdc08, init=<optimized out>, fini=<optimized out>,
    rtld_fini=<optimized out>, stack_end=0x7fffffffdbf8) at ../csu/libc-start.c:360
#20 0x0000555555641b9e in _start ()
(gdb)

[prissi]

There was a typo, r11523 works again.

[Yona-TYT]

There was a typo, r11523 works again.

Works great! I didn't leave a single cactus on the map.

Thank you very much prissi.


No more cactus !

[Andarix]

A new release of Simutrans is planned for next week.

Please check the tutorials for pak64 and pak128 for functionality and correctness of the texts.

Texts are currently available for English, Spanish and German.
The texts can be changed here.
If you can't find a text, ask here before changing an incorrect text.

the linked text chapter_03#01_2-2.txt is Chapter 3 Step A Substep 2/2

And something else important: The texts presented here are based on pak64. If you make any changes to the content for pak128, please DO NOT CHANGE them, but post them here.

The current version r11559 of Simutrans is required.
Nightly Andarix
Nightly Simutrans Organisation

[EDIT]

new version below

[Yona-TYT]

Wouldn't it be a good idea to send the texts to simutanslator?.

[Andarix]

Wouldn't it be a good idea to send the texts to simutanslator?.

You are welcome to do that.

I don't have an account there and the service is very inefficient. Which is why I won't have an account there either.


or you translate in the Wiki

[Yona-TYT]

I will use this link for the text update script https://simutrans-germany.com/translator_page/scenarios/scenario_5/data/language_pack-Scenario+Tutorial+multipak.zip

Edit.
I have already sent all the updates to pak128, and I have also updated the link of the script to download texts.
https://github.com/simutrans/pak128/commit/238d73031edffefe4a947654e82d57471cf7fb5b

[Andarix]

With Git you can also add other Git repos as subrepos.

There seems to be some confusion in the translations. It is necessary to delete them first. If you just copy them in, old files will remain.

[Yona-TYT]

With Git you can also add other Git repos as subrepos.

There seems to be some confusion in the translations. It is necessary to delete them first. If you just copy them in, old files will remain.

Ok, I'm going to delete them and download the new ones, I don't know much about git so I don't know how to create a sub repo

[Andarix]

Ok, I'm going to delete them and download the new ones, I don't know much about git so I don't know how to create a sub repo

https://git-scm.com/book/en/v2/Git-Tools-Submodules

[Andarix]

A new release of Simutrans is planned for next week.

Please check the tutorials for pak64 and pak128 for functionality and correctness of the texts.

Texts are currently available for English, Spanish and German.
The texts can be changed here.
If you can't find a text, ask here before changing an incorrect text.

[EDIT]

new download here

the linked text chapter_03#01_2-2.txt is Chapter 3 Step A Substep 2/2

And something else important: The texts presented here are based on pak64. If you make any changes to the content for pak128, please DO NOT CHANGE them, but post them here.

The current version r11559 of Simutrans is required.
Nightly Andarix
Nightly Simutrans Organisation

[EDIT]

new testversion

[Andarix]

adding info text for paksets

example info_pak128.txt

Display below the tutorial short info

[Yona-TYT]

https://git-scm.com/book/en/v2/Git-Tools-Submodules

Clone the repo and delete all unnecessary files, this worked fine, it's the same as what they do in pak129.comic

https://github.com/simutrans/pak128/commit/ca8a57c50c232ce237a0b691aec1776b6e40d82e


Edit.

This is no longer a pak64-only tutorial, so I'd like to rename the repo to https://github.com/simutrans/tutorial_multipak 

I'd also like to stop it from being a forked, what happens if I delete the main repo? Will this one be deleted too?.

[Yona-TYT]

adding info text for paksets

example info_pak128.txt

Display below the tutorial short info

I think it's a good idea, each pack has its own unique economy and behavior.

[Andarix]

https://docs.github.com/en/repositories/creating-and-managing-repositories/renaming-a-repository

[Yona-TYT]

https://docs.github.com/en/repositories/creating-and-managing-repositories/renaming-a-repository

Perfect, now it's https://github.com/simutrans/tutorial_multipak.git

[Andarix]

add release script

https://github.com/simutrans/tutorial_multipak/releases

I just don't know how to add a tag in the browser.

[Yona-TYT]

I just don't know how to add a tag in the browser.

Still, it's great!.

[Yona-TYT]

There are several uncommented debug messages, are you still testing?.


This isn't actually doing anything, however I'm not sure whether to remove that line now.

Code Select Expand

chapter            <- tutorial.chapter_02       // must be placed here !!!

https://github.com/simutrans/tutorial_multipak/commit/b6a6a9f8e06cff681c0d56472147c357fb90a95c

[Andarix]

There are several uncommented debug messages, are you still testing?.

...

disable forgot

[Andarix]

more bugfixes

new beta release

[Yona-TYT]

When reloading a savegame, the variables are not being sent correctly to the text files.

[Andarix]

shold fixed

https://github.com/simutrans/tutorial_multipak/pull/37/commits/5b848d93f406f2c7a64511baf8355222a7aa68af

[Isaac Eiland-Hall]

disable forgot

I wish I could disable forgetting

[Yona-TYT]

The savegames from the other paksets are not removed, I tried to fix it but I realized this is not linux.

I reverted the changes here: https://github.com/simutrans/tutorial_multipak/commit/65ba87acf7556a7cf053f7647ba97b2a13813860

I also left "workflow_dispatch" enabled, but if you notice that it is detrimental you can remove it. 

[Andarix]

Why shouldn't the other sve be included?

Since the rest of the code, including set_data.nut, contains references to all 3 sets, the sve files should also be included.

And 600 kByte more makes no difference.

But if that bothers you, you can do that.


change for single file

copy *.sve tutorial

->

copy [filename].sve tutorial

[Yona-TYT]

But if that bothers you, you can do that.

No, there is no problem, in any case the pak128 repo is in charge of cleaning everything and pak64 is @prissi who does it (manually I think).

[prissi]

How to include the latest version into the pak64 svn? Download the entire folder? And the text import script, is that stil valid? I though this was now moved over to Frank?

And you are calling functions before initialisation like ttext() line 18 (see documentation, this is impossible for squirrel, "common pitfalls")

When accidentily close all windows, I close also the toturial and it does not come back. Also the tutorial is always at the bottom and the scrollbar is strange.

In the release version, I could not build a road. Any click on 185 and 186 never built anything. Only when dragging I could build a road. Quite confusing.

Later error message appear for a short time (There is a halt here and only 7 halts are needed) which vanish quickly and proceed to the next stop.

Also later, I had to click many times quickly to build the bridge. A single click was always ignored.

In the line window, if one makes any mistake, on cannot amend this in the depot window. I think the line window needs some words too,

Then I accidentally closed all windows and could not continue.

[Yona-TYT]

When accidentily close all windows, I close also the toturial and it does not come back.

I don't understand this, it seems to have more to do with the GUI than with squirrel.

In the release version, I could not build a road. Any click on 185 and 186 never built anything. Only when dragging I could build a road. Quite confusing.

This is strange, on my PC I am not able to replicate this, maybe on touch devices it is different?.

Later error message appear for a short time (There is a halt here and only 7 halts are needed) which vanish quickly and proceed to the next stop.

"only 7 halts are needed", This should only appear once there are already 7 stops built, if it appears before then it is a bug.
"There is a halt here", This only appears if there is already a stop at the marked point and you click on it again.

Also later, I had to click many times quickly to build the bridge. A single click was always ignored.

As with the road, on my PC this works fine, I don't know what factors could be causing failures from one device to another.

[Andarix]

....
When accidentily close all windows, I close also the toturial and it does not come back. Also the tutorial is always at the bottom and the scrollbar is strange.
....

This is probably due to the new nested menus.

pak64 reopern tutorial



And there was a bug report about the scroll bars a long time ago. Squirrel has no access to this at all.

[Andarix]

...
Later error message appear for a short time (There is a halt here and only 7 halts are needed) which vanish quickly and proceed to the next stop.
...

This happens when you have built the 7 stops and then accidentally click somewhere because the tool is still active.


I create a release v2.0.00

The files contain the translations and texts from now on.

[prissi]

I think we need a floating icon if a scenario is active. Or at least something like the networkicon to click on the continue the tutorial.

Bet would be check if close and reopen the window after 5 s from the script. Not sure if possible.

I will look into the scroll issues and maybe there is a way to jump to the top when replacing text from squirrel.

[Andarix]

....
I will look into the scroll issues and maybe there is a way to jump to the top when replacing text from squirrel.

When you resize the window, the bars jump to the edge.

...
Bet would be check if close and reopen the window after 5 s from the script. Not sure if possible.
...

As far as I know, there is currently no access from Squirrel.

That is also the problem that the toolbars cannot be closed when all icons are hidden.

[prissi]

Backspace works ...

There was also an error that Simutrans crashed when editing a schedule as the calcuation of the has might never encounter a null byte before out of bounds access for that emory page. I still need to find the scrollbar error.

EDIT: found the error that the tutorial never realised that the texts were updated. But now I cannot preceed beyond clicking on the attractions. There is never something flashing any more.

[Yona-TYT]

But now I cannot preceed beyond clicking on the attractions. There is never something flashing any more.

Now I have a horrible headache, so I'll try to fix it later, I'll try to use the time_x class to calculate the delay.

[Andarix]

...
EDIT: found the error that the tutorial never realised that the texts were updated. But now I cannot preceed beyond clicking on the attractions. There is never something flashing any more.

It looks like the delay_mark_tile() function no longer works.

This means that the label_bord() function is not terminated or the script is no longer called after execution.

[Yona-TYT]

It looks like the delay_mark_tile() function no longer works.

This means that the label_bord() function is not terminated or the script is no longer called after execution.

This is what causes the failure:

This doesn't work currently, this patch fixes it: 0001-ADD-support-for-iterate-tile_x.patch

[prissi]

Reverted your patch and made also the scrollbar reset when text is changed. However, this has the side effect, that when building a stop, then scrollbar also reverts to zero. I have no easy idea how to fix that unless only looking at the first 128 bytes or so, which only change between chapter.

[Yona-TYT]

Now I have a horrible headache, so I'll try to fix it later, I'll try to use the time_x class to calculate the delay.

I have rewritten the flashing logic and now the delay is obtained from time_x

https://github.com/simutrans/tutorial_multipak/commit/b2acf53e6690a0bcc6726fbd26773466ca89cc38#diff-3568f64b9cd2f0a269e9320c00f268f721bf2dc5f7ba8c8514b3060c6b1f2df7

[Yona-TYT]

There was also an error that Simutrans crashed when editing a schedule as the calcuation of the has might never encounter a null byte before out of bounds access for that emory page. I still need to find the scrollbar error.

EDIT: found the error that the tutorial never realised that the texts were updated.

Something has changed and now the API does not show information windows for errors of non-existent variables or poorly defined functions.

[prissi]

It may take up to 10s to show a message. I have shorted that time to 1s for local games.

But I note assertion failure because of wrog random mode when clicking next.

If that does not help, I need a testscript.

[Yona-TYT]

Something has changed and now the API does not show information windows for errors of non-existent variables or poorly defined functions.

Oh sorry @prissi, I got confused here, there is actually no such glitch.

But I note assertion failure because of wrog random mode when clicking next.

Are these debug messages?, Because I clicked next many times and no script error window appears.

[prissi]

No, the script runs during a sync step, called from scenario_info.cc. It may have been connected to resume a vm after suspension.

OK, script_text() changes the map but runs (of course) in a sync_step()

script_text() MUST NOT CHANGE THE MAP.

Sorry, but you need to set a flag in script_text, and then do the action in some other routine. Same for any other routine you call from the  script tags in flowtext.

[prissi]

If this is really impossible to change, maybe I can hack together a tool that calls the script during the next step.

Btw, same rule for updating the goal text (and any other text).

EDIT: I have pushed a commit which moves the jump to next chapter call to "is_scenario_completed()" which is called in a step and can alter the map.

[prissi]

Sorry for the triple posting:

I tried to find the reasoning of the vehicles and road/track choices in the nut files, But I had no such luck.

The choices even contradict the text, saying better use cheap and slower rails first. But, for goods, the engine chosen is way too strong for five cars (and thus too expensive). Next, the 200 km/h tracks are used, despite only a max speed of 100 km/h.

Same for the bus, for the beginning the cheaper H-Trans bus would be better. And again, a street matching the max. speed of the bus. Also too many post trucks, leading to blocking the single bus.

That scenario leads to being bankrupt before even transporting 160 passengers in the final step without some additional measures like stopping the wood transport and so on.

Maybe we can do some fine adjustments, like not using a way faster than the engine/bus and using a sensible choice for the engine. The sqai_rail has plenty of code for that.

[Andarix]

The definition of the objects is in class_base_data.nut.

I haven't checked the code completely yet. Aliases have been defined that have not yet been adjusted.


When it comes to roads and rails, it doesn't matter which one you choose. The same goes for bridges.

The roads and tracks specified are used for automatic progress. The selection should also apply from the beginning of the tutorial. And that was probably 10 years ago now.

The choice of vehicles and the number of them are also a bit questionable for me.

That was the main reason for taking the object data out of the code and collecting it in a separate file that is easily accessible.

In any case, I would avoid making fixed specifications. Suggestions and recommendations can be made in the text.

[prissi]

I just suggest to search for an available sensible vehicle at that moment and then select a usable waytype for it. But I edited the file for pak64 accdingly.

Also in chapter 7, terraforming should be allowed. There is one corner, which makes a roundtrip bus alsomost impossible in the last city.

And after finishing, all tools should be allowed again ...

[Andarix]

I just suggest to search for an available sensible vehicle at that moment and then select a usable waytype for it. But I edited the file for pak64 accdingly.
...

The tutorial is intended to convey the basic procedure. That is, what works and how you can build.

Specific game strategies are more or less left out. Therefore, no reference is made to costs, profit and marge.

If it's about teaching strategies, then that requires another tutorial.

Even the current one is not efficient in all steps. The use of the many public stations is not very useful in my opinion either. But it is currently the way it is.

The crucial thing is the attached texts. And I can't see anything there at the moment. Unfortunately, it is not possible to link to the program's help texts, it seems. This means that a lot of what is actually in the help has to be written again. It might work to include the help files, but then the window would be hopelessly overloaded. Chapter 3 is already very long.

But I don't want to criticize too much here, because it certainly took a lot of work to write the current one. My goal was to make it relatively easy to integrate the tutorial into other packs. However, that goal has not yet been fully achieved. There is still a lot to do, especially with the texts.

It may also be possible to use different maps so that the tutorial is not the same everywhere. But that is more of a long-term solution, because it will require quite a lot of parameters.

[Yona-TYT]

It may take up to 10s to show a message. I have shorted that time to 1s for local games.

I hadn't tried it, but certainly now the window updates very quickly, great!.

[prissi]

I have renamed chapter07/goal_step_05.txt to finished text to be shown after playing through the to\utorial, which otherwise never finishes.

I also tried to enable the landscaping tools for chapter 7, but I failed. Maybe someone better into the script could change that. Also, I could not rename the chapter07/goal_step_05.txt to finished.txt on the translation site

And when is chapter07/goal_step_01.txt actually used.

[Yona-TYT]

I also tried to enable the landscaping tools for chapter 7, but I failed.

Ok, I'll fix that.

Edit:
https://github.com/simutrans/tutorial_multipak/commit/d91f9b3dce965312a47b570b1bdc477b9841739b


Edit2:
Now all the tools should be available in the final step.
https://github.com/simutrans/tutorial_multipak/commit/e43f29edf662a68cb536bf877b5991b6d42f0355

[Andarix]

...
And when is chapter07/goal_step_01.txt actually used.

This is the old translation page. Just like ...02.txt, ...03.txt and ...04.txt, this is no longer used.

They have not been removed yet.

The currently used text for all 4 steps is in goal_step_01x04.txt.

...
I also tried to enable the landscaping tools for chapter 7, but I failed. Maybe someone better into the script could change that. Also, I could not rename the chapter07/goal_step_05.txt to finished.txt on the translation site
...

Which is currently completely uninteresting and unnecessary.

I had planned to remove this text from the chapters and put it in the global directory anyway.

And text editing in the GitRepo is no longer planned. The texts are not up to date and will not be used when building the release.

I would suggest that you make suggestions here in the forum or provide a patch.

[Andarix]

@prissi

https://github.com/simutrans/tutorial_multipak/commit/d455037e9c6ccee3b3763d72b8c7436d9fb7bc80#diff-b8e5346ffb9b79e47b0b3bbb6993f345c61d0d03de5bf628589bb7310834a3c0R230

...
case 5:
//return 90
        return 100
break;
}
local percentage = chapter_percentage(chapter_steps, chapter_step, chapter_sub_steps, chapter_sub_step)...

What do you want to do here?

This prevents the actual calculation of the progress.

Code Select Expand

local percentage = chapter_percentage(chapter_steps, chapter_step, chapter_sub_steps, chapter_sub_step)
If you don't know what the code does, it's better to ask before you change anything.

I don't know what the code does in many places either. I don't touch those places. That's why some of the things I would do differently haven't been implemented yet. For example, in pak64.german there are bus stations that accept passengers and mail. Then an additional post office building is not necessary. But something like that entails more extensive changes.

With your changes you make it unnecessarily difficult to expand the chapter because then this code also has to be changed.

Adding finished.txt in get_result_text() (scenario.nut) might be the wrong place because that is a different tab.
Here it would probably be more appropriate to add a final chapter (currently Ch8). I had already thought about that.

Also a change that is planned in Chapter 7. That it is not a specific field that requires the bus to stop at the station. The file may not be found because the path is incorrect.

[Andarix]

Chapter 7 seems to have a problem with the passengers it transports.




[EDIT]

bug found

Not fixed yet, as Yona's opinion on the changes to Chapter 7 is still missing.

[prissi]

I tested it with the current code and it worked and still works. But I should use chapter_max instead of 7, that is correct.

The change of tab happens from Simutrans whenever a scenario finishes. Not my doing, but it clearly shows that the scenario has finished. Because until now, the tutorial never ever finishes which was strange, as all tasks have been finished at the end.

Return 100 finishes the scenario. Otherwise, it never finishes and is stuck at the last step. 90 was returned, because 100 advances a chapter and thus additional logic was required in scenario.nut. I changed that logic too.

The other way could be to add a dummy chapter 8 for finishing which would be even more code.

Personally, I think in the long run the code needs some cleaning up. Maybe even let the tutorial choose buses, trucks, engines and ways.

[Andarix]

...
Return 100 finishes the scenario. Otherwise, it never finishes and is stuck at the last step. 90 was returned, because 100 advances a chapter and thus additional logic was required in scenario.nut. I changed that logic too.

The other way could be to add a dummy chapter 8 for finishing which would be even more code.
...

90 not returned, is commendet

As I wrote, it is better in the long term to separate the conclusion from the last chapter.
The calculation is based on the steps and sub-steps. So if fulfillment is to be returned, the steps must be adjusted. And then the finish text must be displayed instead of Chapter 8. This requires changes to the chapter call function. No new chapter is called there, only the text is displayed.

I just haven't had time to look at it in more detail yet. I haven't had a chance to look at other things that I would like to change either. The focus was initially on making sure that the code works flawlessly with multiple packages. And there is still a lot to do in this regard.

Sorry, I don't think much of such quick implementations of ideas. Especially shortly before a release of Simutrans. There has been no feedback for the last few months and just before the release there is suddenly a rush of action.

The last releases of Simutrans have shown what this leads to.

[prissi]

I have tested the scenario, and it crashed when advancing a step. Reproducible. And it never finished. Both are errors.

The code had a variable "chapter_max" yet did not use it correctly. Thus, I fixed this.

Inside the text says, use not the fastest way yet the fastest way is used. Also, it went bankrupt before reaching 160 passengers a month, so it was almost impossible to finish unless one was very quick. Thus, I corrected the choice of vehicles and ways for pak64. What is the point of testing, if not fixing errors?

Back to more testing, now pak128: Jumping the electricity connection, the pak128 electricity line is not built by the advance step function. The other things seem to work.

[Andarix]

...
The choices even contradict the text, saying better use cheap and slower rails first. But, for goods, the engine chosen is way too strong for five cars (and thus too expensive). Next, the 200 km/h tracks are used, despite only a max speed of 100 km/h.
...

In the German texts there are no guidelines for the selection of roads and railways. The selection is not checked and is therefore free. And that is a good thing, because a road is a road and a railway is a railway.

[Yona-TYT]

Chapter 7 seems to have a problem with the passengers it transports.




[EDIT]

bug found

Not fixed yet, as Yona's opinion on the changes to Chapter 7 is still missing.

Something strange is going on here, in my last tests this did not happen.

[Yona-TYT]

For example, in pak64.german there are bus stations that accept passengers and mail. Then an additional post office building is not necessary. But something like that entails more extensive changes.

The idea here was to explain the use of extension buildings, but as you say, there are too many, in fact there is a code in the tutorial for pak192.comic that combines extension buildings and some multi-purpose stops (passenger and mail), I think it would be good to improve this after the release. 

Here it would probably be more appropriate to add a final chapter (currently Ch8). I had already thought about that.

Yes, I also agree with another chapter to finish, but since there is a release very close, it is best not to complicate things so much for now. 

[Yona-TYT]

Inside the text says, use not the fastest way yet the fastest way is used. Also, it went bankrupt before reaching 160 passengers a month, so it was almost impossible to finish unless one was very quick. Thus, I corrected the choice of vehicles and ways for pak64. What is the point of testing, if not fixing errors?

Personally I don't give much priority to economy, but if it can be made more efficient then it is welcome.

Edit:
Additionally, we can choose a better number of wagons, coal trucks and buses that can help balance expenses better,

I also like the idea that each pakset has its own values for loading and waiting times, perhaps in the future also a number of vehicles and wagons.


Regarding the texts that show speed modes that don't exist, perhaps the speed values can be obtained dynamically, so they will always be consistent with the pack.

Back to more testing, now pak128: Jumping the electricity connection, the pak128 electricity line is not built by the advance step function. The other things seem to work.

Yes, I already had this bug in mind, it only occurs in pak128, but it is strange, since if you click on one transform and then on the other (imitating what the automated command does), then it works fine, so this makes me suspect a problem in the API.

[prissi]

I always click next to a transformer, never on top of it. Shouldn't the way tool do the same? And it works in pak64.

Ok, there was an error. Since we have a list of transformers, we do not need a list of coordinates any more.

[Yona-TYT]

There was a strange bug where if you paused the game you couldn't build the stops because the text label wasn't removed.

Another strange bug is that station names were interfered with by label texts, this is also resolved.

With unowned text labels this is solved, plus there are now more cost savings and the player can't edit the text of said labels.

Therefore I have changed almost all of them to unowned.

https://github.com/simutrans/tutorial_multipak/commit/ccbca621d2388480fd778f726938f6f3e6f7d612