Forcing the parser to always ask which do you mean

Authoring Inform 7
1

I want to make the parser always ask the player which item they mean if there is even a single criteria met for the parser to have 2 possible items. I never want the parser to choose which item the player means, unless there is only one single item that meets any criteria. If an item has “1 point” and another has “5 points”, I still want the game to ask which do you mean.

Case in point below. This is just a silly example, and I am not looking for ways to make ONLY this example work. I could even do that by adding other parameters to the apples that would be something for the player to distinguish between the apples. However, in a real application where I am generating lots of randomized scenarios procedurally, and where I am doing some other crazy things with the naming conventions or conditions for items, such simple fixes do not apply (but posting an example of that entire framework would be insane and get off track too easily).

In the following code, the player can never choose if he takes the apple with or without the worm. The parser just takes the first apple in the list.

The kitchen is a room.

The player is in the kitchen.

An apple is a kind of container. Understand "apple" as an apple.

A worm is in the kitchen.

2 apples are in the kitchen.

To place the worm:
	repeat with x running through apples:
		if a random chance of 1 in 2 succeeds:
			now the worm is in x;
		if the worm is not in an apple:
			place the worm;

When play begins:
	place the worm;

Even if I try a “Does the player mean” phrase, it doesn’t work because though in plain English this looks like the odds of either being the case should be equal, one still “wins” when the parser decides for the player.

Does the player mean taking an apple that contains a worm:
	it is possible;

Does the player mean taking an apple that does not contain a worm:
	it is possible;

What can be done? Was Disambiguation Control by Jon Ingold (depreciated) the only solution to this problem? I’d hate to have to go back to an old Inform 7 forever before I even finish my first project.

2

In general, the parser only asks for disambiguation if it thinks the objects are distinguishable to the player. When you say “2 apples are in the Kitchen”, you are creating identical objects.

You could write this:

The Kitchen is a room.

An apple is a kind of container. Understand "apple" as an apple.
The printed name of an apple is usually "apple".

The apple1 is an apple in the Kitchen.
The apple2 is an apple in the Kitchen.

Then the parser will ask for disambiguation, but it will come out as “Which do you mean, the apple or the apple?” Presumably that’s not what you want.

3

I know that is possible, but there are a few issues with that.

As you already pointed out, the code name of each object is not friendly and the printed name presented to the player makes them equal. This would be easily solved for by adding a property and and understand phrase for that property. I am aware of how to do this.

However, this apples and worms thing is just a simplified example to work through the question. Assume for this question that I do need it to disambiguate, even if from the simplified example you could theorize other ways to solve the problem in the example. The missing details are that I have good reason not to use properties for everything that is presented to the player as part of the names of objects for the application I am making… it would be insane and maybe not possible to code. It would also force the player to have to type in very specific lines strings of words to isolate their choices, which is annoying, and I would prefer to create an easier syntax for them to follow… enter the general kind of thing and select from a list.

The following enhanced example shows the beginnings of why I will need this:

The kitchen is a room.

The player is in the kitchen.

An apple is a kind of container. Understand "apple" as an apple.

The printed name of an apple is usually "[if the item described contains a worm]wormy [end if]apple".

A worm is in the kitchen.

2 apples are in the kitchen.

To place the worm:
	repeat with x running through apples:
		if a random chance of 1 in 2 succeeds:
			now the worm is in x;
			break;
		if the worm is not in an apple:
			place the worm;

When play begins:
	place the worm;

Here, the player can’t type “take wormy apple” because the parser won’t find that. I could have made “wormy” a property and made it understood by the parser, but the problem in the real application is that it becomes a nightmare dealing with things like “the hovering, glowing crystal ball of knowledge” or “the +1 rapier of disintegration”. The thing is, in my application, lots of what is being presented to the player is purely text driven, and no such properties really exist, or they exist in a special way such that it isn’t available to the parser, or very difficult and tedious to code to make it available to the parser.

It also doesn’t help the player to attach lots of understood properties in my application, because they have to type in such specific things when there starts to be lots of loot in the same place anyway… as in if there are a “broken leather doublet,” “broken leather helm,” a “broken steel helm”, a “broken silver helm”, a “broken steel short sword,” a “broken silver short sword” etc… rooms with this kind of list (far more than this many things) could become common in my application, and so I want to make it possible for the player to only have to type the kind of the item, as in “take sword,” “take crystal ball,” or “take helm” or the most high-level of properties like “take leather” or “take steel”. This should give the list of options to the player, and only these high level properties are really properties that are available to the parser, whereas other aspects of the printed name may not be.

