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.

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 , 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

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

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 .

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 . 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 . 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 . Maybe not.

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