November 29, 2020, 05:28:19 am

Author Topic: Dynamic Plug-in Updates:  (Read 1072 times)

0 Members and 1 Guest are viewing this topic.

Offline The Crazy Animal

  • Administrator
  • Master
  • *****
  • Posts: 2448
  • Karma: +18/-20
Dynamic Plug-in Updates:
« on: July 07, 2006, 11:57:54 pm »
This is something that Danelin mentioned in passing and I have to agree with we need a way to make it possible for third parties to create non-conflicting updates to the game.

The way I can see this being done is to have the game engine have a data configuration menu that is accessible via the computer it?s running on. This Configuration menu would allow you to add new databases into the system. Once the new databases are listed in the system then you would compile a new compiled database similar to the wccupda2.dat file was configured.

Pre-update the data manager needs to auto back up the last copy of the game prior to compiling so the new update file doesn?t clear any data prior to checking for problems. To ensure there are no record level conflicts. As the system is compiling the update it should use the old compiled database as a template so with the exception of overwrites everything is in the same place with added data appended at the end.

The added data files would be basically shortened version of the individual data files with the exceptions they would have to include a way to tell the game engine how to compile the file as well as keeping records linked. This would be done via the editor and interpreted by the game engines compiler. The way I see this working is having the plug-in data have two types of record numbers one that pertains to a temp number such as T123 and one that pertains to an existing record such as 123. The game engine would then interpret the temp numbers as temp numbers and append them to the end of the compiled data file and the real record numbers would be overwritten.

Now Some updates are going to conflict no matter what we do these are more then likely going to be the at the textblock level so there will need to be an output that can report to the sysop what has been overwritten at the end of the process. This then would allow the sysop to go back into their editor and create a quick fix if there is any loss of functionality.