[PennMUSH] Function Invocation limits
Ervin Hearn
ehearn at pennmush.org
Sun Jan 28 17:14:52 PST 2007
Hi Suzanne,
With regard to the hardcode issue, there is no difficulty setting any of the
directives mentioned below to values above 8192 in mush.cnf.
You seem to be mixing two different configuration settings...
function_invocation_limit can be set well above 8192 without any issues,
though it's uncommon for higher than 10000-15000 to be necessary. There is not
a value that is considered 'unlimited' for this configuration directive, you
must set it to the maximum value you want to allow. This directive controls
how many total functions can be used in a single queue entry, and will result
in an error message about the function invocation limit being exceeded if this
limit is hit.
call_limit however, has an extensive comment section discussing the need for
higher than 8192 recursions should never be necessary (it defaults to 100). It
supports the value of 0 to signify 'unlimited'. If the limit is set beyond the
host machine's stack limitations, the game will crash.
So, my recommendation would be to set your function_invocation_limit to
perhaps 10000 and see how it works. Your call_limit is likely fine at the
default, but if you wish to increase it I would recommend doing so in
increments of 25 at the very most.
Regards,
Ervin/Noltar
Suzanne Baylor wrote:
> The hardcode issue: Setting function_invocation_limit to anything 8192
> or to 0, the server seems to assume 0 or 1 and all code gives errors.
> This was 1.8.2 p2 and an clean install of 1.8.3. Looking at the help 0
> should be 'unlimited'.
>
> For the softcode:
> I'm getting close to the upper wall in function invocation .. it'll
> error at 8000 but not at 8192. The function will only run a few times
> daily (if that) on a newer machine with a gig of ram so I'm not
> concerned about resources. I'm more concerned it'll get to 8193 and I'll
> be stuck. So.... any suggestions on how to do this another way if I end
> up hitting the wall?
>
> F.CHECK.PREREQ #=
> [iter(get([v(ogl_db)]/d.feat.prereq),[iter([get([v(ogl_db)]/
> d.feat.prereq.##)],[setq(F,
> %qF%b[u([v(ogl_misc)]/f.check.type.[extract([get([v(
> ogl_db)]/d.prereq.[first(%i0, :)])], 4, 1,
> |)],[get([v(ogl_db)]/d.prereq.[first(
> %i0, :)])])])])][if(gte(member(%qF, 0), 1),,[setq(P,%qP%b##)])][setq(F,
> )])][set(get(%#/d.sheet),list.feats:[squish(unique(sort(%qP)))])
>
> I like the nested iters as they are automated and far more readable than
> doing it with a ton of if/else statements or switches. d.feat.prereq has
> the potential to be large in the future. d.feat.prereq.## should have a
> max of 5 or 6 sub items.
> _______________________________________________
> PennMUSH mailing list
> PennMUSH at pennmush.org
> http://www.pennmush.org/mailman/listinfo/pennmush
> PennMUSH FAQ-o-matic! http://www.pennmush.org/cgi-penn/fom
More information about the PennMUSH
mailing list