[Utility] GSBEdit: any modder interest? (was: Modding tools)

I probably won’t make too much progress on the app over the next few weeks due to holidays, but I’ll try to make up for it afterwards :slight_smile:

Its looking really great. If u can include the value “icon” and “turret sprite” , by searching the dds file and adding it to the field will be just awesome.

Dont worry, i think on christmas time only a few people will work hard in their mods… we all deserve a break !!! ^^

Thanks Kemp :slight_smile:

As long we can execute it as a .py (python .py) I’m happy. But a .deb package would be awesome! May be as a PPA?

By that, do you mean showing a preview of how the icon and turret graphics will look in the game? That (along with previews of beams as suggested elsewhere) will be on my todo list. I suspect that particularly the beam preview will be useful to people as it seems hard to get them just right sometimes. Once I’m done with the base module editor I’ll put together a more comprehensive list of future features and let people vote on which ones are most important.

I could set up a PPA as I already have a Launchpad account that I’m not using much. I think you can create up to 5 personal PPAs. The thing there is that it adds an extra layer of packaging, so I’d need a few people to be interested in using it for it to be worthwhile. I suspect most modders here are on Windows.

Added to todo list: formation editor.

It has occurred to me that the tool needs a name to make it easier to refer to. A logo would be good too so I can use an actual icon for it rather than the standard “Nothing to see here” that gets assigned. The name I’ve been using in my head until now is GSBEdit (in line with quite a few other modding tools), but let me know if any of you has a better idea. As far as logos go, I’m open to suggestions.

I wasn’t looking for someone to dedicate real time to it right now, more looking for concepts. The ship+pencil isn’t a bad idea, variants seem fairly common for this type of program. As far as size goes, 48x48 is common to Gnome and Windows XP, with XP also using 24x24 and 16x16 (I can scale the 48x48 for those sizes though). A larger version would also be displayed in the app (probably in the About dialog), but I don’t have a size determined for that yet.

Well, since XP, Vista and Windows 7 can handle bigger icons (128x128 and 256x256) its better to make the icon bigger as possible, but not more than 256x256 in size. Cuz if u are using a big icons style list view, u will see the icon blurry if u only use 80x80, for example. And btw, some icon bar editors, like Rocket Dock and others (i only use rocket dock… ) needs high resolution icon sprites to look sharpen when u add it on the cuxtomized icon bar… well, since this is not so important, i really dont care the size of the icon, just keep the good job and we will be happy no matter wat ^^

May be 256x256 pix svg file, as svg doesn’t loose quality when scaling. Can windows handle .svg files?

I think SVG would be the way to go for Linux. I’m not sure if XP can handle SVG, I’d probably have to export it in several sizes. I think I have an idea for the icon now though. I’ll try to sketch something up tomorrow to see what you guys think.

I’m also going to try to get set up to work on the code, but between two sets of parents being here, me having to work on my girlfriend’s laptop, and not having a copy of GSB installed (the latter being the only aspect I can fix), I don’t hold out too much hope. Maybe when we start our actual holiday and get some peace…

I spent a little time today knocking together a simple vector version of the usual ship. It’s nowhere as detailed as the original bitmapped image of course (partly due to my very limited skills), but it has enough detail for icons and it’ll resize without any loss of detail or pixelisation. Particularly for Gnome, which supports SVG icons and any level of resizing in your folder views, this is a good thing.

The result (in PNG form as a lot of people don’t have browsers that’ll show SVG images) is at http://files.iualdii.net/GSB/vector_ship.png, with the original on the right.

I’ve put together a quick demo shot to illustrate how I’m approaching the required/optional fields in terms of the UI:

Required and optional fields there are fairly self-explanatory. Unused fields are those which are not needed for a particular type of module (e.g. cloak_rechargerate on a SIM_LightningGunModule). As some people like to try to break the game, the unused fields can be enabled. The red background indicates that in the best case the value won’t be used, and in the worst case it’ll cause random crashes. I may eventually end up entirely hiding the unused values (unless enabled), but for now they’ll stay.

