Updating kickstart

[SavageMessiah]

Well, I've brought this up before. I'll update kickstart. Unfortunately, every time I do, every one pisses and moans about what language it should be in. NO VB NO VB! Well, I'm definitely not learning Delphi just for this project. I never much liked pascal anyway. However, I'm learning java right now. Anybody going to complain about java? I'm not going to bother doing this if nobody else is willing to pony up a little support. If nobody has any problems with java, then I'm pretty sure I can figure out the swing library and pound out a gui. The rest will be easier. What I need though, and I'm pretty sure nobody has put this together yet, is a good request list for a new version, besides better integration with the packs. What do you want changed about the interface, etc. Erm, that's all I have to say.*bug*

EDIT: And java would make it easier for me to put out a linux binary for when 1.8 comes out...

EDIT #2: Cross-platform compatability aside, any chance anybody knows if J# requires the .NET framework to be installed? I would assume so, but if it doesn't that would speed development by a lot.

[Slide]

Well I'd prefer VB to java - but I don't mind really - I really don't like pascal and its offshoot Delphi.

But unless you've learnt Swing through and through you will probably find doing Kickstart in Java absolute hell - especially if you're used to drag and drop VB. A week or two of debugging action listeners and nested gridbag layouts will have yo crying for mercy in my experience.

Either way good luck it really needs doing - i've done some stuff myself on this but don't have the time to do it properly.

BTW don't kid yourself you will almost certainly have to do some debugging to get a multitabbed interface working on both linux and windows platforms - but I guess it will still be easier than from VB.

Edit:
j# does require the Framework AND an extra java runtime to be installed - although you can easily convert the code to c# and do without the second issue.

[SavageMessiah]

Well, I'd love to do it in VB .NET, I'm pretty damn good with it (I'm writing a fully scriptable game engine in it) but everybody complains so damn much about having to get the framework, or for vb6, the runtimes and controls (though a decent installer will alleviate the control problem) that I gave up, and I don't have the motivation to write it just for me. The thing with debugging is that I have this magical ability to do things right on the first time. I'd rather not depend on it though :p, because sometimes it leaves me with these hidous bugs that take forever to root out. Actually, I'm kinda bored so I'm going to poop out a gui in vb.net so I have something to look at. Do you think I should stick with the old tabbed interface? I think it would be better with just one box where ou add wads, pk3s, dehs, and ksas.

[Tolwyn]

I think it works abso-fucking wonderfully in whatever language it's in right now.

My only wish is to allow loading PK3 files as well as PWADs. :)

[draconx]

My recommendations are either C (using GTK) or VB6.

VB6 apps generally run fine on linux under wine, and the libraries aren't really much of an issue (there's a tutorial for making NSIS installers install & register them automatically)

And tolwyn (someone correct me if im wrong) i think if you add the pk3 to the wad panel it will work.

[Tolwyn]

I think the tabbed interface ROCKS.
It works. It's clean. Don't break a good thing.

[sLydE]

whatever you think is best, as long as it'll have all of the same features as the current one, and some more in the future, i'll be happy

[SavageMessiah]

A. you can add pk3s under the wad panel if you got the new version from the modelyard, I fixed that.
B. The wine bit didn't occur to me. I guess I'll probably switch back to vb6 for this then. .net doesn't offer enough advantages to me as a programmer (for this anyway) to justify giving up linux compatability.

C. I got a sweet idea for an interface,, much better imho than the current tabbed one though maybe I could do both and make it optional? I'll post a few screens later, but I'll try to describe it.

First, you'll be able to create new profiles inside of kickstart, without having to play with the text files. In the profile view there will be two tree views, one will be the stuff to be used and the other will be various packages. These packages will be the jdrp, jdep, etc, along with the core game dlls and wads. Yo uthen jsut click and drag the bits you want to the profile tree and you're done. There will be an add file button for all the stuff that doesn't have a package definition (like a ksa). IEvery ksa will have compatability info, basically just listing what it replaces, and the program will warn you when you add something that might conflict. Add a box for additional command lines, and a checklistbox with additional options, and all the sub-tabs under games have been rendered pointless. What do you think of that?

[lechtansi]

i didnt quite understand what you meant in your description, i think ill have to see it in practice before i make a judgement. if you are going to update the current kickstart, my few things i would like to see are:

PK3 and DEHsupport ("PK3_List" and "deH_List" parameters for KSPs and KSAs), they were supposed to be in the most recent version but they dont work.

fix for the pop-under method of launching kickstart, its kinda annoying :P

other than that, kickstart works fine for me (most of my problems are trying to get various things to work with doomsday, and not KS itself).

[SavageMessiah]