These may not all be the best examples, and there are entirely other uses cases than what I’ve outlined. The complexity and randomness of what I am trying to write makes it hard to come up with the best examples, but in my test applications, I have run into lots of annoying use cases until I started using Disambiguation Control by Jon Ingold. Now that that extension doesn’t work with the newest build, I am at a loss. If it can’t be solved, I fear I would have to not keep my Inform up to date…

4

I would caution against putting properties in the printed name that aren’t understood by the parser. I’m sure this is not what you’re going for:
[rant]You can see a broken sword and a shiny sword here.

TAKE BROKEN SWORD
You can’t see any such thing.
TAKE SWORD
Which do you mean, the broken sword or the shiny sword?
BROKEN
You can’t see any such thing.
TAKE SHINY SWORD
You can’t see any such thing.
TAKE ALL
broken sword: Taken.
shiny sword: Taken.
WIELD SWORD
Which do you mean, the broken sword or the shiny sword?
QUIT[/rant]

Also, how are you storing information about these objects if not in properties? Tables would work (although they need just the same amount of memory and are harder to access), but in that case you’d probably define new adjectives for each property anyway.

5

@Draconis: I’m also using Numbered Disambiguation Choices, so it would be like this:

>take broken sword
Which do you mean the 1) broken steel short sword, 2) the broken iron claymore, 3) the broken steel scimitar

>2
taken

The reason this gets important, and why I don’t want to and it is not helpful to make everything properties (and properties take up memory also) is that things have even more complex names, as the way I’m trying to write the game is much more narrative than the standard way the IF system is set up to display information to the player. For example, “broken steel short sword” may be simple, but you could have a room like this:

>take claymore
Which do you mean 1) the doom-rune engraved, +1 mithral dwarven claymore of destruction, with a golden, skull-shaped hilt, 2) the moon-rune engraved, +1 mithral dwarven claymore of holiness, with a silver, star-shaped hilt 3) the fire-rune engraved, +1 mithral dwarven claymore of destruction, with a golden, demon-shaped hilt, 4) the star-rune engraved, +1 mithral dwarven claymore of holiness, with a silver, moon-shaped hilt

>2
taken

If I made all of those things properties, for the player to disambiguate them, they’d have to enter something like this:

>take doom-rune engraved, +1 mithral dwarven claymore of destruction, with a golden, skull-shaped hilt
taken

>quit

There are multiple problems with this.

First, there’s a comma, because “golden, skull-shaped hilt” is all one property. “golden” is not a property of hilts, as the material here refers to the hilt, whereas the blade material property is “mithral” and “golden” might be a different property of the blade, not hilts. This is a nightmare to deal with, but I am not willing to let the comma grammar go, as it would make no sense without it.

Second, even if I could solve the comma problem, requiring the player to type "take doom-rune engraved, +1 mithral dwarven claymore of destruction, with a golden, skull-shaped hilt " is much more tedious than asking the player to type “take claymore” … “2”.

Third, these full descriptions are not present in the room or container descriptions… each of these would simply say something like “clearly magical claymore” but when you try to take one, more information is present… this also ties into the “real-time” tracking I want in the application, which gives the player some information when examining the room as a whole, but not all. Examining is not a free action in my game, but costs the player time. When you try to take something, you are also automatically doing a “closer examination” and getting more info (you can also do a closer examination without taking at the end of said examination as well).

6

If you’re using Numbered Disambiguation Choices, what’s the problem with making everything properties? Or obscured hardware names? The player won’t have to type the full printed name, they’ll just have to type a number.

I feel like you’re attacking a design problem and presenting it here as a programming problem. In your example with the wormy apple, do you want the player to be able to type “get wormy apple” or not?

7

So I tried a little hack, to make Inform think there’s a third apple in the room in order to force a choice. I thought I could be clever…

[code]“The Kitchen”

Include Room Description Control by Emily Short. [For the description-concealing rules.]
Include Single Paragraph Description by Emily Short. [I used this one for simplicity, but there are other options.]
Include Numbered Disambiguation Choices by Aaron Reed.

The kitchen is a room.

The player is in the kitchen.

An apple is a kind of container. Understand “apple” as an apple.

A worm is in the kitchen.

2 apples are in the kitchen.

To place the worm:
repeat with x running through apples:
if a random chance of 1 in 2 succeeds:
now the worm is in x;
if the worm is not in an apple:
place the worm;

