Directory structure

[La Muerte]

Code: Select all

Also the current implemenation only uses a single language file (like es, with en=,de=,whaterver= tags), no en/de/whatever subdirectories. As such, you'll have a single language file per plugin, or in rare cases multiple if the plugin uses more then one (internally!).


That could get ugly when multiple translators try to work for a different language at the same time, one of them will have to start over.

I really, really like how SourceMod arranges their language files, specially their dev area for translators. It is genius. http://www.sourcemod.net/translator/?go=translate&op=status

[satoon101]

The loadable sub-addons is still not going to happen :P . However, I have been planning adding a built-in system designed to help do that job for plugins. More details on that once I have gotten at least some of that coded.

Satoon

[satoon101]

That could get ugly when multiple translators try to work for a different language at the same time, one of them will have to start over.

I much prefer having one translation file over having one for each language...

Satoon

[La Muerte]

I do too but only for small projects

[satoon101]

Trust me, GunGame is not a "small" project, and it works out "much" better having languages set up the way we did in GG51.

Satoon

[Omega_K2]

That could get ugly when multiple translators try to work for a different language at the same time, one of them will have to start over.

I really, really like how SourceMod arranges their language files, specially their dev area for translators. It is genius. http://www.sourcemod.net/translator/?go=translate&op=status

You can just merge the files if you have 2 different versions (and, if any conflicts occur fix them manually). This is not much of an issue usually. The only problem I can see is getting huge files if many translations are present or trying to keep translations up to date, but you'd need a more elaborate system in place first.
But for modular stuff it still works, see my definelty not final RPG translations:

https://svn.german-slaughterhouse.de/svn/gsrpg/trunk/resource/source-python/translations/gsrpg/

[La Muerte]

Gungame is a massive project, so you need to wait until one translator is done with the file before another translator of another language can start with it?

Edit:

You can just merge the files if you have 2 different versions

Ah ok, I didn't think of that .

[satoon101]

Ummm, no... You can merge changes, just as Omega mentioned in the post above your's. It really isn't that difficult.

Satoon

[satoon101]

Also, we broke our language files out so that they were grouped together by what they were for. This looks to be the way Omega has done his in the link he provided. It is a much better way to do things than having one gigantic file.

Satoon

[Omega_K2]

The loadable sub-addons is still not going to happen :P . However, I have been planning adding a built-in system designed to help do that job for plugins. More details on that once I have gotten at least some of that coded.

Satoon

It's not that hard implement, but overkill if you don't want any extra features, just simple loading of sub-addons. The reason to have such a thing is to get a clear directory structure

[satoon101]

Yeah, I need this functionality for GunGame anyway, so I already had planned on creating it within SP's API itself. I am trying to work out a way to create a base class that even AddonManager (which will probably be renamed PluginManager here soon) will inherit from.

Satoon

[La Muerte]

ok, languages thing I fully agree with now

as for site_packages, why not just put under engines again? and also, please add sqlite3 in there as well if it isn't anywhere else yet

[satoon101]

sqlite3 comes with Python, so we don't really need to "add" it. mysql, on the other hand, does not. We might consider adding that at some point, but so far, we have only added site-packages that we are actually "using" with the API.

Satoon

[satoon101]

Ok, having thought a little more about it, I am liking the following structure:

• addons/source-python/
  • bin/
    • core binaries
  • data/
    • custom/ - data for custom packages
    • plugins/ - data location for plugins
    • source-python/ - data for SP's Python API
  • packages/
    • custom/ - custom packages created by SP scripters
    • source-python/ - SP's Python API
  • plugins/
    • user made addons to be loaded by "sp load"
  • python/
    • site-packages

All of the other folders are lower-case, so I think I would want to leave "python" that way as well. I would name it python3, but if we migrate to Python4 (since we have stated we want to keep our Python version at the most up-to-date version), I would hate to completely change the directory name at that time. I am still considering moving site-packages inside of the "packages" directory. However, since Python naturally has site-packages within its core packages, I think it might be best to leave it as-is.

Satoon

[Omega_K2]

I doubt "python4" is coming anytime soon, unless they are going to change their naming scheme.

[La Muerte]

isn't "python" looking a bit strange a as a sub-folder of source-python?

addons/source-python/python

you could just put all python files in there, thats what i'd expect when seeing that structure : /

