1.0.0 ~reboot

Submitted by Trispis on Mon, 2006-09-25 04:45.

Systems

@@ ======================================================================== @@ .:....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....: @@ ========================================================================

Printer-friendly version
Login or register to post comments

MUX

Submitted by Trispis on Sun, 2007-01-07 16:18.

I have it on good authority that this code appears (without actually testing it) to be MUX-compatible. This isn't greatly surprising, since there really isn't much code (mostly instructions so you don't ruin your game inadvertently).

Planned Change

Submitted by Trispis on Mon, 2007-03-19 08:51.

As will be illustrated and/or explained in the rewrite of the manifest section pertaining to attributes and attribute trees, there is a high likelihood that this module will result in the following change.

The ~`#### tree will, in all likelihood, be migrated to the startup`#### tree.

Apart from the few tweaks necessary to impliment this migration, no other changes are planned for this module at this time.

Planned Change

Submitted by Trispis on Wed, 2007-03-28 11:37.

As mentioned in the script itself, pennmush alots some initial queue cycles to #1 and this code exploits that.

At present, the code (as written) basically dumps everything into one queue cycle.

Planned rewrite will provide for distributing #1's startup actions over more than one queue cycle (ala 'run levels').

If memory serves, #1 is given the first five (5) queue cycles. Thus, the plan for the rewrite will create a potential (user-specifiable) for distribution of #1/startup over anywhere from 1-4 sequential 'groups'.

... basically resulting in a quadrupling of the capacity of this little code snippet.

Adding this to the grouping feature of the renumbering function, there will be some room for features to be added (e.g., configuration/management/organizational $commands).

Rhost

Submitted by Trispis on Wed, 2007-06-27 09:16.

Installed this on Rhost this morning. Works.

User login

Navigation

Postings by topic

Topic

Recent blog posts

Softcode

Everything but code

Syndicate

1.0.0 ~reboot

Comment viewing options

MUX

Planned Change

Planned Change

Rhost

Comment viewing options

The WARPEDcore

Poll

Tinytalk Podcast

ElectricSoup

Gateway announcements

Skotos Game Design