[road map discustion] what want to see in v0.6.x

[www2]

Meby is this quastion to sone but: what do want your to see in the road map of v0.6.x?

-------------------------------------------------------------------
my ideas are for the multiplay games:
-------------------------------------------------------------------
A updater for the multiplay/mmo game's

This is for downloading new content and securty updates for a svn/repasetory server.

--------------------------------------------------------
Admin panel for thr game master/moderator/admin

this is a panel ingame/progame for game administration e.g. desine new area's, events, submit news, user administration, bug/suport tikets, ingame mail clent, etc.

------------------------------------------------------------------

I want hear what your think that need in v0.6.0

[charlieg]

List of features I think really need to go into 0.6.x:

• Remove need for gtk1.2 - perhaps use autopackage for the installer instead of loki?
• Complete UI makeover. Review options, and aggressively back one, make the UI something sweet.
• Adopt and fix the OGRE backend Klauss was working on

Some nicer-to-have features:

• Modular ships - be able to bolt ship components together to make something new
• Faction wars
• 3D base screens (not walk-around bases but perhaps a step towards that)

Some if-only features:

• Base construction / procurement - have your own space stations, become your own faction
• Procedural planet generation
• Ability to enter planet atmosphere

[prolog]

Atmospheric flight would be what I'd want. FE:2 had it more than fifteen years ago - what's stopping VS?

[DancesWithProtons]

We need to be able to access the nav comp while docked to determine where the systems are for missions and cargo. Not sure how it is programmed, but could there be access to the shift-m enabled at all times, not just while launched?

This would make things much nicer. I know the navcomp is simple and needs upgrades (the subjects of several different threads and many complaints) but for those of us who do use it, having access while docked would help very much.

Thx and kudos on a great game!

[SyntaxVorlon]

One thing I'd like to see is a straightforward keybinding listing in the HUD panel. The current system is nice, but it doesn't tell you all the key bindings, or they joystick/joypad bindings.

[ace123]

Should be possible to do a nav system. As far as hitting shift-M is concerned, at the moment the keyboard input goes to active widgets on the screen (base computer, Python interface).

Right now I'm thinking it could be possible to check if anything is accepting input, but won't be so easy.

Perhaps ctrl-M might work since it isn't a textual character you might want to use.

Also, you might not be able to do this inside a computer screen, only in the base.
This might also be subject to the 3d camera lighting issues that have been reported in bases.

[chuck_starchaser]

It's never clear to me whether threads in this forum are about Vegastrike the Game (VSG) or Vegastrike the Engine (VSE). If the latter, I'd like to restate priorities for PU:

• Separation of user_settings.xml from vegastrike.config.
• A fix for the lighting of ships on the landing pads and repair rooms: Light position, color, intensity; plus color of ambient light component. Furthermore, right now the FOV angle for ships at bases is controlled from one place in vegastrike.config. But different base art have different intrinsic FOV perspectives, so a ship may look right at one base, but "fish eye"-ish at another. For example, the repairs room should get a very wide angle shot; a real close-up; whereas most landings are further-away views.
• Native functions for tweaking faction standings and dynamic controls. In PU we're having to jump through hoops to get mission enemies to be enemies, or to ensure that your wingmen don't attack you, or the ship they're supposed to help you protect, or one another. The VSG rules of faction standings' dynamics rule upon other mods with an iron fist, and to get around them we have to come up with new, temporary factions by adding underscores to the names... It's total insanity; and all of Dilloh's time seems to go down the endless task of fixing mission problems that are almost unfathomable without trying to think of what would happen if the player was friends with the kilrathy and enemy of the merchants, for example. Really frustrating. We need a native means (c++ functions) to introduce temporary faction biases and restores. In the orgiginal game Privateer, mission enemies were always enemies regardless of faction standings. Mission friends were always friends regardless of faction standings. And if you fought hunters who were mission enemies, this had little or no impact on your standing with the hunters faction. Never mind questioning the logic of this; I could explain the logic of it, actually; but the fact is that this is the functionality that we (PU) need, and we shouldn't have to be hacking with python all the time for the lack of two simple functions.
  Another feature of the original Privateer game was that you could be surrounded by a bunch of goons that appeared as friendly (blue) while trying to negotiate something out of you; and it was after you said NO to their demands that they turned red and starting attacking you. To this day, there seems to be no way to duplicate this behavior with the VS engine; and every time we've asked for it we got suggestions for hacks that might approximate it. Enough. We NEED this kind of dynamic control. And we need it yesterday.
  And similarly, in Privateer, when you faced mission enemies, there were no random enemies around to complicate things, EVER. And we NEED this feature, as well, --and no if's or but's. Or, at least, some help with directions for what c++ files to look at to make it all happen ourselves. We just can't finalize PU without these features; understand? It will remain a sub-standard piece of unfinished work, until it can work like Privateer originally did, rather than like VSG. So, please help!, and help VSE become a true engine, in the process.
  Either bias and restore functions; or a way to specify "mission enemies" and "mission friends" that override standings.
