Community
SCI Programming => SCI Development Tools => Topic started by: gumby on December 15, 2010, 07:39:15 PM
-
Okay, it's on. I've scrapped my current tool (which generates all possible permutations of a user inputted string into said() statements) and I've moved on.
My current endeavor is to accept a 'user input' string, like 'drop the scepter off the cliff'. The application would look up all the inputted words in the vocabulary to determine parts of speech, then run them through the rules located in the 'black box'... and out will pop the appropriate Said() string, ready for you to plug into the code for your game.
It will also support 'batch processing', accepting input from a file, so you can load up multiple user input strings in there.
-
That sounds like a real time and drudgery saving tool.
-
Update:
I've got the user-input parsing working properly & generating a parse tree. But, I just hit a speedbump - and I should have seen it sooner. The process described in the documentation is this:
1. Parse the user input string (example: 'take troll to game')
2. Parse the said string (example: take<to/troll/game )
3. Match the user input parse tree to the said string parse tree.
Which is all fine. However, a user input string can match multiple said strings (I wish I had some examples here, but I certainly saw it with my work on generating all possible permutations of said strings). And I'm not just referring to 'optional' words - like in this case 'to', or adjectives. The documentation is based on having some said() string that is being evaluated for a match to a particular user input - something I do not have & am trying to generate.
EDIT: I may be wrong about this. Perhaps I need to walk my semantically parsed input string through the said() parse tree...
I can probably plow ahead & come up with something that works properly, but my approach may have to change.
-
I've totally re-thought this. I will retain the parsing of the input string to validate that we are not wasting our time attempting to build something invalid, but I'm going to assemble the said() without using the said spec.
I think I can do it with just a few rules:
Steps:
1. Dissect user input into parts of speech.
2. Collapse consecutive nouns & adjectives - last noun leads. Subject or subject & suffix if we have 2 sets of noun/adj sets.
3. Pair adverbs & prepositions with the verb - verb leads. Predicate part. Preposition indicates a (possible) split between subject & suffix.
Additional conditions:
1. If multiple parts of speech are defined for a word, we need to set an order of precedence & resolve it to a single part of speech
2. If specified, articles can be discarded?
Precedence:
1. Nouns take precedence over prepositions (as in 'of')
2. Verbs take precedence over nouns (maybe only if there are no other verbs specified in input?)
Examples:
1. 'quickly play short game of checkers again' => adverb/verb/adj/noun/noun/noun/adverb (note that 'of' is being treated as noun)
2 Subject = checkers < short < game < of
3. Predicate = play < quickly < again
4. Assemble: Predicate/Subject = play < quickly < again / checkers < short < game < of
1. 'give food to dog' => verb/noun/prep/noun
2a. Subject = food
2b. Suffix = dog
3. Predicate = give < to
4. Assemble: Predicate/Subject/Suffix = give < to / food / dog
-
Rule update: an article also acts like a preposition in step 3. It will separate a subject from a suffix.
-
Another rule: The first imperative verb found is the only one allowed in the input. Any other imp. verb found must be a different word class.
-
Here it is. It's (once again) a Perl script, which I've also compiled into an executable. I've tested this against variations of from the 'comprehensive said() string examples' in our how-to against a stock vocab file from a template game.
Oh, I made one change to the 'stock vocab' file - made 'of' a noun (as well as a preposition). The vocab file I used for developing/testing is also included.
It's all 'batch process' oriented - I didn't think that it made sense to allow for interactive input of user strings. Input is provided from 'userInputs.txt' file - I've included the sample I was testing against as well. The output is to screen & to a file 'saidStrings.txt'.
The application also verifies that the input string can be successfully parsed by the vocab.900 (the 'black box') and that all words are in the vocabulary before attempting to generate a Said() string.
I'm sure there are some 'valid' user inputs that this tool cannot handle (especially regarding words that have multiple word classes & the 'special' word classes). I'd appreciate feedback (and additional testing)!
http://www.mediafire.com/?4zpnyy3f7gai3qu
Hopefully we can get this hosted here & in our wiki?
EDIT: Ha, the compilation process failed to include a dependency, so I've fixed it and now it's hosted on our wiki: http://www.sierrahelp.com/SCI/Wiki/index.php?title=SCI_Resource_Utilities#Gumby.27s_SCI_Tools
-
Nice! I'll try and find time in the next few weeks to put some practice on this baby.
-
I could create an FTP account on SHP for you to upload all of the tools you are working on and then you can make a page for them on the Wiki's Tools section and link to them.
-
I could create an FTP account on SHP for you to upload all of the tools you are working on and then you can make a page for them on the Wiki's Tools section and link to them.
Sure, I don't mind doing the uploading & linking into the Wiki. Let me know & I'll go to town.
-
Login and link info in a PM to you on SHP.
-
Made another update to the application. Now word suffixes are supported. I've re-uploaded it to the wiki.
-
If all of the links go to your folder, you can maintain it yourself.
-
If all of the links go to your folder, you can maintain it yourself.
Yeah, I think you might have skimmed my last post. I was able to re-upload it to the wiki,..
-
No, I caught that. I was more or less just "thinking aloud" because that is not where I would keep it if I were maintaining it.
-
Gotcha.