I keep getting conflicting reports about wether deh and pk3 support works. I didn't add new list parameters, but you should be able to add pk3s and dehs to the wad list and they'll work fine. I remember on my first fix, I made it so you could add them, but it turns out that cheb's code always changed the extensions to wad when the files were added to the comand line. I fixed that in a second release. I'm assuming that's the one up right now.

The pop-under thing bugs me too :p

Thanks for the feedback people, this is what I didn't get last time.

[lechtansi]

savage: im sad that you didnt get this kind of feedback last time, anyone who works on anything having to do with this project shouldnt get any flack for anything.

what i was saying was in the KSP and KSA files, the parameters "PK3_List" and "deH_List" do not work, and yet they are supposed to.

thanks

[Sin4U]

Aparantly MS isnt far from releasing a linux .NET framework, so youre not really giving up on linux compatablity. In fact, part of the point of .NET was complete platform independance (all the way down to your fridge), without Java's performance problems. (you dont even need multiple distibutions) Of course, there's no guarantee what windoze likes will go down with Red Hat, but thats programming for you. I also think the framework comes with XP, so quite a few users should already have it... but I could be wrong, of course.

[Slide]

If you code your VB6 in an object oriented way and with Option Explicit On (which I hope you do anyway) follow the standard naming conventions - you will probably find you can have a VB6 codebase that will be fairly trivial to update to VB.Net /.Net 2k3 (simple conversion wizard and replace some IO classes with the VB.Net ones - with proper oo encapsulation I don't imagine this will be hard i.e. define your own serialise method then write a new method with the same name for VB.net that you can just drop in). So you can support the framework anyway and perhaps switch to it completely once the framework is a little more widespread.

As an interesting aside the next version of VS.Net will have a pre-compilier which hopefully will allow you to create vb 6 style native exe's (it's mainly for ASP.Net so I'm not 100 percent on that one).

Also the framework does not come with XP but if you chose to automatically download updates you may have it by now - if not it's free from Windows update or the MS Download site.

[SavageMessiah]

I was wondering when the other platform versions of .NET were going to come out. Not that I support M$ getting their greasy fingers into everything, but I really hope .NET turns out the way it's supposed to. Real cross-platform compatability for rapid-development languages like C# vb.net would be a real boon to me personally, as I'm way too lazy to become proficient in Delphi or C right now :p.

I haven't had much trouble porting a few other smallish programs to .NET so I think I'll go ahead and start it off in VB6. I always use Option Explicit, because I usually do Directx stuff, and it fusses if it's not on :p. I don't know the naming conventions for everything, I assume those are in the msdn library somewhere?

[Wicked Anime Kid]

Well let's get to the KS requests;)

1. tabs for both pk3's and wads (seperate)
2. Add-on tab where you can configure your models in
3. Screenshots with the Add-on model tab (so that you know what model you pick)
4. Engine defs better viewable (the little window with the options wasn't too good IMHO)

And any other requests........hey i don't have any anymore

[SavageMessiah]

If I can make the interface I was thinking of work, the wad/pk3/addon tabs won't be needed. I didn't think of a screenshot window though, that would be useful and easy to implement. I plan on doing a completely new options page, though I'll need to dig up a complete list of command line options for doomsday before I can do that.

[Wicked Anime Kid]

I can help with that list:

Just press LISTCMDS in the console and there you have them;)

Else look under your doomsday/run/jdoom folder and go through the cfg files there. The cvars are in one of those files

[DaniJ]

I'm glad to hear you back on the project SavageMessiah. Do you still plan implementing the pk3 support in the way we disscussed (each pack containing a info file with all the setup stuff)?

It would be good if an addon could have it's own options (checkboxes) that could be used for adding commandline flags eg -noweaponmods

[Slide]

How about we try and work out a full pk3 structure with standard folders etc.. (should be easy as mostly doen already), work out how to embed preview shots - say a max 256X256 image in preview.jpg or something and an embedded customisation options (jDRP Blood options, jDEP no fog, anti fog light glare) and introduction ("The jDUI is a collections of some of the most...").

If we can agree to a standard I'll redo the jDUI and jDEP to match.

I'd also like to see a more professional game look with you being able to choose from the major Doomsday DLLs (jDoom, jHexen and jHeretic) then have a quick launch option (Start Doom | Start Doom 2) or the ability to add mods to your game, disable the standard packs (if we set the jDEP, jDRP etc.. to allow a skip if -NOJEDP -NOJDRP that should be easy). Then have access to global settings for all DLLs such as the CVARS and render options. User profiles would also be a nice touch.

A repair option might be nice - something that would copy back the major DED files if somebody mucks up and deletes the client.id file (a constant problem).

Also since this will be a major break from the past how about a name change - this isn't the old kickstart so it seems natural to have a new name: jLaunch perhaps?

[SavageMessiah]

Slide, most of your suggestions I already have plans for, I didn't think of the quick start bit, I'll definitely put that in. I'm not sure if we really need user profiles at this point, but it's a possibility. Do you think the dll options should be set globally, for each dll, or per game profile? I was planning on continuing the current scheme, global options, which are mirrored in each profile for alterations.

Hmmm, a new name. It is totally different from kickstart, but the purpose is still the same, so maybe jStart?

Danni: I'd like to do it that way, but I'm not having much luck working with zips. The only stuff I've found for vb are commercial products that cost a fortune. I was thinking that instead of keeping the descriptive files in the pk3s, they would be seperate. This has a number of advantages (to me at least)

1. I know a lot of people that play doom have older computers, having to pull the files out of pk3s (especially if there is a file in each internal pk3, which means extracting that (potentially large) file and then opening it, etc etc) could be time consuming
2. And if we just extracted it one and kept it in a cache, then why not distribute keep them seperate, and place them by default in a package directory for kickstart
3. This goes along with the way I would like the format to work, combining a way to manage the major packages and their components but also giving a way for the end-user to put together their own packages of stuff they already have, in this way they would work like ksas. The package def I would prefer would use an xml type schema, and would contain screenshot nodes and description nodes to handle that. Each main file would have it's own node, and internal files that are intented to be optional will be entered as child nodes. Remember, I'm planning on displaying all the packages in a treeview, using the tree to show what packages and components are available, and another tree to display the ones that will be used. You click and drag between the two, or select and press a move button. The old wad/ded lists will be in there, you'll just hit the add file button and the file will be added to the "use" tree like anything else. I know this is a little hard to visualize, but it makes sense to me at least :p. It sounds a little complicated, I think, but it's actually a powerful and expandable way of handling the whole mess, IMHO. I could mock something up if you like.

As for the file standard, other than what I've mentioned here, I think the specifics can be left up to you guys, as you actually make the packs.

I'll probably write my own basic file parser for now, and when this goes .NET I'll switch to the built in parser.

Oh and about the seperate dlls, I was planning this:
When you make a new game profile, there's a part of tree called core, and five packages inside, doom, doom2, heretic, hexen, doom64, each contains the dll and the main wad, you pick just the dll instead of the wad if you like just by dragging it instead of the parent node.
In the bit where you pick and profile and hit play, I was going to a set up check boxes to filter the list by dll.

What do you think about a skinnable interface? That will be difficult and require directx in VB6, but will be pretty easy in .NET, so this will probably wait for the .NET version.

EDIT: Heh, this is hilarious. i've always done most of my programming in VB6 and liked the way it worked. Now that I do all my homework in Java, I've gotten used to real OOP and a lot of other stuff. I might have to do this in .NET just so I don't get pissed at it :D . Maybe not.

EDIT2: AAAARGH! Crappy return types and no function overloading! How did I get by without this stuff before?!*angry*

[Slide]

You can always use VC++ ;)