• Dynamic control of system/jump point visibility. SYSTEMS (not jump points) ideally would have a visible flag. All jump-points leading to an invisible system could programmatically be turned invisible. Doing it this way would dramatically reduce the number of variables needed.
• Lip-synching...

[charlieg]

It's never clear to me whether threads in this forum are about Vegastrike the Game (VSG) or Vegastrike the Engine (VSE).

I think it's fair to say "both".

[ace123]

It's never clear to me whether threads in this forum are about Vegastrike the Game (VSG) or Vegastrike the Engine (VSE). If the latter, I'd like to restate priorities for PU:

THe former implies the latter. But anything in C++ is the engine.

Separation of user_settings.xml from vegastrike.config.

Will happen someday, but I'm not going to do it right now.

A fix for the lighting of ships on the landing pads and repair rooms: Light position, color, intensity; plus color of ambient light component. Furthermore, right now the FOV angle for ships at bases is controlled from one place in vegastrike.config. But different base art have different intrinsic FOV perspectives, so a ship may look right at one base, but "fish eye"-ish at another. For example, the repairs room should get a very wide angle shot; a real close-up; whereas most landings are further-away views.

Should also happen...

Native functions for tweaking faction standings and dynamic controls. In PU we're having to jump through hoops to get mission enemies to be enemies, or to ensure that your wingmen don't attack you, or the ship they're supposed to help you protect, or one another. The VSG rules of faction standings' dynamics rule upon other mods with an iron fist, and to get around them we have to come up with new, temporary factions by adding underscores to the names... It's total insanity; and all of Dilloh's time seems to go down the endless task of fixing mission problems that are almost unfathomable without trying to think of what would happen if the player was friends with the kilrathy and enemy of the merchants, for example. Really frustrating. We need a native means (c++ functions) to introduce temporary faction biases and restores. In the orgiginal game Privateer, mission enemies were always enemies regardless of faction standings. Mission friends were always friends regardless of faction standings. And if you fought hunters who were mission enemies, this had little or no impact on your standing with the hunters faction. Never mind questioning the logic of this; I could explain the logic of it, actually; but the fact is that this is the functionality that we (PU) need, and we shouldn't have to be hacking with python all the time for the lack of two simple functions.
Another feature of the original Privateer game was that you could be surrounded by a bunch of goons that appeared as friendly (blue) while trying to negotiate something out of you; and it was after you said NO to their demands that they turned red and starting attacking you. To this day, there seems to be no way to duplicate this behavior with the VS engine; and every time we've asked for it we got suggestions for hacks that might approximate it. Enough. We NEED this kind of dynamic control. And we need it yesterday.
And similarly, in Privateer, when you faced mission enemies, there were no random enemies around to complicate things, EVER. And we NEED this feature, as well, --and no if's or but's. Or, at least, some help with directions for what c++ files to look at to make it all happen ourselves. We just can't finalize PU without these features; understand? It will remain a sub-standard piece of unfinished work, until it can work like Privateer originally did, rather than like VSG. So, please help!, and help VSE become a true engine, in the process.
Either bias and restore functions; or a way to specify "mission enemies" and "mission friends" that override standings.

Unfortunately it's not so easy to do all of that. Anything that the engine supports is already exported to python. Other things might require changes to the unit classes.

There are ways to change faction relationships permanently (as well as push/popFactionRelationship for temporary changes)

There are also flightgroup directives as are used in bounty and patrol missions, so you can force someone to target you (and this should make it appear red on the radar as you were suggesting).

But you sound like you want something more complicated, like how to change a specific person's relationship or something of the sort. This unfortunately isn't possible at the moment.
It brings up a question: when do faction-wide relationships take precedence and when do unit-specific relationship matter?

