[chief1983]

Yeah, a reprogrammed interface might not even need to be bitmap based, it could just be text over a static background or something simple.

[Turey]

I've redone the mainhall with just four files (make that 6 if you want support for both resolutions). It's not that complicated.

[chief1983]

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?

[blackhole]

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.

[Unknown Target]

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.

[chief1983]

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.

[WMCoolmon]

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.

[blackhole]

Is that IMPLEMENTED? Cuz its not worth anything to the modders if its not implemented

[WMCoolmon]

Not really.

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.

[blackhole]

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?

[Lt.Cannonfodder]

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.

[blackhole]

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 ). You'd need to PM an explanation as to just what the hey is going on there.

[karajorma]

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.

[Wanderer]

Or wait for (and/or help) taylor with his interface project thing (which i don't know much about)