Don't reinvent the wheel!

[vexed]

You know, with all the limitations of WZ's GUI, and the lack of any real progress towards doing a new GUI for various reasons, I have been thinking about doing this for awhile now, and I think it is the correct direction for the project.

What we need to do is have a Qt based launcher for WZ, and that would immediately solve all our woes with WZ's lack of a real GUI.

This would give us much more flexibility, since, Qt does GUIs very well.
This would allow us to have much more freedom in how we can do things, and we could also integrate a IRC client into it as well if needed.
The possibilities are endless, however, this will *not* fix the in-game GUI, and I honestly don't see a good fix for that until someone rewrites it.

All this sounds good right ?

Well, not entirely. It still requires someone to do it.

Right now, I am redoing the net stuff, both in WZ & server side, so my hands are full.
Thus, I am looking to see if there are any people out there who would like to get the ball rolling with getting a WZ launcher written using Qt, and we can go from there.

If not, then, it will still be done, but, it will just take a much longer time.

Comments, questions, concerns ?

[JamesNZ]

By 'launcher' do you mean the UI for creating/joining games, setting options, etc? If so, what's wrong with the current launcher?

[NoQ]

What i was *dreaming* of so far is the approach i've seen in mplayer (the famous unix-way movie player). As far as i understand, all they did is provide a good CLI, and then all GUI, if necessary, is provided by an external wrapper (eg. smplayer) that simply pipes stuff in mplayer's stdin and integrates mplayer's output window inside its own window somehow. All the necessary GUI widgets can be just drawn on top, iirc. So we don't start the original wz2100 process until the game is already starting. And we can optionally, as a feature, disable the graphics completely and allow making a dedicated server (?) And also, this way we don't necessarily need to implement the GUI wrapper itself; there had been enough community wrappers, i believe this effort would continue, we just have to wait (:

Another approach is to simply encapsulate the existing GUI deeply enough, and then see what API we need and how we can re-implement it. Or vice-versa: make some sort of libwz2100, encapsulating everything else, and let external applications call its API. Anyhow, it seems there is a natural need to provide some sort of abstraction layer between the UI and the rest of the game.

[crab_]

Hello.
I cant help with Qt stuff cause i do not know Qt.

You know, with all the limitations of WZ's GUI, and the lack of any real progress towards doing a new GUI for various reasons, I have been thinking about doing this for awhile now, and I think it is the correct direction for the project.

I think you are right. Remaking GUI is correct direction of the project.
In-game GUI should be also rewritten, cause it does not provide vital information to players. Anyway better to start from wz launcher.

Right now, I am redoing the net stuff, both in WZ & server side, so my hands are full.

It sounds very interesting. Can you say what goal of remaking netcode? Sync model will be changed again?

[Terminator]

I agree about launcher, Its a good temporary(perma) solution untill in-game full rewrite of something. It should e done long time ago.
Agree with NoQ, more reworked CLI will help building a better launcher. However my attempt to make launcher didnt give much feedback(except "how it works"). I know my app. aint good at all, but it's not demanded cause very poor warzone's integration... irc, well web qwebirc do it better(and with lobbycheckerlauncher not need at all).

Well I would love to see devs minimum enhance of current CLI for netplay and may be finally make the game work with new masterserver protocol.

Right now, I am redoing the net stuff, both in WZ & server side, so my hands are full

Interesting to hear some thoughts.

[NoQ]

And while a launcher can serve some valuable functions, there are others in cannot...

Guys, again: with a nice CLI, a good launcher is quite omnipotent (see smplayer, which is merely a qt launcher for the command-line mplayer). I'm not sure it's exactly what we need, but it might just be the easiest thing to do.

[Rman Virgil]

.

@ AWarZoner: You've created what's called a "strawman" in logic. The C# FlaMe is cross-platform ! You need to do some more research on C# and MONO..

Re-writing WZ in C++.... do you have any idea of the man-hours that would take ?

========>

@NoQ: What I was thinking of was augmented unit command UIs. I couldn't see how to do that from a launcher unless you could pull up the augmented UIs in-game to make command changes based on gameplay circumstances.
.

[NoQ]