When play begins:
place the worm.

Disambiguation-nevermind-device is a thing in the kitchen. It is fixed in place. The printed name is “never mind”. Understand “apple” as disambiguation-nevermind-device when the number of apples in the location is greater than 1.

Every turn:
now disambiguation-nevermind-device is in the location.

A description-concealing rule:
now disambiguation-nevermind-device is not marked for listing.

Instead of doing anything to disambiguation-nevermind-device, say “You decide against it.”[/code]

Then you get this:

kitchen
In the apple is worm. You also see here an apple.

take
What do you want to take?

take apple
Which do you mean, a 1) apple or 2) never mind?

2
You decide against it.

My guess is Inform won’t disambiguate two duplicates from the same kind, ever.

8

The wormy apple vs apple example is too simplified. I would be fine with someone having to type “get wormy apple” but I am not fine with someone having to type “the moon-rune engraved, +1 mithral dwarven claymore of holiness, with a silver, star-shaped hilt”.

The Numbered Disambiguation Choices won’t come into effect until/unless the parser can’t decide. Unfortunately, the parser DOES decide between these items unless the player were to type out the whole thing… and even then, I don’t know how to (or want to) turn things like “silver, star-shaped hilt” into a property. I’d rather parse that information in another way than making it a property value, but it itself is made up of multiple pieces like "silver, " and “star-shaped”, which could be a list of things like “golden”, “silver”, “steel” etc. and “moon-shaped”, “star-shaped”, “skull-shaped” etc. with lists that could be very long, and there could be more components from disparate considerations like “blood-soaked, chipped, golden, skull-shaped, ruby-encrusted hilt”.

I’m not saying I’ll necessarily have such long annoying names for everything, but it can happen, and I don’t ever want the player in a situation where he is unable to determine exactly which item he means because the parser thinks it knows which one.

I’m not sure why I’m getting pushback on figuring out how to do this as a programming problem, because the program issue exist. My entire application is too big to share, and is broken and disorganized with lots of other problems at any given time as I work on it… but, when I get it to a compilable state periodically and run it, I DO encounter situations where the parser is deciding what the player means, and I don’t want it to/consider it’s decision to decide it knows which one to be incorrect. I’m not sure why I have to defend it so hard and explain the entire premise of WHY I want a feature so badly, instead of asking the question on the premise of a practical solution to the problem I am having.

9

I think you’re confused about the way the parsing of property names works. If several properties “refer to” an item, the player only needs to type one of them for Inform to figure out which one they want. I believe it can also deal with multiple levels of disambiguation, so you can continue to specify one property at a time until only one object fits the given criteria. E.g.
[rant]> TAKE SWORD
Which do you mean, the red short sword, the red long sword, or the blue short sword?

RED
Which do you mean, the red short sword or the red long sword?
LONG
Taken.[/rant]

10

@Draconis: I’m not saying it can’t be done another way, and I understand that you can attach properties and that is the normal way of doing it in most applications. I’m trying to create what is, quite painfully obviously, a very different kind of game than most are used to with IF. I still think this engine can do it, and I want the text input parser, the save system, etc. so making my own thing is out of the question, but there is lots of specific code to write to rewire a lot of the basic premises of the game to make it possible. Memory limitations are one of the reasons I’m doing things the way I am in the first place anyway.

I can’t have separate properties for every word of text. I’ll run out of memory from the use of properties just like I would for the use of things. I’m still not sure if I’ll run out of memory from dormant until used tables (from what I gather in another thread, I should be able to have 2 gigabytes of those), but if I do, I also should be able to store those tables outside the application in external files and refer to them that way. I can’t store objects or properties outside the application, and so I can’t have thousands of those… the application will not run after I have about 600 of them, no matter what memory allocation settings I adjust… there appears to be an upper limit, and my game will blow that upper limit out of the water like a nuclear bomb.

I need to have these descriptions be text-based, and then have the game parse the text and perform logic on what is in the text, and figure out how the item works based on this.

If I am wrong about all of the above, well, I’ve asked many times how I can go about making an application that can have the appearance of many thousands of things, and though people say it is possible, their examples of how don’t have the kinds of things I’m trying to create as the kinds of things in the example. I’m doing my best trying to work toward the application I am trying to make when the engine can’t handle what I’m trying to do by the normal operations of things. I know the normal operation of things would be to attach properties to every item, but what if… just WHAT IF, that approach doesn’t work, and is crashing the application…

