Problems with Bulk Limiter extension


I’m having trouble with Eric Eve’s excellent extension - it’s stopping my file from compiling and showing 6 “problems” within the extension.

All the problems revolve around the use of the word “sum” in the extension, eg (at line 26 in the extension)

I’ve used the extension before without any issues, but this is a fresh install (same version 6L38) on a new PC. I haven’t tampered with the extension so they are identical on the old and the new PCs.

Any thoughts appreciated.

I’m able to get a bare bones program using the extension to compile under 6L38:

Include Bulk Limiter by Eric Eve.

Start Room is a room.

This is with version 8 of Bulk Limiter and version 8 of Plurality installed.

Are you able to get the trivial program above to compile?

The latest version of the extension (9) doesn’t have that code at line 26 so you’re most likely using an outdated version. Download the latest from the Public Library tab.

I did not know that tab. Amazing! :mrgreen:

Thanks for replies.

Vince - trivial example also fails, both with version 8 and version 9.

Juhana - thanks for the tip re version 9 which I have now installed. Alas, the same problem, and the line in question does exist in both versions.

Any other ideas? Why should the trivial example in 6L38 work for Vince but not for me?

I’m not saying that the line doesn’t exist, but that it doesn’t exist at line number 26. If you have version 9 and the error message still points at line 26, it’s likely that something went wrong installing it and the compiler still tries to use an old version. Does the compiler show a different error if you specify the version number when including the extension? (“Include version 9 of Bulk Limiter by Eric Eve.”) If it finds an older version it should say it at this point ("…but my copy is only version X").

Thanks for another good tip - I didn’t know you could specify a particular version of an extension. It doesn’t fix my problem, though. Both versions 8 and 9 of the extension cause the problem described.

The six problems that emerge are identical in both versions.

Here is the text of v9 used during the failed compile:

I expect that this code is fine and the problem is elsewhere but I’m at a loss as to where that somewhere else might be.

It’s because, for example #1, you can not subtract “description of relations of values” from “total bulk of things carried by targetperson” (i.e. a number - a string).

Try something like this instead:

Understand "zonk [thing]" as zonking. Zonking is an action applying to one thing.
Carry out zonking something (called the target):
	let N be 0;
	let N be the total bulk of things carried by the target;
	say "Carried bulk: [N]".

…of course the above probably wouldn’t work for containers like chests because they “contain” things, not “carry” them (or “hold” them like people) so maybe use “contained by the target” instead of “carried by the target” if it’s just a container and not a person. Test the below on a chest containing several objects of various bulk for example and you’ll see what I mean.

Understand "zonk [thing]" as zonking. Zonking is an action applying to one thing.
Carry out zonking something (called the target):
	let N be 0;
	let N2 be 0;
	let N be the total bulk of things carried by the target;
	let N2 be the total bulk of things contained by the target;
	say "Carried bulk is: [N][line break]Contained bulk is: [N2]".

…So in the above example if you “zonk chest” and the chest is a container then it will always show “Carried bulk is: 0” (because containers don’t carry things, they contain them). So just be careful when trying to sum up bulk carried vs. contained. Also, I imagine “surface” objects like tables may have to be checked by “total bulk of things on the target” instead. This is the tradeoff using Inform 7 vs. other text adventure languages. Since it’s using English you have to be highly precise in cases like this.

There isn’t an attempt to subtract anything. (total bulk of the things carried by targetperson - description of relations of values) is something produced by the parser, to show that it’s trying to interpret the part of the code that says “total bulk of the things carried by targetperson” as a description of relations of values. And then the other three examples are the other attempts it makes to interpret it–the desired interpretation is #4, that “sum” should be a temporary named value and “total bulk of things carried by targetperson” should be interpreted as a value, namely, the total of the bulks of things carried by targetperson.

Yonder, have you looked in your code to see if you gave a different definitions to any of the terms that are getting used by the extension? Sometimes this kind of namespace clash produces error messages for the innocuous code in the extension, which makes it hard to trap down. Or, if it’s really failing to compile when you don’t have any other code, maybe you should search around your computer to see if you have any other copies of the extension in unexpected places–I had trouble once where I’d installed an outdated version of an extension in a place where Inform would grab it instead of the one I wanted.

