Question Trigger Loop Limit

So it seems upon carefully reading dg_scripts.c that the number of total loops allowed in a single trigger is set to 100. Changing the maximum value is easy enough, but cleverly recoding script_driver() to allow multiple while loops, each under 30, that exceed the limit seems to be beyond my introductory skills in coding. So I guess I have some questions.

1) Is that the intent, to only allow the trigger itself to have a hard limit of 100 loops total?

2) 100 seems a bit arbitrary, is there some sort of dynamic calculation that might work better?

3) What is the reason for a 100 loop limit? Why not 200 for example?

Thomas has covered that in the other thread.

thomas wrote: The limit is there to prevent a trigger from occupying too much cpu time. You should seriously consider altering your logic if you hit the ceiling.

thomas wrote: The main issue isn't the time it takes, but that - since the server is singlethreaded - it only has a limited time to perform its duties before people perceive the delay as lag.

There's some safeguards built in to prevent this:
If you loop more than 30 times in a while loop, you're broken out of it immediately.

But your solution: start new while loops - they reset the counter.

But he didn't seem to think that the intent was that hard limit since he felt that the counter would be reset, which it wasn't. I also don't understand that 30 loop thing since I think my loops were closer to 40s.

Well, that's just the thing and why I'm asking for clarification. Finding done doesn't reset the counter for the number of times a loop occurs in a trigger and while loops should be limited to 30, but they are not.

I'm puzzled, Parna.

Below, the value of a loops to 100 and then the error occurs.

I've never had any problem with a script looping more than 30 times, I had never even seen it referenced till this thread that that was supposed to be a limit. I have however ran into the 100 loop limit on multiple occasions, and it's never really been due to faultily written scripts like Welcor's response seems to imply, just a case of much more than typical complexity in said scripts. The 100 number though is fairly arbitrary and can certainly be changed, especially since processors are much faster today than they were when the limit was chosen. I only personally know of one script that very noticeably lags due to the amount of looping involved, and it's one of the most complex DG scripts I've ever seen, it's a mapper written by Detta that prints a map of the room you're in and it's surrounding rooms.

Any other time I've seen that loop, I've been grateful for it because it's been a fault in my triggers, an accidental endless loop. I don't really think the 100 total is my problem, I think there's something somewhere between the code and my trigger which is causing the count to not reset. It's a bit strange since I'm sure there must be other triggers that have a loop following a loop. We just wouldn't really notice if there's no error message.

After my discussion with Krell though, I've decided that I'll have to use a workaround because even if it's a code problem and even if that code gets fixed, since this will be a donated zone, not every mud will be using the fixed code.

So, yeah, I think there's a problem and, yeah, it's depressed me enough that that particular trigger is now on a back burner but, no, the problem has not killed the trigger. One of these days I'll get back to it I'm quite pleased with the trigger itself, even with the workaround.

As I mentioned earlier, I generally like the limit since it catches a lot of my errors. When I saw this comic, it really amused me for this reason.

thenoobcomic.com/comic/445/

For those who don't understand the code, I'll spoiler in a few comments from the readers: