pak64 tutorial feedback

[Andarix]

I noticed that many stops are made public in the tutorial. Public stops are only useful in games with multiple players.

Above all, there is a warning at the beginning that making stops public is very expensive. And then almost every chapter requires you to make stops public, which I don't think makes much sense for explaining the game itself.

On the contrary, it creates the impression that you have to make stops public, which is not necessary when playing alone.


Sorry if I'm imagining something. With so many texts that are often very similar/identical, it's difficult to get your bearings after a while.

[Andarix]

I don't think it's good that the streets aren't available in the menu in Chapter 7. This limits the placement of stops and the depot. But there are no fixed guidelines here.

[Yona-TYT]

On the contrary, it creates the impression that you have to make stops public, which is not necessary when playing alone.

Certainly, in the case of Chapter 7 it is done in order to be able to connect the bus stops with the train station, I understand that the stops must be made public in order to be able to connect your network with another public stop, or am I missing something?.

I don't think it's good that the streets aren't available in the menu in Chapter 7. This limits the placement of stops and the depot. But there are no fixed guidelines here.

Very little has been said about Chapter 7, not many have the patience to get to this point. 

Edit.
What do you think about this?:


https://github.com/simutrans/tutorial_pak64/commit/bd8309cf8f85e6080986bfc367bc833eeaed88d8

[Andarix]

There is an almost identical text in class_basic_chapter.nut.

The difference is a versus for.

f:\simutrans\124-2\pak\scenario\tutorial\class\class_basic_chapter.nut (2)

(2659):      local tx = "The extension building for station [%s] must be for [%s], use the 'Remove' tool"
(2666):      local tx = "The extension building for station [%s] must be a [%s], use the 'Remove' tool"

[Yona-TYT]

There is an almost identical text in class_basic_chapter.nut.

The difference is a versus for.

That was intentional, since one was to refer to the load type (passenger or mail), and the other to refer to the specific name of the building.

This hybrid system is only used in Pak192.comic, but I wanted to leave the function available in all scripts to maintain consistency.

[Andarix]

chapter 4

I think 5 ships each for oil/petrol is too many.

2 each should be perfectly sufficient.


No idea if it's the script or Simutrans.

Simutrans 124.2.2

If you close the mission status window and then open it again, the scenario's start page (Summary tab) is always displayed.

The Mission Objectives tab should be displayed when you open it again.

[Yona-TYT]

chapter 4

I think 5 ships each for oil/petrol is too many.

2 each should be perfectly sufficient.

It´s ok!

https://github.com/simutrans/tutorial_pak64/commit/2d93800daea2312038a925ea7087ca1cb2eecbeb

If you close the mission status window and then open it again, the scenario's start page (Summary tab) is always displayed.

The Mission Objectives tab should be displayed when you open it again.

It would be nice to set a default tab so that it always shows up there when opened, but I don't think this is possible.

[Andarix]

The following function, which is in chapter files 0, 1 and 7, is a bit suspect to me. A value is assigned to a local variable, but this is not processed further.

Code Select Expand

  function is_schedule_allowed(pl, schedule) {
    local result=null // null is equivalent to 'allowed'
    return translate("Creating Schedules is currently not allowed")
  }

There is a function with the same name in scenario.nut. The chapter function is probably accessed there. However, since the chapter functions always return a string, the result is always not zero.

Code Select Expand

function is_schedule_allowed(pl, schedule)
{
  local pause = debug.is_paused()
  //if (pause) return translate("Advance is not allowed with the game paused.")

    local result = null

  if (pl != 0) return null
  result = chapter.is_schedule_allowed(pl, schedule)
    if (result != null)
         active_sch_check = true
    else
         active_sch_check = false

    return result
}

These functions make no sense to me.

Suche nach "is_schedule_allowed" in Verzeichnis "...\tutorial_pak64" (12 Fundstellen in 10 Dateien)

