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.
Posted 07 January 2017 - 09:46 AM
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.
Posted 07 January 2017 - 10:41 AM
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'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.
Edited by DarkDragon, 07 January 2017 - 10:41 AM.
Posted 07 January 2017 - 11:45 AM
Posted 07 January 2017 - 01:39 PM
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.
Posted 07 January 2017 - 09:17 PM
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.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
Posted 08 January 2017 - 04:36 AM
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.
0 members, 1 guests, 0 anonymous users