Disambiguation Control was a major key to solving that dilemma for me, and all I’m asking is if there is another clever approach to solving it without that extension since it is not updated.

11

Tables can use just as much memory as properties or more, depending how you’re using them, and will often be slower (if you already have a pointer to the object you want, you can access the property directly rather than sorting through an enormous table with as many rows as you have objects). You shouldn’t need a separate property for every word of text; in your previous post you said the solution given wouldn’t work because you generally had many words per property. :stuck_out_tongue:

If you really want to cut out the object-name parser entirely you can do something like this.

After reading a command: let X be word number 1 in the player's command; change the text of the player's command to X.

This removes everything after the verb, so GET SWORD becomes just GET (prompting the game to ask what you want to get). But again, I’d be very frustrated if I were playing a parser game and it couldn’t recognize the names of objects it gave me. Something like this would be going to far IMO:
[rant]You can see a sword and a dagger here.

GET SWORD
Which do you mean, 1) the sword or 2) the dagger?
SWORD
You can’t see any such thing.[/rant]

I’d say conditional understanding would be a much better solution. No matter how the property is determined in the code, you should still allow it to be parsed.

12

If it is true that too much table data that is not being processed at initial runtime will make the application run out of memory/be unable to compile, that too many objects will make the application run out of memory/be unable to compile… I don’t see how having multiple properties will help me, because I have no way to store and retrieve the assignments of the properties. I can have all the properties in the world, but if I can’t explicitly create enough objects, and I can’t have enough tables to run logic against to change the properties of a smaller pool of objects…

Then this is impossible. I tried to ask the question before, is there a limit to the scope of a game made for IF. If no matter how I slice it, I am limited to 600 things or less, then yes, there is a severe scope cap. Is this impossible, or is it possible to have more than “600 things” (as far as how it is presented to the player). Remember, the values of these “things” have to be able to change (that’s why I’m trying to use tables, because I need to update, store, and retrieve the info). Just having “loose” “now the whatever of prop1 is whatever value” phrases won’t work, because that defeats the purpose of the prop in the first place… it can’t have multiple possible stored values, only the one, so it might as well not have been a prop to begin with.

… is it impossible to make an application in IF that has or simulates having more than 600 things (tens of thousands of things) the player can interact with?

13

I think it would help if you explained in full what you’re trying to do. You post a lot of questions which we answer but then apparently they won’t work in your big project. We need to get a grasp on the whole thing.

14

I thought I have explained it, multiple times in multiple threads where I have had responses from the same people. Let me try again, from the top and see if I can make it more organized to make some sense.

Most IF games have specific “puzzles” or sequences of actions, with one or few predefined courses to take for each, and “guess the verb/guess the noun” is as much a part of the game play as anything. The standard rules assume this kind of game, and more than in mechanics, even in output, as in the responses like “I beg your pardon?” or “(the apple) Taken.” or “the [container] (empty)”. I am trying to make a very different kind of game in how the player is presented with the world. If I am way off base and there are games that don’t behave this way, I’d love to be pointed in their direction, not just as a game maker, but as a player.

Kerkerkruip, for example, is a fun game, but it fits the mold of the “typical” IF game as described above, more or less. I may never finish what I am trying to do, and Kerkerkruip is a finished game people who made it can be proud of. I want to make sure that it is understood I am not disparaging that game, or any other game made that follows the genre norms. I am giving this preamble so that it is clear that I am making something a little different, and I have to establish what kinds of things I intend to differ from for that to make sense.

I am certain that the “language” of the code in this engine is capable of doing what I want, but it has become evident that, at least by doing things in the typical way this engine was set up for dealing with typical IF games, that memory and performance issues will prevent the game from reaching the scope I am aiming for. I don’t care if it takes me 20, 40, or 60 more years to complete, the kind of game I want to make is the kind of game I want to make… I just don’t want to have to write a parser, save system, file management system, etc., and I would like a delivery medium that is known, so I am trying to get it to fit my project into the IF engine.

I tinkered with writing my own engine from scratch in C# and javascript, and while it is technically feasible on an indefinite timeframe, it’s not really “fun” for me to write that part of the program, and I want to focus on functions that will manipulate the “game world” or else my whole hobby is going to be spent doing stuff I don’t like, so I abandoned that avenue and went back to trying Inform.

