Data Structures by Dannii Willis is not in the 10.1 branch on github, so I suppose this means it hasn’t been updated. Which is too bad since I enjoyed using it in my last game, which was 9.3, and it would be an elegant solution to a problem I have with my WIP in 10.1.
Anyway, if someone is considering updating it, count this as my vote in favor. If not, well I’m planning to learn some I6 anyway.
I ran into a severe bug when trying to port it: Log in with Atlassian account (the compiler hangs with no indication why)
If you need Data Structures stick with 6M62.
Well, that’s a shame. I hate to stay with old versions, though, lest Inform v10 become the next Python 3. So I’ll probably hobble through with some inelegant solution. Oh, for composite keys in Inform tables!
Thanks!
I7 does a linear search through tables anyway, so you don’t lose anything by doing your own loop through the table looking for your multiple fields. That’d be a pain if you had to do it in multiple places, but you could do something like (untested):
To decide what number is for (index1 - a text) and (index2 - a number):
let i be 0;
repeat running through the table of hardcoded-name:
increment i;
if col1 entry is index1 and col2 entry is index2, decide on i;
decide on 0;
[then, within some rule or phrase... test for 0 before choosing the row if you're uncertain there will be a corresponding entry[
choose row for v1 and v2 from the table of hardcoded-name;
Choosing a row by row number doesn’t incur a second linear search. There isn’t a non-I6 way to get the row number, hence the manual index tracking above.
@OtisTDog wrote a multi-column table lookup I6 hack, but it’d be a little onerous in practice 'cause any routine that used it would have to have a separate choose row 'cause the compiler balks at use of entry if the routine doesn’t have a choose row. I suppose it could be modified to return a row number and this hack of mine would let you directly access column entries by row number. But my guess is that this wouldn’t even have appreciable speed advantage, so I wouldn’t actually recommend it.
Unfortunately, if you’re doing this with multiple tables, then, unless there are a huge number of them, your life would be easiest writing multiple routines that hardcode the various names.
Put a trailing newline in the neptune file, that seems to resolve the hang.
Thank you, but I hate that that was all it was.
There have been a few issues now with trailing line breaks that are showing Inform to be quite brittle.
Now I’m getting an internal error instead (unable to represent kind in inter). Not sure what the cause is…
Uh, if I’m reading this code correctly, then it looks like Inform now no longer allows for new constructor kinds??
This would mean Data Structures can’t be implemented as an extension/kit and must be built-in.
That’s good to know. I tend to get hung up on how I’d do things in the non-Inform world. Thanks!