News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

[Script] Help to create a function

Started by Yona-TYT, January 11, 2017, 05:01:40 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Yona-TYT

I'm trying to create a function that allows to move the screen position with entering a coordinate, I will use "welt-> get_viewport () -> change_world_position (koord3d (k, welt-> min_hgt (k)))"

But not how to get the coordinates entered from the script.

Any welcome suggestion. :D

An_dz

I don't know why you want it, Simutrans already has it.

Yona-TYT

Quote from: An_dz on January 11, 2017, 07:56:49 PM
I don't know why you want it, Simutrans already has it.

If I know, but I would like to use it in the tutorial to locate the player in the right place.

I also want to learn how to modify the simutrans code. 8)

An_dz

Ah, ok. I misunderstood you. You want to create a script function to move the screen position.

Yona-TYT

I managed to make it work. :D

api_world.cc

#include "../../display/viewport.h"

SQInteger world_change_coord(HSQUIRRELVM vm)
{
    koord k = param<koord>::get(vm, 2);
    welt->get_viewport()->change_world_position(koord3d(k,welt->min_hgt(k)));
    return push_instance(vm, "coord", k.x, k.y);
}

STATIC register_function(vm, world_change_coord, "chag_coord", 2, "");


The synthesis is as follows:

local pos=coord(95,33)
world.chag_coord(square_x(pos.x, pos.y))




Dwachs

Did not saw this thread.

Your patch is correct. Instead of returning push_instance(..) it could return SQ_OK. You could also look into functions exported to the script by register_method. This would be much easier.

But I do not like the idea that the scripting could move the viewport. Why not adding some text to the scenario info window? There the user could click again on the link to make the viewport jump to the desired position. Maybe we could add a 'Help' tab?
Parsley, sage, rosemary, and maggikraut.

Yona-TYT

Quote from: Dwachs on January 15, 2017, 10:17:45 AM
Did not saw this thread.

Your patch is correct. Instead of returning push_instance(..) it could return SQ_OK. You could also look into functions exported to the script by register_method. This would be much easier.
Thanks, I had doubts with that return (it's my first patch by the way).  ;D


My intention with this is to prevent players from getting lost on the map.
Also for the "map divided in regions" I like the idea of moving the player to his respective region.

It can also be used to change the position when starting a savegame.  8)

Yona-TYT

This behavior I have seen in tutorials of other games, I really would like to have it in simutrans too. I do not see how this can give gameplay problems.

Dwachs

I see two problems:

1) Jumping of view point without user interaction can be irritating. I find it very irritating that the viewpoint changes if one builds a factory.

2) There is no way the user can tell the script `Do it again!`
Parsley, sage, rosemary, and maggikraut.

Yona-TYT

Quote from: Dwachs on January 18, 2017, 07:28:12 AM
1) Jumping of view point without user interaction can be irritating. I find it very irritating that the viewpoint changes if one builds a factory.

Some of the existing functions can also become irritating, but that depends on the use they are given.
Helping / annoying the player will always depend on the script creator. ;)

Quote from: Dwachs on January 18, 2017, 07:28:12 AM
2) There is no way the user can tell the script `Do it again!`
I do not know if I understood correctly, but it does not seem very useful for my aspirations, it is not my intention to replace the "Jump to" window.  ???

Leartin

Quote from: Dwachs on January 18, 2017, 07:28:12 AM
I see two problems:

1) Jumping of view point without user interaction can be irritating. I find it very irritating that the viewpoint changes if one builds a factory.

2) There is no way the user can tell the script `Do it again!`

I agree, but shouldn't one think about solutions to these problems?
About the first, it really depends on the usage. For example, if it's used to change positions on startup or load, it's not as much a view point jump as it's just defining a starting area. If it's used on player selection, there is a user interaction.
If the screen would go dark before changing the view point, the player would be more likely to understand that he just teleported, resulting in less confusion. This is especially true if a new window pops up at the same time, explaining what happened.

About the second, if it's a concern that the player can't tell the script to do something again, why not add a function for that? I suppose in a scenario, there should be some windows filled with explainations on what to do occasionally. As far as I am aware, coordinates can already be used and link the player to them by clicking on them, so in addition to the teleportation, open a window in which is explained why he was teleported, and what he has to do now - that window can easily include the coordinates of the position he is supposed to be. There only needs to be a way to always reopen these windows if they get closed.
If what you want to repeat for the player is more complex than going to a specific place, I guess there is a need for functional buttons in those windows that call other parts of the scripts, which the player can press in the same way.

