Hi TeeEmCee,

On Mon, May 14, 2012 at 3:37 PM, Ralph Versteegen <teeem...@gmail.com> wrote:
> I've been working on a crude nohrio program to import and export data
> (enemies, heroes, attacks, items, textboxes) to csv files. It's
> totally generic, working by inspecting the fields of the lump's dtype,
> but there weren't any other interesting lumps to handle (aside from
> shop items, but nohrio can't memmap .stf directly because of the odd
> length).

I think that must be a Windows-only constraint. I can memmap with any
offset and any length.

>
> What I learnt is that this is totally the wrong approach, and it needs
> to be rewritten. You really need to write lump-specific code which
> knows how to handle things like enumerations, off-by-ones, arrays that
> are split into two pieces, and the like.

Yeah, that's what I decided. A more conventional record interface
implemented in Python, which uses ndarray subclassing to provide
enumeration, badstring, off-by-one, and split record handling. It
needs to address two distinct needs : arr.fieldname needs to
behave like `recarray`, but it should determine the subclass of the
returned array from the dtype metadata associated with the field.

To that end I started working on improving the datatype definitions
(we can store such additional info in the 'metadata' field of the
dtype object.). The format is compilable (ie. you can produce actual
dtypes with metadata attached from it, and vice versa), but incomplete
(off-by-one isn't handled. not sure if badstring is handled).

I thought I'd pushed this work, but no.. Well, that's remedied now.

> I think nohrio itself should
> know what's in a data field, rather than just the dtype. For example,
> I even had to recognise strings by their dtype. My eventual goal for
> nohrio is to do better, and wrap all lumps in classes (preferably
> ndarray subclasses) to cleanup the interface.
>
> So little of this code has any use, aside from the csv
> handling/escaping functions. However, just as I finished, I discovered
> that Python actually has a module for CSV files. That's to be
> expected, but I didn't even think to look.
>
> I did however fix several nohrio bugs and implement missing
> functionality, though.
>
> http://gitorious.org/~tmc/nohrio/tmc/commits/rpgbatch

Cool, I'll check that out when I have time.. Right now, I'm both sick
and caught up in moving.
_______________________________________________
Ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org

Reply via email to