Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

Working on Jesse, again

2005-04-30
2013-04-23
  • Summer is here so I will have to work on the improvements I plan on for Jesse.  I'm getting ready to draft up a specifications for my input file for map tile data and I needed you guys input on a question.  How big on file names do you guys plan on making the graphics?

    Would 15 characters (not counting the file extension since assumedly all graphic files would use the same extensions) be enough to handle the planned growth you give for the names of the graphic files?  Whatever specs you guys want to stick to on names doesn't bother me, I just want to leave room for planned growth when I start the specs and creating the separate program to write the data to a binary file.

     
    • Sean Ford
      Sean Ford
      2005-05-06

      I would think 15 characters could be restrictive in some cases. 30 would be safer. Ideally, I think there shouldn't really be a limit, except for the filesystem name limit.

      Yeah, I am hoping to get some more work done too as we approach summer. I am on the quarter system at school which makes it tough to get coding in during the quarter.

       
      • "30 would be safer. Ideally, I think there shouldn't really be a limit, except for the filesystem name limit. "

        Only reason I want a limit because I'm storing data.        The sample form I uploaded to the gladiator group uses a limit of 50 characters for folder name and 20 for tile names and smoother types.  But that's just the gui so I can expand it out.  I'm going to expand the length of the folder name out to 60 characters and graphic file name to 30 (not counting the extension) and the Smoother-type name to 60.

        How do you guys want to store the radar color information for each tile?  3 different numbers: 1 for the amount of red, 1 for the amount of blue, 1 for the amount of green or some other scheme?

        It doesn't bother me.

        Great, I just remembered that I forgot to allow the user to select pasable status for each tile.  Hmm, that doesn't effect me, but it'll have an effect on you guys.

        * * * *

        The reason I made, in James, the image height and image width property, umm, able to changed is I see applications for Jesse .02 beyond Gladiator and I want to code for flexibility.  Also, this means down the road if you guys want to use different size tiles than we're currently using, my program can already handle it. :-)

         
    • 30 characters?  np.  If I don't have the ability to use those graphic files in my program yet, I still want that information listed.  Right now, the specs for that map tile file look like the following:

      1st line: version number of this file - not that I'm counting on  updating this file, I want room for change down the road
      2nd line: number of map tiles - I'm not overly fond of coding to read until eof if I want to add more details after this list of files, I'm prepared.

      the rest of the data is a set of repeated records consisting of the following:
      1)map tile number
      2)internal map tile name - a string
      3)smoother type - string name - (obviously used for the smoother function; eliminates calling a function)
      [The next three values are RGB color combos used for representing the map tile on the built-in radar  - hopefully this doesn't counterdict your plans, but having these values here eliminates the use of a couple of functions]
      4)int - 0 to 255 - amount of red used in radar view
      5)int - 0 to 255 - amount of green used in radar view
      6)int - 0 to 255 - amount of blue used in radar view
      7)graphic file name - string - the file name of the graphic file associated with this file minus the extension

      Is there anything else you guys think needs to be added to this list of related data?