Everything about development and the OpenMW source code.
- Site Admin
- Posts: 1193
- Joined: 05 Aug 2011, 22:21
- Location: Wroclaw, Poland
- Github profile: https://github.com/lgromanowski
This topic is about the bug:
I think i've found out something interesting.
The hex of the record of the references that fail is 0x4C414944 and spells LAID in ASCII. Since record names seem to be inreverse the real name of the rec is DIAL which is a Dialog topic according to a esm format documentation.
REC_DIAL is implemented but isn't checked in loadRefs.
So these references aren't for npcs but for dialogs with the names of these npcs.
Since record names seem to be inreverse the real name of the rec
Actually, that is purely a question of endianess. (just a side note)
With loadRefs you mean the function in the cell store class? It is not supposed to load dialogue records. It isn't supposed to load any top-level records at all. Only references.
My interpretation of your find is, that the end of a cell record isn't identified correctly. The record loader thinks it is still reading the cell record, while it actually has started reading the the beginning of a following dialogue record.
Any progress on this? With your findings it seems this task is a lot more important than I originally thought and it would be really helpful to get it out of the way soon.
Sorry i haven't worked much on this. I still have to learn alot about how the parser works and how everything interacts.
It would be nice if you could tell me an easy way to access what is processed as raw binary so i can write it to a file and check where too much is parsed.
I've tried looking into the esm, but sadly i don't have a really good hex editor and it's too big and complicated to search in it.
Btw i'm making good progress with the C++ book and it's really good
I would consider a Hex Editor the best option. But you can also look into our esm tool (apps/esmtool/). Might require some code modifications.
I think i've made some progress althought it's just a speculation.
It seems like all affected NPCS have a Dialog with their Name and somehow the reference to the dialog and not the reference of the npc is found.
I don't know much about how all the loading stuff works, but it seems like the position of the definition in the esm of the object, npc, etc. which is referenced in the cell is important. All the npc definitions are at the top of the esm while all the dialogs are defined at the bottom.
I hope this makes atleast some sense since this is the only difference between the npcs that are loaded correctly and the ones which aren't that i could find so far.
That was the hint I needed. Some optimisation code that Nico added to esm_store/store.cpp was a bit too eager and added stuff to the search that should not have been found.
I pushed a workaround (storefix branch). There is more clean up to do in the esm store and we will have to look at the data structures at some point (there is already an issue on the tracker for the later), but that can wait until 1.0.0 or longer. For now we are good.
I'm glad it was this easy to fix
I'll see if i can find another task for me tomorrow.
Learning c++ and getting used to the structure of openmw is a higher priority thought so i'll probably take a task that doesn't need to be fixed soon.
We are currently short on task suitable for beginners, especially for C++ beginners.
I see only two semi beginner friendly tasks:
Mostly just moving stuff around, but requires a good understanding of the C++ class concept.
Requires a good understanding of STL containers and algorithms.
If you find something else that you think you can handle, we can discuss it.
Who is online
Users browsing this forum: No registered users and 2 guests