Allowed filetypes

All other Source.Python topics and issues.
User avatar
Project Leader
Posts: 2643
Joined: Sat Jul 07, 2012 1:59 am

Allowed filetypes

Postby satoon101 » Sat Dec 29, 2012 6:09 pm

We have been working on getting some things narrowed down on our "Addon Approval" system. One thing we thought we would open up to suggestions are the allowed file types. All files must be in a .zip file, but we will only allow certain file types to be included in the zip. So far, the list is as follows:

  • .py
  • .cfg - though possibly only allow use of config module to create these
  • .ini
  • .res - though possibly only allow use of event module to create these
  • .txt
  • .mdl
  • .vtx
  • .phy
  • .vmt
  • .vtf
  • .wav
  • .mp3
  • .spr
  • .pcf

If there are more file types we have missed, or that you would like to be able to include, please post in this thread.

Junior Member
Posts: 17
Joined: Sat Jul 07, 2012 3:53 am

Postby Logifl3x » Tue Jan 29, 2013 8:44 am

I'd suggest having the .ini files available within the .zip file because some plugins have .ini files that might be different for different maps and such requiring ConfigObj.

Unless you're thinking about making .txt for those things.
User avatar
Project Leader
Posts: 2643
Joined: Sat Jul 07, 2012 1:59 am

Postby satoon101 » Tue Jan 29, 2013 2:28 pm

The way we ended up designing the LangStrings system was to not create the files using Python. I think this is probably the best way to do it, and I actually was never really big on what cfglib.AddonINI ended up becoming. I need to add this to the thread about LangStrings, but we ended up going with a 2 file system, which is what I originally proposed for inilib (which became cfglib.AddonINI) for ES. The basic idea is that you pass LangStrings your ini file's location, and then it automatically creates a server specific file that the server operator can use to add/modify language strings to. The reason for the server specific file is so that when an addon gets updated, it should only contain the original ini, and not the server specific one, so that only the original gets overwritten. And yes, I do notice the need for other .ini files, as well, that scripters will need (especially when it comes to the dyncall and dyndetours functionality).

*Edit: went ahead and removed that comment from ini's in list above


Return to “General Discussion”

Who is online

Users browsing this forum: Bing [Bot] and 2 guests