I think u should just avoid the “unused” field, since it is no sense to mix a variable from another class module into a different one (the game will just ignore it). No crashes will happen cuz the game will ignore all the values that are not specific from a module class. The game can crash if it encounters a wrong value on a variable, or some variables are very out of range, but will never crash for “adding” variables that the game will just ignore.

That’s a good point. My decision behind this scheme was based on two things:

  1. It’s easier to have the same fields shown for all modules (at least in early revisions of the tool). Colour coding is much easier than changing the interface on a per-module-class basis.

  2. There have been a couple of requests to Cliff to allow mixing of module attributes between classes. I don’t expect this to be allowed (as the recoding probably isn’t trivial and the balancing issues would be a nightmare), but the easiest option (as noted above) is to provide some initial support for this scenario.

However, it is likely that I will eventually modify the tool to completely hide the unused fields (unless specifically enabled by the user) for the reasons that you gave.

I know wat u mean in the point number 1, i am a programmer too -.- in fact i was thinking time ago on making a editor like the awesome work u are doing, but in visual basic, but i was to lazy to install the whole visual basic on my hd -.-

About the point 2, yea u right, there are some requests about mixing module capabilities, but to be honest there are more important things that clinfski should improve / allow to modders before that. In fact, too many things to think of… (for example, the possibility to make custom bullet textures, that will definitely awesome).

But as i said before, u are doing the hard job , so do watever u want and the program will not be less useful without that field. We only can give u advises -.-

I invite all of you to advise, criticise, suggest, comment, or otherwise pass judgement. Any input I get will help to make the program more useful for you guys. Nothing that is said will be dismissed just because it doesn’t agree with what I wanted to do. It’s all taken into consideration and in one way or another will be acted on. After all, the tool is for the community, not just for my personal use :slight_smile:

I’m hoping to release a preview build once I get module editing finished and stable, that way you guys can give me some feedback from actually using the tool rather than having to read my (sometimes pretty weak or boring) descriptions. I’ll probably end up doing that after each major feature is added.

boy, i hope this isnt dead :S

Don’t worry guys, I’m just on holiday with my girlfriend’s laptop and limited internet access :slight_smile: Module creating/editing/deleting is coming along though, and I’m still putting quite a portion of my development time into making sure I build a sane back-end. Building an editor is easy, building an editor that I can extend, update, and maintain is the hard part :wink: This involves taking an object-oriented approach and ensuring a very clean division between the back-end (game data representation and processing) and the front-end (the GUI).

My next task is to derive a new implementation of the .ini file handler mechanism so I can force it to:

  1. Write out variables in a pre-defined order (otherwise the ordering is essentially random, fine for machine use but hell for someone trying to manually compare or edit the modules later on).
  2. Automagically add quotes around some variable values but not others. I don’t know if GSB really cares, but I’m trying to stick to the implied spec as closely as I can.

After that I will finalise the module wizard (which got put on the back burner after I finished the concept stage for it) and neaten up the code which allows you to choose the GSB install and mod you want to work on. Then I can release an alpha if anyone is interested, though I’m not sure anyone will be so keen for an app which only allows you to work with modules…

ok, thanks for letting us know :slight_smile:

i understood about 5% of what you said, but it sounds great :smiley:

Yay, thats the hard job, to make the “inside” of the app the most handly possible, thats for example, the basics of a game that can be modded in a lot of ways.

Is the wizard havig the option to make “standard default weapons” ? i mean, for example, the wizard asks u, Do u want high damage, standard dmage or low damage? or Do u want standard fire interval , long fire interval and so on?? i mean, in those cases, it will be almost necessary to make a formula for calculating the dps, and balancing thed mg with the fire interval, etc…

At the moment I’m planning a simpler and more general wizard for quickly filling in the boring variables that you have to set every time, but I’ve now added a more advanced wizard to my todo list based on your suggestion :slight_smile: Another entry on the list (that should make it into the first alpha) is for the module editor to calculate some comparison values such as DPS and so on where appropriate.