Some little questions'

[Ra'Jiska]

Great, thank you for this information.

 

[Ra'Jiska]

Hello' There,

A new question. This time, it'd be on the Python code of the Module System.
In 'module_scene_props.py', at the line n° 8, we got 'import header_lazy_evaluation as lazy'.

What I'd like to do is finding a way to not be dependant of a 'non official' file (non official = file not given in default version of Module System).
So, I simply removed the line and putted the content of the external file in the scene_props file.

However, it's giving me errors since lazy.* is called multiple times like here:

init_trigger[1].append((scene_prop_set_slot, ":instance_id", slot_scene_prop_resources_default_cost, lazy.add(
        lazy.price(resource_list[0]), lazy.price(resource_list[1]), lazy.price(resource_list[2]), lazy.price(resource_list[3]))))

What's I'd concretely need to do is call the lazy.* internally instead of going through an exterior file.
Also, are there any other exterior 'non official' files imported in the module system ?

Thank you for your help.

P.S: I absolutely have no knowledge in Python.

 

[Vornne]

What I'd like to do is finding a way to not be dependant of a 'non official' file (non official = file not given in default version of Module System).

The PW module system is almost totally rewritten from the Native module system, with processing scripts that are compatible with most Native code but also include extra features for PW, including a simple form of "lazy evaluation", Python generation of triggers and scripts, and more. This means that Native code will be possible to integrate into PW, but parts of PW are not possible to integrate into a Native based module system without also implementing major changes to the processing code (which would be more difficult than just using PW as a base). In other words, you can't just copy certain PW files or scripts into a Native module system, since they require underlying systems specific to PW.

What is meant by "lazy evaluation" is calculations that can be done when the module system is being built (rather than by module code when the game is running), such as adding and subtracting ids (item, scene prop, etc.), or inserting lists of operations into the current code block (necessary for certain PW features that use automatic code generation). Examples of features that require the lazy evaluation functions are: banner chooser, profile options, administrator panel, item crafting stockpiles, resource processing scripts, the animation menu, and chest load outs.

Also, are there any other exterior 'non official' files imported in the module system ?

As for file names: module_generated_scripts.py, module_generated_strings.py, header_debug.py (optional, not required by released official PW code), header_lazy_evaluation.py; but certain "official" files have extra features that rely on other parts of the PW module system, such as module_scripts.py, module_items.py, module_scene_props.py, and probably more.

Basically, to use PW code you should base on the entire module system, or take out small parts and adapt them if necessary for the different systems in Native.

 

[Ra'Jiska]

Alright, thank you for the explannations.
Unfortunately, I'll have to change my way to do what I want since with what you said, it won't be possible, thanks.

 

[Ra'Jiska]

Hello' there, back again with a little question.
I'd like to know how to get a variable from a player slot in the presentation.py file.
The thing is when I get the slot I've assigned in my scripts.py, to my presentation file, it appears as empty, though, the player ID is the same, I checked it.
So maybe is it because the presentation is only dealt client side and doesn't have access to server resources (so the slot we assigned) ?
Then how would one be able to access it ? The value from the slot must imperatively have the associated player ID linked to it.

Thanks.

 

[Vornne]

Slots (or global variables) are not synchronised between server and clients, so to access any player slots from a client presentation you must transfer the correct slot value to that client. PW has some existing network events to manually synchronise slots, though: search for usage examples of "server_event_player_set_slot" in official scripts (there are also server_event_scene_prop_set_slot, server_event_faction_set_slot, server_event_troop_set_slot, server_event_agent_set_slot). Note that setting certain slots with those network events can also trigger things to happen on the client, as listed in the event handlers in script game_receive_network_message.

This behaviour is useful for only sending the data to each client that they should know about, to avoid some kinds of cheats and hacks: for example, only the client of the faction lord has the information sent about who has keys or other permissions, and only admin clients get sent things like the server password.

 

[Xaphan]

nice read, it solves and error I have been scratching my head at. 

 

[Ra'Jiska]

Hello' there,

I'd have a little question, not sure it's possible though.
What I'd need to do would be to preven the client of interacting with the server untill server has finished setting uo the client.

Example, if the client uses a modified version and on join excute scripts, it'll be triggered at the same time as the server (even though it's the client). How would I be able to prevent such things or at least put it on hold untill server verifications are done ? Would a function rename do the trick ? Is it clean enough ?

Thanks.

 

[domipoppe]

I also thought about something like this, I could imagine making the "Join Game" button somehow unavailable to click until every synchronizing was done.
There is worked on "escape_menu" with the join game string but I'm not sure if the first presentation is this one actually.

It would be just a trigger-like method, set a slot or something on the player like "slot_player_readytojoin" and set it if all is done to one - make the button available to use.

 

[Vornne]

The client joining code in PW updates the command_set_server_mission_timer last after all other code called in script setup_player_joined, which on the client side triggers the script after_client_is_setup, which enables displaying the large information messages and repositions castle banners (working around an engine feature / bug). You could add your own code or script call there if the client just needs to wait for the synchronous code called from ti_server_player_joined, but if you wanted to wait until after asynchronous setup was completed, such as waiting for data from an external web server, you would need to send your own "ready" network message to the clients.

 

[Ra'Jiska]

I also thought about something like this, I could imagine making the "Join Game" button somehow unavailable to click until every synchronizing was done.
There is worked on "escape_menu" with the join game string but I'm not sure if the first presentation is this one actually.

It would be just a trigger-like method, set a slot or something on the player like "slot_player_readytojoin" and set it if all is done to one - make the button available to use.

I wasn't refering to the join button, but the join event (which is triggered when the player joins the server itself).
Also, it isn't the button that must be greyed out but what it triggers, what I'd like to prevent is any interaction from client to server before some checks are done.

The client joining code in PW updates the command_set_server_mission_timer last after all other code called in script setup_player_joined, which on the client side triggers the script after_client_is_setup, which enables displaying the large information messages and repositions castle banners (working around an engine feature / bug). You could add your own code or script call there if the client just needs to wait for the synchronous code called from ti_server_player_joined, but if you wanted to wait until after asynchronous setup was completed, such as waiting for data from an external web server, you would need to send your own "ready" network message to the clients.

Alrighty, but then, won't I have to do the check for every single actions to see if the client is ready ?

Thanks for your answers !