Server Help :: View topic - Subgame to ASSS cfg converter

Server Help

Misc User Apps - Subgame to ASSS cfg converter

ExplodyThingy - Mon Oct 06, 2003 7:24 pm
Post subject: Subgame to ASSS cfg converter

Behold, a quick editor to change the Subgame cfg files into ASSS's conf files. Simply do "convert config", and the file config.cfg will be run through, along with config.conf setup for you.
C++ source included.
Later, the INI converter.

[EDIT: old build removed]

Mine GO BOOM - Mon Oct 06, 2003 11:27 pm
Post subject:

Trying to be helpful here, but there is some flaws with your program.

When releasing binaries, please try to use the most optimized builds possible. In Microsoft Visual Studio, go to Build, Set Active Configuration, and choose Release. That should make a file around 44k. Much better than the 200k file you have.
Does not check to see if no inputed filename. Do a if (argc > 1) test to make sure you are actually getting something for input.
Does not check to see if inputed name already has the .cfg extention on it. If you drag-and-drop a file onto the program, windows will convert that into the full path, including directory, and extention of the file as the arguments passed onto the program.
You don't delete name after you finish using it. With new, you have to delete the memory at some point. So before the second new operation, use delete name; somewhere.
You didn't delete the second memory allocation of name.
When you define a variable to be 256 bytes, and you read in a max of 256 bytes of data, you do not get the trailing '\0' (aka NULL) value added to the end. Or it might add that null character at the 256th position, which is outside the defined space of line, which is a buffer overflow. Ever wonder what code looks like that has all those security errors that can cause virii to spead? Thats an example. Though, in your case, it would never do any harm, as it would max out to only being a null added to the end of the space, but thats how problems do start.
strnicmp will do you better than strstart. Examples:

