I'll look into refactoring the "flee from object" command. Not sure how complex that will be. In the code, #object# allows you to use a generic variable for interacting with objects in a scene. And if you don't have #object# in the actual command, then you can't use that variable. Thus, if you have a lot of monsters, you would have to duplicate code every time for each monster. By using #object# it reduces code redundancy by a lot. I can understand that "flee" would be a simpler solution for the player, but may be several hours of refactoring for me. Plus, by the time the player gains their first character level, they should have acquired sufficient progression to take on their first Primal Chaos on floor 2. Thus, I've found in my own playtesting that I rarely flee, which is why I don't find the command all that wordy. However I will take a look into how much trouble it will be to refactor it.
It may be a bit silly sounding, but as you guys have pointed out in your feedback, players don't go looking for help most of the time and thus things must be forced into their face so that they don't miss it. For example, in the first release I had the command list in the game, and mentioned how players could get to it, but it seemed no one here found it. It was only after forcing the command list into view, by adding the "new player" prompt, that anyone was able to get into the game period. Granted, the first release did fail on many fronts, particularly guidance for the initial area, which I do apologize for. However, a few of the feedback I've received implies that they never read any of the gameplay tips I put in the game. I'd prefer that a player will go looking for help when they need it, but what seems like a simple and straight forward tactic of telling a player to type "display info" and then "commands" wasn't enough to get the command list to the player. So unfortunately, this prompt is a necessary evil.
I don't know what people wanted in the help screen. I can always change it based on feedback.
In the monster spawn code, there are 5 options: Quick, Tough, Spellcaster, Drainer, and Boss. If you aren't on the boss floor or the boss is dead, then it instead spawns a Drainer. So, drainers have a 40% chance of spawning on most floors, and 20% chance of spawning on a boss floor when the boss is alive. Primals cast spells, and thus they only drain XP if and only if they penetrate your spell resistance. So if you have high spell resistance or you kill the primal in one hit, then you can defeat a primal with ease.
That is an extremely weird edge case scenario. I've never encountered it. I'm not sure how you could have encountered it. It seems like the codebase is doing weird things lately, for unexplainable reasons. The way I have it setup in the code, the room that most of the action takes place in is entirely separate from the room that a player is in when they do character generation. And as I don't have anything in the entire codebase that allows you to get back to the character generation room, that I know of, debug control or otherwise, I'm not sure how you had this happen to you. As the character generation script is built directly into the room and thus isn't a free-floating script, I haven't the foggiest idea how this could have happened. Plus, in Quest, objects do not normally transfer to another room unless the programmer builds in this functionality. I'll post on the Quest forums to see if anyone has an idea of how this might happen.
Yes, noticed that one for the spider web. The print message was supposed to be set to "expression" but forgot to do so. Easy fix. Will be in the 3rd hotfix.
Thanks for the feedback!
EDIT: I posted a thread on their forum, you can take a look at it and give your opinions on their responses. Also added two weird cases of my own that I encountered. Link to that post =
http://textadventures.co.uk/forum/quest/topic/tyd_mwgm4es8qelorf3pxa/i-have-some-very-wierd-things-going-on-in-my-codebase-unexplainable-things-wtfEDIT2: The hotfix will have to wait until I get a response to the above thread. Until I know why my codebase is inexplicably failing, in improbable ways, that defies programming logic, I should probably wait on working on the code. Its possible that after enough complex syntax and logic, that the Quest Engine simply fails and then starts to produce unlikely logic that shouldn't be happening. But perhaps the people on the forum will know what is going on.