34 replies to this topic

[James24]

So I've been thinking.  We all know that there is ZScript for ZC right now.  But why restrict it to ZC?  Why not ZScript for ZQuest too?

 

The idea is that someone who is very good at scripting can make a "module".  A module would be a complicated script paired with all the automated setup instructions and other resources.  All a user needs to do is tell ZQuest to load a module and the automated setup instructions would take care of the rest.  At the end, the user would be left with an easy to work with interface that handles all the complexity associated with dealing with the script.

 

Think about it like a USB drive that you might use.  When you plug the USB stick into your computer it has its own self-contained instructions that allow the computer to interface with it and the user ends up with a nice GUI to interact with the files on there.  You don't need to worry about how the computer and the USB stick talk to each other.  If people needed to learn about that, USB sticks wouldn't be used anymore.

 

As it stands right now, there are some scripts on the database which are simply too complicated to download and setup for the average or beginner user.  Only expert users who have been here for years stand a chance and even then it would take them a few hours to figure everything out.

 

This all sounds very good.  But there are two major hurdles with it  First, if the devs think its a good idea, this is going to be a massive investment of their time to make. Scripting for ZC only took 7 hears to make.  This one might take more.  Second, the community would be absolutely reliant on the goodwill of the whoever made the complicated script to spend their precious time converting it into a module for the average or beginner users to use.  Why would they spend their time converting it into a module when they already have mastered their complicated script and they can use it just fine?  This would only work if they had to spend a very short time converting it.

 

 

[Evan20000]

Crowd-sourcing UI design with all the people involved in the end product working in isolation sounds better than half the scripts that get pitched to be made into comedies. I'm game for a quality giggle.

[Aslion]

If people aren't writing good enough documentation to make it easy to set up a script they're not gonna write an entire other script to do it either

[Moosh]

I've thought about this kind of thing before. Less so for scripts and more for enhanced editor functionality. Better shortcuts and whatnot more types of relational combo placement modes. User made features to make the editor faster and easier to use. Unfortunately something like that is very difficult to implement. Some of what you're describing is in 2.55 via existing modules and script metadata, though I can't imagine setting up scripts will ever be drag-and-drop. Heck, ZC itself will never be drag-and-drop. At least it's headed in a more user friendly direction. 

[Haylee]

I mean I imagine you're suggesting something different here, but just in case....

 

 

?????

Edited by Einsiety, 22 March 2021 - 10:14 AM.

[Moosh]

If people aren't writing good enough documentation to make it easy to set up a script they're not gonna write an entire other script to do it either

You'd actually be very surprised. Some scripts like my Gameboy map script are I believe very well documented, yet still a nightmare hellscape to set up. If I could write a module to lessen that burden somehow I definitely would. But the problem here comes down to data input and the user's attention span. If the user has to input a lot of data all at once specific to their quest in order for said script to work no amount of module design is going to overcome the bottleneck that is their attention span. This is why sometimes having multiple variants of the same script is a good thing. 

 

Take my simple GB shutters script vs. the more advanced ALttP version. Both can perform the same task in the EZGBZ tileset but the gameboy version has less arguments, relies more on vanilla mechanics, and is probably a better fit for a newer user.

 

https://www.purezc.n...=scripts&id=286

 

https://www.purezc.n...=scripts&id=290

 

This actually reminded me that I need to update the description of the gameboy version to clarify something that might confuse people.

[Evan20000]

You'd actually be very surprised. Some scripts like my Gameboy map script are I believe very well documented, yet still a nightmare hellscape to set up. If I could write a module to lessen that burden somehow I definitely would. But the problem here comes down to data input and the user's attention span. If the user has to input a lot of data all at once specific to their quest in order for said script to work no amount of module design is going to overcome the bottleneck that is their attention span. This is why sometimes having multiple variants of the same script is a good thing. 

 

Take my simple GB shutters script vs. the more advanced ALttP version. Both can perform the same task in the EZGBZ tileset but the gameboy version has less arguments, relies more on vanilla mechanics, and is probably a better fit for a newer user.

 

https://www.purezc.n...=scripts&id=286

 

https://www.purezc.n...=scripts&id=290

 

This actually reminded me that I need to update the description of the gameboy version to clarify something that might confuse people.