python has a too board meaning in my opinion to really make sense in this context

whats wrong with engines? xD

[mister-man]

Good morning after a long night

Languages:
I like to put all languages in one file. So all translation are clearly structured.

Structure:

• addons/source-python/
  • bin/
    • core binaries
  • data/
    • custom/ - data for custom packages
    • plugins/ - data location for plugins
    • source-python/ - data for SP's Python API
  • packages/
    • custom/ - custom packages created by SP scripters
    • source-python/ - SP's Python API
  • plugins/
    • user made addons to be loaded by "sp load"
  • python/
    • site-packages

I thng it's a good way to structure the folder.
But is one folder with all data not enough? Further a default datalocation (take a look on sm) for plugins without its own datastructure would be nice.

Subscripts:
I have no idea of it works, but at these time I use for subscript importing these code:

Code: Select all

# Import all submudules
__import__ = ['player']
LoadLib = loadlib.loadlib()

def loadPlugins():
    for mod in __import__:
        LoadLib.aodLoad(mod)


Code: Select all

# =============================================================================
# >> IMPORTS
# =============================================================================
import imp


# =============================================================================
# >> CLASSES
# =============================================================================

class loadlib(object):
    def __init__(self):
        self.__loadL = []
       
    def __del__(self):
        pass
       
    def aodLoad(self, item):
        # Format aodloader output
        print('Try to load: ' + item)
        path = 'AoD' + '/' + '_plugins' + '/' + item + '.py'
        importstr = 'AoD' + '.' + '_plugins'  + '.' + item
        print('    Load: ' + path)
        print('    Import: ' + importstr)
        # Load plugin
        try:
            # import .py file
            exec('from AoD._plugins import ' + item)
            self.__loadL.append(item)
        except Exception as e:
            # Print loading error
            print("    Load error: ", e)
        # Exec load section
        try:
           
            exec(item + '.load()')
        except:
            print('    ' + item + ': No load section found')
           
    def aodUnload(self, item):
        pass
       
    def aodList(self):
        pass


But I have no idea of it works, and I thing there a better way. I'm rally new at SP and it would easier for new script authors to have a build in subscript system!

[satoon101]

We are starting to get a bit off-topic with the sub-addon discussion, but I have to comment a bit on your code.

First, do not use __import__ as a variable. __import__ is already a built-in function in Python. You actually should be using either __import__ or importlib to load the sub-addons, and NOT exec. I have programmed quite a bit in Python over the last several years, and I can honestly say I have never used "exec". Not saying it doesn't have its place, but it should definitely not be used in this context.
http://docs.python.org/3/library/functions.html#__import__
http://docs.python.org/3.4/library/importlib.html



As far as data folders, I much prefer separating types of data from each other. Having one folder "could" cause folder name duplication. For instance, what if a custom package has data that it wants to put in a "player" directory. Then, we also have a "player" directory already in the "data" folder for the SP Python API. The files will get mixed in together, and that is not a good idea to me. I have always believed in proper separation of ideas and I don't think that will ever change.

Onto other posts. As far as why not "engines", the only place I have seen the default Python packages in a folder with that name is EventScripts. engines does not really describe, to me, what the folder actually houses. I guess, you are right, Omega, that Python 4 is probably further off than this project would need to concern itself with. Python3 or python3 would definitely describe what is in the folder, properly. I think capitalizing it will separate it from the other folders.

Satoon

[satoon101]

I have started work on this locally. I will probably make these changes when we move to GitHub. Adding/removing as many files as we are going to be doing (moving adds new ones and deletes old ones) always causes us to need multiple commits/pushes. I'm not sure if this is a limitation of Mercurial, TortoiseHg, or GoogleCode (I assume GoogleCode, but have never really tested), but I have been told it is not an issue with Git Bash and GitHub.

The structure I am currently working towards:

• addons/source-python/
  • bin/ - core binaries
  • data/
    • custom/ - data for custom packages
    • plugins/ - data location for plugins
    • source-python/ - data for SP's Python API
  • packages/
    • custom/ - custom packages created by SP scripters
    • site-packages/ - 3rd party packages
    • source-python/ - SP's Python API
  • plugins/ - user made addons to be loaded by "sp load"
  • Python3/ - the Python installation itself

Satoon