Thank you all for your prompt and elaborate responses, I highly appreciate it.
hellcatv wrote:it sounds like you have some very good ideas here
I noticed that a lot of these things were proposed earlier, but my main point was uttering what I'm interested in.
and we could certainly use another coder, especially at a time like this when folks are busy at school
I'm too, and also busy with a lot of other stuff, so it is well possible that my first results will come up in a few weeks or even months, but this thread should serve as a good starting point for me nevertheless.
I think ogre keeps taking baby steps towards newer graphical features whereas crystal space has to worry about physics and other things we'd end up ignoring (space physics is a lot different than land physics--esp wrt double precision, etc)
Ah, that's a good reason of course. I have found CS only to be more mature than OGRE, and that's mainly why I asked.
In the main engine discussion thread it was said that the new engine would have to be able to cope with the enormous distances needed by VegaStrike while still keeping up with detail. I'm not sure how CS' portals would fit into there, but what I know is that this is only achievable with enough bitspace. Java3D, for example, uses 256 bit fixed-point coordinates, which is enough for all purposes. I believe OGRE uses floats/doubles (?), which are probably both not enough...
a) damage on the hud: that would be quite useful--we'd probably consider a better internal representation of the damage--though SVN does have a mode where it lists damaged systems---the method for figuring these out is quite poor
I'm *highly* interested in working on the damage model. A lot of interesting RPG possibilities depend on that.
least Sol is 1/10 normal size---which means the sun is huge.... which system has the scale problem?
The starting system of 0.4.3.
d) the visible lag I think is an effect that can be disabled :-) in the config file (hud_lag?)
Ah, didn't know that. I wonder who would like hud_lag=1 and why...?
e) better fonts wouldn't be terribly hard---but given that ogre already has these--may as well just work on ogre?
I'm with you.
f) better joystick support would be awesome--and probably a reasonable first project to familiarize yourself with things...
Yes, and also one that might fit into my airtight schedule.
g) hmm vssetup worked for me--but ya a few folks had it crash on load---I think it had something to do with the -static flag I passed to gcc
It fails locating setup.config here. Well, moot point, I'm going to try SVN and try to fix the problem if I still experience it.
Now what I think a great starter project could be is a new cross platform config file editor that lets folks set the XML to various presets, but also lets folks customize individual values in the XML aside from the various presets (so they can fiddle with things individually after selecting a decent preset)
The current approach to things (XML with interleaved GUI instructions) seems very hackish too me. But devising a system that's good isn't easy either. Probably XSLT is the most straightforward way to go?
h) yes multiplayer development would be awesome--right now it's just deathmatch--but with some cargo and upgrades it could be a lot more like privateer--and with some sort of mutual goals it could become cooperative---course it would only be a few lines of code to make a coop multiplayer gauntlet that spawns enemy bots one by one with increasing difficulty---spiritplumber's WC server has bots flying around that respawn ---so using that code would be easy
For me the main incentive lies in carrying out missions with a few human wingmen (or being a wingman to a human leader yourself).
i) realistic landing---probably needs a huge graphics overhaul so should wait until ogre work is ready
Yes, it's hard.
j) definitely worth doing at some point---not sure it's a huge tangible gameplay benefit--but it could make folks more interested in seeing the rest of the game
I'm sure everyone who likes Wing Commander IV would agree that those parts of the game make up a lot of tangible gameplay benefit :)
There's more stuff I came up with:
k) there's no title screen, only the loading screens. Perhaps a nice title screen for VS should be shown for a few seconds.
l) no main menu -- you're just thrown into things. A main menu would also solve the title screen issue: show title screen a bit -> show main menu which doesn't need a lot of stuff in memory -> start game (if users has decided to do so) -> pick up the stuff from the current state of affairs.
m) related to the previous issue: in-game MOD manager. It should be possible to activate a MOD just by using in-game GUI.
n) The loading screens are sooo 90s :) That's of course not a programming issue, but at least the gals and guys could wear something more futuristic.
ahh yes--- 0.4.3. is sorely out of date--and it's strongly recommended you try out the svn release---or at least some of the mods to the games' releases--because they have newer engines I think even...
I'm on it.
not sure why large binary files are there---- we can look at that...
I just took a look at the check-out process every now and then and saw OGG files almost every time :)
as for mailing lists---it's dead because of the spam mostly :-/ we turned it to member only postings---- but somehow the spam still gets through... we can definitely coordinate there--and it's a good place to post ideas---we can revive it from the dead if there's interest!
BBS is a nice way for casual users IMO, but I like the flexibility of mailing lists -- I can use my favorite editor and save my work on large posts regularly, for example.
I'm not sure what went wrong with your members-only setup, this usually works fine. We could try it again.
A mail<-->BBS gateway would be best, of course... it would be no good if one half of the development would be discussed on the ML and the other on the BBS.
because when the developers have an hour of time they'd rather spend it on working the engine rather than cleaning up management stuff that hobbles along well enough as is...not a great policy--but we do what we individually like cus it's a volunteer project (for worse and better)....
Well, I have to admit I'm not very fond of that admin stuff either, I'd rather do more coding. But if it's for the greater benefit of the project and attracting more contributors, it needs to be done...
klauss wrote:You lost me. The sun is really bigger than your ship. Really. Even in 0.4.3.
Yes, it is bigger. But it's definitely not on the star scale, it's probably not even a cap ship :)
The binary files are there for two reasons.
A) They're the game's data files, so they're an important part of the project.
That's not stuff for Subversion, that's stuff for an FTP server.
I'm talking mainly about those pesky OGG files.
Nobody has anything to say there. Most of what has to be said is said on the boards... just the way it is. Feel free to use them (the mailing lists), what you say there will be heared just the same.
If you say so, I will. Thanks.
JackS wrote:See also: our model of Sol.
Is this information on the Wiki?
it wasn't very hard to clean up some of the more egregiously out-of-place cruft (evilwm,ethereal,...). Should be a little tidier now.
Thank you.
[Discussion mostly in private] is not a scalable pattern.
What's worse is that it makes it harder to participate for new people.
klauss wrote:If you feel comfortable with Ogre, or wish to dig into that, it would be a nice project. Two interesting things about it: it's a part of the 0.5.x project that lagged terribly behind schedule, so it could use some pushing, but also it's quite disconnected from the rest of the engine, so you wouldn't have to study the entire codebase.
Noted. I'm not very positive that I can get that done in the next time, however. We'll see.
It's definitely interesting stuff, and I have worked a little bit with OGRE in the past.
If you want to pick that task up, I'd have to finish that which I started a while ago and never finished (and now feel ashamed while I remember), which is the documentation of the many options which are not well understood by many, and sometimes not even on the vegastrike.config (they're left to their defaults most of the time).
Yes, I noticed that. My approach would have been to dig into the code to see what they mean and then write it down somewhere, but it's a lot more effective if you'd do it.
Whichever you pick, thanks for helping.
And whatever else, thanks for offering.
Thanks for your time. I'm sure we can figure something out.
Rylis.
).
)
