My impulse at present is to just get a creature-editor working the way I want, then either expand it or start from scratch and re-implement its functionality : the endgoal of CSE (critter stats editor) isn’t simply to edit UTCs – it’s to display accurate lists of what the values mean while editing UTCs … (similar to Yata Paths for crafting/spells.2da files, but for UTC files). The GFF stucture was totally new to me a week ago and just getting it to parse out was a bit … frustrating … so, will keep this in mind but, practically, if and when i get a file to write out correctly I’ll just want to relax and cook a hotdog.Īlso I think you should provide at least minimal support for editing other types of blueprints (basic field editing should be enough for most cases), so people don’t have to switch between different tools. That might be a bit much for me at present.
Though I don’t think many people use diff tools (this one is git diff) on their projects, so probably you’d better ignore this if it takes too much work. gff field order, string order, …) so that I can quickly see what fields have been changed between two versions of the UTC file, like this: One feature I’d like to see is that you editor keeps the gff file structure as generated by the toolset (i.e. yeah i’ve done enough c#/.net programming to have a grip on basically keeping things compatible w/ Linux and Mono Looks promising, and it seems to works well on Linux too * read: if a GFF-editor truncates nwn2-style (32-char) resrefs to nwn1-style (16-char), it’s because the programmer of the editor designed it so said truncation is not a characteristic of the GFF spec itself.
#Wxhexeditor switch to little endian code#
Ie, will try to keep the code adaptable to the general GFF spec.
In fact, the GFF-spec itself doesn’t limit the length of CResRef fields* … so i’ll probably end up issuing a warning instead of an error if the length of the string exceeds 16/32 chars.
It will support Nwn2’s 32-char CResRef field. i intend it to provide hints etc during editing, so we/you/me doesn’t have to go hunting through 2da files for what the assorted values translate to … It won’t will be a generic GFF editor, although it’s primary purpose is to edit UTC blueprints. So am presently sinking my time into GeneralGFF (github c#). I also wanted to get a grip on the GFF specification.
#Wxhexeditor switch to little endian 64 Bit#
when looking at the hexadecimal representation).īeware that any number larger than that fits in a register should be handled correctly by the application for instance the code for handling 128 bits do not just have to worry about the order of the bytes, but also of the 2 x 64 bit words.I got a bit too fedup with the vagaries of creature-stats (blueprint) editing in the Electron toolset. Although instructions such as rev generally do not reverse the bits within a byte you can assume that the bit order is fixed (when debugging the bits in bytes are generally shown as big endian, e.g. The rev instruction reverses the bytes in a word. If you are going to do functions to load single fields from memory then just use little-endian loads and use the "rev" instruction to reverse the result - it's only one additional instruction and much faster (and small enough to be inlined so you avoid the function overhead too). Let me quote Peter Harris, a Mali GPU distinguished engineer at Arm: In ARM it seems that this instruction is called the rev instruction. That's of course generally true of any Turing complete computer, but in general CPU's have instructions to reverse the data within words. The reason for that is simple: anything you can do in one mode, you can also do in the other. No processor needs to be run in big or little endianness.
0 kommentar(er)
