openmw.org

Terrain Editing

Re: Terrain Editing

this would automatically change the texture for all LANDs that are using this record

First, I'm not sure we're on the same page, so let me reiterate and slightly expand on my previous posts. The LTEX is not a true record. It is either "new" or "base" (a limitation of the save format). You can not modify a base LTEX for several reasons. One, it simply does not make sense. The "base" LTEX records are the LTEX records for different plugins, not the current plugin. Any such changes would not persist between sessions. It would show up as a "new" record on reload. Two, under the hood we would need to modify every single LAND that references it. I'm fairly certain this would be bad for multiple mods. Any mod changing a base LTEX would conflict with others that modify LAND records. I haven't been able to test it, but from what I've seen in the source code it looks like the last one loaded is picked. We should try to avoid having such a tool where the consequences (significant mod conflicts in this case) are major and not made obvious by the gui. I would suggest having an "import" tool instead that will mark as modified all LAND records referencing a specified base LTEX for the use case where a user wishes to change an LTEX across all LAND records.

So to clarify my previous post, there are two LTEX records. The base LTEX and the added LTEX. After changing either the user friendly name or the texture referenced by the LTEX record, we cannot know that the base and added LTEX are referencing the same thing. Thus when modifying a base LAND, another LTEX will have to be added.

Re: Terrain Editing

Posted: 31 Aug 2017, 09:03

by Zini

First, I'm not sure we're on the same page, so let me reiterate and slightly expand on my previous posts. The LTEX is not a true record. It is either "new" or "base" (a limitation of the save format). You can not modify a base LTEX for several reasons. One, it simply does not make sense. The "base" LTEX records are the LTEX records for different plugins, not the current plugin.

We are on the same page. With modified I was referring to the modified part of the record struct. The record state would then be ModifiedOnly.

Two, under the hood we would need to modify every single LAND that references it. I'm fairly certain this would be bad for multiple mods.

Only within the edited mod. Other mods have their own set of LTEX records.

So to clarify my previous post, there are two LTEX records. The base LTEX and the added LTEX. After changing either the user friendly name or the texture referenced by the LTEX record, we cannot know that the base and added LTEX are referencing the same thing. Thus when modifying a base LAND, another LTEX will have to be added.

I think that is the point. You can not modify base LAND records directly. By doing so you turn the record into a modified record, which means it is now part of a different content file and refers to a completely different set of LTEX records that are unrelated to the set of LTEX record it was referring to when it was still in base.

Re: Terrain Editing

Posted: 31 Aug 2017, 14:06

by aesylwinn

I see I was misunderstanding on some levels.

A bit of a progress update, I'm working on the ability to "touch" a land record. This merely copies the base version and calls the setModified function, as long as the record is not already modified. I'm choosing between implementing it as a proper table/collection operation or a column hack. I think the functionality is only needed for the land record, so I'm leaning towards the column hack. It's also much simpler since I don't need to deal with all the layers of abstraction that make up the table system. On a related note, testing shows that the terrain storage system (for rendering) will need to be reworked because it does not use the tables/records system properly.

Edit: Looks like there is already the ability to modify the record state through the columns.
Edit 2: The record state column won't work, I'll start a pull request soon of what I have so far.

Re: Terrain Editing

Posted: 02 Sep 2017, 13:11

by Zini

It just came to my attention that the merge tool doesn't handle LTEX and LAND records properly either. If you want you can handle this issue as a part of this task or if you don't want to bother with it, we make file it as a separate issue.

Re: Terrain Editing

Posted: 02 Sep 2017, 15:24

by aesylwinn

A separate task would be best. There's quite a bit to this task already.

Re: Terrain Editing

Unfortunately, not done yet. The cell table has extended delete/revert functions that affect records associated with the respective cell. Considering what we know about how LAND/LTEX records work, this will probably trash something in its current state. Needs also to be looked at.

Re: Terrain Editing

Posted: 05 Sep 2017, 03:36

by aesylwinn

The extended delete doesn't seem to delete the related pathgrid or land record associated with it. Maybe I'm misunderstanding what it's suppose to do or something is not set up?

Previously you mentioned (before the discovery that LTEX's were plugin specific) that LTEX records should be deleted if the sole LAND record referencing it is deleted. Do you still think we should have that functionality? I only ask because it complicates matters and is potentially very expensive to determine if no LANDs reference an LTEX. Iterating through the texture index array of every LAND would take quite a while, so we would likely have to cache the LTEXs referenced (something else to maintain).

Re: Terrain Editing

Posted: 05 Sep 2017, 09:59

by Zini

The extended delete doesn't seem to delete the related pathgrid or land record associated with it.

I haven't looked at the code in ages, but I am pretty sure that is supposed to delete these records. If it doesn't then that is an unrelated bug and you don't need to bother with it.

Previously you mentioned (before the discovery that LTEX's were plugin specific) that LTEX records should be deleted if the sole LAND record referencing it is deleted. Do you still think we should have that functionality? I only ask because it complicates matters and is potentially very expensive to determine if no LANDs reference an LTEX. Iterating through the texture index array of every LAND would take quite a while, so we would likely have to cache the LTEXs referenced (something else to maintain).

That is a good question. Ideally we would want to have a way to automatically clean up LTEX records to avoid piling up of unused records. But you are right. That is expensive and complicated. I suggest to leave this feature out for now. We can have a go at it another time (and maybe with a different approach that doesn't share these problems).