So I realized that I've been sort of cataloging my journey on integrating my favourite libraries into the core on my "too many tabs" topic, and that was foolish. Now someone who only cared about making tabs toggle-able instead of permanent has all sorts of stuff they might not care about reading that relates to integrating a whole set of libraries into the core. SMH
Anyway, that's here: https://textadventures.co.uk/forum/samples/topic/y_eruu9bp0mq498lw7tknq/too-many-tabs-adding-your-library-tabs-to-the-features-tabs-so-they-can-be-to
But now I'll put stuff in a real topic devoted to integrating your favourite libraries into the core.
This process can:
1. reduce the number of tabs altogether, placing controls on pre-existant tabs (eg. LiquidLib)
2. inspire you to create new controls in the editor for overriding/working with your fav modifications on your fav libraries
(eg. mana, player-stats, or customisable monster scripts, etc. in CombatLib)
3. reduce/nullify the setup a library needs before it will work (eg CombatInitialise, InitInv2, Scopebackdrop, & WeatherLib
setup)
4. reduce the amount of things the library user needs to remember, or go to documentation for, when they want to use the
library (because they're added to the editor and controls)
Remember before editing the core to save a copy of it somewhere pristine, especially the "core.aslx" file itself, as the others can be renamed to sit side-by-side one another comfortably, but this one can't easily and so modified versions will replace eachother. Simply add a number to the edited core file for version, and update the "includeref" code in "core".
So far, I've updated these files in my "core3" ("core2" was for just integrating the tabs onto the "features"):
"CoreCommands3.aslx (now includes many commands added by libraries)
"CoreFunctions3.aslx (now includes many functions added by libraries)
"CoreTypes3.aslx" (now includes many types added by libraries)
"CoreStatusAttributes3.aslx" (Auto-adds additional CombatLib attributes when enabled, hitpoints, mana, xp)
"CoreOutput3.aslx" (includes integrations of Output Text Paragraph, and MessagePlus libraries, etc created by EightOne)
"CoreCombat3.aslx" (includes surprisingly few integration components as most of CombatLib actually ended up being
included in other areas of the core)
"CoreEditor3.aslx" (calls updated editors and additional editors "tabs" from libraries)
"CoreWearable3.aslx" (includes some portions of CombatLib which are needed for wearable types)
"CoreEditorGame3.aslx" (Includes features checkboxes to enable libraries/tabs, also statnames string dictionary editor on
the player tab--WhenCombatLib enabled)
"CoreEditorObject3.aslx" (updated to call the modified and integrated editor tabs)
"CoreEditorExit3.aslx" (includes calling descriptions tab if some of my personal libraries are added/enabled--intend to
eventually determine what happened to MrAngel's ExitDescriptionsLib when the other libraries
were enabled that killed it and integrate his awesome checkboxes too this is one is not neccessary
really as it stands)
"CoreEditorScripts3.aslx" (includes integration of some of EightOne's editor libraries)
"CoreEditorObjectSetup3.aslx" (now includes some additional checkboxes and type dropdowns depending upon
library/feature integration)
"CoreEditorObjectRoom3.aslx"(now includes smell and listen scripts for the room ambiance)
"CoreEditorObjectFeatures3.aslx" (Includes checkboxes for toggling those tabs/enabling integrated library
features as discussed in the other forum post)
"CoreEditorObjectUseGive3.aslx" (integrates the editions of EightOne's "UseAllRound" library)
"CoreEditorObjectContainer3.aslx" (includes the LiquidLib tab portions for objects)
"CoreEditorObjectWearable3.aslx"(now includes wearable types from CombatLib and relevant editor pieces)
"CoreEditorObjectOptions3.aslx" (I honestly can't remember what--if anything-- I updated here)
"CoreEditorObjectLift3.aslx" (this is what's left of LiftLib's tab after integrating the rest of the library--only appears if a
room or object given a "Lift type" with dropdown on the setup tab)
"CoreEditorObjectStack3.aslx" (same as above, remaining bits of a tab from a Pixie library)
"CoreEditorObjectWeather3.aslx" (same as above, remaining bits of the tab from latest upgraded WeatherLib)
"CoreEditorObjectHoly3.aslx" (Tab from one of my personal libraries for a game I'm working on. It wouldn't be in
something posted to the site as a finished product and probably wouldn't interest most folks to use it.)
"CoreEditorObjectNpcandPostures3.aslx" (All that's left of editor tabs from Pixie's various NPC and Postures
libraries)
"CoreEditorObjectConversation3.aslx (all that's left of ConversationLib is the Conversation tab as this file... as I
make this list, I wonder if this can disappear altogether by integrating it with "CoreEditorObjectAskTell"... I'll be
looking into that)
For CoreEditorScripts, I plan to eventually learn and integrate further some very commonly called functions and used
attributes from libraries (like CombatLib) but I'm not there yet.
"CoreEditorScriptsOutput3.aslx" (Includes EightOne library integrations)
"CoreEditorScriptsObjects3.aslx"(Includes EightOne library integrations)
"CoreEditorScriptsScripts3.aslx" (Includes EightOne library integrations)
Advanced folks can do their own versions of things to make their lives easier.
Newbies could conceivably use a polished version of these updates as a standard set to just have more available to them without much coding... although I LOVE how Quest and all the current documentation and using these libraries has taught me what little I know about coding.
Still working this project, but having a blast!
Latest little side-quest as I work on this. Pixie's CombatLib mentions fungi, but didn't actually have any...
Since I was a Moria/Angband/Zangband player before windows stopped handling it well, I have an affinity for mushrooms that do stuff in games.
So.... I added a Fungus Type which works with some of Pixie's (modified) functionality in my core3 update.
First thing was to update the "edible" type slightly. (Some of the edits are merely to incorporate other features of Pixie's CombatLib like Hitpoints and Mana) It can be found in CoreTypes3.aslx
<type name="edible">
<displayverbs type="listextend">[Eat]</displayverbs>
<inventoryverbs type="listextend">[Eat]</inventoryverbs>
<eat type="script">
if (HasInt(this, "lastsfor")) {
do (this, "starteateffect")
}
else if (HasScript(this, "eateffect")) {
do (this, "eateffect")
}
if (HasInt(game.pov, "health")) {
game.pov.health = game.pov.health + this.eathealth
}
if (HasInt(game.pov, "hitpoints")) {
game.pov.hitpoints = game.pov.hitpoints + this.eathealth
}
if (HasInt(game.pov, "mana")) {
game.pov.mana = game.pov.mana + this.eatmana
}
if (HasString(this, "eatmsg")) {
msg (this.eatmsg)
}
else {
msg (DynamicTemplate("Eaten", this))
}
if (HasScript(this, "tastedesc")) {
do (this, "tastedesc")
}
if (HasInt(this, "lastsfor")) {
MakeObjectInvisible (this)
}
else {
destroy (this.name)
}
</eat>
<eathealth type="int">0</eathealth>
<eatmana type="int">0</eatmana>
</type>
Next (conceptually) was to make a Fungus Type, which could be selected from the Edible Tab's dropdown:
<type name="fungus">
<inherit name="editor_object" />
<inherit name="edible" />
<inherit name="merchandise" />
<inherit name="useasother" />
<feature_edible />
<feature_combat />
<scenery type="boolean">false</scenery>
<feature_usegive />
<useasotherverb>eat</useasotherverb>
<sense_able />
<attr name="status_descriptions" type="boolean">false</attr>
<destroyonsale />
<starteateffect type="script">
do (this, "eateffect")
game.pov.currentbelly = this
game.pov.eateffcountdown = this.lastsfor
if (GetBoolean(this, "cannothold")) {
DropEverything
}
if (HasObject(this, "specialattack")) {
game.pov.equipped = this.specialattack
}
</starteateffect>
<endeateffect type="script">
game.pov.currentbelly = null
if (HasScript(this, "terminate")) {
do (this, "terminate")
}
if (HasObject(this, "specialattack")) {
game.pov.equipped = fists
}
destroy (this.name)
</endeateffect>
</type>
The Edible Tab now needs updated as such to better include CombatLib... It can be found in CoreEditorObjectOptions3:
<tab>
<parent>_ObjectEditor</parent>
<caption>[EditorObjectOptionsEdible]</caption>
<mustnotinherit>editor_room</mustnotinherit>
<onlydisplayif>this.feature_edible</onlydisplayif>
<control>
<controltype>dropdowntypes</controltype>
<caption>[EditorObjectOptionsEdible2]</caption>
<types>*=[TypeCannotEaten]; edible=[TypeCanEaten]; fungus=Fungus</types>
</control>
<control>
<controltype>number</controltype>
<attribute>eathealth</attribute>
<caption>[EditorObjectOptionsChangehealth]</caption>
<mustinherit>edible</mustinherit>
<onlydisplayif>game.showhealth or game.feature_DescriptionsTab</onlydisplayif>
</control>
<control>
<controltype>number</controltype>
<attribute>eatmana</attribute>
<caption>Change Mana by</caption>
<mustinherit>edible</mustinherit>
<onlydisplayif>game.feature_mana</onlydisplayif>
</control>
<control>
<controltype>textbox</controltype>
<attribute>eatmsg</attribute>
<caption>[EditorObjectOptionsMessageEat]</caption>
<nullable/>
<mustinherit>edible</mustinherit>
</control>
<control>
<controltype>script</controltype>
<caption>Eat Effect (what happens when eaten)</caption>
<attribute>eateffect</attribute>
<mustinherit>edible</mustinherit>
</control>
<control>
<controltype>label</controltype>
<caption>Below are for use if the fungus has a turn-limited effect.</caption>
<mustinherit>fungus</mustinherit>
</control>
<control>
<controltype>number</controltype>
<caption>Last for (turns)</caption>
<attribute>lastsfor</attribute>
<width>100</width>
<mustinherit>fungus</mustinherit>
<minimum>1</minimum>
</control>
<control>
<controltype>script</controltype>
<caption>Script to run when the effect has finished (remember to also include a message to describe any changes)</caption>
<attribute>terminate</attribute>
<mustinherit>fungus</mustinherit>
</control>
<control>
<controltype>checkbox</controltype>
<caption>Cannot hold anything during effect?</caption>
<attribute>cannothold</attribute>
<mustinherit>fungus</mustinherit>
<nullable/>
</control>
</tab>
And so as you review these type and tab changes (if you're familiar with CombatLib) you can see that it uses something very similar to his lasting magic effect/potion effect system.
The scripts on the fungus starteateffect and endeateffect are versions of startmagiceffect and endmagiceffect from the type "magicaleffectprovider"
This means that in CombatStuff3.xml in the "attacktheplayerturnscript" you need to add some code similar to that which handles "magiccountdown"
// Check for Edible effect expiring
if (not HasInt(game.pov, "eateffcountdown")) {
game.pov.eateffcountdown = 0
}
if (game.pov.eateffcountdown > 0) {
game.pov.eateffcountdown = game.pov.eateffcountdown - 1
if (game.pov.eateffcountdown < 1) {
do (game.pov.currentbelly, "endeateffect")
}
}
et voila! You now have several CombatLib options related to your edibles which are easily adjustable in the editor:
You can use the same exact health attribute to add/subtract from Hitpoints that was already in the core
You can perform the same behaviors with a mana attribute
You can give any edible an "eateffect" script
You can turn your edible into a fungus by selecting "fungus" instead of "edible" in the dropdown and add the additional functionality of making the "eateffect" last a specified number of turns like a spell or potion.
It also includes "tastedesc" description/script if you're using my senses or the updated weatherlib. You can delete that row if not wanting to use or change it if you've got your own senses worked out in your game.
Also, to have the game recognize whether you've selected to use Shops, Combat, or Mana, etc. and update the appropriate attributes I've modified CoreStatusAttributes3 as follows:
<function name="InitStatusAttributes">
<![CDATA[
if (game.showscore) {
game.score = 0
if (game.statusattributes = null) {
game.statusattributes = NewStringDictionary()
}
dictionary add (game.statusattributes, "score", "[Score]: !")
}
if (game.feature_DescriptionsTab) {
game.pov.xp = 0
if (game.povstatusattributes = null) {
game.povstatusattributes = NewStringDictionary()
}
dictionary add (game.povstatusattributes, "xp", "XP: !")
}
if (game.showhealth) {
if (game.povstatusattributes = null) {
game.povstatusattributes = NewStringDictionary()
}
dictionary add (game.povstatusattributes, "health", "[Health]: !%")
}
if (game.feature_DescriptionsTab) {
if (game.povstatusattributes = null) {
game.povstatusattributes = NewStringDictionary()
}
dictionary add (game.povstatusattributes, "hitpoints", "Hitpoints: !")
}
if (game.feature_mana) {
game.pov.mana = 0
if (game.povstatusattributes = null) {
game.povstatusattributes = NewStringDictionary()
}
dictionary add (game.povstatusattributes, "mana", "MP: !")
}
if (game.showmoney) {
if (game.povstatusattributes = null) {
game.povstatusattributes = NewStringDictionary()
}
dictionary add (game.povstatusattributes, "money", "[Money]: !")
}
if (HasAttribute(game, "feature_ShopLib")) {
set (game, "moneyformat", "£!1.2!")
}
]]>
</function>
I've also added some "player" combat controls to the combat tab based on following Pixie's documentation and attributes he tells you are available.
<!-- Player -->
<control>
<controltype>checkbox</controltype>
<caption>Has venom glands?</caption>
<attribute>haspoisonglands</attribute>
<mustinherit>editor_player</mustinherit>
</control>
<control>
<controltype>textbox</controltype>
<caption>Display when player tries to talk if this player object cannot talk</caption>
<attribute>gagstring</attribute>
<mustinherit>editor_player</mustinherit>
</control>
<control>
<controltype>objects</controltype>
<caption>Starting Weapon</caption>
<attribute>equipped</attribute>
<mustinherit>editor_player</mustinherit>
</control>
<control>
<controltype>objects</controltype>
<caption>Starting Shield</caption>
<attribute>shield</attribute>
<mustinherit>editor_player</mustinherit>
</control>
<control>
<controltype>textbox</controltype>
<caption>Starting Status effect</caption>
<attribute>status</attribute>
<mustinherit>editor_player</mustinherit>
</control>
<control>
<controltype>number</controltype>
<caption>Starting Hitpoints</caption>
<attribute>hitpoints</attribute>
<width>100</width>
<mustinherit>editor_player</mustinherit>
<minimum>1</minimum>
</control>
<control>
<controltype>number</controltype>
<caption>Starting Mana Points</caption>
<attribute>mana</attribute>
<width>100</width>
<mustinherit>editor_player</mustinherit>
<onlydisplayif>game.feature_mana</onlydisplayif>
<minimum>1</minimum>
</control>
<control>
<controltype>number</controltype>
<caption>Starting Mana Max</caption>
<attribute>mana_max</attribute>
<width>100</width>
<mustinherit>editor_player</mustinherit>
<onlydisplayif>game.feature_mana</onlydisplayif>
<minimum>1</minimum>
</control>
<control>
<controltype>number</controltype>
<caption>Starting Mana Bonus</caption>
<attribute>mana_bonus</attribute>
<width>100</width>
<mustinherit>editor_player</mustinherit>
<onlydisplayif>game.feature_mana</onlydisplayif>
<minimum>1</minimum>
</control>
<control>
<controltype>number</controltype>
<caption>Default Strength</caption>
<attribute>strength</attribute>
<width>100</width>
<mustinherit>editor_player</mustinherit>
<minimum>1</minimum>
</control>
<control>
<controltype>number</controltype>
<caption>Default Agility</caption>
<attribute>agility</attribute>
<width>100</width>
<mustinherit>editor_player</mustinherit>
<minimum>1</minimum>
</control>
<control>
<controltype>number</controltype>
<caption>Default Stamina</caption>
<attribute>stamina</attribute>
<width>100</width>
<mustinherit>editor_player</mustinherit>
<minimum>1</minimum>
</control>
<control>
<controltype>number</controltype>
<caption>Default Intelligence</caption>
<attribute>intelligence</attribute>
<width>100</width>
<mustinherit>editor_player</mustinherit>
<minimum>1</minimum>
</control>
Eventually I'll work out the best way to integrate the recipe/venom system so that creators who wish to use that functionality that Pixie created don't have to work so hard to made additional recipes and venom. It's on a to-do list, but so are many other things that look more fun to me. For now, player venom is easy to toggle, congratulations, you can spit on your weapon now.
I'm also planning to work out the best way to deal with "fists" in case creators want to easily change/modify the default "unequipped" attack object.
Have added to the editor on "CoreEditorGame3.aslx" so that you can easily add/remove status attribute names in the dictionary that Pixie has you set up in the documentation. It's now on the Player tab:
<tab>
<caption>[EditorGamePlayer]</caption>
<advanced/>
<control>
<caption>[EditorGamePlayerobject]</caption>
<attribute>pov</attribute>
<controltype>objects</controltype>
<advanced/>
</control>
<control>
<onlydisplayif>game.pov = null</onlydisplayif>
<advanced/>
<controltype>label</controltype>
<caption>[EditorGameIfnoplayer]</caption>
</control>
<control>
<controltype>script</controltype>
<attribute>onhealthzero</attribute>
<onlydisplayif>game.showhealth</onlydisplayif>
<caption>[EditorGameScripttorun]</caption>
</control>
<control>
<controltype>textbox</controltype>
<caption>[EditorGameMoneyformat]</caption>
<attribute>moneyformat</attribute>
<onlydisplayif>game.showmoney</onlydisplayif>
<width>50</width>
</control>
<control>
<controltype>stringdictionary</controltype>
<caption>[EditorGamePlayerobjectStatus]</caption>
<keyprompt>[EditorGameAttributesPleaseenter]</keyprompt>
<valueprompt>[EditorGameAttributesPleaseenter2]</valueprompt>
<attribute>povstatusattributes</attribute>
<advanced/>
</control>
<control>
<controltype>stringdictionary</controltype>
<caption>Stat Names</caption>
<keyprompt>attribute name</keyprompt>
<valueprompt>Name for attribute player sees</valueprompt>
<attribute>statnames</attribute>
<advanced/>
</control>
</tab>
And checked that ondeath mechanism incorporates xp
I wanted to make a help commands editor, but it's currently beyond me. If anyone knows how to create controls in the game object editors that would be able to override commands? Otherwise, it might just be that people have to override those the "hard" way.
But if Pixie mentioned in his documentation to create or override a script, I've already added them or plan to add them to the editors in the appropriate places.
Anyway, here's hoping that this stuff is interesting/useful to someone.
Finally having some time to work on these integrations again. So much fun and so much of a learning experience for me personally!
So the ChangePOV function was created without the full CombatLib from Pixie in mind. In order to switch to another player object when using CombatLib, you need to update InitPOV function so that it does the portions of CombatInitialise function from Pixie's library that set important attributes from game.pov .
Also, in my integrated library, I've created controls for the Combat Tab on "Player" objects so that you can now have a default attack other than fists. This is great for creating something like an animal or monster that the player can become. Took a little figuring, out, but now I can set "claws" as an invisible object-weapon-attribute with the cat as a parent and when player becomes parent, game.pov "defaultunequipped" is now "claws" instead of whatever it used to be. I also added for fun a "defaultequipped" in case you want someone to start out with a sword, etc.
This of course also required an update to the ChangeEquiped change script on weapon types so that it checks for the new attribute "defaultunequipped" and modification to the player type so that it's defaultunequipped is "fists"
I'll also need to update DropEverything to check defaultunequipped, and Endmagiceffect and the weapon-type's unequip script. maybe scriptholder's changedequip. But it's worth the initial setup to add this feature I think.
Looking at updating initPOV, I decided it might actually better to create a function which acts like a sort of patch. It can be called just after changePOV to do the additional needed "housekeeping." I'll do upgrades to it as I find more things that need to be added to game.pov after the switch with all the libraries integrated. For now it looks like this:
<function name="Core3InitPOVpatch">
if (game.showmoney) {
if (not HasScript (game.pov, "changedmoney")) {
game.pov.changedmoney = scriptholder.changedmoney
}
}
if (game.feature_DescriptionsTab) {
if (not HasScript (game.pov, "changedhitpoints")) {
game.pov.changedhitpoints = scriptholder.changedhitpoints
}
if (not HasScript (game.pov, "changedequipped")) {
game.pov.changedequipped = scriptholder.changedequipped
}
if (not HasScript (game.pov, "changedshield")) {
game.pov.changedshield = scriptholder.changedshield
}
atts = "money;turncount;armour;armour10;stamina;xp;ob_bonus;next_round_ob_bonus;db_bonus;defence;magiccurse;sneaklevel;magiccountdown"
atts = atts + ";attackbonus;defencebonus;armourbonus;magicbonus;damagebonus"
atts = atts + ";strength;agility;stamina;intelligence;pointsleft"
foreach (s, Split(atts, ";")) {
if (not HasInt (game.pov, s)) {
set (game.pov, s, 0)
}
}
foreach (att, game.statnames) {
if (not HasInt(game.pov, att)) {
set (game.pov, att, 0)
}
}
game.pov.immunities = NewStringList()
game.pov.dead = false
UpdateStatusAttributes
UpdateStatus
UpdateArmour
UpdateHitPoints
}
if (game.feature_mana) {
SetMana
}
</function>
I'm making notes to update the above function with checks for creator-added attributes on the new POV as well. There will have to be editor-tab updates to include scriptdictionary and something like a "specatts" attribute to have the change add and update as well. This allows creators to make something like a "cat" which might have different attributes and stats than the original POV.
Now that I see that the Core3InitPOVpatch function is essentially acting like the CombatInitialise for a POV switch, it might be something like having ChangePOV call specialized initialisation scripts after checking whether a library is being utilized via a checkbox on the Features tab.
it might be something like having ChangePOV call specialized initialisation scripts after checking whether a library is being utilized via a checkbox on the Features tab.
I think it shouldn't be called from ChangePOV.
If your function needs to be called whenever the pov changes, you should call it from game.changedpov
Thank you MrAngel!
The changedPOV script on the defaultgame type had eluded me as part of this equation for so long!
I think you're right. Whatever patch function(s) end up being used should be added to the changed script on the game object.
I didn't even consider that there's a "game" type! I'd been wondering how to update the game object with core integration changes, and have been doing weird things in initialisation scripts and start scripts. These can maybe all be moved over to the game object as an attribute of the type like ChangedPOV. These ChangedPOV patches called from ChangedPOV. (I don't know if anything other than CombatLib needs to be integrated that way yet, but I don't think so.)
It looks like these things need something like at least 2 components:
an initialisation at game start if they're adding attributes to player/game that the library is constantly checking for
something like an update to the changedpov script on the game object which makes sure needed attributes are updated upon POV change as well.
The example is from Pixie's CombatInitialise, but I do want to make it so that attributes any creator adds are also added to the POV during a change if they're needed.
MrAngel, you're truly a gem and hero!
One problem I've been working on is allowing the game creator to modify extant help commands from the integrated libraries.
One way might be to incorporate a system of delivering instructions in-editor for overriding the commands when feature checkboxes are ticked. (maybe part of the tabs that go with those libraries).
I was thinking of a "Help Commands" tab or an "overrides" tab on the game object.
But just recently I was seeing how Pixie's "scriptholder" object works in his CombatLib and wondered.
If copies of the script portion of the commands were attributes on the Game Object, and then there was a function that ran at start which "initiated" the custom commands by changing the extant command to incorporate the creator's script changes...
would that be easier or harder for the average user than simply overriding the commands and modifying them in the built-in editor?
Or is there a way to automatically make an editable copy of a command when a feature checkbox is checked (overriding it)?
It took me an embarrassingly long amount of time to discover the override feature, and I was going back to original files to change things and see if it worked and saving test version files rather than overriding within a test game. (SMH)
I feel like there's a few things I'm learning backwards or in less-efficient order than maybe I should. But it's simply fun for me to learn either way.
So, had been overthinking a bit with the idea of creating a separate patch for the POV changing.
After re-looking at MrAngel's advice and where to stick the patch, and re-looking at what the patch is made of, essentially rather than a "patch" the game.changedpov would only need to call the initialisation functions from any library like CombatLib's Combatinitialise again. Or maybe call a modified version of them.
I'll have to check carefully, but I think it might be as simple as adding combatinitialise to be called by changedpov in this case.
Mr. Angel was giving me some advice on integrating the WeatherLib into the core in a thread on a different topic here https://textadventures.co.uk/forum/quest/topic/tdkgofzjmeyuet_c10vvta/no-verb-objectobject-on-hover
I also just remembered as I was about to start work the entire reason why the weather objects follow the POV around in the game. they're background objects where the look scripts read attributes off of game.currentweather. That's how the game creator customizes the different "lightning" or "rain" or whatever interactions to line up with their weather room. Then whatever "currentweather" is set, a "look", "touch," "taste," etc. for these objects reads off game.currentweather's settings for the weather.
So customizing whether these objects move into the room with the player or not for an individual room may or may not be redundant. If someone didn't set the weather room's "taste rainbow" script to either print something, or do something, then the default is already pre-programmed as if there's no rainbow in the room for any actions on the rainbow.
Still, it might be handy if someone wanted to simply not have the objects there, rather than have a bunch of pre-programmed defaults in case the user tried to look at the snow, etc. It would go back to the game default for looking at things that aren't objects in the room. At any rate, I'm liking the idea of moving many of the weather turnscripts and functions to outside or windowed typed rooms rather than having them set to run every game turn by default and do nothing only if a room is flagged "inside."
Follow us on Facebook
Follow @TextAdv on Twitter