Now that the preamble is over, what am I trying to do exactly? I am trying to create a scalable framework in which a lot of conventions of “reality” (not necessarily “realism” but a contextual “reality”) are present in the game that are not in typical IF. I want this framework to provide the mechanisms to do this in a centralized, reusable, specific-thing agnostic manner, so that I can utilize this framework like an extension (possibly series of extensions) on which I build the game. What I’m trying to do is basically rewire a good portion of the standard rules, making a subset of standard rules for building the kind of games I want to build.

The kind of game I want to build is an open world game, but more than that, I want a richly populated and contextually sensitive world where “guess the verb/noun” is a thing of the past, and normal conventions of “reality” are present. So, a “person” is not just a single object, but has body parts which can be individually injured for various effects. The player has body parts, such that you can’t look at your own head. People react to events around them, and have context sensitive things to say or do based on how the world changes (if you take their stuff, they get angry, etc.). People are equipped with armor and clothing that can only overlap “slots” in logical ways. The reporting of actions is narrative in presentation, seamlessly placing the responses of what was done into a flowing paragraph. Time is moving forward for any action, there are no “free” actions… “examining” something has at least 2 (maybe 3) levels of examination detail, each which takes different amounts of time. I also want this world to have some of the conventions of other open-world games such that “loot” and “quests” have a hint of “randomness” such that it isn’t the same each time you play it. And more…

Now, all that sounds very complicated, and it very much is. I may indeed never achieve my goal, but that’s where I’m headed. Again, even if it doesn’t turn out quite as expansive and dynamic as I hope, and even if it takes me years and years, that’s what i am trying to do. Now, the key here is that in order to pull this off, a world like that needs LOTS of things. A person has to be made up of multiple “things” and there have to be many people, there have to be thousands (if not tens of thousands) of items or possible items, which have “random” properties and placements.These “things” are not necessarily Inform convention thing objects, but must present as things to the player. The whole point of my questions is trying to circumvent the limitations of the engine related to Inform things.

So this brings us to what has been discussed in this thread. How can I solve for these issues. I am getting very close to having a better, more consolidated framework for “item substitution,” or “props,” as I like to call them. It isn’t ready to share yet, but it is getting there. It uses a system of tables and properties to dynamically change a limited selection of rooms, people, and things by changing their properties. So, the limited number of things can look like they are “infinite” things. I am deeply concerned now that Draconis has stated that tables will end up taking up as much memory as objects… it’s easy to test 600 objects, because you can put a line like “100 props are in the void,” in 6 or more times. To create unique tables, I have to manually come up with 600 or more names for tables, so that’s hard to test and I haven’t… so, I ask, after all this incredibly long post, is what I am trying to do feasible under even the best of circumstances (I don’t mean am I personally capable of finishing it in my lifetime, but rather is the engine actually capable of a game expansive enough that “600 things” is far, far fewer things than are necessary).

And finally, how does this relate to the original topic of this thread? Well, I was asking a question about how to do something that is needed for my game. The more narrative responses of the game, coupled with the complex and random item generation and properties, makes it so situations WILL happen where the standard parser is going to decide it knows what to choose for the player when in fact, it is wrong that there aren’t disambiguations left to consider. People not understanding the kind of game I am trying to make lead them to tell me to do things differently, but not understanding the full scope of what I am doing, their suggestions are either wrong for what I am doing OR (and I am willing to concede this graciously) I am doing things wrong BUT the answers people are giving are incomplete to account for all the variables I am dealing with.

15

I’m confused about one thing now–you say you want to completely eliminate guess-the-verb but still use the standard parser. People have been trying to do that for years but (imo) have never entirely succeeded. What is your plan for that?

More on-topic, I think the best thing to do here would be to use multiple gblorbs for different areas and pass data between them using external files. For the most part things from one region wouldn’t travel to another (e.g. very few NPCs would be willing to follow you that far away), so you could fully implement them using the Standard Library and not need to worry about their possible interactions with things from the other regions. Perhaps there are mountains between Informland and the nearby Tadopolis, so the journey is difficult and you can’t reasonably bring more than 10 things with you. You would only need 10 blank props in each place, which are filled in with the details from the external files. And so on.

16

Now THAT is interesting. I’ve thought about that, but my search fu is horrible with Inform and I couldn’t figure out what was possible with multiple files in that manner. If you don’t mind, I’d like to start a new topic about that instead of continuing it here.