Remember you can hack OO in VB6 with a little effort there are several internet guides to this effect - this would probably help with any move to .NET in the future.

As for how you set up the options what you want to do is think about how the launcher will be used:

> To play game with previous settings (quick start)
The idea being you can play the game in two clicks since a lot of the time the game settings should be stable
> Add packs/mods to game (jDRP/Textures)
> Add Mutators (change CVARs | jumping | perhaps different setup packages - modern, classic, extra gore, etc...)
> Setup game engine options - realy good to be able to have profiles (classic, low, medium, high, very high, Max - classic could be the game as it was) - global options should include all renderer, sound and misc options. Also misc repair search for WADs etc settings.
> Setup multiplayer (Server | Client) a game search might be great in future versions.

So the initial page should have say:

jDoom
jHeretic
jHexen
Engine Options

Then say on jDoom you have:
Doom 1 | Doom 2 | Ultimate | Plutonia | Evilution | Custom
Launch Game
Load settings
Save Current Settings
Customise Game
Multiplayer
Engine Options
Back to Main
if you click on custom then you can setup non official game wads - being able to save your game settings would be good for this - custom controls saved here might be good esp. for multiplayer (remember 1.8 you get splitscreen) and wads with odd weapon setups. Also if the list of Doom games could be populated based on the wads present (ie if you don't Ultimate Doom it shouldn't appear).