Thanks for clarification. I think if the statements were more simplified there wouldn’t be problems.

Okay, tested out Bulk Limiter by Eric Eve a little bit…

"Bulk Tester" by Bill Chelonis

Include Version 9 of Bulk Limiter by Eric Eve

[Added this as Bulk Limiter version 9 by Eric Eve only handled person and container, not surface]
[NOTE: To avoid confusion for Tads 3 programmers working with Inform 7, in Tads 3 there is the "surface" kind - in Inform7 this is actually "supporter"]
To decide what number is the free capacity of (targetsupporter - a supporter):
  let sum be the total bulk of the things on the targetsupporter;
  now sum is the bulk capacity of the targetsupporter minus sum;
  decide on the sum.

[Below we define "bulk held" for person, container and supporter objects for one easy reference 
 vs. "carried by".... "contained by".... and"on"]

To decide what number is the bulk held of (targetperson - a person):
	let sum be the total bulk of things carried by targetperson;  
	decide on the sum.

To decide what number is the bulk held of (targetbox - a container):
	let sum be the total bulk of things contained by targetbox;
	decide on the sum.

To decide what number is the bulk held of (targetsurface - a supporter):
	let sum be the total bulk of things on the targetsurface;
	decide on the sum.

[This command is used to test the bulk held of objects or, lacking that, the bulk of the object itself]	
Understand "plover [thing]" as plovering. Plovering is an action applying to one thing.
Carry out plovering something (called the target):
	If the target is a person or the target is a container or the target is a supporter:
		say "The bulk [if the target is a person]carried by[else if the target is a container]inside[else if the target is a supporter]on top of[end if] [the target] is [the bulk held of the target].";
		say "The bulk of [the target] is [the bulk of the target]."

Understand "plover location" as plovering the place. Plovering the place is an action applying to nothing.
Carry out plovering the place:
	let N be the list of all things in the location of the player;
	let counter be 0;
	Repeat with N2 running through N:
		If N2 is a person or N2 is a container or N2 is a supporter:
			say "[N2] self bulk ([the bulk of N2])  + carried bulk ([the bulk held of N2]) = [the bulk of N2 plus the bulk held of N2][line break]";
			now counter is counter + (the bulk of N2 plus the bulk held of N2);
			say "[N2] bulk: [the bulk of N2][line break]";
			now counter is counter + (the bulk of N2);
	Say "The total bulk in [the location of the player] is: [counter]." 
The Treasure Room is a room. The description is "A dinky little alcove carved out of solid granite, dusted over by centuries of neglect. A [little black iron chest] sits in the corner beside [a large oak table]."

A little black iron chest is a fixed in place, openable, closed container in the Treasure Room. 
A large oak table is a supporter in the Treasure Room.

A coin is a kind of thing. 
100 coins are in the black iron chest.

On the large oak table is a golden apple and a blue crystal. A pirate hat is a wearable thing on the large oak table. 

Test me with "plover chest / plover table / open chest / get 100 coins / get coins / I /  get coin / get hat / plover me / drop 10 coins / get hat / get apple / get crystal / plover me / plover table / plover chest / put 90 coins on table / x table / put 10 coins on table / look / plover location". 

…Interesting of note that if, in the above example, you open chest and try “get 100” coins the parser replies “Only ninety-nine of those are available.” (When there are actually 100 in the chest). Not sure if this is a bug or not but after you try a subsequent “get coins” it gets 99, then you can “get coin” to get the last one. I think the parser must be interpreting 99 as plural separately from the 1 oddball coin in there as singular for some reason.

Hmm, the “Only 99 of those are available” error is newly restored to 6M62 after having been unreachable for a while. I wonder what happens in 6L38. I also wonder whether the issue isn’t simply that the parser doesn’t want to act on more than 99 things at once.

Well, the 6M62 app was being balky so I couldn’t try it out in 6M62, but in 6L38 when you try the following:

Test chamber is a room. A coin is a kind of things. 100 coins are in Test Chamber.

then “take 100 coins” gives “You can’t see any such thing,” and “drop 100 coins” (when you have them all) gives “You can’t use multiple objects with that verb” as per the bug report linked above. So I think it must just be that the parser is refusing to parse collections of objects of numbers greater than 99.