Code: Show/Hide
if (!strnicmp(line, "[Warbird]", sizeof("[Warbird]"))
--- or ---
#define test(a, b) !strnicmp((a), (b), sizeof(b))

Sorry if it looks like I'm being very critical of this, but I learned C the hard way. Just trying out random things until it work, and not knowing about problems that can occur later on.

The idea is good. To have a smart way to automatically split all the configs into easier to handle files.

Anonymous - Tue Oct 07, 2003 7:36 am
Post subject:

Much appreciated.
The release of the debug versus the final was just a careless error on my part. I tried running a missing filename at argument, it simply creates all the files, and leaves them blank. Theres also a typo where it does not create a newline after the #define in the conf file. Ill post a new final build tonight.

Smong - Tue Oct 07, 2003 2:22 pm
Post subject:

Heres and idea, make a "ship-all" file containing common settings that all the ships use. This should help cut down on file space. Just use an #include straight after writing each [ship] section title.

What about arena.conf instead of the original file name with .conf stuck on the end?

I think Notes:MapName and Misc:LevelFiles should be converted to General:Map and General:LevelFiles. Also the standard modules need to be loaded:
[Modules]
AttachModules=fm_normal points_kill

A really fancy program would read the flag/soccer/periodic settings and decide what other modules should be on that list.

ExplodyThingy - Tue Oct 07, 2003 8:07 pm
Post subject:

Right now im working on a way to add in the ASSS-specific settings, preferably based off the current cfg. ie: Add the SpawnX=512, SpawnY=512, SpawnRadius=Misc:MinVirtual to the Soccer section. This should make it pretty simple/fast to convert.
Later, ill have it store variables to add the necesary modules based if whether or not there is a ball count, flag count, etc.
A ship-all file would be simple enough to implement on my end, but it would really require ASSS to add support for it. Though now it could just make a file with all the [Ship] sections, and a variable set 8 diferent times, which is simply redundant. Another approach would be to use a macro! #define ALLSHIP_SettingName 17;
Much of the things im thinking of doing would require going through _.cfg twice, and lots of control variables (such as ShipAll.conf)

Build on the assumtion that strnicmp is not case-sensitive. Based on the tests that ive run, is this true? Additionally, this function does not quite seem to do what I will need it to do, no allowance for the "all other" sections check.

Drag and drop will not be supported (yet?) due to something i plan in the future.

[Edit: Old build removed]

Smong - Wed Oct 08, 2003 2:17 pm
Post subject:

ASSS already has support for ship-all file:

ship-all wrote:

;All the stuff that is the same for each ship here
UpgradeRotation=0
UpgradeThrust=0
UpgradeSpeed=0
UpgradeRecharge=0
UpgradeEnergy=0
...

arena.conf wrote:

[Warbird]
#include ship-all
InitialGuns=3
...

[Javelin]
#include ship-all
InitialBombs=2
...

The bit where I said make it arena.conf, scrap that, setting_name.conf's should be in the conf/setting_name folder and arena.conf should make an #include to it. That way multiple arenas can have the same/similar settings but different maps.

ExplodyThingy - Wed Oct 08, 2003 8:05 pm
Post subject:

Ah, good idea! However, detecting that sort of thing requires a LOT of pre-reading of the file, and that is so far beyond the scope of the program's design and purpose. Its primarily made to simply convert the Subgame-specific files to the ASSS-specific files.
I can make do the #include ship-all.conf at the head of every ship file by default to accellerate conversion times. However, since it is included before the ship-specific settings, and EVERY ship-specific is in each ship's file, then everything from the ship-all file will be overwritten. This means that even though it saves time to add that line to the confs, you still need to go in manually to remove the variables. Maybe later I (or you) will make a redundancy-eliminator.

Dustpuppy - Thu Oct 09, 2003 9:43 am
Post subject:

I realise you probably aren't bothered, but I imagine something like this would be much better written in, say, perl. The string handling and regular expressions would make things easier...

ExplodyThingy - Thu Oct 09, 2003 6:59 pm
Post subject:

One problem with perl is that too few people have the capacity to run it. I decied to use a language that didnt require an interpter to use the program. (Dont get caught up in the details of that sentence).
Im gunna release a new build maybe later tonight. Ive been making it pre-read the cfg to get certain valuse (such as flag and ball count) and then adding the necessary modules into the CFG. It also now moves some of the variables around to thier new sections.

Mine GO BOOM - Thu Oct 09, 2003 8:28 pm
Post subject:

ExplodyThingy wrote:

One problem with perl is that too few people have the capacity to run it.

Actually, the target audience is Linux servers, which either default with perl, or can easily get perl added to it with little effort. Windows is just a side-product, used for testing but not actual usage for large zones.

Dr Brain - Thu Oct 09, 2003 8:36 pm
Post subject:

Mine GO BOOM wrote:

[..]Windows is just a side-product, used for testing but not actual usage for large zones.

The problem is that the current server infrastructure is Win32.

ExplodyThingy - Thu Oct 09, 2003 9:51 pm
Post subject:

Well, do you think people will be running this on the server, or do you think they will be downloading the settings and changing them on thier computer? Either way, the source is included so people can use it on whatever system they damn well please.

Newest build contains some pre-reading cababilites, to move, adjust, ignore certain variables. See the new readme to see whats up.
(This is my little pet project, expect many more as i become more familiar with ASSS)

[Edit: ironically, i forgot the latest source]
[Edit: Old removed]

Mine GO BOOM - Thu Oct 09, 2003 10:23 pm
Post subject:

Dr Brain wrote:

The problem is that the current server infrastructure is Win32.

Actually, both of the large SSC servers will switch over to the linux version once it does everything they need it to do. Xalimar has being asking for a good linux version years ago.

Plus, with almost any host that you have shell access to, you can setup a ss server on it within minutes.

Dustpuppy - Fri Oct 10, 2003 8:51 am
Post subject:

If portability was the problem you could just make a perl web script, so people can just provide their settings file and the script outputs the conversion.

ExplodyThingy - Fri Oct 10, 2003 4:40 pm
Post subject:

Would YOU trust a webscript to run your private settings through and potentially allow them to be stolen by the script?

Either way: This is a hassle-free thing to use. Even the not-so-hardcore-linux people (ie, NORMAL PEOPLE) can use this.

ExplodyThingy - Mon Oct 13, 2003 7:21 pm
Post subject:

New build. Uses ASSS's method of reading .confs to read the .cfgs. Quite interesting, really.

Also, while line-by-line checking to make sure the cfgs variables are in the same sections as in the .confs (such as the Misc:LevelFiles move), i noticed that there is no Bullet:ExactDamage. I assume this is simply an oversight on the sample SVS.conf.