I recommend doing a mock up of the interface (easy in vb6) then thinking how you would use it day to day (perhaps do a closed alpha test - I don't recommend an open test as you WILL get loads of negative comments).

[SavageMessiah]

I wrote a rather messy and somewhat incoherent file format spec (http://members.lycos.co.uk/lardboard/format.txt). I'm going to start writing the parser for it now. The format, as it is, works perfectly with the way packages will be handled in the program. I'd like to hear some feedback from you package developers on the kinds of fields though. I think I included everything you would need though, a long with plenty of explanations. Somewhere in there I mention checking the other file about compatability. This is the other file *rolleyes*. I figure the stuff you put in the compatability fields will mostly be meaningless to kickstart. It will jsut build a table as yu add packages to a game profile warn you if a duplicate comes up. This means you will have to come up with and enforce a standard for this. I would suggest using the internal doom names for stuff like music and patches, and using something a little easier for monsters and items and such.

Since I hate doing functionless mockups, I'm writing everything I need to load and parse profiles,settings,and package defs into objects. THEN I'll make an interface that actually uses all this data and do a closed alpha to see if it works out, then I'll actually make it run doomsday.

For most of the engine settings I'm planning on defining them all in a seperate configuration file, like cheb did, so it can be updated without changing the code.

Cheers.

[DaniJ]

Me reads *book*

That sounds great, though where do you put your external files - configs, screenshots etc?

Another node would be needed for pack dependancy. For instance in the jDRP there are some packs that depend on the generic effects pack or the particle pack. If you disable/change packs it'll alter a lot of other things.

[SavageMessiah]

Doh, I completely forgot about dependencies. That won't be too hard to check either. More on that later this week after I finish this vrml project for school that I totally fucked up and now have to restart. I think it's worth 7% of my grade :(


As or the external files, I was thinking of this

c:\doomsday\jstart\ -the program config goes here with the exe
c:\doomsday\jstart\packages packages with no screens or other files go here packages with that stuff can each go in their own subdir
c:\doomsday\jstart\profiles\ the game profiles go here

Simple.

[Slide]

That file you linked to is dead, can you post it somewhere else I would like to have a look.

As for your structure what about pack DED patches and other addons. Also it might be prettier if the data associated with a pack could be placed within a PK3 itself (or default to just having a folder).

I think calling the folder 'packages' might be confusing (some extra's are merely DED's) perhaps 'addons' would be better - also you may want to separate out game DLLs, WADs from enhancement packs (for instance the old Doom64.dll, new Doomsday non DLL games say resurrection and classic doom stuff like the Alien TC - for which auto generated configs might be nice - for stuff like controls).

edit:
Odd I can get the file now

[SavageMessiah]

Hmm, the file works for me at home and at work, so I don't know what the problem is. I'll mirror it at my college account later if you need me too.

As for all you just said, I think my plan for the packages will work perfectly. It's all in my head and I doubt I'd be able to explain the whole thing coherently. So, just wait and we'll see how it turns out. I writing this is in my usual, modular style, so it will be easy to change if I need to.

I got my project done :D I'll be seeing oceanographic data in my sleep. 5000 points *eek* merged into a single coherent visualization. Whew!

[DaniJ]

I don't think we should be installing the packages into: c:\doomsday\jstart\packages

It makes a lot more sense to keep them in the relative data\j* folder and sticking with Doomsday folder conventions.

All that's needed is a place to put all configs and screenshots so if they went in their own folder in c:\doomsday\jstart\packages that might be the best option.

How will the individual packs be loaded? I would like to specify in the module addon config both the ded and the pk3. ATM you don't need kickstart to use the jDRP. So for instance when using Doom Connector you load the whole jDRP in Doomsday via the command line:
-file jDRP.ded jDRP.pk3

This would be broken by the new launcher. It would mean a batch file for running Doomsday + jDRP without the launcher but thats no biggy.

PLEASE can you make the launcher not close when it starts Doomsday? Ideally it should minimize whilest playing and then open up again once Doomsday closes.

Another thing missing from Kickstart is Demo support.

[Slide]

PLEASE can you make the launcher not close when it starts Doomsday?

I'd prefer that as an optional feature though I wouldn't mind which was default - the only problem with minimising the thing when you start doomsday is bringing it back up when doomsday quits.

I've had a look through your file format and it ain't bad - though I can think of a few little changes - I might have a go at an XML version over the weekend. I take it you're doing one too from what you said before it might be interesting to compare notes

[deepteam]

I'd prefer that as an optional feature though I wouldn't mind which was default - the only problem with minimising the thing when you start doomsday is bringing it back up when doomsday quits.
No need to quit or minimize. Just wait for JDOOM to end. JDOOM will overlay the dialog and Kickstart will automagically reappear when it ends.

Minimize doesn't save you any resources, but if you wanted to do that, all you need to do is issue a maximize command to yourself (opposite of minimize which I'm assuming you issue to get it to minimize) and the dialog should restore itself automatically.

Only problem I've run into is that "memory bugs" in various ports can cause weird things to happen to your code - even on XP.

[SavageMessiah]

I don't think we should be installing the packages into: c:\doomsday\jstart\packages

I only meant a "package" to mean configs and screenshots used to integrate a group of things for jdoom into jstart, be it the jdrp or whatever.