… which is why in Tatds 3 you will NOT see these kinds of bugs. Now you make an Iform 7 that is equal to a Tads 3 and then I will be convinced. So far… I’m not. Tads 3 is far, far better in my opinion for what it can do. Yet here, today, you see so many, many people trying to code in Inform 7. Leaves me with wondering… why?

Thanks again, all. Matt, it fails on my trivial example so it can’t be a clash. When I click on the little orange arrow next to the problem description in the results window, it takes me to the correct version of the extension. I have obliterated all other reference to the extension on this computer (it’s less than a week old) and still no joy.

Well, in my case, every time I think of picking up TADS 3 I run up against the fact that there isn’t a development environment for the Macintosh. Being able to use the IDE on the Macintosh is much more important to me than writing a game that allows the player to type “take 100 coins” and get 100 lines that say “coin: taken.”

True. I have a Mac also (for programming testing purposes) though I almost never use it. I also have an Android tablet but only ever use it for chess. I’m one of those Bill Gates type nerds. I’m one of the people living in doubt that there was ever really an “Apple” movement in the world (though I do recognize Appple has better graphics development programs by far even to this day). My thought on it is over time only one operating system will survive so you’d better place your bets now and look at the trend. If nothing else Linux will come out the victor. Thing is, I’m a long time EverQuest (EQ) player and that kind of sort of requires Windows (to my knowledge but there may have been a MAC version way back when). I sunk so much time into EQ that I don’t dare switch operating systems at this point.

On Tads 3… have you even heard what it is capable of doing? It supports some basic HTML commands and multi-media. Meaning, if you want to go full-on RPG you can create a really nice table based, blocky inventory system (which I’ve done), use sound clips and so on. Plus it has an extensive built in object class system for lots of things that in Inform 7 you have to go out and grab to include in your library.

Of course, the problem with all this is supporting ALL the platforms, and with Tads 3 you can’t do that (yet - unless maybe with Java Jetty Tads). So I can see the Inform 7 movement for that. Plus, if you want just a no-frills text adventure Inform is for sure the way to go.

However all that aside, I can, right now code up something in Tads 3 that will let me “take 100 coins” (and not just 99), like you said, and just so long as I have enough computer memory I can have infinite rooms and infinite objects in any text adventure I make. Props to Mike Roberts for that.

Hmmm… but I shouldn’t rant and I’m sorry. I’m trying desperately to pick up Inform 7 as my next programming language for text adventures but whenever I run into bugs like these it gets aggravating. Especially math bugs since computer programming is so math heavy. Since Inform 7 kind of limits the number of objects, 100 coins could just be shortened to “the treasure of gold” or something as one object. I mean, what adventurer would take only 99 coins anyhow? You’d take them all, right? So “take treasure” should be the real goal here and it’s easily done if you just make that into one single object.

Well, that’s pretty much the approach most people would recommend and take even if “take 100 coins” did work… in a text adventure there’s very little to be gained by implementing the pile of coins as 100 separate coins. It wouldn’t be that hard to hack something up so that piles of coins were represented as single objects with values for the number of coins in them, so that when you type “take 100 coins” you subtract 100 points from the pile that’s there and add 100 to the pile you’re carrying, and so on.

The limitation does seem like a possible bug, though. I’ll think about reporting it later when I have more time.

Thanks. Yeah, if I find what I think is a Tads 3 bug I report it for sure. I’m so new at Inform 7 that I don’t dare submit bug reports yet because there may already be a work-around that I’m not aware of right now. Though if you run the “test me” in my example, you’ll see bugs cropping up. “put 10 coins on table” for example (in my “test me”) as well. It “seems” to be a bug but maybe coins needs to be defined in a more precise way to catch them all. I simply don’t know, though, in Inform 7, how to catch this error.

Inform’s limit of 100 objects in a command is described in the manual chapter 4.14.

You can increase it, but you’re almost certainly better advised to write a game that doesn’t contain 100 identical objects. Or even twenty.

There we go, then.

(Hmm, I see that 4.14 recommends “Some polyethylene and polyethylene terephthalate are chemicals in the Lab,” but if you do that then an attempt to refer to the polyethylene would wind up in an infinite disambiguation loop. Probably not worth changing though.)