On Nov 9, 2007 2:30 PM, David Gowers <[EMAIL PROTECTED]> wrote: > The attached doctest (most easily runnable with 'nosetest enemy.txt' > (http://somethingaboutorange.com/mrl/projects/nose/), and requiring > PyYAML (http://pyyaml.org/)) provides a complete textual > representation of all parts of enemy .DT1 data (and also the facility > to translate it back into binary). I wrote it as a doctest mainly > because that makes it really easy to find mistakes. > > Here is an example representation, taken from enemy.txt: > > appearance: {palette: default, picture: small-0} > attacks: > alone: [] > counter: [] > desperation: [] > regular: [3] > bitsets: absorbsel6 entype6 > extradata: > - [30, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, > 0, 0, 0, 0, 0] > - [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] > name: Plip > rewards: > exp: 3 > gp: 4 > item: > - {30: 50} > - {14: 1} > spawn: {alone: null, death: null, elem1hit: null, elem2hit: null, > elem3hit: null, > elem4hit: null, elem5hit: null, elem6hit: null, elem7hit: null, > elem8hit: null, > nonelemdeath: null, nonelemhit: null, number: 0} > stats: {acc: 50, ctr: 0, def: 3, dod: 40, hp: 25, mag: 0, mp: 0, mp~: > 0, spd: 16, > str: 7, wil: 0, xhits: 0} > stealability: once > stealinfo: > - {30: 40} > - {0: 0} > > > NOTES: > * I have a few options as to the layout of the data in YAML format. > This is one of the more compact versions. > * I preserve the 'unused' values, for forward-compatibility.
If you want to be truely forward compatible, you would need to take into account the possibility of the binsize changing (and updating binsize.bin when importing? I don't know how it will work), does it? > * bitsets are a space-delimited string of enabled flags. > * Item name lookups (so items can be named instead of numbered) are > not implemented yet. > Reference by number will always be supported -- it's useful if you > wish to refer to an item you'll later create. So, would it print both the item number and name, and ignore the name when importing? Otherwise, renamed/unnamed/identically named items would be a problem. But that would be good. And the same for attacks, and spawns? > * Empty entries are removed from attack lists, so I am assuming that > order doesn't matter for attack lists. > * It's a bit liberal yet: Exporting to OHR binary doesn't auto-crop > lists such as 'stealinfo' and 'rewards/item' > (... UPDATE: Fixed.) > > * Bitset names are not finalized, I'd appreciate suggestions. Here is > the current list of bitset names in full: > > weaktoe1 weaktoel2 weaktoel3 weaktoel4 weaktoel5 weaktoel6 weaktoel7 weaktoel8 > strongtoe1 strongtoel2 strongtoel3 strongtoel4 strongtoel5 strongtoel6 > strongtoel7 strongtoel8 > absorbse1 absorbsel2 absorbsel3 absorbsel4 absorbsel5 absorbsel6 > absorbsel7 absorbsel8 > entype1 entype2 entype3 entype4 entype5 entype6 entype7 entype8 > uu0 uu1 uu2 uu3 uu4 uu5 uu6 uu7 uu8 uu9 uu10 uu11 uu12 uu13 uu14 uu15 > uu16 uu17 uu18 uu19 uu20 uu21 harmedbycure > mpidiot > boss > unescapable > diewoboss > fleenotdie > untargetablebyenemies > untargetablebyheroes > uu22 uu23 uu24 uu25 uu26 uu27 uu28 uu29 uu30 uu31 uu32 uu33 uu34 uu35 > uu36 uu37 uu38 uu39 > > I'd particularly appreciate suggestions on the first 4 sets > (entype/etype/??? weake1/weakel1/weaktoel1/???) etype and weakelmt ? > > If you want to run the test or fiddle with it, you should copy > wander.dt1 into the same directory as enemy.txt > _______________________________________________ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