Passageways kill the LttP shutters dead.
(They're actually great aside from that... interesting interplay of ZC mechanics.)

[Timelord]

I have on several occasions considered adding some soft of scripting engine to the ZQuest Editor. It would certainly not be ZScript/ZASM, as it is completely unrelated to how that works. In general, it would need to provide macro functionality, so that repetitive tasks could be automated. It'd also need to be immediately interpreted. There are a few things that exist that could fulfill these obligations, but integrating them into ZQuest and making them functional is a monumental task, especially given the sprawling nature of the software. 

 

What you have to understand, is that ere writing one single line of code for such a thing, it must be completely specified. We need to consider everything that we want it to do, everything that it will be able to do, what hooks it will requires, what code it can access and modify, and a lot more. I do not add things this complex without a truly comprehensive plan. At present, we barely have enough weekly time, spread across everyone involved, to continue development. Something like this requires a lot of forethought, dedication, planning, and resources. 

 

In the future, it is possible, or even likely that something like this may become part of the editor. At present, we simply do not have the available resources to implement anything on that type of scale. 

 

The present ZASM implementation does allow for a lot more information to be embedded, including some basic setup details. That however has nothing to do with adding scripting to ZQuest. Ultimately, in the future, it is my hope that more scripts will be readily available as .zasm files, as resource packages, or other similar modular objects that can be imported directly. I have been working on this as a goal with npcs at present. Once we have an assortment of new format npc scripts and collected assets, it will be possible for me to make a pair of save/load npc module functions (this was planned all the way back in 2017) to load their data values, graphics, scripts and other assets all as one package. 

 

If anyone is curious, for ZQuest scripting, I have considered AS, Ruby, Python, and even flipping Hypercard. The issue is that none of these provide out of the box macro implementation other than Hypercard, and this is pretty damned proprietary. 

[Saffith]

I had hoped to do something like that with some sort of annotations. Godot uses an "export" tag: https://docs.godoten...pt_exports.html
 

# Export can also take a resource type to use as a hint.
export(Texture) var character_face
export(PackedScene) var scene_file
# There are many resource types that can be used this way, try e.g.
# the following to list them:
export(Resource) var resource

# Integers and strings hint enumerated values.

# Editor will enumerate as 0, 1 and 2.
export(int, "Warrior", "Magician", "Thief") var character_class
# Editor will enumerate with string names.
export(String, "Rebecca", "Mary", "Leah") var character_name

Something like that could work in ZQuest. You'd annotate a variable or constant with a type, a description, and whatever else, and ZQuest would present an appropriate input widget. But all that would require pretty major changes to how scripts are handled internally, and I'm not so sure the GUI code's up to it, either.

[Timelord]

I had hoped to do something like that with some sort of annotations. Godot uses an "export" tag: https://docs.godoten...pt_exports.html
 

Something like that could work in ZQuest. You'd annotate a variable or constant with a type, a description, and whatever else, and ZQuest would present an appropriate input widget. But all that would require pretty major changes to how scripts are handled internally, and I'm not so sure the GUI code's up to it, either.

 

 

 

If by this you mean to annotate variables in ZScript scripts for ZC Player, this is already somewhat implemented, and can always be expanded. ZASM now stores metadata for each run() argument, and you can pass information for the GUI to use into the scripts for those args for most script types, 

[James24]

For this to work, it sounds to me that ZC needs a sponsor/investor more than a it needs a competent and able developer.  No offense to you Zoria.  Not only would they have to fund the upgrade itself but they would also have to incentivize the best script makers here into creating workable modules for others.  A tall order indeed.

[Deedee]

For this to work, it sounds to me that ZC needs a sponsor/investor more than a it needs a competent and able developer.  No offense to you Zoria.  Not only would they have to fund the upgrade itself but they would also have to incentivize the best script makers here into creating workable modules for others.  A tall order indeed.

Zoria, the mad bloke, has been funding the entire development out of his own pockets. You can basically consider him both sponsor, investor, and lead dev. When I learned how much he had sunk into this bloody program I was shocked, and I was shocked he was still willing to contribute more.

[Moosh]

For this to work, it sounds to me that ZC needs a sponsor/investor more than a it needs a competent and able developer.  No offense to you Zoria.  Not only would they have to fund the upgrade itself but they would also have to incentivize the best script makers here into creating workable modules for others.  A tall order indeed.

This is why the best application of editor scripting is editor automation, not script automation. It benefits everybody and scripts made for it are far more modular than say if I wrote one to set up my map script. Everybody wins.

 

Like imagine automated DoR mountain combo placement. Okay now stop imagining it, that would be an absolute trainwreck to make. But a trainwreck that half-works is still better than what we have now.

[James24]

If Zoria really is funding this game then he would do well to make projects such as this top priority.

 

The uncomfortable truths about ZC is that its a 21 year old program designed to make (much loved) NES quests for a generation of players who are now long gone.  NES Zelda is now out of fashion and a new generation of players is demanding that ZC make modern Zelda games similar to the ones that Nintendo has been releasing lately.  ZC is incapable of doing this except via scripting.  And scripting is very hard to learn, very hard to perform and lots of new players get scared off by it.  This project would lower the costs of learning such scripting dramatically and open the gates to a new generation of players who can now make their dream Zelda quests just as cheaply as the previous generation did.

[Deedee]

If Zoria really is funding this game then he would do well to make projects such as this top priority.

 

The uncomfortable truths about ZC is that its a 21 year old program designed to make (much loved) NES quests for a generation of players who are now long gone.  NES Zelda is now out of fashion and a new generation of players is demanding that ZC make modern Zelda games similar to the ones that Nintendo has been releasing lately.  ZC is incapable of doing this except via scripting.  And scripting is very hard to learn, very hard to perform and lots of new players get scared off by it.  This project would lower the costs of learning such scripting dramatically and open the gates to a new generation of players who can now make their dream Zelda quests just as cheaply as the previous generation did.

A lot of 2.55's new features make using scripts even easier than ever. Scripters have to rely on less dumb workarounds and less hardcoding because of compiler changes, and gives them many more tools to streamline the process of using scripts. In return, 2.55 offers much more customization on the user's end, letting them use scripts in more creative ways. For example, the in development Ghost3, which is Ghost but for 2.55, has all of it's weapon behavior in one weapon script. Every enemy allows you to attach not only an NPC script, but also a Weapon script; which means base enemy-editor enemies can now fire ghosted weapons with fancy movement patterns without having to even touch a script. You can easily have a gleeok fire weapons that bounce off the walls, or a wizzrobe that has it's shots reaim towards you. The potential here is amazing.

The big problem with 2.55 until recently was adoption. Nobody wanted to touch the alpha, they had it in their heads that it was unstable and even after it got more stable that first impression stuck. However, more and more people are doing stuff with 2.55 and seeing the absurd potential here, and that means more scripts are gonna get written for 2.55 that incorporates these streamlining features.