Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integrate a Plugin Dumper #7

Open
magicaldave opened this issue Jul 3, 2023 · 4 comments
Open

Integrate a Plugin Dumper #7

magicaldave opened this issue Jul 3, 2023 · 4 comments
Assignees
Labels
enhancement New feature or request

Comments

@magicaldave
Copy link
Member

magicaldave commented Jul 3, 2023

For now, there are a handful of options, in order of preference:

  • ktools, zig-based so possibly not the easiest option, but certainly the most performant
  • DFL, which has a tes3conv dependency. I question how well this one would integrate due to its dependency on tes3conv. @VidiAquam
  • espParser, which is not ideal, but entirely Lua-based, thus the easiest of the three to integrate. Also has an external dependency on some lua libraries, so maybe no better than DFL in this regard.
@magicaldave
Copy link
Member Author

There are a few ways we can do this, and the choice is yours

The somewhat obvious conclusion occurred to me recently that openMW itself already has an esm reader. Naturally, since this is already used to generate server data in some cases, it might be useful to have a persistent store for the original state of the game as is used in many custom scripts.

This route would also be preferable since the above solutions are not necessarily going to be compatible over time. Indeed, most of them will probably be crippled by the ESM4 format. Of particular note here is DFL which has been confirmed to have no intent to support later games via its dependency on the TES3 library. Not necessarily a problem with DFL itself.

@SaintMercury
Copy link

We should use the openmw provided reader/writer.

It already supports plugins made by mw cs, and we won't have to worry about updating/supporting other formats as openmw supports more games (obvs years down the line). Plus, it'd be real wack if the client supports/doesn't support a record/plugin and the server does the opposite.

It shouldn't be impossible to just expose another namespace/variable within the server lua to just allow for reading a .omwaddon/.esp and doing something with the records.

Something ideally like:

let pluginFile = esmio.read(PATH_TO_FILE)
let records = pluginFile.records

for _, record in ipairs(records) do
    if record.type == 'DELE' then
        createDeleteRecord(record)
    else
        createRecord(record)
    end
end


let createdRecords = GetDynamicRecords()
let createdPlugin = esmio.createPlugin(PLUGIN_NAME, PLUGIN_DATA, createdRecords)
esmio.write(PATH_TO_CREATED_PLUGIN, createdPlugin)

or whatever

@magicaldave
Copy link
Member Author

Hm. I suppose it would kind of make sense not to duplicate all this data out into JSON if we just had the appropriate functions to read their native formats in lua.
This also provides a deeply interesting possibility of creating plugins server-side, which I hadn't thought about in this way before, but sounds extremely tempting.

@SaintMercury
Copy link

You could THEORETICALLY dump all created records from your world into an omwaddon, and allow people to laod it up in single player. Maybe not desirable, maybe desirable.

@YvanCywan YvanCywan added the enhancement New feature or request label Oct 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants