Changes

→‎Medium changes: move consistent display name usage to done
Line 6: Line 6:     
===Small changes===
 
===Small changes===
* ☐ Change all remaining <code>internal class</code> and <code>private class</code> to <code>public class</code> to simplify mod access.
+
''All done!''
<li>☐ Make methods virtual:
  −
{| class="wikitable"
  −
|-
  −
! class
  −
! methods
  −
|-
  −
| <samp>Background</samp>
  −
| <samp>draw</samp>, <samp>update</samp>
  −
|}</li>
      
===Medium changes===
 
===Medium changes===
* ☐ Some XNB files have a separate display name field, but only in non-English. Using display names consistently regardless of language would let mods rename things without breaking keys:
+
* ☐ Add map property for default warp location (e.g. <samp>Utility.getDefaultWarpLocation</samp>).
** ☐ <samp>Data\Bundles</samp>
  −
** ☐ <samp>Data\CraftingRecipes</samp>
  −
** ☐ <samp>Data\CookingRecipes</samp>
  −
** ☐ <samp>Data\Weapons</samp>
  −
* ☐ Remove hardcoded logic that ignores display names when playing in English (e.g. for NPC gift taste dialogues); can search <code>LocalizedContentManager.LanguageCode.en</code> to find many of them. That causes a bug where renamed NPCs still show their internal name in some places.
      
===Refactoring===
 
===Refactoring===
* ☐ Add unique item keys and allow custom spritesheets per item. This would eliminate the current complexities with adding custom items to Stardew Valley, make code much more readable, simplify troubleshooting mod errors, and make it possible to support any item type in cases like sending mail. See the [https://gist.github.com/Pathoschild/92d1fcb7c2ffeb7e1461c242cdb025e2 detailed proposal doc].
   
* ☐ Change all <code>const</code> fields to <code>static readonly</code>. They're accessed the same way and the performance difference is negligible, but that'll make the decompiled code much easier to understand, and avoid issues where const values get 'baked in' to mod assemblies.
 
* ☐ Change all <code>const</code> fields to <code>static readonly</code>. They're accessed the same way and the performance difference is negligible, but that'll make the decompiled code much easier to understand, and avoid issues where const values get 'baked in' to mod assemblies.
  
translators
8,438

edits