...\tutorial_pak64\scenario.nut(669): function is_schedule_allowed(pl, schedule)
...\tutorial_pak64\scenario.nut(677):  result = chapter.is_schedule_allowed(pl, schedule)
...\tutorial_pak64\class\class_basic_chapter.nut(320):      result = is_schedule_allowed(pl, schedule)
...\tutorial_pak64\class\class_chapter_00.nut(53):  function is_schedule_allowed(pl, schedule) {
...\tutorial_pak64\class\class_chapter_01.nut(227):  function is_schedule_allowed(pl, schedule) {
...\tutorial_pak64\class\class_chapter_02.nut(919):  function is_schedule_allowed(pl, schedule) {
...\tutorial_pak64\class\class_chapter_02.nut(1480):        if (is_schedule_allowed(pl, sch)==null)
...\tutorial_pak64\class\class_chapter_03.nut(1955):  function is_schedule_allowed(pl, schedule) {
...\tutorial_pak64\class\class_chapter_04.nut(612):  function is_schedule_allowed(pl, schedule) {
...\tutorial_pak64\class\class_chapter_05.nut(758):  function is_schedule_allowed(pl, schedule) {
...\tutorial_pak64\class\class_chapter_06.nut(595):  function is_schedule_allowed(pl, schedule) {
...\tutorial_pak64\class\class_chapter_07.nut(524):  function is_schedule_allowed(pl, schedule) {

[Yona-TYT]

The following function, which is in chapter files 0, 1 and 7, is a bit suspect to me. A value is assigned to a local variable, but this is not processed further.

In fact, in those chapters it is never called so they can be removed, but for all the others it is used.

Edit
https://github.com/simutrans/tutorial_pak64/commit/a3d8ee851116f6c80b95852bbfa40ae567a81f95

...\tutorial_pak64\class\class_chapter_02.nut(919):  function is_schedule_allowed(pl, schedule) {
...\tutorial_pak64\class\class_chapter_02.nut(1480):        if (is_schedule_allowed(pl, sch)==null)
...\tutorial_pak64\class\class_chapter_03.nut(1955):  function is_schedule_allowed(pl, schedule) {
...\tutorial_pak64\class\class_chapter_04.nut(612):  function is_schedule_allowed(pl, schedule) {
...\tutorial_pak64\class\class_chapter_05.nut(758):  function is_schedule_allowed(pl, schedule) {
...\tutorial_pak64\class\class_chapter_06.nut(595):  function is_schedule_allowed(pl, schedule) {

These should not be removed, they serve an important function and are accessed when assigning a schedule/line to a vehicle.

...\tutorial_pak64\class\class_chapter_02.nut(1480):        if (is_schedule_allowed(pl, sch)==null)

This is a special case, it was the solution I implemented to dynamically determine if the bus stops have been selected in the schedule, it works even if the vehicle is sold, Chapter 2 is the only one that uses this mechanism.

[Yona-TYT]

Code Select Expand

Code Select Expand

function is_schedule_allowed(pl, schedule)
{
  local pause = debug.is_paused()
  //if (pause) return translate("Advance is not allowed with the game paused.")

    local result = null

  if (pl != 0) return null
  result = chapter.is_schedule_allowed(pl, schedule)
    if (result != null)
         active_sch_check = true
    else
         active_sch_check = false

    return result
}
These functions make no sense to me.

It's a bit complicated to explain, what happens is that when the result in "is_schedule_allowed" then the schedule list is cleared (or at least it was in the past), so if while assigning the route you closed the schedule window (now it's a tab) then you had to start over selecting the stops.
"active_sch_check" is an important part of that mechanism, it basically assigns a lane to the vehicle with the selected stops in case the player closes the schedule tab.

Code Select Expand

    function set_convoy_schedule(pl, coord, wt, line_name)
    {
local depot = depot_x(coord.x, coord.y, coord.z)  // Deposito /Garaje
local cov_list = depot.get_convoy_list() // Lista de vehiculos en el deposito
local d_nr = cov_list.len()   //Numero de vehiculos en el deposito
        if (d_nr == 0) reset_tmpsw()
if (d_nr == 1 && active_sch_check){
            active_sch_check = false
            local cov_line = cov_list[0].get_line()
            local play =  player_x(pl)
            local sched = schedule_x(wt, [])
local siz = tmpcoor.len()
for(local j = 0; j < siz; j++) {
local c = tmpcoor[j]
        if (tmpsw[j] == 1){
//gui.add_message("("+tmpcoor[j].x+","+tmpcoor[j].y+")")
        sched.entries.append(schedule_entry_x(c, 0, 0))
}
else {
break
}
        }
    local entrie

    try {
     entrie = sched.entries[1]
    }
    catch(ev) {
    return null
    }
            if (!cov_line)
                play.create_line(wt)

            else if (cov_line.get_name() == line_name && cov_line.get_waytype() == wt){
                cov_line.change_schedule(play, sched)
      return null
            }
    // find the line - it is a line without schedule and convoys
    local list = play.get_line_list()
    local c_line = null
    foreach(line in list) {
                if (line.get_name() == line_name && line.get_waytype() == wt){
                    c_line = line
                    break
                }
                else {
            if (line.get_waytype() == wt  &&  line.get_schedule().entries.len()==0) {
            // right type, no schedule -> take this.
                        line.set_name(line_name)
            c_line = line
            break
            }
                }
    }
if(c_line){     
c_line.change_schedule(play, sched)         
cov_list[0].set_line(play, c_line)
}

  return null
        }
        return null
    }

[Andarix]

I think the player color should be changed.

Since the highlights are red, the markings in player color (currently also red) are difficult to distinguish.

[Yona-TYT]

I think the player color should be changed.

Since the highlights are red, the markings in player color (currently also red) are difficult to distinguish.

Hmm, that would be nice.

[Andarix]

I think there is something wrong with the code.

The query for the factory name returns the name that is shown on the map (already translated) and not the object name.

tile_x.find_object(mo_building) returns the factory_x object.

But factor_desc_x.get_name() returns the object name.

exampel
class_chapter_03.nut line 256 - 265

...
    local t = my_tile(fac_1.c)
    local buil = t.find_object(mo_building)
    if(buil) {
      fac_1.c_list = buil.get_tile_list()
      fac_1.name = translate(buil.get_name())
      local fields = buil.get_factory().get_fields_list()
      foreach(t in fields){
        fac_1.c_list.push(t)
      }
    }
....

I don't know if it makes sense to rename the factories when the tutorial is running when the language changes.

I also found a solution to translate the object texts when the tutorial starts and thus save a lot of translate() calls. However, I don't know how much performance this change will bring if the translate() calls are omitted.

Changing the language during the tutorial should also reload the translation.

[Yona-TYT]

Changing the language during the tutorial should also reload the translation.

For factory names this is not working:

Code Select Expand

translate(fac_1.name)
I have no idea what could be wrong or if it's a bug in simutrans

[Yona-TYT]

I think there is something wrong with the code.

The query for the factory name returns the name that is shown on the map (already translated) and not the object name.

tile_x.find_object(mo_building) returns the factory_x object.

But factor_desc_x.get_name() returns the object name.

Remove redundant translation calls
https://github.com/simutrans/tutorial_pak64/commit/af1ac7cef0ee68e37d1b4e37d64982c1ae32a037

[Andarix]

That's what I mean, fac_1.name already contains the translation. And the translation of the translation just doesn't work.

local buil = t.find_object(mo_building)
fac_1.name = buil.get_desc().get_name()


translate(fac_1.name)

The easiest way is to call rename_factory_names().

Please wait with changes as I am working on a patch and merging will become more difficult if you make further changes.

[Yona-TYT]

I also found a solution to translate the object texts when the tutorial starts and thus save a lot of translate() calls. However, I don't know how much performance this change will bring if the translate() calls are omitted.

Changing the language during the tutorial should also reload the translation.

Yes, it would be good to translate all the texts at startup, but also to call a function from the simutrans language manager that is executed every time the language is changed. It doesn't seem like a difficult thing to do, I think it's within my reach.

[Yona-TYT]

Please wait with changes as I am working on a patch and merging will become more difficult if you make further changes.

Oh no, sorry, I didn't read your message and I had already sent the changes :(

Edit.}
You can submit your changes, don't worry if that breaks the ones I made.

[Andarix]

https://github.com/simutrans/tutorial_pak64/pull/15/commits/72c234ad9c8485ada5440336fbe3bcfabca973ce

first part

[Yona-TYT]

I made a small patch to call a function if the language is changed by the player, if you think this would be useful then you can open a request for @Prissi to add it.

0001-ADD-is_language_changing-script-function.patch

[Andarix]

For factory names this is not working:

Code Select Expand

translate(fac_1.name)
I have no idea what could be wrong or if it's a bug in simutrans

This is probably because the name assignment takes place in start_chapter(). And this is not called again when the language is changed.

[Yona-TYT]

This is probably because the name assignment takes place in start_chapter(). And this is not called again when the language is changed.

https://github.com/simutrans/tutorial_pak64/commit/14a68be021fccb6473cc2fb2d3b6ba4af617bc55
I think this solves the problem, now the names are translated when changing the language.

[Andarix]

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

This way it seems to work.

not everything has been checked yet

[Andarix]

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

I have a problem assigning the factory data. If I assign the data in the class header (outside the functions) an exception occurs. Therefore the data assigned in the respective functions is current. I assume that I am not doing the assignment correctly.

actual unused function get_factory_data(id) (class_basic_data.nut line 9)

class tutorial.chapter_03 extends basic_chapter
{

  fac_1 = factory_data.rawget("1") <- not work :(

  function set_goal_text(text){

    local fac_1 = factory_data.rawget("1") <- work
    local fac_2 = factory_data.rawget("2")
    local fac_3 = factory_data.rawget("3")

  }

}

Another problem is that I can no longer build bus stops in Chapter 7 (pak64.german). I don't know what the reason is yet. I haven't tested the other chapters by hand yet, only with the automatic link.

[Yona-TYT]

oblem is that I can no longer build bus stops in Chapter 7 (pak64.german). I don't know what the reason is yet. I haven't tested the other chapters by hand yet, only with the automatic link.

How strange, I have been able to build the stops, although in order to advance in the chapter I made a hybrid between pak64 and pak64.german.

Do you get any pop-up messages if you try to build the stop?.

[Andarix]

...
Do you get any pop-up messages if you try to build the stop?.
..

yes, tool not allowed

It's possible that something went wrong during the merge.

[EDIT]

OK, that's been resolved.

I didn't make the first stop next to the station public. That means no more stops can be built.

I would do without this restriction. So the obligation to make it public before more stops can be built.

The message 'Action not allowed' is pretty meaningless at this point.

[Andarix]

@Yona

You removed the function is_schedule_allowed(pl, schedule) from class_chapter_07.nut.

This is not good, you can not create a line schedule.

Error: [the index 'is_schedule_allowed' does not exist]

[Yona-TYT]

@Yona

You removed the function is_schedule_allowed(pl, schedule) from class_chapter_07.nut.

This is not good, you can not create a line schedule.

Error: [the index 'is_schedule_allowed' does not exist]

I'll fix it later, regarding public stops, I did it that way so that the player wouldn't forget to make said stop public, and it also requires that there be a stop exactly at those coordinates.

I suppose that to avoid using the tool to make stops public so much, new teen stations will be made that belong to the player and not to the public service.

[Andarix]

I'm more concerned with the flow. I distribute the stops and then make one stop public.

So I have to build a stop, change the tool to make it public and then change the tool again to be able to continue building.

So it would make sense to swap points 2 and 3.

[EDIT]

An alternative would be to specify the bus stop on the map at the start, so that stations with bus stops are already there.

[Andarix]

For the messages in is_work_allowed_here(), .tostring() should be changed to coord_to_string()/coord3d_to_string().

[Yona-TYT]

For the messages in is_work_allowed_here(), .tostring() should be changed to coord_to_string()/coord3d_to_string().

https://github.com/simutrans/tutorial_pak64/commit/81eecc831d1a55efaf6300de5926890b33b1679d

Its fix.

[Yona-TYT]

An alternative would be to specify the bus stop on the map at the start, so that stations with bus stops are already there.

This means that the texts of chapter 7 must be changed, this is my proposal:

Code Select Expand

<p>
The city {city} needs to design a bus network that allows passengers to move to the train station: {name}.
</p>
<p>
Build as many bus stops in the city as you need, but you must make sure that the bus arrives at {bus stops} near of {station}, so that passengers count.
</p>
<p>
Progress is made to the next step, when more than <em>{load}</em> passengers are transported to {name} in a month.
</p>
<p>
<st>Translated this month:</st> <em>{get_load}/{load}</em>
</p>

@Yona

You removed the function is_schedule_allowed(pl, schedule) from class_chapter_07.nut.

This is not good, you can not create a line schedule.

Error: [the index 'is_schedule_allowed' does not exist]

Is fix here: https://github.com/simutrans/tutorial_pak64/commit/1980a703bb38cb3dcb25df99271905601dfa35e3

[Andarix]

thank you for fixes

[Andarix]

You have undefined placeholders {} in the text.

I suggest the following text:

Build as many bus stops in the city as you need to cover the city.
Make sure that there is a bus stop on square {stop} that is connected to station {name} so that passengers are counted.

After your changes, roads can no longer be built on free fields.

I would do without all tool restrictions, except for building in the city area.

[Andarix]

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

I added a check if stops are merged.

[EDIT]

class_basic_chapter.nut line 469 - 471 (pull request file)

Code Select Expand

    if ( persistent.chapter == 7 && this.step > 0 && this.step < 5 ) {
      text_step = ttextfile( path + "goal_step_01x04.txt" )
    }

This means that only one file is needed for Chapter 7 Steps 1 - 4.

I would prefer the same for the chapter rules. The same thing is in all rules.txt files. Only one file can be used there.