SaveScum / skyrim-plugin-decoding-project

Automatically exported from code.google.com/p/skyrim-plugin-decoding-project
0 stars 0 forks source link

Hardcoded FormIDs prevent changing of referenced records. #77

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Open the main file (FalloutNV.esm)
2. Open Voice Type and right click on Record xx00002D
3. Select Change Referencing Records, type in xx016312
4. Select any number of the records and hit okay.

What is the expected output?
XX number of records changed from xx00002D to xx016312

What do you see instead?
0 records changed from xx00002D to xx016312

What version of the product are you using? On what operating system?
FNVEdit 3.0.22

Please provide any additional information below.
Using the Change Referencing Records works on everything except any records 
that are considered Hardcoded in the Game Engine, such as xx00002D. I don't 
know why that restriction was put in there, but it makes it hard to change 
large numbers of records easily.

Original issue reported on code.google.com by harkness...@yahoo.com on 30 Oct 2012 at 1:30

GoogleCodeExporter commented 9 years ago
Here is the test file. It has both the hardcoded and the non-hardcoded voice 
type records, along with an NPC that uses this record for testing.

Original comment by harkness...@yahoo.com on 30 Oct 2012 at 1:33

Attachments:

GoogleCodeExporter commented 9 years ago
There is a hardcoded check in xEdit if OldFormID<$800 to not do anything.
I don't know why Elminster put it there, but I guess it is there for a reason. 
Have any ideas?

Original comment by zila...@gmail.com on 30 Oct 2012 at 3:45

GoogleCodeExporter commented 9 years ago
My only thought is that he put it there to prevent inexperienced users from 
royally breaking their games. But in my experience changing the referencing 
records for hardcoded records has about as much room for error as normal 
records do. The check on the hardcoded records is a sound one, but it shouldn't 
be restricting the ability to change a records referencing records, only the 
ability to create new records under that xx000800 mark. It's easier to break 
the game by making a record that is under that mark than it is to change 
referencing records of a hardcoded record or editing the record.

Original comment by harkness...@yahoo.com on 31 Oct 2012 at 9:16

GoogleCodeExporter commented 9 years ago
Thet problem is, that check for less than 800h is used about 15 times through 
all the source code. If I am going to allow change reference for them I'll need 
to overcome that limitation almost everythere, and that can lead to 
unpredictable results.
I asked Elminster about it and waiting for reply.

Original comment by zila...@gmail.com on 31 Oct 2012 at 12:05

GoogleCodeExporter commented 9 years ago
This has a valid reason AFAIK. There is code into the game engine that will 
treat FormID below xx00080 as reserved (and this is done using bitmask filters 
thet does'nt check the plugin ID). In fact it should NOT be possible for the 
GECK/CK to create ID's in this range, so anything with xx different than 00 is 
"non standard".

So: FormID below 00000800 should absolutly be left alone. Other FormID like 
xx000800 should be reported as Errors. Obviously, correcting the error requires 
allowing changing them.

Original comment by HuguesLe...@gmail.com on 31 Dec 2012 at 9:37

GoogleCodeExporter commented 9 years ago
I have run into this as well. I agree, creating NEW records whose FormID is 
<=800 should be discouraged if not completely unallowed. Changing referencing 
records, on the other hand, I can verify causes no issues (I did it, by hand, 
for voice files with ID <= 800). Even changing the FormID of a record <=800 to 
a new ID >800 has no ill effects.

Original comment by Friel.Kr...@gmail.com on 13 Jan 2013 at 12:25

GoogleCodeExporter commented 9 years ago
I have had the same results as above myself. I can concur that changing 
referencing records and changing the base record's form Id have caused no 
problems for me.

Original comment by kyleco...@gmail.com on 14 Jan 2013 at 11:34

GoogleCodeExporter commented 9 years ago
Are you explicitly trying to change those record, or they just "happen to be in 
the way" of a larger selection of records to change ?

Original comment by HuguesLe...@gmail.com on 14 Jan 2013 at 9:24

GoogleCodeExporter commented 9 years ago
I'm trying to change records that reference one of the protected hardcoded 
records, such as an NPC referencing one of the hardcoded voice type records. 
Using the Change Referencing Records on any of the hardcoded records does not 
actually make any of the changes to the referenced records, it simply fails 
silently. It makes no sense to block them from that function since the actual 
hardcoded records aren't modified, only records using that hardcoded record.

It makes sense to block changing the FormID on those hardcoded records because 
the game requires them to have that specific FormID to be read. However, most 
of the hardcoded records found in the master file are built into the engine 
code, meaning you can change some of them and have no critical issues - but 
this is NOT recommended. It also makes sense to block creating records under 
that magickal 800 mark in case the game uses one of those FormIDs to define a 
specific record. Making a record under that mark can potentially break that 
engine coded record by overwriting it with a record of another type.

Original comment by harkness...@yahoo.com on 14 Jan 2013 at 11:06

GoogleCodeExporter commented 9 years ago
I am a lead designer for TTW (www.taleoftwowastelands.com) and I am trying to 
write a script that can dynamically update Fallout 3 mods to work with TTW. 
This requires changing the formID of a lot of different forms, two of which are 
the default male and female voice types ( MaleAdult01Default [VTYP:0000002D] 
and FemaleAdult01Default [VTYP:0000002E] )

Original comment by kyleco...@gmail.com on 14 Jan 2013 at 11:18

GoogleCodeExporter commented 9 years ago
You are all lucky as only one of the checks pertained to CompareExchangeFormID

Original comment by HuguesLe...@gmail.com on 15 Jan 2013 at 12:25

GoogleCodeExporter commented 9 years ago
Fixed in 3.0.28

Original comment by HuguesLe...@gmail.com on 9 Feb 2013 at 6:52