Edit: As for the guess the verb/noun issue, again, I may not achieve all my goals. However, the idea I have is to internally expand most verbs to understand many words, and to make the narrative world OUT OF nouns, so that when you see “there are [trees]” here or “there is [an altar]” here, there actually is. I hate it when I am playing a game and the room description is full of texts or scenery that can’t be interacted with, but sound like they are things you should be able to interact with. I end up typing things like “look altar,” “look crack” (in wall), etc. and going nuts. I don’t want to add anything that sounds like an actionable noun to the room descriptions unless it actually is one.

17

Let’s back up.

Correct.

Not correct. You can always force the parser to think that items are distinguishable, even if the difference is hidden from the player. That was the point of my original answer:

An apple is a kind of container. Understand "apple" as an apple.
The printed name of an apple is usually "apple".

The apple1 is an apple in the Kitchen.
The apple2 is an apple in the Kitchen.

In this example, the parser will never auto-choose one of the apples. It will always ask a disambiguation question. But the player will not see the “apple1”, “apple2” labels.

For this toy example, the player is screwed, because the parser will ask “Which do you mean, the apple or the apple?” But if you add Numbered Disambiguation, the player can cope. If you start adding visible distinctions to the objects, you can make a playable game this way.

18

Interesting, and not to say ambitious, ambition. Fundamentally, you are asking : "How do I manage, in memory, a potentially infinite number of objects, and their various conditions. As well as : How do I enable the player to disambiguate between these things in a world where objects may have similarities.

Simple answer is, I think, you can’t. Within the boundaries of the world you’re creating you’re going to have a memory limitation, and you will have a cap on how many objects you can create.

Assuming you are creating the world dynamically, and each ‘object’ in the world has a number of parameters - then you’re going to need to either limit the number of objects (whatever - people, swords, cats) or create and destroy them dynamically, or create them algorithmically or do some sort of clever file swapping stuff.

I would argue that you need to create an objects table that hold the dynamically created object properties

Sort of:
OName OType OProp1 OProp2 OProp3 OProp4 HP Condition…
Bob Man Long Nosed – – 43 asleep
Sword sword short diamond-encrusted – – – Poor
(Just an example, but you get the idea)
And, rather than 600 tables, this gets created during the game. Or something.

Just my tuppenoth. Interesting programming exercise.

19

[quote="McTavish"Sort of:
OName OType OProp1 OProp2 OProp3 OProp4 HP Condition…
Bob Man Long Nosed – – 43 asleep
Sword sword short diamond-encrusted – – – Poor
(Just an example, but you get the idea)
And, rather than 600 tables, this gets created during the game. Or something.[/quote]
That’s sort of what the game already does. Extensions allow you to add to the relevant table at run-time.

Small note: you might also want to make everything privately-named, which will mean that the parser won’t recognize “apple1” or “apple2” as valid names for the apples.

20

@zarf: I don’t want to beat a dead horse. I know I can supply ways to disambiguate, but the problem was that I keep running into limitations that make it difficult or impossible to use those normal conventions you are asking me to use in such a large application. I think I have to transition my focus to that for the time being, and come back to the disambiguation issue later. Not being able to even build the world large enough is a more fundamental problem, and the course of this discussion has made that extra clear.

@Draconis: I’ll take the tip about privately naming things.

@McTavish: As for creating and destroying things, I’ve looked into destroying things/deallocating memory, but as far as I can tell, you can’t do this with Inform 7. I don’t know I6 at all, and part of what is intriguing about this project is doing it as much in Inform 7 as possible. If the core engine is written in I6, that premise is lost. I know there is an extension to create objects in I7 (Dynamic Objects does this right?), but as far as I know there is no way to destroy them and get the memory back.

Even if there were, I still need to store the records of the object when I were to destroy it so that I can recreate it again later with any modified parameter values that happened to it during the course of play… otherwise, nothing can ever change, and ends up always reverting to the initial values when recreated. I’m really not sure how to deal with this problem except to store information in a table or data file of some sort, so instead of creating/destroying, I’m using “props” as a limited set of persistent objects that are being updated with different properties read from tables. I’m still confused as to if this will actually help with the memory limitation or not as it is hard to create the test scenario without first attempting to write an actual, large game with hundreds of data records.

Also, I don’t really need “infinite” space, but I didn’t realize that the application would break down at 600 things. I keep using that number, because that is the number it keeps breaking down at for me. I just need a lot more things, not completely unlimited things. The cap I’m running into is just too restrictive for what I am trying to do. I’m hoping I can figure out how to use external file references from the resources zarf posted in my other thread, but I haven’t had much time to look at them yet.