20 replies to this topic

[Avaro]

I'm fine with this if it is not mandatory and you can still do it the old way.

But yeah, it would be nice if you could export all the code that's stored inside the quest and not just the buffer.

[DarkDragon]

I'm fine with this if it is not mandatory and you can still do it the old way.
But yeah, it would be nice if you could export all the code that's stored inside the quest and not just the buffer.

No, to be clear, this is technically impossible. There is no (practical) way to take ZASM and convert it back into ZScript. The only way to do what you say (have the ability to save scripts from the .qst) is to switch to the new way.

Edited by DarkDragon, 07 January 2017 - 10:41 AM.

[Russ]

So wait a second. As I understand it, when you compile ZScript, the compiler converts it to ZASM code, correct? There's no way to save a copy of the ZScript in the quest file, and then compile ZASM based off that? Seems a bit weird.

As far as my opinion goes, while it'd be great to have scripts be a part of the quest file for lots of reasons, I do really worry about the time factor. As somebody who often has to fix bugs in six different inter-related scripts when compiling stuff, I imagine this would add lots of needless time just importing each script one by one. As it stands right now, being able to just hit the compile button to do it all in one fell swoop is infinitely more convenient. So while I'd love to see the scripts embedded, unless that can be done without significantly complicating the compilation process, I'm gonna have to vote no.

However, I will say, regarding Dimentio's concerns, that I think such fears are unfounded. There are already ways to break into quests, and the newer versions, as I understand it, are moving away from password protection. People always bring up the "People will spoil stuff!" argument, but honestly, even with access to everything but the scripts, they can spoil stuff already. They either will or they won't, and basing decisions this large on concerns of that nature seem a bit nearsighted to me.

[DarkDragon]

So wait a second. As I understand it, when you compile ZScript, the compiler converts it to ZASM code, correct? There's no way to save a copy of the ZScript in the quest file, and then compile ZASM based off that? Seems a bit weird.

 

Yes, the first part is right: when you compile the ZScript, the ZASM is saved in the quest, and that is what is read by ZScript at gameplay time.

 

The full ZScript is not stored in the .qst; only the buffer is. The full ZScript is reconstructed each time you hit "compile" but is then discarded. Saving a copy in the .qst is exactly what I'm proposing in this thread

Edited by DarkDragon, 07 January 2017 - 01:39 PM.

[Russ]

The full ZScript is not stored in the .qst; only the buffer is. The full ZScript is reconstructed each time you hit "compile" but is then discarded. Saving a copy in the .qst is exactly what I'm proposing in this thread

Oh, I very much misunderstood then. I was under the impression that, to save a copy in the quest file, you'd have to manually import each script, rather than just import a master file into the buffer. If that's not the case, disregard my post, I'm bad at reading.

[Timelord]

No, to be clear, this is technically impossible. There is no (practical) way to take ZASM and convert it back into ZScript. The only way to do what you say (have the ability to save scripts from the .qst) is to switch to the new way.

I don't think that's technically wholly true. The parser should be able to copy its own buffer string into a string in the quest file, during the compile process, as it reads in all the imported files; and store it as a whole, assuming that the packfile is adjusted to handle it. That's what I was originally planning to have it do, with an 'Export' button to save that string out as a text file.

 

You might lose some formatting, such as tabs, and spacing, but it would otherwise retain all of the script text. doLines() could probably be adjusted to preserve the tabs, spacing, and CRs, in the process of storing the char anyway.

This would be no different than the existing 'export ZASM' option, save that it would be a pre-compile toggle, that the user can tick to store the scripts before hitting the compile button. When the parser reads them, the doLines() function just appends the new instructions to a separate buffer string, and at the end of the process, that string is embedded.
 

This model doesn't require a new way of doing things, to accomplish from what I can see. Am I mistaken?

(Obviously, converting ZASM back to C syntax is a wholly different can of worms, and would require a disassembler/decompiler, and would of couse lose any identifiers that the er declared in the process. I had thoughts about making such a thing at one time, but when I weighed its usefulness against the work involved, I decided against it.)

 

We should at least add an 'export ZASM' button, which I was also planning to do, to the menus. That would at least allow recovery of the assembled code from any quest. All this needs to do is select a slot, and print it out to a text file. (It might need to parse it through a reverse word table.)

 

 

Oh, I very much misunderstood then. I was under the impression that, to save a copy in the quest file, you'd have to manually import each script, rather than just import a master file into the buffer. If that's not the case, disregard my post, I'm bad at reading.

 

Unfortunately, you did read that. The change as originally proposed would remove the ability to do this as it works at present. It may replace it with an alternative way to read from disc, but it would effectively require revising every script that imports from disc at present.

 

FWIW, my suggestion here, was to add an #include directive, to do exactly what DD wants to do, and retain import as-is.

 

Something else that was mentioned in this topic, was file size. It reminded me of a discussion that I had with LinkTheMaster a year ago, when I was pushing to include the revised std.,zh stuff with ZC as a general replacement, and he was against it because he thought that having all the new functions in the header would bloat quest size, and thus, database size.

 

While that was not true (functions are resolved down to ZASM instructions when called in scripts, but functions in the header are not directly retained), I am concerned that if retaining scripts with quests starts adding +1MB to +5MB, to some quests, or potentially as much as +14MB (max buffer size), that they would not be allowed in the database here; and that's more of a staff concern, to discuss and deliberate.

 

The average scripted quest uses about 100KB to 500KB of scripts (a practical guess), which should be negligible, but with some of the bigger headers, and script engines, 1MB to 10MB is possible, so if we implement any method of saving scripts in the quest file, you could end up with quests that are 30MB to 40MB in size popping up occasionally, and you may need to determine if that would be problematic.

 

I know that one of my quests has 8MB of scripts, which cannot be trimmed, and will likely use > 15MB of tiles and internal SFX when done. It's pretty much DoR-sized, plus a long list of SFX, and storing all those scripts would put it easily around 30MB in size, if not more, by the time it is done.

 

In fact, being able to store scripts in separate buffers would be ideal for that quest, and its custom engine, as I have often worried about the engine exceeding the maximum buffer size. I had given thought to using multiple buffers for the parser, without storing them as individual buffers per script, a long while back, simply to increase the max size from 14MB to say, 140MB, if needed.

 

I was never certain how practical buffer shifting would have been.

 

Anyway... I would be concerned if storing scripts would be disallowed by Pure, when submitting a quest, so some feedback on that in general might be helpful.

Edited by ZoriaRPG, 08 January 2017 - 05:06 AM.