User:Inutt/CodingIdeas

From Flexible Survival
< User:Inutt
Revision as of 04:07, 29 August 2019 by Inutt (talk | contribs) (Add Glitch's info on item availability props)
Jump to: navigation, search

Coding ideas

Please note: These are just ideas that I've had and are not necessarily well thought out, are in no particular order, have no guarantee of ever actually happening, may be either impossible or inadvisable, and may contain nuts.


For any players not on the staff side of the MUCK feel free to take a look at this list, but it may not make a great deal of sense if you haven't seen the code.


  • Make indentation consistent [Happening as I edit code]
- It just makes code easier to read, enables code folding, and lining up corresponding if/then statements makes the code vastly easier to parse! (Yes, I know two of those points are the same, but it's an important one)


  • Add prop to players that have womb/other private rooms so they can be found without looping through all room objects - it would just make more sense and improve efficiency
  • Write a parameter checking function - basically an improved checkargs to highlight more clearly when incorrect parameters are passed
    • Check number of supplied parameters is actually on the stack
    • Check type of arguments
    • Something like "str:foo int:bar dbref:baz any:qux" checkparams
      • Check stack depth
      • Split on ' ' and foreach in reverse order
      • Split on ':' into type,name
      • If top of stack matches type, add to dict of parameters by name
      • Would be handy for checking the parameters are all present and of the specified type, instead of just pulling the top 'n' things off the stack and breaking with a generic error if the wrong things were passed in. (The check could produce a more detailed error message - "[funcname] called from line [x] of [calling program] expected parameters [x,y,z] but got [a,b,c]" or something)
  • Unify use and +use
  • Merge/replace hasBoxItem with findBoxItem - they both seem to do the same thing
    • hasBoxItem returns 0 or 1
    • findBoxItem returns the slot the item is found in or 0
    • findBoxItem could therefore be used for any binary checks that hasBoxItem is currently used for
    • hasBoxItem has caching due to many calls from combat code, so that would need considering if merging the functions
  • Find the various places the bodypart list ({ "arms" "ass" "legs" "cock" "head" "torso" "skin" }) is referenced and centralise it.
  • Add more RP details
    • Chastity belt affects player sex too not just NPCs? - Liquid/gel/goo players able to escape?
    • Scent always comes from skin, even if all other mutations are another species - maybe switch scent to the majority infection as per the new glance code
    • RP tick credit for players in womb room/zipper
  • Encourage RP in more areas
    • Extend RP hotspot to multiple locations
    • Needs some kind of frequently visited/RPd at tracking system - pot log tidying process maybe keep a summary when the log is cleared?
  • Fix rpo command, and add functionality
    • Option to randomise order
    • Indicate next person to pose?
    • Indicate previous people that posed, for rule-of-3 type groups (rule-of-n?)
  • Collect all fluid production/capacity functions for milk and cum into a single library, and update existing code to refer to it as necessary
  • Rewrite +groin to merge actual and real size functions to remove duplicated code
  • Allow setting player options directly instead of through the editplayer menu
    • Something like editplayer <option>=<value>
  • Sort +gear/prove output in logical groups rather than alphabetical order
    • Keep infection props of children together, rather than having them split up by the father prop
  • Use item tags to organise all items
    • Make sure to include a 'not to be handed out by +reward' tag!
      • 'availability' - used to prevent recipes showing up if they're in-progress, only available via an NPC, or other limited sources. Text field. Code (currently) only checks for existence.
      • 'reward?' - if defined, means the recipe is not valid for +reward. Should probably be renamed 'no reward'. Currently binary.
      • 'no bounty' - if defined, means the recipe is not valid for bounties (faction, top tier, makes multiple, etc). Possibly convert to enum? Code only seems to check for existence and in a couple of cases, if it contains the string "No Mako".
      • 'private' - redundant, only on one recipe that already has 'private' in availability. Can be removed.
  • Make commands consistent
    • command vs +command vs @command - IC/OOC/backend?
    • command/subcommand vs command #subcommand - second form would simplify command action naming