Aleph One/Bet does not save the contents of the original OS’ resource fork in saved games, nor does it bother transmitting them over network games. This poses problems in certain cases, especially but not exclusively for embedded TEXT resources. This is a problem for several reasons, and I would like Aleph Bet to handle it less clumsily.
Currently, there is only one way to reuse the same script file within multiple levels that works on all three major operating systems, other than literally copying it to the directory of each map that uses it (and repeating this every single time it’s changed): embed it as a TEXT resource. (Aside 1: This is a major flaw with Atque that we should take a look at fixing. AFAIK, it can use hard links on MacOS and Linux, but not Windows, and cannot use symlinks on any OS.)
The problems here should be obvious, chief among them:
All scripts that are embedded in a map as TEXT resources will be lost if their parent map is not accessible to Aleph One/Bet when a player loads a saved game from that map. Thus:
If someone wants to transfer their saves from Eternal 1.3 preview 5 to 1.3 preview 6, the Lua scripts on the level they load won’t run, so they’ll lose all their secret collection info, etc., unless they know how to edit the save file header. (Aside 2: It might be worth creating a utility to associate a particular saved game or film file with a specific map.) For the final release, I won’t be embedding TEXT resources, but they’re vastly more convenient while we’re still in the development stage.
For similar reasons, we had to edit the map headers for the hellpak patches so that players would be able to transfer their saves between versions. This is generally a Bad Idea™, but in this case all the alternatives seemed worse.
Network games on maps that depend on MML/Lua scripts embedded as TEXT resources will quickly go out of sync unless all players have the map.
My solution is very simple: I’d like Aleph Bet to save all TEXT resources (or at the very least, all TEXT resources called as either MML or Lua scripts) in saved games and to transmit them over the network. The former of these, at least, should be a relatively easy fix; the latter may be worth holding off until Netzspieldämmerung, depending on how complicated it would be to implement it independently. (It may be as simple as “only transmit TEXT resources if all players are using Aleph Bet.”)
(I can see a potential case for adding a setting for how to handle other parts of the resource fork (snd, CLUT, PICT, etc.), but I strongly support treating embedded MML/Lua scripts as a special case and always saving or transmitting them.)
Aleph One/Bet does not save the contents of the original OS’ resource fork in saved games, nor does it bother transmitting them over network games. This poses problems in certain cases, especially but not exclusively for embedded TEXT resources. This is a problem for several reasons, and I would like Aleph Bet to handle it less clumsily.
Currently, there is only one way to reuse the same script file within multiple levels that works on all three major operating systems, other than literally copying it to the directory of each map that uses it (and repeating this every single time it’s changed): embed it as a TEXT resource. (Aside 1: This is a major flaw with Atque that we should take a look at fixing. AFAIK, it can use hard links on MacOS and Linux, but not Windows, and cannot use symlinks on any OS.)
The problems here should be obvious, chief among them:
My solution is very simple: I’d like Aleph Bet to save all TEXT resources (or at the very least, all TEXT resources called as either MML or Lua scripts) in saved games and to transmit them over the network. The former of these, at least, should be a relatively easy fix; the latter may be worth holding off until Netzspieldämmerung, depending on how complicated it would be to implement it independently. (It may be as simple as “only transmit TEXT resources if all players are using Aleph Bet.”)
(I can see a potential case for adding a setting for how to handle other parts of the resource fork (snd, CLUT, PICT, etc.), but I strongly support treating embedded MML/Lua scripts as a special case and always saving or transmitting them.)