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 !