but I do have Direct X, version 11

DxDiag shows the following:

------------------System Information------------------Time of this report: 3/9/2010, 14:17:45   	Machine name: MI-PC   Operating System: Windows 7 Home Premium 64-bit (6.1, Build 7600) (7600.win7_rtm.090713-1255)       	Language: English (Regional Setting: English)System Manufacturer: LENOVO   	System Model: 3241                        	           	BIOS: InsydeH2O Version 1ECN30WW(V5.04)      	Processor: Intel(R) Core(TM) i7 CPU   	Q 720  @ 1.60GHz (8 CPUs), ~1.6GHz         	Memory: 4096MB RAMAvailable OS Memory: 4086MB RAM      	Page File: 1742MB used, 6429MB available    	Windows Dir: C:\windows	DirectX Version: DirectX 11DX Setup Parameters: Not found   User DPI Setting: Using System DPI System DPI Setting: 96 DPI (100 percent)	DWM DPI Scaling: Disabled 	DxDiag Version: 6.01.7600.16385 32bit Unicode------------DxDiag Notes------------  	Display Tab 1: No problems found.    	Sound Tab 1: No problems found.    	Sound Tab 2: No problems found.      	Input Tab: No problems found.

Just to add a precision, the WOW6432Node serves to store registry information for 32 bit programs.
On a 32 bit os it will be stored in HKEY_LOCAL_MACHIN/SOFTWARE/Bethesda Softworks/Oblivion/.
If a 32 bit program tries to access this on a 64 bit os it will be automatically redirected in the Wow6432Node part of the registry .

Good for you!

"I get a d3dx9_33.dll notice"

You see that number nine? You need DirectX 9. There's a link in the opening post of this thread.

ok, misunderstood you :blush:

got to relearn this new forum settings - thanks Display

Does anyone know the override rules for exterior cells, in particular the grup attached to the cells?
I made a little tool to fix tears, it makes a .esp and in it I export only the LAND records(and all the hierarchy of grups leading to them).
But apparently Tes4edit is not happy with it(throws an exception when I try to open the worldspace part of it ).

Should I also export the Cell records attached to the modified LAND? or even all the temporary/permanent grup attached to the CELL?

Well unless I'm misreading, you seem to be sort of contradicting yourself. You say you're exporting "all the hierarchy of grups leading to them" which I take to mean the parent records of the LAND record. But then you say "Should I also export the Cell records attached to the modified LAND? or even all the temporary/permanent grup attached to the CELL" which implies that you have NOT exported the parent records of the LAND record.

What you need in the new ESP for a single LAND record is:
Header
Worldspace group
-[Worldspace Record] (e.g. Tamriel)
--Block xx,yy
---Sub-Block xx,yy
----CELL record
-----Temporary group
------LAND record

So you must ensure that all parent records of the LAND recording, leading right back to the root of the branch are included in the ESP.

Well I'm not really contradicting myself because CELL/WRLD is not directly a parent record of the LAND record.
The reality is more like this:
Header
-Worldspaces Grup
--Worldspace Record
--Worldspace Grup
---Block
----SubBlock
-----Cell Record
-----Cell Grup
------Temporary
-------Land Record