For disabling random encounters, that's entirely done in python and it should be relatively simple to do (aside from handling conditions where a mission is failed or something of that sort). I'm thinking a list of (playerunit,significant) pairs for which no enemies are spawned.

Dynamic control of system/jump point visibility. SYSTEMS (not jump points) ideally would have a visible flag. All jump-points leading to an invisible system could programmatically be turned invisible. Doing it this way would dramatically reduce the number of variables needed.

Also nice to have, and I don't think this will prove impossible since all the information is there. We'll have to figure something out so that it doesn't have to check a save variable each and every frame.

Maybe only display jump points if you have targetted them, and then combine that with checking for the save variable upon selecting a target, and upon attempting to activate the jump drive.

Only displaying them when they are targetted might actually prove to be a neat effect. What's your opinion?

Lip-synching...

Practically impossible.

There is code to have an image stream from a python script.
Now combine that with the textual versions of the speech combined with information on how many syllables in each word and length of time to pronounce each one and you might be able to do this.

Still, I don't know how privateer managed to do this. Perhaps someone hand-coded the timing for each sound file... maybe it's embedded as tags in the original sounds.

[chuck_starchaser]

Thanks. I'll PM you with a few questions.

[spiritplumber]

HAY GUYS WHATS GOING ON IN THIS THREAD...


Can I offer a simple suggestion for the .config conundrum? Just have the engine look at two files with related names, concatenate them internally, and parse them as vegastrike.config is now parsed. This lets people put stuff in the wrong file in theory, but that can be good for defaults (so, have vegastrike.config contain defaults and have setup.exe act on vegastrike.config.user). This makes necessary that .user supercedes .config, but since it's all xml you basically just call the parser twice...

[safemode]

I personally dont like the idea of making ogre3d a "todo" for 0.6. Ogre3d is a massive change. It's the difference between 1.0 and 2.0, type stuff. And we're gonna need more people actually working on the port before it can be made a todo for anything, 1 person is hardly enough for something that big of a project.


why is atmospheric flight so important to people? What exactly do you expect to do in this mode?


My 2 cents for 0.6 would be in addition to the network stuff (which i dont really pay attention to right now), we'd develop some high quality campaigns for VS the game, and overhaul the AI for VS the engine. I'd like to see the faction system overhauled to be more integral to the game and allow the user to choose a faction and allow the ability to defect to another under certain circumstances. I'd like to see the AI setup home systems for factions and treat them as such. I'd like to see the elimination of factions if all their occupied bases are destroyed.

I'd also like to see that spawning ships only occurs at special "ship yard" bases and this is allowed to happen at a random rate proportional to the number of bases under that faction's control.

and blah blah blah. In reality, nothing on a todo list is going to get done unless someone wants to do it themselves. I have my wish list. I can probably do some of it but who knows until the code is actually looked at.

Perhaps we should just stick to "Bugfixes for 0.6" rather than a wishlist of new features.

1 elimination of being able to sell items and buy them back for less than you sold it for.

2. elimination of the bug where you can store items larger than what should be able to fit inside your ship.

3. elimination of bug where heavy beam weapons do not draw sufficient power to make them unusable on anything less than a capital ship. This goes for any weapon sufficiently strong enough to make the game non-competitive. You should require multiple reactors and that should be impossible for any non-cap ship

4. fix Nubula's so that they work as intended. Make them massive and see if we can use some GL effects to make them non-ugly.

5. jump gates should be invisible off HUD.

6. remove ships from the display in the NAV computer. It's completely useless to show them anyway.

7. Reduce the range of the strongest sensors so that ships extremely far away are not displayed on cycling the units in the HUD.

8. Seriously reduce the amount of particles given off during damage. This is a massive cpu user per frame. If we can't figure out another way to make an effect for this type of damage, then limit the number of concurrent particles to 1 and as damage increases, decrease the interval.

9. Users who eject, and survive, and have money, should not be left out of the game. There should be a way for a user to pay a ship to transport them to a given system where their other ships are docked or they have the ability to buy a ship. This would entail the development of a "classifieds" type system in the Computer where the user can choose from various menus various actions and objectives to create a mission and then give a price for any who choose to take it up. This would then go on the mission computer and allow the AI to accept. We may have to fudge the "ai" accepting the mission for now, but it would allow the user to also assume the ability of the "fixer". This would fix the "stranded" bug where a user has ships, or has sufficient money, but is standed in a system where they can't access either.