What I was thinking of was augmented unit command UIs. I couldn't see how to do that from a launcher unless you could pull up the augmented UIs in-game to make command changes based on gameplay circumstances.

The game engine would run the game simulation, display terrain and units and stuff on the given surface (which is embedded into the launcher window), and accept orders, as pieces of data similar to orders transmitted via network, but instead take them in text form from standard input (to which the launcher writes them), probably also handling mouse actions over its surface. The rest of the UI (eg factory and lab menus, game menu, alliance and intelligence menus) are handled exclusively by the launcher. One more thing necessary for this to work is for the launcher to have stdin commands to query the game state (eg. what can i research?, what units can i produce in this factory?).

Well, it's getting quite complicated. Not sure what to do with minimap radar. Not sure if it's actually the right idea.

[Rman Virgil]

.

@ NoQ: Your explanation was very helpful. I understand much better. Thank you.

Now that you mention the Mini-Map, I also see that as a key area for extended development in so far as being a means to facilitate coordinated multiple combat group maneuvers. Whether an evolved Mini-Map would also have to be worked into the launcher is something I'm not able to speak to with any authority. For while my understanding is better it is still tenuous.

@ AWarZoner: I'm glad you clarifed that point about "hacking" because I thoroughly misunderstood what you were saying.

In so far as MS's motivation for creating C#, I think there was more to it than just creating thier own language. There are notable differences between C# and C++ that have resulted in C#s ever growing popularity. But really, what it comes down to from my PoV, is answering the question of whether FlaMe C# is gonna be able to serve all WZ map maker needs well, across the 3 supported platforms, and my answer is yes.

Now my question to you is, how exactly do you think a WZ Map Editor written in C++ / Qt would serve all those needs, cross platform, better than C# ? In other words, what precisely are the practical advantages in the functionality of the tool for the end users as well as its maintenance, and on-going development, from the coders vantage ? From those utilitarian considerations how exactly is C++ the clear superior choice such that FlaMe C# should be disregarded ?
.

[cybersphinx]

I tried to split the topic, please continue the discussion about programming languages etc. here: viewtopic.php?f=3&t=11769

[vexed]

I did more clean up.

Anyway,

By 'launcher' do you mean the UI for creating/joining games, setting options, etc? If so, what's wrong with the current launcher?

What current launcher do you speak of ?
If you mean what you see, now, in the game itself, it really is limited in everything we want to do with it.

What i was *dreaming* of so far is the approach i've seen in mplayer (the famous unix-way movie player). As far as i understand, all they did is provide a good CLI, and then all GUI, if necessary, is provided by an external wrapper (eg. smplayer) that simply pipes stuff in mplayer's stdin and integrates mplayer's output window inside its own window somehow. All the necessary GUI widgets can be just drawn on top, iirc. So we don't start the original wz2100 process until the game is already starting. And we can optionally, as a feature, disable the graphics completely and allow making a dedicated server (?) And also, this way we don't necessarily need to implement the GUI wrapper itself; there had been enough community wrappers, i believe this effort would continue, we just have to wait (:

Another approach is to simply encapsulate the existing GUI deeply enough, and then see what API we need and how we can re-implement it. Or vice-versa: make some sort of libwz2100, encapsulating everything else, and let external applications call its API. Anyhow, it seems there is a natural need to provide some sort of abstraction layer between the UI and the rest of the game.

Well, the plan way back was to do something like this, but, after the initial plans fell through, and we are where we are today.
There was some nice mockups, but, those were just that.

I know there are other libs out there that we could shoehorn into WZ, but, it still won't allow us the full suite of GUI controls that Qt has. It is also far more complex to integrate cleanly, and I thought it would just be easier/faster to just make a launcher instead of doing all this within WZ itself.

Also just a FYI, the plan was to integrate Qt into WZ, but, after using Qt (pre 5+), you can see that we are still using SDL, since it was more robust on windows (& macs?). We can't move on to newer versions of Qt without lots of rewrites, since they changed things around, and we are using deprecated features.

A dedicated server is still out of the question, for a variety of reasons, at least, until there are LOTS of rewritten code.

crab_ & Terminator, nothing will change with the current sync code. What is being worked on is the lobby <-> server stuff.

Sorry for the lengthy delay in the response, I had a unplanned trip I had to take care of.