Try viewing an ESP using TES4Edit, it displays the records in a manner clearly showing what each subrecord requires. In TES4Edit, there is no Cell Grup or Worldspace Grup displayed at all, so I know nothing about those (I'm just an end-user).
But it shows that Worldspace group is a parent of the worldspace record is a parent of the block group is a parent of the sub-block group is a parent of the CELL record is a parent of the Temporary group is a parent of the LAND record. That's the direct line of required records from root to LAND record.

Yes I know what tes4edit displays, but it simplifies it for easier viewing .
In reality a record can't have any children who is a record or a grup, only subrecords(ie what you see as grup children of the cell records are actually grup next to the cell record, not a children, they are identified and associated through the formID in the grup header).
Check http://www.uesp.net/wiki/Tes4Mod:Mod_File_Format for more info(the groups section details all the different GRUP types).

Found a bug.

In the Worldspace records, each WRLD record stores any persistent references in a dummy CELL. If you change the persistence of a reference, you have to translate the position of the reference to/from the appropriate CELL. TES4Edit does this, but it goofs up on the calculations by (I'm guessing) truncating instead of flooring. It'd be easiest to explain it with an actual example.

REFR: 000039CA (OBGateRandWW001MapMarker) places a persistent MapMarker at -99123.445312, 14940.896484
To change this to a temporary reference, you have to figure out which CELL it belongs to.
Each CELL is 4096 by 4096 units, so divide the X,Y coords by 4096.
You get -24.2, and 3.65.
TES4Edit appears to truncate this to -24, 3, so it looks for a CELL with those coords.
To figure out the Sub-block -24, 3 would be in, divide each number by 8. Again, TES4Edit appears to truncate any remainders.
You get -3, 0.
To figure out the Block -3, 0 would be in, divide each number by 4. Again, TES4Edit appears to truncate any remainders.
You get 0, 0.

So, TES4Edit looks for a record in Block 0, 0, Sub-block -3, 0. That sub-block doesn't exist, so it can't resolve the CELL, and it throws an error.

The problem came when TES4Edit truncated the values. Instead, the proper thing is to floor these values (round down).
So, for the CELL coords, you get -25, and 3.
Dividing by 8, you get -3.125, so the Sub-Block turns out to be -4, 0.
Dividing by 4, the Block turns out to be -1, 0.
Looking in Block -1, 0, Sub-block -4, 0, you find CELL 00007D38 (OBGateRAndWW001). If you open the CS, you can confirm that this is where it should be.

@Waruddar:
You're obviously correct and just learned a place in my thanks list because I was about to do the same error in my own program .
The author of tes4edit probably did an integer divide without accounting for the remainder(like I was about to do...).

You're going to a technical level of detail I'm not willing to invest time with, so I'll just accept and agree While what TES4Edit shows (simplicity) may have made my earlier comment inaccurate, it still probably contained the answer to your original question; yes to the CELL records and their corresponding Temporary Grup, but no to their Persistent Grup. You're probably well beyond the point of needing the answer to that question now of course!



I''ve left a message for Elminster telling him of your find, hopefully he will pop in here, confirm the issue and do something when he has some time (which might take a while, he's busy with RL work).

I don't suppose there's any way to make TES4View respect the BASH:Filter tag is there?

If I don't uncheck all my "Filter" mods, it crashes TES4View.

I think it's probably best to just not try to load a Bash Patch into TES4Edit.

Well, when you are debugging import functions and bash tags you kind of have to include the bashed patch.

But, it's not the patch that causes the problem. It's mods like Item Interchange that have tons of masters that don't exist in the load order. The bashed patch doesn't care because of the filter, but TES4View dies when it tries to load them. Likely to be an increasing problem as patch mods start to use the Filter tag.

I never have any trouble getting tes4edit to load my bashed patch. It doesn't try loading the All Natural indoor weather filter which also has tons of masters that aren't available. I can't really see why it would want to load a filter mod directly or why the bashed patch would try to do the same if the mod isn't even there for it to have pulled in data from.

The problem is that when you load TES4View for bug-checking, it only pre-checks the mods in your active list.

In order to load all your mods to check overrides, you have to right-click and choose "load all".

But then that selects the Filtered mods as well, so you have to unselect them. So far, that's only three for me. One more with the mod delayer.

I expect that number to increase, though, since the filter thing seems to be quite useful.

Another couple minor bugs to keep in mind, since ElminsterEU is still absent.

In LAND records, TES4Edit is treating the height data as unsigned when it should be signed. I.E. it displays a value as "254" when it should be "-2". This won't break anything since TES4Edit doesn't do anything automated with LAND records, but if anyone happens to edit a LAND record by hand ( :shocking: ), they'll need to convert unsigned to signed on their own.

Also, the color data is mislabeled. "X" to "Red", "Y" to "Green", "Z" to "Blue"

And there's a small typo as well "Vertext Height Map" to "Vertex Height Map"

I rather doubt anyone is adjusting LAND records by hand, but this is a heads-up just in case.

Well I've done a bit of tinkering with LAND records by hand but I've never tried to use it for anything more than returning sections to vanilla values to manually address tears along edges. Usually runs into trouble though if there's an offset value. I can't imagine this being a true substitute for normal landscaping work.

Really, for TES4Edit to be useful when editing LAND records, it needs to display the actual heights and not the offsets. The http://www.uesp.net/wiki/Tes4Mod:Mod_File_Format/LAND#VHGT_subrecord_.281096_bytes.29 isn't too difficult:

To find the actual height of any point in a cell with coordinates (pointX,pointY) (untested):

landHeight = 0.0f;for(unsigned int curRow = 0; curRow <= pointY; ++curRow)    landHeight += (VHGT[0][curRow] * 8.0f);for(unsigned int curColumn = 1; curColumn <= pointX; ++curColumn)    landHeight += (VHGT[curColumn][pointY] * 8.0f);return landHeight;

Adding this stuff to CBash atm, though even it would be impractical to use manually since it won't have a GUI.

I've forgotten...is it safe to copy Scripts, like say copying a Stage from a Quest entry containing a script, from one mod to another?

I would assume so. That should make the mod the script is copied into dependent on the mod that the script is copied from. I guess if TES4Edit does not alert you that a master is being added, you should add it yourself so that all of the script's references are valid. The other option is TESCS...

Yes, it's safe. If you edit the script in TES4Edit, you'll need to launch the CS and recompile it. If a script is actually dependant on unique items in its own ESP, when you try to copy it you will be asked to add mod A as a master to mod B. Choosing not to will abort the copy. If it doesn't ask, then there's no dependencies to worry about.

how do you get the editor id of a placed object?

I got the form ID from the console. I found the formid in tes4edit, but it has no editor id, its blank and I cant reference the object without it.

the placed object is a piece of armor.

If it's blank, then it doesn't have one. You'll need to give the object an Editor ID yourself before referencing it in a script.