[charlieg]

6. remove ships from the display in the NAV computer. It's completely useless to show them anyway.

Even capships? (FYI, I don't play VS -- or games in general -- as I'm too busy working. Just reading the forum for brain R&R.)

[safemode]

I wanted to stick to bugfixes only but you could add a drop down somewhere to select predefined groups of ships .. (all, none, capships, enemies, friends, cargo vessels)


in any case, that's not important, what's important is that showing "all" all the time, is broken by lack of usability.

[chuck_starchaser]

I couldn't agree more, safemode. Bug fixes before features. The way it should always be.

[Coragem]

Just read the 9. bugfixes list, just about all the main issues i see during play are there.
Since multiplayer is new, i say, try it out, test, and make it work as flawless as possible in 0.6

As for my wish list.

1- Make Dodos and other non-letal armed ships not engage in combat unless fired upon.
2- Nerf tractor and repulsor beam on players. (Dodos annoy me a LOT)
3- Make the AI stop kamikasi chashing onto players.
4- Make the autopilot follow a ship using spec a little more carefull. i got INTO a corvete once it stoped in front of me. (colission problem, maybe this new collision code will work out better)
5- Make the Total kills also have a "kills by ship type indicator" Llamma:1 Robin:3 etc...
6- 3D cockpits enabled and for more ships?
7- Dumbfire explosions are Huge! i did kill myself many times, is this suposed to be right?

Well if i remember something else all post again.

[www2]

I heft some ideas for multiplay and game/server administration.

1. use OpenCDS sending updats for the multiplay clients.

2. administration page on the the servers for the server and game admin's.

3. In game moderation tools for the game admin's.

4. A master server like what use in openttd for the deadmatch servers.

5. Optional a new host out site sf.net and ouwer one servers.

edit:

6. A easy ingame deadmatch server setup screen

[charlieg]

I personally dont like the idea of making ogre3d a "todo" for 0.6. Ogre3d is a massive change. It's the difference between 1.0 and 2.0, type stuff.

I'll respectively disagree. Yes, the ogre3d switch would be a massive change but it's not really going to affect gameplay.

I would like to see a series of 0.5.x releases adding new features and keeping development active rather than stagnating for a long period like between 0.4.3 and 0.5; keep putting out new updates to keep people playing and contributing. Then when the ogre3d release is ready push a 0.6 or 0.7 (wherever you guys are up to by then) and when it is polished, label that 1.0.

That is, of course, if the ogre3d release even happens. It's not unthinkable that VS stays with it's own engine that simply pulls what it needs from the code of other graphics engines like ogre3d and crystal space.

[safemode]

a todo means "wont be released until" and that's not what should be on 0.6. Ogre is too big. It's already a "todo" for the project, and it will continue on through 0.5 just like it has been for 0.4, and will continue until it's done. What you'll get if you make ogre a 0.6 requirement is just a bunch of 0.5.x releases while ogre continues to be worked on. Nobody is going to wait another year while the one guy working on ogre continues working. It's semantics. Either we avoid having 10 0.5 revisions before 0.6 (many of which may be signicant changes), or we move on to 0.6 after a signicant amount of change from 0.5 and continue on a practical and logical version roadmap parallel to ogre development.

If you really want ogre to get in before 2009, start helping. The ogre port seems to be much more frustratingly difficult than it seems on the surface, and none of the other active developers (including me) are very enthusiastic to tackle it. The ogre port needs more people to help, if it remains a one guy effort, you'll be waiting and 0.6 will not.

edit:
I'm not being combative here, it's just the reality of the situation. One person doing ogre is going to take a really long time. Much longer than it will take for the rest of the developers to make significant changes to the VS engine and data4.x, and it'd be stupid to get into the double digit 0.5.x versions despite the changes possibly being bigger than 0.4 to 0.5. That's why i disagree with putting it on any version ToDo list. Like you said, you dont want to wait for development to get to packaged binaries, well, the timetable for releases has to be shortened greatly, and the ogre port can not comply.

[chuck_starchaser]

