Vega Strike Forums

So that game was started in 2002, and we are in 2015 .
Are you happy with what you got today in your interface ?
...
That would be nice to have some improvements , like real buttons that produce sounds ,
some backgrounds that create an interesting ambiance for the menu.
But that might be too much work and too difficult to do , as no one in the dev team had
the idea and/or the motivation to make it .

For me , the gameplay starts in the first seconds when the game launches , and the menu is the first thing a new user will see ( and appreciate or not ... )

Perhaps you need some real example to understand my request ?
I was thinking at something like thet :
https://sourceforge.net/p/vegastrikevo/ ... ui-rooms-/

Yup, those Python menus and all that need improvement.
What would immediately and greatly enhance functionality:
1. Unified slot selection based installation system instead of ugly slot selection window.
2. Expansion of "base interface" to linkable "ship interface", integrated with runtime setup, nav screen instead of ugly half-broken current version (it seems to be a sane thing to check actual routes before accepting a contract, for one) and linkable to base interfaces of other units.
The rest is mostly decorative, though redesign would be nice, of course.

Hi , thxs to be here .

If you could describe with more details your ideas , i will make my possible to do what
is needed . ( to first check every point you will expose with code " how to " )
And with pleasure of course .

ezee wrote: If you could describe with more details your ideas

It was discussed a bit, but the point is, there are mount points and Upgrades categories that by virtue of appearing in Prohibited Upgrades count as de-facto slot types.
Further enhancement beyond explicitly allowed / explicitly prohibited would be better after overhaul of ship part system, if we'll need more than that earlier, a few optional refinements can do.
Thus, right now we have a list of goods on the left and already categorized list of installed upgrades on the right... To replace the mount selection window, we'd need to have mounts as separate entries on the right list (to handle removal), then include empty ones and while focus is on the left list, use selection on the right, along with mount type validation (to buy).
The same mechanism can be used for goods in multiple holds, like on Llama and including "Hidden_Hold_Volume".

As to the baseinterface, it already has "simulate_while_docked" confvar, so theoretically a default (later, to be expanded into cockpit- and/or unit-dependent) baseinterface room plus bound key to access the ship's own "cockpit/bridge room" and back at any moment would do, then it's a matter of adding control elements on Python side.
This would also remove some clutter from the current controls - it's easier to choose a turret from pictograms than find the right one by cycling.
At this point, nav screen, cargo manifest, etc could be absorbed into this interface and called with one line -
Base.Comp (room_nav, 'navcomp', X,Y, W, H, 'Navigation', 'SystemMap JumpMap')

Or from any base at all, via either importing the part of PDA "rooms" and node-connecting, or shortcut.
Saving configuration may be tricky, but all we need is to have a fixed subset of confvars written to separate XML file and made to override on game load; perhaps it could even be stored as an extra savefile (currently there's universe status text dump + CSV for each player ship).
Which is a good idea anyway, so we'd have:
- ruleset XML (server-side stuff) in data/mod root
- user controls (interface colors, joysticks if any, binding) in user dir.
- saved vars (cockpit dependent, perhaps extras like weapon groups) in savefile dir.

ezee wrote: ( to first check every point you will expose with code " how to " )

I would already have it written if had a clear idea how. Right now, it's in a gap between general concept and implementing specific details.

Okay ...
I think i'll try to make that room accessible in the cockpit first .
Then try the different otions you suggested to save the layouts and configs.

The layout of the rooms would be scripted anyway in a python module , like the main-menu.py actually do .

The joystick binding ... it's already in the config file , no ?
If i can create a c++ func and a python wrap for it , there will be no need to save it
in a different file/folder ? But the idea to have a separate config file for the joystick/Key mapping is good btw .

I think to code a page in my new menu options room for keys and joysticks binding.
So it should use that wrapped funcs , and save that setup then in .config or as you suggested an other file.

ezee wrote: The joystick binding ... it's already in the config file , no ?

It is. As well as mouse sensitivity, HUD colors, thickness and length of crosshair lines, speed of light and warp rates, AI autopilot parameters and lots and lots and lots... With conditions implemented via comment tags.
Splitting this pile to several (parameters that should be server-side, user hardware parameters and GUI tweaks) would be a good idea before trying to write there casually, no?

So you are talking to modify the configuration file ... why not ?
As the server don't need of graphics, input and sound configf data , that would make it
easier to edit for the server admin .
But the client also need network configuration ...

I think that i prefer to make my new functions using the actual config , then redirect the i/o
if needed . ( i don't want to debug the new config system + my new wrapped python funcs
in the same time ... )

But if you have a clear idea on wich datas should be mooved , you always can list them
( or copy/paste sections ) for i could then work on it .

13 years later and there's still no WYSIWYG editor for the basic things we need to rapidly make this game better.

Darkmage wrote:13 years later and there's still no WYSIWYG editor for the basic things we need to rapidly make this game better.

I'm for Python Glade in this area. Then we'll just fiddle a bit with GUI-builder, stuff a few .glade files in ruleset directories (visual styles mean proper flavours for mods), and all is set.
Inventing bicycles is both time-consuming and was exactly what gave us this mess in the first place.

I think we just need a "simpler" interface, games should be fun and easy.

With VS though, I think we should have an option for "realistic" where you would want a lot of controls to play with just to complicate things (though I always imagined vehicles in the future would be simpler to control).

PS: Sourceforge is down. :/

PS: Sourceforge is down. :/

I know just pointing Maxxale to the source code his music issue needs a local build.
Second the need for some complexity for the in cockpit controls we do bill ourselves as a space sim might be fun to handle touch screens in the interface as even Linux supports them now .

Enjoy the Choice