Enquirer Home Page | Twitter | Back to Improbable Island

 Forum Index > Places > Places: Feedback and Development New Topic Post Reply
 Places Programming Modifications
 |  Printable Version
 Monday, August 13 2012 @ 02:41 PM UTC (Read 1559 times)  
Forum Contender

Status: offline

Registered: 07/28/11
Posts: 50

Okay, I'm not sure if any of you guys know how many contraptions and contrivances I've already used in Mobile Base Alpha, as well as the number of Run Program contraptions alone, but saying I've used over 250 Run Program contraptions alone is a reasonable estimate. Seriously. As for the other contraptions, I've must have used more than a thousand of them by now. So I know a few things about the nuances about the programming system.

However, some of those nuances actually hold some of my programs back, and push the amount of time it'll take to get just the basics out of my place's game system working. I respect you, CavemanJoe, for the power of your Places Programming system, but some of the things that a certain feature of your system prevents are rather irritating to me. This feature has a name: the infinite loop detector. While I can see how having it stop programs from running after they've run a flat three times helps reduce lag, it gets in my way twice: Once when I try to use non-infinite loops, and twice when I try to use a program multiple times without actually using it in a loop. First, here's my explanation of why this is such a problem:

In case you're wondering how one can create a non-infinite loop in Improbable Island's Places Programming, there's two approaches: Using Memories and Using Thoughts. For using Memories, a Memory Equals, Memory Less, Memory Greater, or equivalent Memory Slot contrivance is needed in a row before the program which the Run Program contraption (which runs the program again) is located. But that's not all you need to make it a non-infinite loop as opposed to an infinite loop. You'll also need an Increment Memory contraption that will slowly but surely increment that memory so that the contrivance which works with the Increment Memory contraption will eventually fail. There's only two problems with this, one being that it screws up the data values for a memory (which is perfectly fine if you've set a RAM memory to the value of another memory and then used several non-infinite loops to eventually get each value equal to zero, while simultaneously setting a thought to each slot in the memory), and two being that the same safety feature that prevents "infinite" loops prevents this program from working more than three times. You can also do the same thing with a Thought, but it runs into the same limited-runtime problem finite memory loops do.

With the stat system, I have managed to circumvent this a bit by having two sets of finite loop programs, one which increments the appropriate thoughts by 4 while reducing the thought which represents the memory involved by 4 multiplied by the appropriate power of 16 (as the stats run on a hexadecimal system rather than a decimal system), before having it run another program which does pretty much the same thing, only all the numbers are divided by four. While I'm fine with having 8 programs to do this for ten stats (there's two memories used for keeping track of stats, and as a hexadecimal system there are 5 "slots"; also the thought which gets set to each memory is the thought for the last stat each memory keeps track of), having to use 16 programs to do what 8 correctly-written programs should be able to do is a waste of contrivances and contraptions. To be specific, a waste of 16 Run Program contraptions, 16 Increment Thought contraptions, and a total of 8 Thought Less and Thought Greater contrivances. And the contraption cost it'll take just to fix the interpreter for the memories which hold the skill values for the skills system, due to finite loops not working, is even greater. It'll take 72 Run Program contraptions, 144 Increment Thought contraptions, and a total of 72 Thought Less and Thought Greater contraptions. And that only boosts the max number each skill can go up to to 6. This is what makes making finite loops impractical for most people on a large scale. (The only reason it's not for me is that the alternatives are even more impractical.)

And then there's the occasions that you may want to run a program multiple times, due to it doing something that can't just all be replicated by running just one program. For example, a program I have that rolls the "dice" used in my game system. It rolls a thought named "dice" to a value between 1 and 6, and depending on the value of the dice, it may increment one or more other thoughts (the thoughts that keep track of how many ones, how many 5s and 6s, and how many 6s have been rolled). And so I use this program with finite loops engineered to work around the problem of programs not being able to work three times, even when they aren't infinite loops, or loops at all, only to realize when I test it that the dice rolling program can only run three times. Which means I need 21 identical dice rolling programs just to accomplish what one dice rolling program could do by itself if the system would let it.

For those of you wondering why I need 21 identical dice rolling programs for this to work, the programs I've made to work around this problem work off of a Base 4 system to eventually lower the value of the dice pool thought down to exactly 0, even with dice pools as large as 40 or more involved. A different program runs the three programs which determine how much to subtract from the dice pool and how many times to use the Dice Rolling Program in order to reduce the dice pool to 0, as well as allow those programs to run three times without affecting whether or not the next program gets to run. First, the 16 dice roll program is run, which checks to see if the dice pool is greater than 15, and if so, subtract 16 from the dice pool and run the Dice Rolling program 16 times. This program in itself runs up to three times, so as-it-is, each Dice Rolling program run from that one has to be an entirely different yet identical program. Then there's the 4 dice roll program which runs after the 16 dice roll program, and as-you-guessed, it checks to see if the dice pool is greater than 3, and if so, subtract 4 from the dice pool and run the Dice Rolling program 4 times. But as this can also run up to three times in a row, each of those Dice Rolling programs have to be an entirely different program from all the other Dice Rolling programs and yet be completely identical to the other ones. And then there's the Ideal Dice Roll program, which runs after both of those programs, checks to see if the dice pool is greater than zero, and if so, subtract 1 from the dice pool and run the Dice Rolling program one time per run, which also has to be another different-yet-identical program.

Which means for just dice pools under 16 dice, I'll need 4 additional programs, 4 Roll Thought Contraptions, 12 Increment Thought Contraptions (which I'm currently extremely low on), and a total of 12 Thought Less, Thought Greater, and Thought Equals contrivances. And to make sure it can handle any ridiculously large pool of dice, I'll need 20 additional programs, 20 Roll Thought Contraptions, 60 Increment Thought Contraptions (this is what I'm worried about), and 60 Thought Less, Thought Greater, and Thought Equals contrivances. Most of which also need to be used elsewhere. I know a guaranteed way to prevent infinite loops from occurring is a good thing, but it keeps other things that'd be great to have from working.

