pak64 tutorial - changes to multipak

[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