On 10 November 2010 05:31, James Paige <[email protected]> wrote: >> > However, TMC's ideas are much better, using working.tmp, and >> > allowing some forms to be refreshable. And the in-game console >> > for script running would be fantastic. Did you intend >> > plotscript commands to be called directly, such as placing >> > a hero or npc in an exact location for testing purposes? >> >> Yes. That's more convenient that having to wrap everything in a script. >> >> I've already started: FB's builtin functions for piping allow only >> redirecting either a process's input or its output, not both. That's >> one reason that I wrote all that process code to fix the import bug. I >> want to keep hspeak running (after loading in the existing script >> files) and have it compile statements one at a time. > > Wouldn't this mean that hspeak would become a run-time dependency of > game?
Only if you want to use the console. It might be possible to actually embed HSpeak in Game by modifying and linking with the generated C code but that sounds pretty awful to me. >> Also, I just remembered why I was looking into IPC instead of David's >> much simpler and saner suggestion of just storing hashes for lumps: >> it's because I'm eager to get rid of working.tmp, and run both Game >> and Custom straight from lumped RPG files, through the lumpfile >> abstraction. > > Thats okay as long as custom saves a complete backup before it starts > editing. I would hate to lose the ability to exit custom and throw away > all changes. Of course. The idea is that it would write modified lumps to a temp directory, or store the changes in memory (irrelevant details), and only write them back to the file when saving changes. In the same way, Game could perform upgrades that it needs to without modifying the RPG file, and without totally unlumping it. > --- > James _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