Since I never made a scenario, I don't know how much of that is already possible. If it's possible, it's more a question about style than anything - if not, maybe look into it?

Yona-TYT




To avoid "teleportation" I can use a loop and increase the values gradually, this must create an autonomous movement (in theory).  8)

Tjoeker

Quote from: Leartin on January 18, 2017, 10:00:11 AM
...

If the screen would go dark before changing the view point, the player would be more likely to understand that he just teleported, resulting in less confusion. This is especially true if a new window pops up at the same time, explaining what happened.

...

A black fade-in/out seems very nice to me. :)
Maybe we could use this not only for teleportation, but also for a jump in time?
Could be useful in the story based scenario's I'm planning for the future. (if I ever find the time...)

Leartin

Quote from: Tjoeker on January 19, 2017, 08:36:27 PM
A black fade-in/out seems very nice to me. :)
Maybe we could use this not only for teleportation, but also for a jump in time?
Could be useful in the story based scenario's I'm planning for the future. (if I ever find the time...)
Why not 'simply' implement a screen tint command - the scripter just chooses an RGBA value for the tint color and intensity, as well as a fade time, and the whole screen will change color accordingly. Thus allowing the scipter to choose black for a fade out, and 100% transparency for a fade in - but at the same time, there can be an orange tint for an especially sunny day, or greyish blue for the coldest winter - if you go for a story scenario.

Now I actually wonder - would it be possible to call scenario scripts using normal menu buttons? For example, we have a time skip button in the menu - but could we instead have a button that calls a script which tints the screen black, skips time, and tints the screen back to normal again?

prissi

I think the easiest (and more interactive way) is to display a small dialoge where the user just had to click to the coordinates. I think that was implemented quite a while ago. The the user can explore around and click again (to go there again). The script could continue when the dialoge is closed. Voila, the user knows he/she is now teleporting and can even repeat it.

Yona-TYT

I wish I could do this. 8)


If the penguin can do it, why does not simutrans ?.  ;)

prissi

Ok, so you need just an API to call add_message I though that was added during the AI development. Aparently not, but that should be very easy to add.

Dwachs

add_message is implemented since ages.  I do not like the suggestion to override user decisions, how to display messages. I also do not like screen movement that happens without user interaction.
Parsley, sage, rosemary, and maggikraut.

Dwachs

(Double post) now with suggestions:

1) I can add a change viewpoint command (like Yona's patch).

2) Screen fading black is currently not implemented, that has to be done first.

3) One could think about the following (like in Leartin's post): Add scriptable buttons to dialogues: if the user clicks the button, then a function in the script is called.
Parsley, sage, rosemary, and maggikraut.

prissi

Why not just use add_message with world coordinates. It will teach how to use this to go to the corrdinates of the message at the same time ...

As a perspective, I think user scriptable buttons will make Simutrans to an new portable GUI ... no that this is a bad thing.

Yona-TYT

Quote from: Yona-TYT on January 21, 2017, 07:22:20 AM
I wish I could do this.  8)


If the penguin can do it, why does not simutrans ?.  ;)
During the exploratory view, this would be good:
1- Prevent the use of any tool.
2- Prevent the player from moving across the map.
3- Set the zoon at an optimal distance.
4- Shows a dialogue window with a brief explanation and a button that allows you to advance to the next position.

I like to explain things interactively  ;D .

Leartin

Quote from: Dwachs on January 21, 2017, 10:51:51 AMI do not like the suggestion to override user decisions, how to display messages.

Aren't scenario messages different from other messages, though? Not if the scenario is just a predefined map with a predefined goal and otherwise played like a sandbox anyway, but if there is a 'story' to it, and several different steps one has to take. A scenario could start with a restricted area to build only, where a mayor wants you to connect the factories all around with the city. Once you reach that goal, you get the message that the neighbouring mayor wants you to do the same thing for him as well, and now you can build on his land as well - and so on. If the player would miss such a message about what to do next due to his own message settings, it would be a lot more frustrating than the same message popping up even though messages were deactivated.
I think in scenarios, especially if in-message-buttons were added, there actually ought to be something different. Similar to what Yona-TYT suggests, a kind of message which is not dismissable, pauses the game, potentially locks any building functionality, and you have to press a button in the message to confirm it and unpause again. These could be used for any kind of decisions - "Besides trains, will you use planes or ships? <Ships> <Planes>" - you can click only one, and it enables either ships or planes, and you won't have the other for the scenario - just as an example.