Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: Unknown Target on July 01, 2007, 03:40:56 am
-
I've been toying with this idea for awhile now, and I was wondering what you guys thought. A lot of the smaller mods out there don't have the manpower to create interfaces like BTRL or WCS, yet still want to have a different "look" than FS2, and want to be released standalone to expand their player base. That's where the idea comes in...with scripting and some new code, would it be possible to create a more generic interface that could be freely distributed by any mod that wants it? I'm thinking more of an interface overhaul, that would more look like Half Life 2's interface - i.e., window-based, and with a background image that's easily changeable per mod. Heck, if that's not possible, how about just a more generic looking interface based on the regular FS2 one.
Obviously it's a lot of work and will probably entail a lot of coding, but it could become a community project to help the smaller mods attain that "we're not FS2" look, without having to have someone redesign the entire interface.
Thoughts?
-
Been proposing this since the SCP was formed, so it's obviously got my support.
-
I'm for it.
-
Put a link to this in that Feature request thread that Razor's Kiss is maintaining...
-
It's not really a feature, jr2, unless we decide to make it more like the HL2 implementation I suggested.
-
It isn't? But it's large enough a job that most small mods can't handle it? Hmm.... Well I suppose it's not a feature per se, but it sure seems like it would require alot of work like a feature... ;)
-
A feature would be something that requires a code change. Unless we request a code change, it's not a new feature.
EDIT: Which brings us to the first question. Do we want to redesign the interface with a code change? It's major, but I feel it's necessary - the old (current) interface is very convoluted and confusing for new people these days. But if no coders say they want to do it, then I don't think we can. It's the preferable option IMO though.
-
I actually love the idea of seeing a new generic looking interface coded into the game, maybe not quite HL2 style, cause I can imagine that's a lot of new coding, but maybe something cleaner. But I agree, even a replacement of the stock FS2 stuff with a generic set would be nice, it'd also give those mods an idea of what they might need to change to get their own customized look started.
-
I can put together a really cheesy default interface set if anyone would like it.
-
cheese ftw.
Yeah, go for it :D
-
Cheesey? How so?
-
IT will be made out of chesse naturally... bottuns would be chesee rolls, the loading bards will be slices..etc.. :D
-
I remember some time ago how a main menu was created completely out of scripting, which had the buttons on the right and a spinning 3D model on the left. Can scripting be expanded to the other menus as well?
-
For simple things like the techroom, yes. For things like the options screen, mission screen, player selection screen (Which all require special hooks to the internal FS2 code) the answer is not at this point.
-
Reding a generic interface pretty much needs SCP cooperation. There's no point to redoing thousands of files if the SCP is going to simplify the process (which is an immensely important thing to do IMO)
-
*Bump*
So, should we start a seperate discussion with a poll, to vote whether or not to code a new interface?
-
*Bump*
So, should we start a seperate discussion with a poll, to vote whether or not to code a new interface?
If we could get the other parts of the interface done up in a similar matter as the Main Hall (with it's table), I think that'd be enough.
-
But you'd still have to make 2D bitmaps, no?
So it comes to the same problem.
-
But you'd still have to make 2D bitmaps, no?
So it comes to the same problem.
Not really. Making the bitmaps is easy. The problem is, no matter what you make for the bitmaps, most of the elements of the interface are fixed in place. So it still looks like FS2.
-
Remaking an entire interface full of bitmaps isn't easy - just go ask Lt. :p
That's why I'm saying a reprogrammed interface would be better.
-
Yeah, a reprogrammed interface might not even need to be bitmap based, it could just be text over a static background or something simple.
-
I've redone the mainhall with just four files (make that 6 if you want support for both resolutions). It's not that complicated.
-
But how about the rest of the interface? To completely replace any original interface art with entirely generic stuff (well, maybe not the briefing anims) would take a bit more work than that, no?
-
Why not make it a bit more adaptable then? If your going to recode the interface, couldn't you allow for text and images, thus allowing for either image based or text based interfaces? the hooks to the internal FS2 code are done per-button, so you might have the same numbers of buttons, but each button could be an image, OR text, OR both. Doing that in table format wouldn't be hard. You'd just define each button, its location, its image, and its text. Then you could also allow for "useless" images, or images that don't do anything, and "useless" text, or text that doesn't do anything. That wouldn't require any changes to the internal hooks.
Now, sliders and more complicated UI interface components would be more tricky, but a similar method could be done.
-
I've redone the mainhall with just four files (make that 6 if you want support for both resolutions). It's not that complicated.
Turey, talk to Lt. The other sections of the interface comprise over 200 images. It's not easy, and it takes a lot, and I mean a lot of work. If you remember the interface alone took BtRL something like 6 months to complete.
-
So that's what it is then:
1) Invest a lot of time creating a very generic looking interface just by an art replacement
or
2) Invest a lot of time recoding the interface to be more easily modified.
Sounds like a great poll question to me.
-
Why not make it a bit more adaptable then? If your going to recode the interface, couldn't you allow for text and images, thus allowing for either image based or text based interfaces? the hooks to the internal FS2 code are done per-button, so you might have the same numbers of buttons, but each button could be an image, OR text, OR both. Doing that in table format wouldn't be hard. You'd just define each button, its location, its image, and its text. Then you could also allow for "useless" images, or images that don't do anything, and "useless" text, or text that doesn't do anything. That wouldn't require any changes to the internal hooks.
Now, sliders and more complicated UI interface components would be more tricky, but a similar method could be done.
That's the idea behind wmcgui.cpp
Taylor's also talked about an interface replacement with a GUI-based editor that I keep on mentioning when this subject keeps coming up, but I never hear anything more about it.
-
Is that IMPLEMENTED? Cuz its not worth anything to the modders if its not implemented :P
-
Not really. :p
You can take a look if you like (you are a coder, right?). It's essentially used for just the lab and the so-called "storybook". In theory you could replace the interface, but you would have to replace all the elements on the screen with the new GUI stuff.
What I was thinking of doing was adding hooks so that you could assign scripting hooks/actions to GUI actions, which would allow you to redo the interface without having to define button classes and so on. Unfortunately I don't see that happening in the short term. But that would let you do things in a bit more reasonable fashion. You could leave all the original interface code intact and just use scripting state overrides to replace the existing interface screens (for the most part) and implement the functionality from the codebase via scripting functions.
The interface stuff uses an interface.tbl, with sections named based on the screen that they represent. IIRC you can also define multiple resolutions, but that might be the HUD table that I'm thinking of. What you can do for sure is define or override button text and images for different states. I don't think I quite got to the point of creating new items via interface.tbl - I think there was some design issue that I had to solve - but I was planning on allowing you to create additional interface elements. interface.tbl was primarily supposed to be for skinning.
I also thought it would be cool to create a 'hud' interface class, so you could deal with mouse movements and any dragging or drag-n-drop stuff via the interface code, rather than having to redo it specially for the HUD.
-
you are a coder, right?
See siggy. However, i doubt i have enough experience to undertake something like that. I may give it a looksee, but i'm terribly busy for the moment. Has this not been implemented because of time constraints or becuase of difficulty?
-
Turey, talk to Lt. The other sections of the interface comprise over 200 images. It's not easy, and it takes a lot, and I mean a lot of work. If you remember the interface alone took BtRL something like 6 months to complete.
Over 1000 files for 1024 resolution alone. And it's not hard, just mind-numbingly boring and tedious work, especially when you really can't change stuff you'd like to.
-
I took a look at the code and i can't even begin to comprehend it, despite WMCoolman's many humerous comments (and lots of hacks :P). You'd need to PM an explanation as to just what the hey is going on there.
-
Problem is that then it's hardcoded. It's exactly the same as the FS2 Interface but with the buttons in different places.
And you'll still need someone to make all the bitmaps for the new interface.
I think the best thing to do is to help WMC expand on the scripting code till it can do everything. That's what the scripting code was originally developed for anyway to a large degree.
-
Or wait for (and/or help) taylor with his interface project thing (which i don't know much about)