1. We have added the ability to collapse/expand forum categories and widgets on forum home.
    Dismiss Notice
  2. All Civ avatars are brought back and available for selection in the Avatar Gallery! There are 945 avatars total.
    Dismiss Notice
  3. To make the site more secure, we have installed SSL certificates and enabled HTTPS for both the main site and forums.
    Dismiss Notice
  4. Civ6 is released! Order now! (Amazon US | Amazon UK | Amazon CA | Amazon DE | Amazon FR)
    Dismiss Notice
  5. Dismiss Notice
  6. Forum account upgrades are available for ad-free browsing.
    Dismiss Notice

Mod for Pitboss Games

Discussion in 'Civ4 - PitBoss Games' started by Ramkhamhaeng, Sep 4, 2014.

  1. Ramkhamhaeng

    Ramkhamhaeng Chieftain

    Feb 24, 2014
    Hello DarkLunaPhantom,

    there are a few 'reasons' for this approach.
    1. Previous versions of PBSpy parses the year information only. The month information was attached later and adding it in the upper bits was the easiest solution.
    2. I prefer the storage of numbers over strings.
    3. For security reasons the input string should not be stored/displayed without any parsing. I wrote the most restrictive parsing function and wait until somebody needs a more flexible solution.
    (Well, this point is not 100% valid because two fields, game name and mod name, are string fields the values were currently saved raw. :) I will update this in the next version and strip out tags, etc...)
    4. The Pitboss server method CyPitboss().getGamedate(bSavegameSyntax) depends on the selected language. This could mess up the displayed string on the interface. A new more robust/general solution should respect this.

    It exists two possible solution.
    A) Simply display the full calendar string, given getGamedate() a.k.a. CyGameTextMgr::getDateStr(...). This approach will work for all mods, too. (Your suggestion)
    B) Write an own function, similar to getDateStr, which returns all information in a predefined, language independent form. This is secure, but do not respect new/fancy calendar types. Disadvantage is complexity and redundancy.

    Currently, I prefer solution B.
  2. DarkLunaPhantom

    DarkLunaPhantom Chieftain Supporter

    Feb 4, 2013
    Just adding all other months (other than January and July) to current parsing function would cover most use cases. That should be more than enough until (and if) someone is eventually willing to spend time to implement solution B.

Share This Page

Ebates: Get Paid to Shop