inform6unix version 6.42 Release 3 which updates PunyInform to version 5.5.1 is now available at 661.org now and at the IF Archive soon.
6 Likes
PunyInform v5.5.2 is out:
- UnknownVerb entry point wasn’t always called when it should
- AfterLife entry point was sometimes called when it shouldn’t
- pronoun/pronouns grammar failed on z3 with newer compiler versions, fixed now
- Cheap scenery extension is once again compatible with the standard library (it was from the start, but this broke a long time ago without us noticing)
- runtests.rb can now take an optional compiler path argument
- Minor optimizations
Upgrading from v5.5.1 is dead simple and there’s nothing to look out for.
8 Likes
The inform6unix package has been updated with PunyInform 5.5.2. Get it from the usual places.
7 Likes
PunyInform v5.6 is out!
- Important bug fix: Transfer action, Empty action and Remove action will now fire before routines and after routines for the ##Take action, so the player can’t bypass rules meant to stop them from picking up objects by using e.g. “transfer object to me”
- New routines to easily figure out the effective values of door_to and door_dir, even for simple doors:
DoorTo(obj),DoorDir(obj) - New globals to say what the action input by the player was: input_action, input_noun, input_second, input_direction. This makes it easy to check if the current action was explicitly requested by the player or if it’s code causing it to happen, such as
<<Push RedButton>>; - action_to_be is now set to -1 when the parser fires the action, so you can tell if your code is called during parsing or not
- The manual has been rearranged and cleaned up a bit
- Some other important bug fixes
Upgrading should be easy, but do have a look at the release notes first.
4 Likes
I think we got too overzealous over the MOVE BALL TO BAG versus MOVE BALL TO ME. According to the DM4 (pg 89) a take should not be generated if the thing is moved from, say, a table to a suitcase. But it’s silent whether this should be the case for MOVE BALL TO ME. Clearly we’re safe calling that a synonym for TAKE BALL. But I think we should both roll back adding a ##Take to all normal transfer actions (not transferring to the PC).
See discussion at Should MOVE BALL TO BAG trigger a Take as well as Transfer?
It doesn’t say that.
It does say that, and, up through library 6/11, it behaves like that.
> transfer rock to chest
[ Action Transfer with noun 113737 (rock) and second 113705 (chest) ]
[Moving rock to yourself]
[ Action Insert with noun 113737 (rock) and second 113705 (chest) (from < > statement) ]
[Moving rock to chest]
You put the rock into the chest.
But I agree with the argument (in the other thread) that this is a design problem and should be fixed.
EDIT: The DM4 statement is about “the object entering the player’s posession”, so the above example is not to the point. Rather, this example:
>remove rock from chest
[ Action Remove with noun 113737 (rock) and second 113705 (chest) ]
[Moving rock to yourself]
Removed.
[Giving rock moved]
1 Like
If we’re talking about the same sentence in DM4, it says that capturing Take and Remove is sufficient to stop an object from entering the player’s possessions. There’s no logical path from this statement to the statement that Transfer shouldn’t issue a Take action.
(Sorry for the multiple edits above. I think I’m saying the right thing now!)
The point of the statement is that you need to block Remove because the action doesn’t generate a Take statement. If we change the library so that it does generate a Take statement, the statement will be misleading. Technically not false, but bad documentation!
3 Likes
Because of that walking into bad documentation is why I don’t want to make those changes in the Standard Library and why I think it shouldn’t be in PunyInform - at least without properly documenting the changes. DM5 would be ideal place to do it, but that’s a long way off. Instead, how about an ongoing official supplement that lists deviations from DM4?
1 Like
That document (Inform 6 Reference Addendum) only covers the Inform 6 language – I6 syntax and compiler use. It does not address the library, because I don’t keep up on library updates.
The library addendum would have to be a separate document. Feel free to start writing that! :)
Or we could do it as a new section of the existing Addendum document, if you’re willing to write it and submit it as a PR on the Git repo.
2 Likes
Ah, I finally think I understand what you’re saying here and why. You think we’re talking about changing so “remove rock from bag” will generate a ##Take action. That’s not correct.
“remove rock from bag” generates a ##Remove action only. That’s okay, well documented, and nothing we’ve discussed changing. (Maybe it would be a good idea to have RemoveSub issue a ##Take action, but that’s another discussion)
“move rock to bag” on the other hand, generates a ##Transfer action. This is the case we’re talking about.
What ##Transfer currently does is:
1: Check that it seems like it should be able to pick up noun, and to place noun in/on second (e.g check that noun isn’t in a closed container, and that second is a supporter or an open container)
2: Move noun to player
3: Try to use ##Insert or ##PutOn to place noun in second
Since no ##Take or ##Remove action has been performed, it bypasses rules put in place by the game author to stop the player from picking up noun. If step 3 fails, noun stays in the player’s inventory.
The author can block the action by capturing the ##Transfer action, but DM4 is clear that it should be enough to block ##Take and ##Remove to make sure an object doesn’t enter the player’s possession. For this reason, I think ##Transfer should issue a ##Take action to pick up noun.
See example at Should MOVE BALL TO BAG trigger a Take as well as Transfer? - #5 by fredrik
(Sorry for the multiple edits. I think I’m done now)
3 Likes
I am talking about both the REMOVE X and MOVE X TO Y cases, which have similar booby-traps for game authors.
I would probably agree to having both ##Remove and ##Transfer issue a ##Take action.
I’m just really confused by this discussion. Seems like we’re all shooting at different targets.
I think the recent change in PunyInform - having the ##Transfer action issue a ##Take action - addresses the most serious issue, which is that ##Transfer can otherwise be used to move an object into the player’s possession, without issuing either a ##Take or a ##Remove action. I have not been convinced that this change should be rolled back.
Having ##Remove issue a ##Take action as well seems like a good idea.
If we go with both, game authors can typically just react to ##Take for objects that the player shouldn’t be able to pick up.
2 Likes
PunyInform v5.7 is out!
- Parser can now handle “take two coins”
- The ParseToken routine can now return GPR_NOUN, GPR_HELD, GPR_MULTI* and GPR_CREATURE and these are handled correctly by the parser.
- Using plurals where there’s a held token to be matched in the grammar, e.g. “give the books to Mandy”, will now give a sensible message.
7 Likes
PunyInform v5.8 is out!
- Messages after containers in lists have been changed (in our opinion even improved)
- Flags extension routines can now be called with negative flag numbers to get the inverse of the check or setting, e.g.
FlagIsSet(F1,-F2)returns true if F1 is set and F2 is clear. - Bug fixes.
Upgrading from v5.7 requires no special attention.
5 Likes
How does this affect existing invent routines?
Good question. The specification of how an invent routine works hasn’t changed. If you print something in your invent routine and then return true (meaning that the library should not print anything more for that object), it will work just the same as before. However, it may happen that you have adapted short_name, or you print something in invent when inventory_stage==2 which says something about whether the object is open or closed and then return false, and this will now be printed by the library as well, e.g. you may get
You are carrying a closed jar (which is closed and empty).
Exactly what is printed after a container is governed by whether it is:
- open
- openable
- transparent
- empty
So basically there are 16 cases, and I don’t have a list of exactly which of these cases have changed. Actually, the routine used to care about whether it’s a wide or tall list as well, but we changed that in this release.
If you have a transparent container, I know there were cases where the library would not say whether it was open or closed, but now it always does.
1 Like
Sorry about being out of it. The inform6unix package is now updated for PunyInform 5.8.
3 Likes