My Suggestions

For those of you that didn't read that big, long argument (or rant, depending on your point of view), as to why the infinite loop detector could use some much-needed improvements, this is where you should start reading. My first suggestion is to let any program which does not have a Run Program contraption run as many times as needed (or with a vastly increased limit to how many times it can run). Seeing as the feature is in place for preventing infinite loops, and there's no way to make an infinite loop with a program that doesn't have any, this should be a good compromise for people who want to make a single program run more than 3 times in a single go for some reason.

Seeing as this shouldn't be hard to code ("set variable infiniteloopdetection=1" when a Run Program contraption is run), it shouldn't be hard to fix either, and it'd take a very determined troll to gather up enough Run Program contraptions to make running that one program repeatedly take so long it lags up the server. I'm not saying it can't happen, but I am saying that it'll happen infrequently enough that using disciplinary measures on the offender(s) should solve the problem. Plus, at least in my case, this should actually reduce server load as multiple identical programs don't have to be stored on the server just to do what one of those programs can. (And I will get around to making those 20 programs eventually if this doesn't get fixed.)

As for finite loops, I have two suggestions: The first (and the simplest) is to make any setup like the one I've suggested above have a greater amount of times it can run (like 9 or 99 or something like that), including situations where the contrivance which checks the memory/memory slot/thought comes after the Increment Memory/Increment Thought contraption which steadily increments the memory/thought to where the program will stop running at its desired point, so long as the Run Program contraption that runs the program itself comes after both of those.

Yes, I do know that as-I've-currently-suggested-it, this can be used to have finite loops that run other finite loops a large amount of times for the express purpose of lagging the server. That is why I'm making the following suggestions: Either have other Run Program contraptions in a finite loop simply not run (this should be the simpler route), or have programs run from a finite loop be unable to run another program. These will also work for the below suggestion.

Suggestion 2 to fix the problem of finite loops not working is both more complicated, but if done right, also more reliable. The idea is to check to see if the loop in question is getting further away from the condition that will stop it from running or closer to it within the first 3 times it does. Obviously, if the condition that will stop it from running isn't changing at all, or there isn't a condition that will stop it from running, it's an infinite loop and should be stopped from running as normal. . However, if the loop in question is getting further away from the condition that will stop it from running, it's either a programming error (perhaps the knob was set to the wrong condition or somebody used a Thought Less contrivance instead of a Thought Greater contrivance) or an intentional way of getting the program to run as many times as it can. In either case, the program should be stopped from running as normal. However, if the loop is getting closer to the condition that will stop it from running, then it's a finite loop and the number of times it can be run can be safely increased to where using one is practical for data handling purposes. You'll have to account for the knob's position and the type of memory or thought checking contrivance involved, but this will make using loops something practical for islanders to use for data-handling purposes, especially if they want to squeeze more data per "slot" at the cost of less slots for a memory, or to a lesser extent, want to squeeze more "slots" into a memory at the cost of less data per slot.

So, any questions or comments?

PS: I'll also write up a guide for making and using finite loops if and when the system is changed so that they're easier and more practical to use.

Profile Email
 Wednesday, August 15 2012 @ 05:58 PM UTC  
Forum Admin

Status: offline

Registered: 02/24/08
Posts: 2281

Just letting you know I've seen this, and I've put it on my to-do list.

Now, my to-do list is bloody epic, but just about everything on it does eventually get done. I just can't promise it'll be terribly soon.

Profile Email Website
Content generated in: 0.20 seconds
New Topic Post Reply

 All times are UTC. The time is now 12:15 AM.

Normal Topic Normal Topic
Locked Topic Locked Topic
Sticky Topic Sticky Topic
New Post New Post
Sticky Topic W/ New Post Sticky Topic W/ New Post
Locked Topic W/ New Post Locked Topic W/ New Post
View Anonymous Posts 
Anonymous users can post 
Filtered HTML Allowed 
Censored Content