CharligG, Klauss worked really hard at the Ogre port, and there's a huge mountain of work already done on it, but for the most part he'll have to find the time to finish it. It's a huge task, and what Hellcat did, in the meantime, was to bring shaders into the engine without Ogre, as a stopgap measure, and it's working out quite nicely. It's not finished yet. At PU, we're going to start working on shaders very soon (a matter of days), to take Hellcat's work a step further: Namely, to have the engine compute tangent vectors on mesh load, for correct normalmapping; and then implement a new texture packing whereby the dU and dV of the normalmap will be on the alpha channels of the glow and damage textures. This new system will serve us well for a year or however long it takes until we do the move to Ogre.
The move to Ogre will be the last step in the shaders evolution. It will use two passes instead of a single pass; and it will implement dual UV mappings: One mapping without UV island sharing or mirroring, --for normal map, light map and PRT's; the other UV mapping re-using islands and using mirroring, to do finer detail in the diffuse and specular channels.
But that implies that all ships will have to be re-unwrapped, to have dual UV's.
So, the Ogre move will auspice not only far more sophisticated shaders, but also will demand a lot of rework by artists. I don't think there's much of a rush to get there. Already, having shaders now, puts the onus on artists to come up with normal maps, and that alone is going to take time.

[ace123]

I heft some ideas for multiplay and game/server administration.

1. use OpenCDS sending updats for the multiplay clients.

That sounds interesting.
I'm not so sure about this yet. We do have Subversion and we've tried an auto-updater before, but it did not work very well.

I am concerned that at this phase in development a lot of the changes will be in the .EXE as well as in Python scripts. And this could break single player if we do it wrong.

2. administration page on the the servers for the server and game admin's.

That is doable, and there is already some support for this. This is all server-side so I will worry about this after the 0.5 release.

3. In game moderation tools for the game admin's.

Exists, to a limited extent. You can spawn AI ships and set admins. Use "/help" to find out which commands to run. These are extensible in Python.

4. A master server like what use in openttd for the deadmatch servers.

So in between a full account server, and individual deathmatch servers. I think this is going to wait for a later release.

5. Optional a new host out site sf.net and ouwer one servers.

Yes, this would be nice. One feature I must add is the ability to have HTTP 302 Redirects so as to allow clients to connect if we move servers.

6. A easy ingame deadmatch server setup screen

It is pretty easy already. What can you imagine to make it easier.

Right now, you run (double click) vegaserver.exe, and connect to the IP address it displays on the screen from in the game.
Then, it lets you choose ships and you can buy some upgrades.

Editing settings is more complicated but it is still possible to do.

Any ideas at all you have would be welcome. There are a lot of things that we can now do with Python scripting that were not available when I designed deathmatch, so many things can change before release.

[legine]

Well first of all I want to see the 0.5 release finished? I still see only the 0.5.0 windows beta is out . (Dont excuse yourselves with svn, thats a living thing.)

Well I have no Idea what 0.6 should contain.

I would like to see VS moves further to OGRE. But as I read this is on the way.

The other point is:

As you said, it would be awesome to squish everything into two APIs:
3D (meshes), and 2D, which could really be an extesion of 3D drawing on a 2D surface, export that to python and you can suddenly do anything in the world Smile

Whishing this, is far more then 0.6.0 should contain. But I have no Idea what smaller steps are wise to do.
From what I read it may be not to much to whish for the shaders in 0.6.

When I have a release of piarmada I will eye the UI stuff and bug you how we can make the UI things move towards the point Ace123 summarized so well.

- I am against anything automatic that would not work without. You cannot provide anything automated for the flavors VS is designed for.

I would like to see for 0.5 a source release (0.6. if not otherwise possible.)

why is atmospheric flight so important to people? What exactly do you expect to do in this mode?

How much games you know that can do such thing?
The point that this Idea is still alive should make us think how we can change the system to one day beeing able to extend the game in this direction. However I have no idea where to start. I just know little about the handywork of the game.

Last thing I would like to see is a workup on datahandling. Dont get me wrong the Handling isnt bad, just, well widespread. We have a lot of XML / Datafiles that have all kind of data spread throughout the folder hierachy. And even some Data are not easy to access (Like Savegames.) I would like to see if we cant at least optionally move to a cleartext savegame and put all Data in one folder while haveing the engine Rule in another folder...
(Backround Idea is to be maybe one day be able to push a Database under VS. I.E for real MMO (if that what ppl want) this is a must have and this is what we can do now )

