Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Kazan on March 02, 2005, 12:11:49 pm
-
please make it so we can save "Settings profiles" So we can quickly switch between settings sets for mods
-
Amen
-
and ad a fred tab, so that it may be lanched with mods and other command line options.
-
Originally posted by Nuke
and ad a fred tab, so that it may be lanched with mods and other command line options.
:yes: :yes:
I tend to use multiple icons but that's certainly not ideal.
-
Two things...
1) This should be in the internal
2) The Launcher is RandomTiger's department, and he hasn't been around here for about six months
-
1) um, no - because i wanted non-coders to be able to insert there support
2) ugh
-
You should know by now that all the user support in the world means nothing if there's nobody around to do it. ;)
-
I'm already working on a few launcher things (reg string bug, OGL caps file, OGL multisample selection). Don't know if I'll get to any of this but I might try to when time allows.
-
Couple things -
1) Use ShellExecute instead of whatever's being used in the command line flag list, that way if people use a non-MS browser it'll open the URL in that one.
2) Don't reset the FS2 location just because a folder exists in C:\games\freespace2. For some build configuration, I had/have the folder being created (unintentionally), and the browse window would go to that folder rather than my E:\games\freespace2. Even though the C: folder had nothing in it, and the E: folder had 23 EXEs or so. :p
-
Originally posted by WMCoolmon
1) Use ShellExecute instead of whatever's being used in the command line flag list, that way if people use a non-MS browser it'll open the URL in that one.
RT fixed that a while back I thought. It used Firefox for me when I just tried.
-
The version of version 5 I have opens IE. :nervous:
-
Originally posted by WMCoolmon
The version of version 5 I have opens IE. :nervous:
Yeah it was 5.3 I think... or maybe that was 5.2. I bumped the version on my Launcher builds and I can't remember which is which anymore. :rolleyes:
I'm working off of a CVS version of the Launcher pre-dx9 since I can't get the DX9SDK for Win2k and so current HEAD won't compile. Doesn't look like the CVS version was kept up to date 100% with what RT released though so figuring out exactly what was in each version isn't easy.
-
So a version that uses the shell hasn't been released?
Because I'm using the latest from the site, and mine opens links with IE, which is a sess-pool of viruses at the moment... :s
-
um.. wasn't the installer last made by Fractux?
-
The launcher isn't the same thing as the installer.
And incidentally, my version of the launcher (5.2) uses the default browser. I just tried clicking on Forums and it opened Firefox.
-
Right. Got mixup. For a moment I thought he did he launcher too.
-
If the community draws up a plan of what they want and how they want it to work I will consider implementing it.
-
Hey RT. Good to see you.
My first suggestion would be support for selecting multiple mods. The code cand do it now but since the launcher doesn't support it most people haven't noticed.
-
OK, theres a mission statement.
Now flesh it out with a plan.
-
What I suggest is this. Instead of getting a requestor up when you press the select mod button you instead get a list.
You can add moddirs to the list by calling up a requestor. You have a couple of buttons at the side of the list which allow you to move the selected directory up or down the list.
When you're done you click the OK button and the list is closed. The -mod command is added to the other command line options like this -mod first in the list, second in the list, third in the list..... etc.
Good enough?
-
What about the storage of settings?
Which settings need to be stored for each MOD and which dont?
-
just store all settings - it's simplier
-
Originally posted by RandomTiger
What about the storage of settings?
Which settings need to be stored for each MOD and which dont?
Which settings? The other command line flags? As far as I know those don't alter depending on the selected mod at the moment anyway.
-
Originally posted by RandomTiger
If the community draws up a plan of what they want and how they want it to work I will consider implementing it.
:eek2: You're back. I thought you were gone for good.
-
I like the mod-list-checkbox idea. Esp b/c of something I was thinking of looking into doing...
Have a file of some sort on the warpcore and/or indiegames server that stores a list of mod names and download locations. Implement some basic HTTP/FTP getting functionality (I think there's already stuff in the code for that) and use that to download the list. Then add that to the mod list, with some sort of marker to denote that they're remote mods. (Ideally there'd be some sort of description with each one, some relevant links or screenies or something). If one of the remote mods is chosen, the Launcher auto-downloads and installs it to a moddir.
If version numbers could be attached to files, that'd be doubly convenient, making it easy to get the latest version of mods (or mVPs).
Something else I'd like to see, the description of a command line displayed without it being necessary to open a browser window. Could be done with a new dialog, or tooltip style.
Welcome back. ;)
-
I was wondering if it would be a good idea for the launcher to store a ini file in a mod dir when you idenify it as a MOD. It could use that to pick it up later by scanning the dirs on that level for this ini file.
The ini could hold all the settings for that MOD. In thoery MOD'ers could create the ini's themselves and distribute it with the MOD's so it had the settings they wanted.
WMCoolmons download idea sounds great but a bit over the top perhaps?
The point of putting the descriptions in html was so coders or even normal users could edit the wiki to keep it up to date without having to touch the code.
The one thing about the Launcher is that its best if you keep the number of revisions down, because everyone gets confused about which version works with which version of fs2_open.
Personally I think we should keep it simple and flexible. If anyone wants to write fs2_open_stream then go ahead but I think it would be better to keep the main effort on the game itself.
-
The point of putting the descriptions in html was so coders or even normal users could edit the wiki to keep it up to date without having to touch the code.
Coders still have to edit the code to add the command line parameter to the list. ;)
struct ModListItem
{
int type;
char* path;
//If a remote mod
char* name;
char* description;
}
void LoadModList()
{
std::vector ModList;
AddModDirsToList(&ModList);
char* buffer;
HTTPGetFile(&buffer, "http://fs2source.warpcore.org/mods.lst");
ParseRemoteMods(buffer, &ModList);
size_t num = Modlist.size();
for(unsigned int i = 0; i < num; i++)
{
AddListItem(ModList[i].name, &ModList[i]);
}
Download/extraction is harder, you'd need a progress dialog and some sort of decompression lib for windows. The upside is that with RAR or something, a mod dir could be created and the RAR directly extracted into that, so mod setup would be pretty quick and easy.
Anyway, I just think it'd be a good way to publicize mods, the system we have now is looking for release threads in the campaign forum. ;)
-
Originally posted by RandomTiger
I was wondering if it would be a good idea for the launcher to store a ini file in a mod dir when you idenify it as a MOD. It could use that to pick it up later by scanning the dirs on that level for this ini file.
The ini could hold all the settings for that MOD. In thoery MOD'ers could create the ini's themselves and distribute it with the MOD's so it had the settings they wanted.
:yes: :yes: :yes: :yes:
-
Originally posted by RandomTiger
I was wondering if it would be a good idea for the launcher to store a ini file in a mod dir when you idenify it as a MOD. It could use that to pick it up later by scanning the dirs on that level for this ini file.
The ini could hold all the settings for that MOD. In thoery MOD'ers could create the ini's themselves and distribute it with the MOD's so it had the settings they wanted.
Already doing that. Using the registry is being ditched in favor of an ini file (in the moddir) like Linux uses. It will have all of the video settings, cmdline options and flags for the new SCP options screen (held up at the moment). There flags in the options screen (and cmdline options for those that aren't replaced) will allow a defaults ini file which could be distributed by the mods. The system specifc ini file would override those only if different.
I halted all of this for now (the basic ini file is working though) since I had a bad thought about the new options screen and want to rework some stuff to make it more useful and much easier to add new options to. Also been working on bugs primarily and OSX support so this isn't really high on my todo list.
-
Originally posted by WMCoolmon
Coders still have to edit the code to add the command line parameter to the list. ;)
Yes but its the build exe they edit not the launcher.
-
:doubt: That's what I mean, have the description in the EXE with the other parameters, in the array in sexp.cpp.
-
I dont see why thats better than having it on twiki.
Has anyone got an ini parser class/file handy?
-
Originally posted by RandomTiger
Has anyone got an ini parser class/file handy?
I'm just using a slightly modified (for memory stuff) version of osresigtry_unix.cpp to replace the Windows and Linux version in the game. Haven't done any useful Launcher work on that yet since I kept changing my mind on how it should be handled. The ini file layout is something like this though:
[Default]
VideocardFs2open=OGL -(1024x768)x32 bit
Gamma=1.00
LastPlayer=
SpeechVolume=100
SpeechVoice=0
SpeechTechroom=1
SpeechBriefings=1
SpeechIngame=1
[PXO]
FS2OpenPXO=1
Login=
Password=
SquadName=
Supress_TO_Warning=1
[Options]
Cmdline_nospec=0
Cmdline_noglow=0
This file is named fs2_open.ini. The options specific ini file only contains the [Options] block, it is named fso_opt.ini. Both can be specific to a moddir and it will only use the first one found of each. The options that are in the options block will be renamed from Cmdline to keep things sane for us and be removed from the set of cmdline options (ie. Cmdline_nospec -> Option_nospec). These will instead be on the new options screen in-game and can be changed on the fly.
-
Originally posted by RandomTiger
I dont see why thats better than having it on twiki.
Has anyone got an ini parser class/file handy?
Code:
- Add another entry to the array
To view:
- Double click on the entry and a dialog comes up
Wiki:
- Open up browser
- Find wiki in the bookmarks list (if you're lucky) or open up HLP and find a link
- Find the command lines entry
- Click edit
- Login
- Click edit again
- Find where the new entry should go
- Add the new entry, with a bookmark
- Submit it
- Copy the url, go back to the code, and add it in along with the bookmark name to the code.
Oh, and of course, if gamespy is down, then you can't add it to the wiki and have to remember to do all this at a later time.
To view:
Double click on the entry and wait for your browser to load up. Take a few seconds to find the command line entry on the screen (Hopefully, it's at the top of the screen since they're bookmarked)
What I don't mention is that this also takes care of versioning - if a command-line option isn't there, then it means it's not supported. With the wiki, you have to add the date it was added and the build's date has to be checked or else you get 'well, it was on the wiki, why isn't it in the launcher?'
-
Yes, that does make sense actually.
Feel free to implement it.
-
Originally posted by RandomTiger
I dont see why thats better than having it on twiki.
Has anyone got an ini parser class/file handy?
freshmeat :)
http://inilib.sourceforge.net/
http://ndevilla.free.fr/iniparser/
http://freshmeat.net/projects/stl_ini/
-
Originally posted by karajorma
My first suggestion would be support for selecting multiple mods. The code cand do it now but since the launcher doesn't support it most people haven't noticed.
Do people use multiple MOD's often?
I take it the first takes priority for common data (eg interface)?
Is this something we deliberately support for a reason or does it 'just work' due to the way its implemented?
Is this something that we should open up to the casual user with a proper interface or leave advanced users to use the command line to specify more than one MOD?
You can currently specify your primary MOD with the 'Select MOD' button and specify secondrys from the custom flags line.
Im temped to refuse this request for now, since multiple mods can be used via instructions on how to use the Launcher or the MOD's could be merged at the directory level and supporting it raises all kind of complications with implementing a settings file for the MOD's.
What I will do is make the 'Select MOD' button specify its MOD as the first as the the moment it puts it last.
-
Originally posted by Nuke
and ad a fred tab, so that it may be lanched with mods and other command line options.
Originally posted by karajorma
:yes: :yes:
I tend to use multiple icons but that's certainly not ideal.
Request refused, for the moment. Sorry.
If I'm going to spend time on Fred it should be to fix bugs.
Multiple icons arent ideal but they are cheap and chearful.
-
Originally posted by mrduckman
freshmeat :)
http://inilib.sourceforge.net/
http://ndevilla.free.fr/iniparser/
http://freshmeat.net/projects/stl_ini/
Thanks duckman, iniparser looks good.
Im going to start with a basic system to begin with.
We can scale it up to Taylors vision later on.
-
Originally posted by RandomTiger
Yes, that does make sense actually.
Feel free to implement it.
Can I use the Launcher sources in CVS, or is there anything special I need to do to get a copy of the source for a version that supports the current FS2Open version?
-
Originally posted by WMCoolmon
Can I use the Launcher sources in CVS, or is there anything special I need to do to get a copy of the source for a version that supports the current FS2Open version?
You could do if it wasnt corrupted, you'll need SAPI SDK.
Could you hold off for now since Im working on it, you've just missed the six month gap when I wasnt looking at it.
I've been thinking and we could have the best of both worlds, just use the same field, if it starts "http:" open a browser, if not display it in a dialog box. Thats easy, what puts me off is that the launcher gets the data by calling fs2_open with a flag that generates this info. The more we add to it the bigger the load up pause will become.
The other problem is that certain changes require everyone to update their versions of fs2_open and the launcher at the same time which is always a nightmare, all you get is hastle off people who are trying to use the wrong versions with the wrong thing.
-
Originally posted by RandomTiger
You could do if it wasnt corrupted.
Could you hold off for now since Im working on it.
I've been thinking and we could have the best of both worlds, just use the same field, if it starts "http:" open a browser, if not display it in a dialog box. Thats easy, what puts me off is that the launcher gets the data by calling fs2_open with a flag that generates this info. The more we add to it the bigger the load up pause will become.
The other problem is that big changes require everyone to update their versions of fs2_open and the launcher at the same time which is always and nightmare, all you get is hastle off people who are trying to use the wrong versions with the wrong thing.
*Holds off self* ;)
We could reduce the pause a couple of ways; one, if FS2 is called with the flags parameter, it looks for the Launcher and, if found, sends it a message with a pointer to a structure containing all the flag data. FS2 could malloc it, and then the Launcher would free it. This might require some memory gimmicking but I'm pretty sure it's possible to send information between two applications without writing to the hard drive or selling your soul to MFC.
Two, the Launcher checks the date on the flag file to the date on the EXE, stores that in the Registry (or, heck, at the end of the flags file) and if the dates check out it just reads the flags file.
Edit: Something that should be added to the flags file (or the flags struct) is what version of the Launcher it's compatible with. That way the Launcher can give an error or warn the user.
-
Originally posted by WMCoolmon
*Holds off self* ;)
We could reduce the pause a couple of ways; one, if FS2 is called with the flags parameter, it looks for the Launcher and, if found, sends it a message with a pointer to a structure containing all the flag data. FS2 could malloc it, and then the Launcher would free it. This might require some memory gimmicking but I'm pretty sure it's possible to send information between two applications without writing to the hard drive or selling your soul to MFC.
Two, the Launcher checks the date on the flag file to the date on the EXE, stores that in the Registry (or, heck, at the end of the flags file) and if the dates check out it just reads the flags file.
If you could do the groundwork on this stuff I would be happy to plug it in. Im not too happy about the way it currently works but I thought it was worth it as taking the info from the build itself is powerful and means the Launcher doesnt have to be updated so often.
It would be best to do all this to co-inside with a major fs2_open release, that way we the transition is likely to be smoother.
-
FS2OPen:
HANDLE hLauncher = FindWindow("Launcher", NULL); //First parameter is window class name
COPYDATASTRUCT cds; //Create copydata struct
cds.dwData=600; //Launcher 6.0
cds.cbdata=sizeof(exe_params); //How big of data are we sending?
cds.cbdata=exe_params; //pointer to the data we're sending
SendMessage(hLauncher, WM_COPYDATA, os_get_window(), &cds); //Send the data!
Launcher:
//This is in the message loop
case WM_COPYDATA:
COPYDATASTRUCT *cdsp = (COPYDATASTRUCT*) lParam;
if(cdsp->dwData == 600)
{
SetupFlagsFromFlagsArray(cdsp->cbdata);
}
I haven't tested it, but from the MS description that sounds like what you do.
-
Originally posted by RandomTiger
Do people use multiple MOD's often?
Very few people use it cause very few people know it exists. I keep telling them but they don't notice. If the launcher supported it though everyone would spot it very quickly
Multiple mods come in very useful when you're playing a campaign based on another teams works. Blaise Russel's Shrouding the Light immediately springs to mind. This one uses FS1-Port's ships but also has it's own tables etc.
With Multiple mods you basically just stick it in its own folder and use FS1-port as the second mod. Without it you're back the bad old days of dragging VP files around and renaming data folders.
StL isn't the only one that uses this either. There are a few campaigns based on Inferno and TBP that could probably use it (Miburo's Tales of EAS Janos springs to mind pretty quickly).
Originally posted by RandomTiger
I take it the first takes priority for common data (eg interface)?
Is this something we deliberately support for a reason or does it 'just work' due to the way its implemented?
Kazan supported it to deal with campaigns like the ones I describe above.
Originally posted by RandomTiger
Is this something that we should open up to the casual user with a proper interface or leave advanced users to use the command line to specify more than one MOD?
I can see big campaigns like TBP running into trouble if people start adding their own mods. Whether simply telling people to edit the command line is the best solution is another matter.
Originally posted by RandomTiger
You can currently specify your primary MOD with the 'Select MOD' button and specify secondrys from the custom flags line.
You can? How? Anything added to that box appears to be added before the -mod part since that is added at the end of the command line.
Originally posted by RandomTiger
Im temped to refuse this request for now, since multiple mods can be used via instructions on how to use the Launcher or the MOD's could be merged at the directory level and supporting it raises all kind of complications with implementing a settings file for the MOD's.
When I suggested it I just thought that it was a simple matter of needed to update the GUI to support a feature already present.
If it's causing you trouble then don't worry about it.
That said using multiple mods would always require that the settings file of the first mod was used in preference to all the others. Plus I don't see why having it entered as a command line option would make it any less troublesome. Surely it's going to have the same problems whether you pick the mod or enter it as a command line. Unless the act of selecting the mod is being used as the trigger for loading the settings file.
Originally posted by RandomTiger
What I will do is make the 'Select MOD' button specify its MOD as the first as the the moment it puts it last.
That should be good enough to please me :)
-
Originally posted by karajorma
You can? How? Anything added to that box appears to be added before the -mod part since that is added at the end of the command line.
...
That should be good enough to please me :)
The next version will see the -mod command come first allowing custom mods to come after that.
Perhaps if it would make more sense to control all this from the MOD ini so the user doesnt have to set it up in the first place. This is easier to implement and I think is more user friendly.
A MOD of a MOD could specify an optional 'primary MOD tag' and optional 'secondry MOD tags' which would build into the command line like:
-mod primary -mod 'this mod' -'secondry mod list'
I'm adding a MOD tab with some fun stuff that I hope MOD'ers will like:
(http://www.randomtiger.pwp.blueyonder.co.uk/freespace/images/mod.jpg)
karajorma, would you be willing to test this stuff out for me when its ready?
-
Definately. :)
-
Originally posted by karajorma
Definately. :)
What do you think of the alternitive multi mod solution?
-
eg
[launcher]
image255x112 = MOD_image.bmp;
infotext = Some information on this mod, thats a nice total war pic eh?;
website = [url]http://www.randomtiger.pwp.blueyonder.co.uk/c_code/freespace/index.html;[/url]
forum = [url]http://dynamic4.gamespy.com/~freespace/forums/forumdisplay.php?s=&forumid=50;[/url]
[multimod]
primarylist = -mod PRI1 -mod PRI2;
secondrylist = -mod SEC1 -mod SEC2;
[settings]
flags = -spec;
Gives: C:\Games\FreeSpace2\fs2_open_r.exe -mod PRI1 -mod PRI2 -mod MOD -mod SEC1 -mod SEC2
Options will be take from the 'active' mod (MOD in this case). I suppose the 'active' MOD doesnt even have to be a real mod, it can just tie other MOD's together.
-
karajorma could you send me an e-mail. I dont have your address any more.
-
I know this sounds strange, but can anybody put a "Use CD media" option? (For FMVs, briefing animations, and stuff like that, since I found the DivX ones a bit artifacty, but that is to be expected.)
-
Mail sent. You're still at blueyonder I hope. :)
FS2_Open can't use the CD media because the MVE playing code was ripped out for licensing reasons before [V] gave us the code.
There's absolutely no difference between the contents of the CDs and what's on your HD when it comes to command briefing animations anyway.
-
I thought I posted about this but it disappeared.
FS2_Open still has the CD reading code in there, I think, you just need to have the VP files on the CD-Rom and not in the main dir. Should work for all or some.
-
Originally posted by WMCoolmon
I thought I posted about this but it disappeared.
FS2_Open still has the CD reading code in there, I think, you just need to have the VP files on the CD-Rom and not in the main dir. Should work for all or some.
Well, apparently not for me. Taking the .vps off just gives me a Windows error instead.
Originally posted by karajorma
FS2_Open can't use the CD media because the MVE playing code was ripped out for licensing reasons before [V] gave us the code.
Can't Volition give the source files for the movies? (Not the MVE ones, but like the original files used to compose that movie, like a FinalCutPro file or something so that it can be recoded to DivX giving us a "cleaner" , if not better format for the rip?)
-
I don't think they would, even if they still had them. There's a big difference between releasing the pure source and releasing media from the game; the former doesn't necessarily rule out future marketability of the game while the latter does. Besides, I'd bet that all of those source scenes were deleted long ago.
And for the VP's, those never were on the CD. The only thing the CD read did was load the movies, which FSO legally can't play, so there's little or no point in trying.
-
Hrm, I'm sure I saw some code related to reading stuff off the CDRom drive in there...
I think the reason Volition didn't release anything else besides the source is because Interplay would also have to give permission. The code is copyright Volition, but the storyline and likeness of Vasudans/Shivans are copyright Interplay.
-
Could you start a new thread, this has nothing to do with the launcher :)
-
How about app run AA for OpenGL, instead of having to fiddle with the card settings? Could actually boost the performance.
-
That's an application setting more than a launcher feature; I've always understood that the launcher doesn't show it because the game doesn't make use of it.
-
Well, can somebody put 32bit textures to off as a default then?
-
It is off by default, if you mean -pcx32. Or if you're refering to 16bit display color depth as opposed to 32, you can always change that manually and most of us would rather use 32-bit.
-
As i have mentioned several months ago, there should be a "Value" tab on the features page.
Example:
(http://www.overlords-from-hell.de/launcher.jpg)
-
Originally posted by Overlord
As i have mentioned several months ago, there should be a "Value" tab on the features page.
Good point. Hard to implement RT?
-
On a similar note, to at least have a listing of all supported flags somewhere, even if they don't have a check-box associated with them. Remembering everything that can be set by the command line is hard for me, a veteran, and I know a lot of the newcomers don't even know that you can change your FOV, for example.
-
Originally posted by karajorma
Good point. Hard to implement RT?
Kind of, need to change the structures inside the fs2_open build as well as the launcher interface. I've always intended to do this but its going to have to wait until the whole system changes over (with WMCoolmon code and other additions).
Im not taking general requests, I dont want to spend all the time I have on the launcher. The thought of that is enough to drive me away for another 6 months.
If you do make request consider using 'could you please' rather than 'this 'should' do this'. Either that or start paying me for this.
I'm looking at what Kazan wanted because he made the effort to find me and ask me about it outside the forums.
And Im implementing (hopefully) what karajorma wants because its easy and hes willing to work with me to implement and test it.
-----
sfried, last time I looked (that was a while ago), 32 bit textures were off by default and the mode depth (16 or 32) is selected in the same way as fs2 retail.
You might want to try pcx compression (-pcx2dds), 32 bit colour depth but takes up a lot less space, the compresion means the image quality suffers though.
-
Please excuse us RT, we tend to get caught up in the feature requests. You know all we ask from any of you is that you do what you feel up to doing, everything else is secondary. Besides campaign-specific requests, the only reason these feature request threads exist at all is to give coders itching to take on a new project some ideas as to what to do. At least, that's the take I've always had on it. :)
-
Originally posted by RandomTiger
Kind of, need to change the structures inside the fs2_open build as well as the launcher interface. I've always intended to do this but its going to have to wait until the whole system changes over (with WMCoolmon code and other additions).
I figured that might be the case (which is why I asked if it would be hard to do). If it was simple you'd have probably done it right from the start :)
Originally posted by RandomTiger
And Im implementing (hopefully) what karajorma wants because its easy and hes willing to work with me to implement and test it.
Always have been RT. :)
-
Originally posted by StratComm
Please excuse us RT, we tend to get caught up in the feature requests. You know all we ask from any of you is that you do what you feel up to doing, everything else is secondary. Besides campaign-specific requests, the only reason these feature request threads exist at all is to give coders itching to take on a new project some ideas as to what to do. At least, that's the take I've always had on it. :)
Thanks for that :)
Its just sometimes I it seems like so many people are going 'I want, I want' then when you need someone to test your feature then only a small number of regulars (like karajorma and lightspeed) can spare any of their precious time to test it.
As a result bugs slip through and go un-noticed and then you get people (and I have had this) shouting at you. And its like, 'who the hell are you to be shouting at me? Your not paying me for this!'
Campaign-specific requests are good, keeps us tided to the MODs which is the future of our project and community. Bring them on but consider a few things (for all requests):
1. Its more fun for coders to work on a verity things. The more fun it is the more we will do and want to do.
2. Try and think out requests in detail.
I hope karajorma doesnt mind me taking his request as an example. All I know is how my launcher passes flags and settings around and some of the ins and outs of the D3D engine.
I didnt know multi MOD's were possible, I didnt know if they were officially supported, if many people used them, why anyone would want / need to use them.
When I have worked on freespace in the past I've only had enough time to code, I've not had the time to look at MOD's and how they work or keep up to date with the improvements of the filing system. I dont have the background knowledge someone like Bob will have from coming from that background.
I could go and learn all this stuff or people could do the research and fill in the blanks for me.
With input from someone who knows the system better and who in the end will use it, the implementation is likely to be better as well.
3. Be patient
We cant get onto most requests straight away, if its a good request theres a good chance we have already thought about it in a form but havent had time to get onto it. Overlords request is an example of this.
4. Think about problems
Try to figure out problems we might run into, exceptions or other bugs or limitations that might cause issues. If we know this stuff before we start it could make it easier and quicker to implement.
5. Never assume something is easy
Things are often more complicated than you might think, usually because of the nature of the code thats already there. Theres nothing more annoying than 'can you do this quickly because its really simple'.
Sometimes, not often, something complex is easy!
6. The most important, be willing to test the result.
Otherwise, two choices
1. The coder tests it. That means hes not implementing someone elses feature request. Also since its been developed on his system, bugs are less likely to show up.
2. It doesnt get enough testing and bugs get in there and arent found until the coder is half way through implementing someone elses feature.
-
On a lighter note heres a picture of my face mapped onto Gollum holding my graphics card!
(http://www.randomtiger.pwp.blueyonder.co.uk/freespace/images/precious.jpg)
-
Productive :yes:
-
That is one of the weirdest yet funniest things I've seen in ages :lol:
-
RT: Something else I've noticed, when switching in between OpenGL and D3D and vice versa, nonstandard resolutions aren't carried over. It's a slight bother for me, not anything too serious.