Really Noobish Question (Simple if-else Statements) (SugarCube)

Comments

• greyelf

  September 2014

  The answer is simple, every time you change passages the built-in java-script engine clones all the $variables (and their properties) so the originals can be added to the History sub-system.
  
  So the second time the IF gets executed the instance of the ArmorPiece object that is stored within the $Player.Armor.Torso variable is no longer the same one as the one stored in window.Nothing, even thought both of these instances of ArmorPiece have the same property values. (eg Slot, Name, Description, Armor)
• EcnelOvelam

  September 2014

  greyelf wrote:

  
  The answer is simple, every time you change passages the built-in java-script engine clones all the $variables (and their properties) so the originals can be added to the History sub-system.
  
  So the second time the IF gets executed the instance of the ArmorPiece object that is stored within the $Player.Armor.Torso variable is no longer the same one as the one stored in window.Nothing, even thought both of these instances of ArmorPiece have the same property values. (eg Slot, Name, Description, Armor)
  

  
  
  Any workaround to achieve what I'm trying to do?
• greyelf

  September 2014

  If your creating a RPG and don't need to allow the Player to undo their choices then you can disable the History Tracking sub-system via the  config.disableHistoryTracking option.
  
  Otherwise you could add a property to the ArmorPiece prototype that is only set true in the Nothing instance and test against that instead

  
window.ArmorPiece = function(Slot, Name, Description, Armor){
this.Slot = Slot;
this.Name = Name;
this.Description = Description;
this.Armor = Armor;
this.isNothing = false;
};

window.Nothing = new ArmorPiece(Player.Armor.Torso, "Nothing", "You Don't Have Anything Equiped In This Slot.", 0);
window.Nothing.isNothing = true;

window.Hat = new ArmorPiece(Player.Armor.Head, "Hat", "A Simple Hat, With A Random Logo On It And Such.", 5);

:: Start
<<if not $Player.Armor.Torso.isNothing>><<click "Unequip" "Start">><<set $Player.Armor.Torso = Nothing>><</click>><</if>>


• TheMadExile

  September 2014

  EcnelOvelam wrote:

  
window.Player = {
Armor: {
Head: NaN,
Torso: NaN,
Hands: NaN,
Legs: NaN,
Feet: NaN,
}
}


  
  
  NaN (floating point: Not a Number) is not null.  Also, statements end in semi-colons.  That should be:

  
window.Player = {
Armor : {
Head : null,
Torso : null,
Hands : null,
Legs : null,
Feet : null
}
};


  
  

  greyelf wrote:

  
  If your creating a RPG and don't need to allow the Player to undo their choices then you can disable the History Tracking sub-system via the  config.disableHistoryTracking option.
  

  
  
  Sadly, that will not solve the issue here (I assume you were thinking it would).  Even with config.disableHistoryTracking enabled, the $variable store is still cloned every turn.  This is to keep the turn-by-turn behavior w/r/t $variables consistent between the two modes.  All config.disableHistoryTracking does is limit the history stack to one state (i.e. the stack is popped just before a new state is about to be pushed).
  
  
  @EcnelOvelam: I'd probably have suggested something similar to what greyelf just did (i.e. the isNothing property).  You could do it other ways (e.g. like checking the Name: <<if $Player.Armor.Torso.Name neq "Nothing">>), however, doing it as a separate property is cleaner and allows you to change the name of your Nothing armor in the future without having to redo all your conditional checks.
  
• greyelf

  September 2014

  @TheMadExile
  

  TheMadExile wrote:

  
  NaN (floating point: Not a Number) is not null.
  

  
  I'm aware of the differences between NaN and null.
  I assumed he was using NaN to track that the property had never been assigned a value vs null meaning the property currently has no value, its a technique I have seen used before.
  
  [quote]
  Sadly, that will not solve the issue here (I assume you were thinking it would).  Even with config.disableHistoryTracking enabled, the $variable store is still cloned every turn.
  
  I will have to remember this.
  Have you thought about allowing the objects' clone method to be aware of the flag and having it returning a reference to the original object if the flag is set, this should allow the rest of the related code to stay unaware that it is not dealing with a new instance (clone) of the object.
• TheMadExile

  September 2014

  greyelf wrote:

  
  I'm aware of the differences between NaN and null.
  I assumed he was using NaN to track that the property had never been assigned a value vs null meaning the property currently has no value, its a technique I have seen used before.
  

  
  
  I never said you weren't.  I was responding to EcnelOvelam (check the origin of my quote there).
  
  Personally, I thought they were just confused about what to do there, especially considering that they immediately set some of those very properties (and so, they're obviously not checking those for undefined-ness).  /shrug
  
  
  

  greyelf wrote:

  
  Have you thought about allowing the objects' clone method to be aware of the flag and having it returning a reference to the original object if the flag is set, this should allow the rest of the related code to stay unaware that it is not dealing with a new instance (clone) of the object.
  

  
  
  If you actually meant an object's custom clone() method, then that is already possible.  On the other hand, if you meant SugarCube's clone() function (and simply misspoke), then I have not thought about it, since, as I noted in my previous reply, the whole reason why I didn't do that to begin with was to keep the turn-by-turn behavior consistent.
  
  Regardless, it's largely a moot point, however, since neither the delta coding code nor the serialization code will preserve referential relationships.  So, even if clone() did preserve referential relationships (either by caching references or simply by not cloning at all), relationships would be lost as soon as either a history navigation was triggered (since all non-active history stacks are delta encoded, and most serialized as well) or a save was loaded (since all saves are both delta encoded and serialized).