hope I am not to much of a lough, but thats where I want to go. And I will help as good I can to get there. I hope more usefull in future then I am now

Cheers
Peter

[ace123]

Sadly, there is a reason that planetary flight hasn't been done yet. It isn't exactly simple to do.


I was thinking last night actually that we could merge the contents of serialized_xml into the save file.

True, it wouldn't necessarily be easier to read, but it would solve the issue with people only copying one of the two directories and then losing their saved games anyway.
Saved games are already cleartext. Do you want a more structured format?

Right now the account server runs either on a file or with a mysql database.

[legine]

Sadly, there is a reason that planetary flight hasn't been done yet. It isn't exactly simple to do.

yes I know. But still it is a very alive dream. One that introduced VS to me. It was not "look another space simulation" it was look people trying to make a "space simulator that can do atmospheric flight!"
And this is something that makes VS unique. And VS should stay unique.

What I want to say is to keep the dream alive and to let it influence developer decision. Who knows where it will take VS. But it will take us where no game was before. And I think that makes this Project more charming then others. =P
Maybe I am too idealistic here. Well for sure I am.

Saved games are already cleartext. Do you want a more structured format?

Yes Think so. I just know that Savegames not the position as binary format, so I guesses it is all binary. Maybe I need really to look first before I talk.

Right now the account server runs either on a file or with a mysql database.

cool!!
But i was more talking of all data, which is far more then just the multiplayer file. I mean all gamedata is there somewhere. I mean we have:
weapon.xml
ships/
universe/
Sector/
stats/
Maybe more I don't know.

Maybe that doesn't matter much. But i think it is easier to move towards a database if the data is arranged in a similar way in files already. Or am I wrong here?
(Ofc, this is not that Important to me. Just something where I am thinking: "Steps for the future.")
[edit]
Yes serilized_xml is a bit confusing to me. But I know nothing about what it is used for. I dont see a reasing to merge both.
And yes a more clear way of reading save games would be great. Also unifying Data presentation.

[safemode]

I think that maybe instead of focussing on specific changes, which requires developers to want to do them (and that anyone with time can do them), we should think about the overall aspects of VS we would like to see changed. Not something as specific as atmospheric flight, or save game changes or wormhole changes, but big changes that gives room for different developers to contribute in different areas. Not everyone is able to code in every area, and by limiting the areas we want to focus on, we remove much needed developers from helping.

I think one major sweeping change we could want to do for 0.6 would be a total reworking of VS's campaign and political/economic system.
1. I'd like to see a campaign where you choose you faction you want to start out in.
2. Factions will be drastically different in AI and missions and they will have home systems and certain trademark ships. You start out with a faction but with the lowest affiliation points. as you help the faction, by trade, kills, mission objective completions etc, you gain affiliation points. 3. These points would also dictate how members behave when you need assistance, and how attractive you are to other factions as far as a price on your head if they're your enemy.
4. AI would be reworked to handle the new setup accordingly. There are multiple ways to give the "faction" a sense of group centralized thought, it'll be up to the developer how it's done.
5. Economics will be persistant. Bases will be responsible for producing items for trade in a logical manner, (mining bases produce raw material, refineries produce refined material , etc etc). Ships will be produced (spawned) only from ship yards. Either on base or in orbit.
6. Factions can produce new ships depending on the economy. Much of the economy is dependent on bases and unseen (pretend) trade based on Real trade by actual in game ships. (If a ship trades between bases, the game will multiply that trade as if many ships made the same route, after the in-game ship is done). Thus, in game ships establish trade routes in which the game pretends a vastly larger number of ships than are in game, travel. Thus simulating a realistic economy of billions and billions of people.
7. If the production facilities of a faction are destroyed and none are made to replace it (due to lack of money) then the faction will slowly die out, unable to create more ships. Factions with planetary bases can be impossible to completely die out if the planetary base is allowed to create ships.
8. The goal of the campaigns are faction dependent and technically without end.
9. You can change factions by helping another faction and gaining points with them. Doing this would be dangerous as your old faction would not be happy with you.
10. If you get enough points, and you get enough cash, certain special (leader-only) ships will be available to you. like large carriers, cap ships, etc.

this hits every system in VS, it gives everyone something to do towards a common goal. This is the type of ToDo list that has a chance of working with the number of developers working on VS now.
Lets see some other suggestions like that.