Terrain Editing

Involved development of the OpenMW construction set.
aesylwinn
Posts: 229
Joined: 14 Dec 2015, 20:30

Re: Terrain Editing

Post by aesylwinn » 24 Aug 2017, 19:56

Zini wrote:
24 Aug 2017, 11:06
Edit: Another idea. A bit radical, but probably usable. We could merge LTEX and LAND into a single record within the editor. Requires some reorganisation and a rewrite but would solve all our problems.
An interesting idea, but how would we handle LTEX records shared between LAND records. Perhaps I'm misunderstanding the structure, but don't all LAND records in a plugin access a shared pool of LTEX records? Assuming my understanding is right, this brings up another potential issue. If the user changes an LTEX record, they could be trying to do it only for a single cell, or for a large grouping of cells (maybe even all of them).

Maybe it's just me, but since LTEX records are plugin specific anyway, it doesn't seem worthwhile or intuitive to mark them as modified. I think LTEX records should be thought of more as a palette. If they exist in other plugins, when the user uses them, they are brought into the current plugin palette. The user can choose to add or remove LTEX records from their palette manually. They can also choose to change what texture the LTEX record in their palette points to. If a LTEX record is removed, any modified LAND records that reference it will have those "references" be set to 0 (which specifies that the default texture will be used). When a LAND record is modified, any LTEX records it references that don't exist in the current palette are added automatically. We could then provide extended tools for changing an LTEX record across multiple LAND records.

User avatar
Zini
Posts: 5132
Joined: 06 Aug 2011, 15:16

Re: Terrain Editing

Post by Zini » 25 Aug 2017, 09:52

An interesting idea, but how would we handle LTEX records shared between LAND records.
You are correct. Unfortunately this will not work.

After looking at it again I am actually not 100% sure if I understand how these records work. As I understand it there is a LAND record per cell and a list of LTEX records per content file and all LAND records from that content file share this list.

That makes them different from any other record type and that is a problem. So the decision that needs to be made here is are we fitting these records (or at least the LTEX records) into our regular record storage system or are we adding a separate record storage system. I would favour the first option a lot, if it is possible. But if the second option can be implemented in a way that reduces the number of special cases significantly that might be the way to go.

User avatar
psi29a
Posts: 3432
Joined: 29 Sep 2011, 10:13
Github profile: https://github.com/psi29a/
Contact:

Re: Terrain Editing

Post by psi29a » 25 Aug 2017, 13:02

I'm not sure if this helps, but here is tesannwyn where I do conversion between raw and an esp filled with LAND/LTEX entries.

https://github.com/psi29a/tesannwyn/tree/reconstruction

aesylwinn
Posts: 229
Joined: 14 Dec 2015, 20:30

Re: Terrain Editing

Post by aesylwinn » 25 Aug 2017, 17:18

We can probably keep using the record system, but we'll need to to eliminate the modified aspect (which looks like it may involve slightly changing the editor load code). An LTEX record will either be base or added. Base records will not be modifiable.

Edit: Does anyone know what happens if multiple plugins modify the same LAND record? Does the last plugin to modify a LAND record win?

Edit 2: It's more complicated then I originally thought. Since the ids for LTEX records can clash across multiple plugins, the collection class will not work as intended. I'll have to think through this for a while. Using a mixture of the plugin number and index value as an "id" may work.

aesylwinn
Posts: 229
Joined: 14 Dec 2015, 20:30

Re: Terrain Editing

Post by aesylwinn » 29 Aug 2017, 06:13

I was able to get the ID table to work using the land texture plugin and index as the source. I still need to work on the land texture cloning/creation, but I don't anticipate that taking too long. However, I have thought up an interesting scenario that needs consideration.

Say the user creates a land texture with an index of 5 that points to a texture called grass.png. They then proceed to edit an existing land record. Coincidentally, the land record in the plugin the land record was loaded from references an land texture with an index of 5 that points to a texture called snow.png. How do we handle this?

If we change the index, then that causes a problem when we modify other land records that reference the original index. We could try to find the land texture by searching for the texture it references, but that would cause issues if the user changed the texture.

If we don't allow new indices to have the same value as base indices, then this particular scenario is avoided. However, if we had two mods that added land records with different land textures and the same index, we would have the same issue.

User avatar
Zini
Posts: 5132
Joined: 06 Aug 2011, 15:16

Re: Terrain Editing

Post by Zini » 29 Aug 2017, 11:02

If a LAND record changes from the base to the modified store it needs to be completely rewritten (i.e. all texture indices need to be adjusted to the modified content file. This may even require creating new LTEX records, because we can not assume all base LTEX records have an equivalent modified LTEX record.

aesylwinn
Posts: 229
Joined: 14 Dec 2015, 20:30

Re: Terrain Editing

Post by aesylwinn » 29 Aug 2017, 13:52

I suppose that's the most sane way of handling it. It may cause some grief to the user though if they change an LTEX in the midst of modifying base LAND records.

User avatar
Zini
Posts: 5132
Joined: 06 Aug 2011, 15:16

Re: Terrain Editing

Post by Zini » 29 Aug 2017, 14:49

Not sure what you mean by that. Changes to the content file data happen one by one. You can not make a change to a LTEX record in the middle of making a change to a LAND record.

aesylwinn
Posts: 229
Joined: 14 Dec 2015, 20:30

Re: Terrain Editing

Post by aesylwinn » 29 Aug 2017, 15:55

Say the user modifies some terrain. They then go to the LTEX tables and change the name and texture of an LTEX record. Then, they go back to editing terrain. An LTEX record with a different index would need to be created since there is no way of determining that the two were the same. We will probably want some method of merging LTEX indices.

User avatar
Zini
Posts: 5132
Joined: 06 Aug 2011, 15:16

Re: Terrain Editing

Post by Zini » 30 Aug 2017, 10:00

If you manually edit a LTEX record this would automatically change the texture for all LANDs that are using this record. Sorry, I still don't get your point.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests