Closed GoogleCodeExporter closed 9 years ago
Tried it in old FNVEdit 3.0.21 and it bugs too, look like a legacy error.
However if I copy DIAL records using deep copy everything look fine.
Why do you need to copy DIAL and INFO separately? Maybe I don't know something,
but it is better to copy everything and then remove what you don't need.
Original comment by zila...@gmail.com
on 10 Dec 2012 at 6:24
If a topic and it's info's are native only to plugin 2, then Deep copy is
available and it works fine to copy it to plugin 1. It just never occurred to
me to try Deep Copy with dialog because with older version of xEdit it would
just end up with assertion errors.
Also, it looks like if a topic is already in both plugins, then deep copy into
plugin 1 is not available. But then the bug seems to only only occur if Plugin
1 has no INFOs and you are copying a new INFO from plugin 2 into plugin 1.
So the work-around would be:
In the GECK, don't add topics to quests without giving them at least one INFO.
Deep copy Topics with their INFOs if the topic doesn't exist in the target.
Just copy if adding new INFOs to a topic that is already in the target.
If the target already has the topic, but no INFOs, delete it so you can do a
deep copy.
Original comment by rickerhk...@gmail.com
on 10 Dec 2012 at 11:37
You've just blown mt brain with this description, but I'm happy that there is a
workaround.
But not sure that I'll be able to fix it any time soon.
Original comment by zila...@gmail.com
on 11 Dec 2012 at 6:04
No rush. Thanks for all you're doing with this program.
Original comment by rickerhk...@gmail.com
on 11 Dec 2012 at 12:15
The exact cause is that xxEdit requires the GRUP for INFO to exactly follow the
DIAL Record to properly display. When you add more than one dial first, then
the INFO(s) the saved order was wrong like (DIAL DIAL GRUP INFO INFO GRUP INFO)
rather tha (DIAL GRUP INFO INFO GRUP INFO). I added an override to AddElement
for GroupRecord that InsertElement the GRUP after the DIAL rather than adding
at the end.
Should be corrected as part of r1069.
Original comment by HuguesLe...@gmail.com
on 31 Dec 2012 at 9:22
Status update
Original comment by HuguesLe...@gmail.com
on 14 Jan 2013 at 12:20
Corrected with 3.0.28
Original comment by HuguesLe...@gmail.com
on 9 Feb 2013 at 6:49
Original issue reported on code.google.com by
rickerhk...@gmail.com
on 7 Dec 2012 at 3:38Attachments: