@@ ========================================================================
@@ .:....1....:....2....:....3....:....4....:....5....:....6....:....7....:
@@ ------------------------------------------------------------------------
@@ WARPED ~~~~~~~~~~~~~~~~ ~
@@ ~~~~~~~~~ ~~~~~~~~~ WARPEDcore ~~
@@ ~~~~~~ ~~~~~~ ~reboot ~~~
@@ ~~~~ Adoption ~~~~ 200609250b ~~~~
@@ ~~~ Date ~~~~~~ ~~~~~~
@@ ~~ 2006.09.25 ~~~~~~~~~ ~~~~~~~~~
@@ ~ ~~~~~~~~~~~~~~~~ core
@@ ------------------------------------------------------------------------
@@ .:....1....:....2....:....3....:....4....:....5....:....6....:....7....:
@@ ========================================================================
@@
@@ LEGAL
@@
@@ This material is released under the terms of the
@@ WARPEDcore Softcode and Documentation License (WSDL).
@@ For details, see: http://community.pennmush.org
@@
@@ USE AT YOUR OWN RISK.
@@
@@ Copyright 2006, The WARPEDcore Project
@@
@@ .:....1....:....2....:....3....:....4....:....5....:....6....:....7....:
@@
@@ README
@@
@@ PLEASE READ THIS SECTION. It is IMPORTANT!
@@
@@
@@ This is a very powerful and delicate piece of code. PLEASE read ALL
@@ of the comments VERY CAREFULLY. Most of this code must be manually
@@ installed (edit a line appropriately, copy/paste).
@@
@@ DO NOT, I repeat, DO NOT attempt to quote this file into your game!
@@
@@
@@ USE AT YOUR OWN RISK.
@@
@@
@@ .:....1....:....2....:....3....:....4....:....5....:....6....:....7....:
@@
@@ BEGIN REQUIREMENTS
@@
@@ * PennMUSH version 1.7.7p21 or newer.
@@
@@ .:....1....:....2....:....3....:....4....:....5....:....6....:....7....:
@@
@@ The Theory
@@
@@ Unless you've tweaked a great deal, your #1/startup contains one of the
@@ following:
@@
@@ a) a very long string of @<command>;@<command>;@<command>[;etc]'s.
@@
@@ b) at least one @dolist.
@@
@@ c) a combination of the above.
@@
@@ If startup sequencing is highly important, you probably have "c"
@@ (above), in which you have the most crucial items done as direct
@@ commands, followed by a dolist or two for the rest.
@@
@@ Depending on how much tweaking you've done, you may or may not have a
@@ well-organized and easily managed process.
@@
@@ That's what this package attempts to provide - a well-organized and
@@ easily managed god/startup - while also retaining as much startup
@@ precidence as possible.
@@
@@ .:....1....:....2....:....3....:....4....:....5....:....6....:....7....:
@@
@@ The 'cut' line.
@@
@@ The text above this point contains no code, and should be removed
@@ if you intend to /quote this file in some way. The recommended procedure
@@ is to read and follow the instructions and to copy, line by line, the
@@ needed pieces as you go; however, I did attempt to write this so that it
@@ could be /quoted if done so with care and responsibility. And, even if
@@ you do /quote it, you will inevitably have some manual adjustments to
@@ make when it's done.
@@
@@ ========================================================================
@@ . . C . . u . . t . . H . . e . . r . . e . .
@@ ========================================================================
@@ .:....1....:....2....:....3....:....4....:....5....:....6....:....7....:
@@ ------------------------------------------------------------------------
@@ authorship, credit, and copyright information.
@@ .:....1....:....2....:....3....:....4....:....5....:....6....:....7....:
@@
&~.legal #1=WARPEDcore~reboot, see: http://community.pennmush.org
&~.version #1=200609250b
@@
@@ ========================================================================
@@ .:....1....:....2....:....3....:....4....:....5....:....6....:....7....:
@@ ------------------------------------------------------------------------
@@
@@ data attributes
@@
@@ ------------------------------------------------------------------------
@@
@@ configs
@@
@@ .:....1....:....2....:....3....:....4....:....5....:....6....:....7....:
@@
@@ god configs
@@
@@
@@
&~`ORDER #1=0:First 1:Attribute 2:Function 3:Command 4:Hook 5-8:Unused 9:Last
@@
&~`ORDER.NOTE #1=Neither this attribute nor its contents is used by the @startup and/or ~`<reboot> code in any way. It's simply a way to store your design plan for reference (e.g., "okay, it's been 3 years since I had to make any changes to this -- now, which numeric group was I using for @commands again?"). It contains a suggested default arrangement. If you don't need it (and plan to dump everything into ~`0???), ignore it.
@@
@@ .:....1....:....2....:....3....:....4....:....5....:....6....:....7....:
@@
@@ local configs
@@
@@
&~`RENUM`INTERVAL #1=10
@@
&~`RENUM`INTERVAL.NOTE #1=This is the renumbering interval used for the auto-renumbering.
@@
@@
@@ ========================================================================
@@ .:....1....:....2....:....3....:....4....:....5....:....6....:....7....:
@@ ------------------------------------------------------------------------
@@
@@ the code.
@@
@@ ------------------------------------------------------------------------
@@
@@ functions
@@
@@ .:....1....:....2....:....3....:....4....:....5....:....6....:....7....:
@@
@@ the renumbering function
@@
@@
&~`RENUM`UFUN #1=iter(lnum(0,9), setq(0,itext(0))[iter(setr(1, filter(me/~`NNNN`FILTER, lattr(me/~`%q0???))), set(me, itext(0).TEMP:[v(itext(0))])[attrib_set(me/[itext(0)])])][iter(%q1, set(me, %q0[rjust(mul(inum(0), v(~`RENUM`INTERVAL)), 3, 0)]:[v(itext(0).TEMP)])[attrib_set(me/[itext(0)].TEMP)])])
@@
&~`RENUM`UFUN.NOTE #1=this function divides the possible 10,000 attribs into groups of 1000, by managing the first number as a separate iteration process, renumbering each group of 1000 (possible) attribs as a separate sub-process. This allows you, if you so choose, to manage groups of processes separately. For example, putting all "really super important" startup commands in STARTUP`0??? attributes, all remaining @attribute commands in STARTUP`1??? attributes, all remaining @command commands in STARTUP`2??? attributes, etc. (or, if don't have very many and don't need such subdivisions, you can put them all into the 0??? category and be done with it - you just won't be utilizing this subdividing feature). It must be operated manually (Logged into god, think u(me/~`RENUM`UFUN))
@@
&~`NNNN`FILTER #1=isnum(rest(%0,`))
@@
&~`NNNN`FILTER.NOTE #1=This is the filter to ensure that only ~`#### attributes are processed, just in case someone adds a ~`NOTE or whatever without thinking. It is used by ~`RENUM`UFUN and @startup.
@@
@@
@@ ========================================================================
@@ .:....1....:....2....:....3....:....4....:....5....:....6....:....7....:
@@ ------------------------------------------------------------------------
@@
@@ globals
@@
@@ ------------------------------------------------------------------------
@@
@@ @attribs
@@
@@ .:....1....:....2....:....3....:....4....:....5....:....6....:....7....:
@@
@@ These are @attribs needed by the WARPEDcore
@@
@@ &~`0010 #1=@attribute/access/retroactive ~=safe veiled visual no_clone
@@
@@ This prepares the ~ attribute (and subsequent tree features) for use
@@ with the WARPEDcore.
@@
@@
@@ ========================================================================
@@ .:....1....:....2....:....3....:....4....:....5....:....6....:....7....:
@@ ------------------------------------------------------------------------
@@
@@ Help
@@
@@ .:....1....:....2....:....3....:....4....:....5....:....6....:....7....:
@@
@@ No such animal.
@@
@@ ========================================================================
@@ .:....1....:....2....:....3....:....4....:....5....:....6....:....7....:
@@ ------------------------------------------------------------------------
@@
@@ activation
@@
@@ .:....1....:....2....:....3....:....4....:....5....:....6....:....7....:
@@
@@ the @startup attribute
@@
@@ .:....1....:....2....:....3....:....4....:....5....:....6....:....7....:
@@
@@ simplest conversion is...
@@
@@ first, make a backup copy of your existing #1/startup.
@@
@cpattr #1/STARTUP=#1/STARTUP.BACKUP
@@
@@ confirm the operation..
@@
ex #1/STARTUP
ex #1/STARTUP.BACKUP
@@
@@ next, copy your existing glob of goo from #1/startup to this system's
@@ "Last" numeric group, in the last entry (this assumes a 'failsafe'
@@ position for all your pre-existing code)...
@@
@cpattr #1/STARTUP=#1/~`9999
@@
@@ then, at your leisure, proceed to gradually migrate things from their
@@ current location (#1/~`9999) into their appropriate new separate
@@ attributes.
@@
@@ give #1 an appropriate new @startup.
@@
@startup #1=@dolist/delimit | [iter(sort(filter(me/~`NNNN`FILTER, lattr(me/~`????)), a), v(itext(0)), %b, |)]=##
@@
&STARTUP`NOTE #1=This makes something like "@dolist/delimit | @<command>|@<command>|@<command>[&c]=##"; and it does so in a manner which prevents non-god insertion of malicious commands. YMMV.
@@
@@ When you finish migrating everything from ~`9999 into appropriate
@@ individual attribute placements (deleting each piece from this
@@ attribute as you do so, eventually deleting this attribute as well),
@@ you can delete #1/STARTUP.BACKUP (the failsafe backup I made you create
@@ earlier in the script).
@@
@@ .:....1....:....2....:....3....:....4....:....5....:....6....:....7....:
@@
@@ The end result should be a game which, during a game restart, processes
@@ "all startup commands" in the earliest possible queue cycle that such a
@@ single action can occur. God is granted five (5) initial queue cycles
@@ during startup, in which it is allowed the unique privilege of freely
@@ cramming stuff into the queue at will, before anyone else's @startup is
@@ processed. This code attempts to use a single @dolist to get as much
@@ 'stuff' into the queue as early as possible.
@@
@@ ALSO NOTE: This code is not restricted only to #1/startup. It can be
@@ used in anything's @startup, or in @aconnect, or any other place you
@@ need to process several commands in sequence.
@@ ------------------------------------------------------------------------
@@ .:....1....:....2....:....3....:....4....:....5....:....6....:....7....:
@@ ========================================================================