Quick status update before I start work. The bugs alluded to above relate to something triggering add_to_scope to stop working causing child objects to detach/disappear. This will make the game unfinishable. Neither the person reporting the issue nor I have been able to figure out the steps to trigger this, so I’m basically stumped in terms of diagnosing this. Reportedly toggling a light source on and off cures the issue, although it is far from clear why from reading the code, but the assumption is that it’s my variable light level extension which is at fault. So my options are:
Abandon the project. I’ve spent a lot of time on this already and there doesn’t seem to be a lot of interest in the game. I’m aware that the game isn’t very well designed and isn’t up to modern IF standards.
Rewrite the game without the variable light extension. That’s a lot of work and as I can’t recreate the problem, it might not be the root cause. It will change a few aspects of the game play, but nothing substantial. I can fudge the one case where it matters. I’m unlikely to do that until I get some time off work.
Property “add_to_scope” is aliased to “in_to” in #PunyInform and I have one use of the latter in the game, so perhaps that’s an issue.
I guess I’m asking if anyone out there really cares if the game gets finished or abandoned?
Please don’t abandon it. I downloaded it a while back and thought it looked good. Admittedly, I haven’t played it yet, as I have too many other things on my plate. I’m happy to help with play testing or troubleshooting, although @fredrik is better at the latter.
This is solvable, no doubt. I’d be happy to help you debug it. (Thanks @Warrigal for bringing this to my attention!)
Only locations can have in_to and only non-locations can have add_to_scope. That’s why they should work as aliases without problems.
If you’ve defined OPTIONAL_MANUAL_REACTIVE, you need to give objects that have add_to_scope the reactive attribute (see Manual · johanberntsson/PunyInform Wiki · GitHub ), but if that’s your problem, it wouldn’t be fixable by enabling a light source anyway.
If your main object becomes invisible due to some mechanism in your variable light extension, I’d expect its add_to_scope routine won’t be considered either.
You can use the “scope” verb in debug mode to see what’s in scope at any time.
Do you use OPTIONAL_MANUAL_SCOPE? If you do, you need to set scope_modified = true whenever you’ve done something in code which may affect what’s in scope. A failure to do so could look just like this. When the player turns on a lamp, the library sets scope_modified = true so scope is recalculated.
You could DM me if you want me to have a look at the source or discuss this further.
@Warrigal@fredrik Thank you both for the input. I’m doing everything on your list of suggestions @fredrik but unfortunately only the player is experiencing the issue but hasn’t been able recreate it in a deterministic manner. I’m not seeing it at all and that’s the big stumbling block.
Yes, I’m using both and scope_modified = true has been added wherever it seemed appropriate. I’ve also used DEBUG REACTIVE to check which objects need the reactive attribute.
Perhaps I’ll remove both and accept the performance hit to see if that helps.
I suspect my only realistic chance of debugging this is if I can either get a transcript showing the steps used from the start of the game, or just randomly try things myself to try to trigger the behaviour, which may take a very long time.
I was sent a command recording and transcript privately which was super helpful. I was able to use this to trigger the issue with all the debugging and error reporting turned on. It turns out the MAX_SCOPE limit was being hit which I must have been close to in my testing, but wasn’t hitting because knowing the game, I was discarding objects once I no longer needed them. Upping MAX_SCOPE to 64 (I hadn’t realised that changing this is a reasonable thing to do) resolves the problem. Value of 64 chosen at random for now.
I have other things to check & fix, but hope to have a new build ready at the weekend. I guess it would be better to make this available privately to anyone willing to test it. Sorry, I’m new here and don’t know the ettiquette/requirements for play testing, so any advice on how to proceed and what to provide would be appreciated.
We wrote a document called Game Author’s Guide which lists a number of things you may want to consider when you’re getting close to releasing a PunyInform game. It’s available in the PunyInform distribution or online: PunyInform/documentation at master · johanberntsson/PunyInform · GitHub . Among other things, it mentions the scope limit.
Thank you. Amongst other things, I plan to read ALL the PunyInform documentation again over the next few evenings. Clearly I have forgotten many things since I first read it.
Just go the the Beta testing category and create a new thread asking for beta testers. Perhaps give a very brief synopsis, the style of the game (parser-based in this case) and anything needed to play the game (a z-code interpreter in this case).
If you want them to check anything in particular, then mention that. Then ask them to send you a personal message, if interested, to get the download link and password, or you can probably insert the zipped game as an attachment, depending on your access level.
I have to admit that I did not encounter serious bugs when I played it. But I played a fairly earlier version and just used the later version to provide screenshots for the test itself in ZZAP. In that context the review actually is a very positive one.
@8bit_era Thank you for taking the time to play my game. Whether you see the bugs will very much depend on how you play the game. In my walkthrough script I wasn’t seeing the bugs either, but of course I know the “correct” order to do things in and also when I can discard redundant objects. Broadly speaking, if the version you played contained a bottle jack then it has bugs, the most serious of which is that you can skip a couple of the major elements of the critical path and still complete the game. The error was obvious once someone else pointed it out and that’s what I’m currently struggling with in terms of “story”. Yes it’s trivial to fix, but I’ve yet to come up with a decent reason / plot point to explain the fix. Sure, I could revert to a much earlier version without those elements, but that version felt rather empty to me (too many locations where nothing much happened).
I’ve just uploaded beta 17 to StarDot as usual. I’ve always made the beta versions publicly available like this, so anyone who is interested can have a go. Hopefully this fixes the bugs and reported design issues (or at least most of them, there was one suggestion I chose not to implement). I’ve tried to fix the missing out large chunks of the game but still being able to trigger the endgame and get the maximum score in a way which doesn’t significantly change the game play from the disaster that was release 1.
As noted on StarDot, I have left runtime errors enabled for this beta release. When the MAX_SCOPE issue was triggered in release 1, it occurred silently, which made debugging awkward. At least this way any similar errors will be visible.