The District of Joban Difference between revisions of "JCM:Scripted PIDS Preset"

Difference between revisions of "JCM:Scripted PIDS Preset"

From The District of Joban
Line 1: Line 1:
{{DraftBox}}{{JCMFuture|version=2.0.0-beta.5}}
{{JCMFuture|version=2.0.0-beta.5}}


'''Scripted PIDS Preset''' is a new experimental feature introduced in '''JCM 2.0.0-beta.5''', it allows content developer to make new PIDS Preset using Javascript. The system is heavily inspired by the '''Nemo Transit Expansion''' mod in MTR 3.
'''Scripted PIDS Preset''' is a new experimental feature introduced in '''JCM 2.0.0-beta.5''', it allows content developer to make new PIDS Preset using Javascript. The system is inspired by the '''Nemo Transit Expansion''' mod in MTR 3.


==== Motivation ====
==== Motivation ====
The most common questions for the JSON-based PIDS Preset is always "Can I replicate X PIDS from this Metro?", and the answer usually boils down to a '''no'''.
The most common questions I have received regarding PIDS Preset is "Can I replicate X PIDS from this Metro?". Unfortunately the answer I have to give them is usually a '''no'''.


This is due to the JSON PIDS Preset always following a fixed-layout consisted of a Header Bar (Weather & Time), and 4 rows of arrivals. However Metros around the world have different approaches to how they want to display their information, and given the combination it's not really feasible to just "add a toggle" for each layout seen around the world.
This is due to the JSON PIDS Preset always following a fixed-layout consisted of a Header Bar (Weather & Time), and 4 rows of arrivals. However Metros around the world have different approaches to how they want to display their information, and given the combination it's not really feasible to just "add a toggle" for each layout seen around the world.
Line 11: Line 11:


==== Why not use JSON format to express custom logic? ====
==== Why not use JSON format to express custom logic? ====
While many content creators are more familiar with JSON than JavaScript, the JSON format is IMO too verbose to write by text, and requires a GUI Editor to achieve anything functional in a productive manner (Which again, takes longer development time).
While many content developer are more familiar with JSON than JavaScript, the JSON format is IMO too verbose to write conditional logic, and requires a GUI Editor to achieve anything functional in a productive manner (Which again, takes longer development time).


A component/module based system is an option ([https://github.com/DistrictOfJoban/Joban-Client-Mod/tree/da4de5801ae7d758f57ceae1f9bf6af811df10e3/fabric/src/main/java/com/lx862/jcm/mod/data/pids/preset/components Which was trialed in JCM]), however the component itself also needs to be configurable enough to allow all sorts of combinations, which sort of goes back to the "add a toggle to everything", just in a smaller scale. Whereas JS allows user to express their own custom logic. (And if logic are to be implemented in JSON, then it might be better to just go with an established programming language)
A component/module based system is an option ([https://github.com/DistrictOfJoban/Joban-Client-Mod/tree/da4de5801ae7d758f57ceae1f9bf6af811df10e3/fabric/src/main/java/com/lx862/jcm/mod/data/pids/preset/components Which was trialed in JCM]), however the component itself also needs to be configurable enough to allow all sorts of combinations, which sort of goes back to the "add a toggle to everything", just in a smaller scale. Whereas JS allows user to express their own custom logic, implemented in the way they wish.


This is also done to assess the performance with larger-scale use of scripting, creator satisfaction and the feasibility of porting scripting to future MTR versions.
(And if custom logic are to be implemented in JSON anyway, it might be better to just go with an established programming language)
 
This is also partially done to assess scripting in a larger-scale and the feasibility of porting scripting to future MTR versions.


==== Will the JSON Format stay available? ====
==== Will the JSON Format stay available? ====
Don't worry, the JSON Format will remain available as a simplified form of customizing PIDS, and it will not be removed anytime soon. It's just another type of preset that is available alongside Scripted PIDS Preset.
Don't worry, the JSON Format will remain available as a simplified form of customizing PIDS, and will not be removed anytime soon. It's just another type of preset that is available alongside Scripted PIDS Preset.


==== Is JS the recommended way of making PIDS Preset from now on? ====
==== Is JS the recommended way of making PIDS Preset from now on? ====

Revision as of 00:37, 8 November 2024

Note

This article is created for Joban Client Mod v2.0.0-beta.5.
Features mentioned might not be available to the public yet.

Scripted PIDS Preset is a new experimental feature introduced in JCM 2.0.0-beta.5, it allows content developer to make new PIDS Preset using Javascript. The system is inspired by the Nemo Transit Expansion mod in MTR 3.

Motivation

The most common questions I have received regarding PIDS Preset is "Can I replicate X PIDS from this Metro?". Unfortunately the answer I have to give them is usually a no.

This is due to the JSON PIDS Preset always following a fixed-layout consisted of a Header Bar (Weather & Time), and 4 rows of arrivals. However Metros around the world have different approaches to how they want to display their information, and given the combination it's not really feasible to just "add a toggle" for each layout seen around the world.

Therefore, it is decided that building a platform that allows players around the world to express their creativity is the way forward.

Why not use JSON format to express custom logic?

While many content developer are more familiar with JSON than JavaScript, the JSON format is IMO too verbose to write conditional logic, and requires a GUI Editor to achieve anything functional in a productive manner (Which again, takes longer development time).

A component/module based system is an option (Which was trialed in JCM), however the component itself also needs to be configurable enough to allow all sorts of combinations, which sort of goes back to the "add a toggle to everything", just in a smaller scale. Whereas JS allows user to express their own custom logic, implemented in the way they wish.

(And if custom logic are to be implemented in JSON anyway, it might be better to just go with an established programming language)

This is also partially done to assess scripting in a larger-scale and the feasibility of porting scripting to future MTR versions.

Will the JSON Format stay available?

Don't worry, the JSON Format will remain available as a simplified form of customizing PIDS, and will not be removed anytime soon. It's just another type of preset that is available alongside Scripted PIDS Preset.

Is JS the recommended way of making PIDS Preset from now on?

Please keep in mind that scripting is introduced as an experiment and we need your voice to tell whether it should be the way forward, so nothing is set in stone yet!

Do I need to learn JavaScript to make this?

Learning the syntax of the JavaScript Language is usually enough to get by. As JS is predominantly used on Websites and Server (Node.js), many tutorials covers those APIs specifically. However most of them are not available in JCM's scripting implementation.

If you are unsure, you can also check out the following tutorial.

Getting started

For a practical tutorial, see Building a Scripted PIDS Preset.

For documentation, please read the Documentation.

If instead you would like to learn by example, you can download the Example Scripted Preset Resource Pack and inspect the scripts.