Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Fineus on October 31, 2003, 11:00:16 am
-
Hey all.. I may be way off the mark with this one - in which case let me know - but it seems a lot of people aren't sure how to turn on / off certain features of the source code.. or indeed what parts of the code are packaged with what *.exe file (the engine trails code change may come with glows and HT&L enabled, it may not - who knows but the person who produced it?).
My point is this.
Would it be possible to package a readme file with all releases of the code, including whatever changes are made from the original source as well as any commands necessary to run the code (or indeed where files need to go etc. to make use of the features it brings. I.E. Ships glows textures go in the effects folder).
It's not a massive thing, it just helps people like me keep track of what code is packaged with what mod and so on... so that if I want to try something I can know exactly what is / can be enabled and how to do it.
Indeed there could be a generic readme section on the website that contains each addition such as:
Glow maps:
These add glow effects to all lit elements of the ships. Glow maps should be placed in the /data/maps directory of the base FS2 folder.
Engine trails:
These add additional trail effects to engines of all ships in game. Textures should be placed in the /data/effects directory of the base FS2 folder.
Engine Particles:
Adds particle effects to ships engine in game. Use the following .TBL entrys to generate the code:
CODE
And place all textures for particles in the /data/effects directory of the FS2 folder.
Developers could cut/paste these into their readmes and add on their own changes at the beginning and/or end. End users could download the file, open the readme to see whats there and immediately make use of it.
Possible? Waste of time? It'd be really handy for the likes of me! :)
-
It would be useful to have a 'Bible' for the SCP, I think a couple of people are working on one, but because it's a WIP, it's constantly being updated.
Flipside :D
-
Such a documentation would need to be online and very easily accessible to all contributing to the SCP. Whenever something gets added or revised, it should be added to that documentation when committing code. I think a wiki (http://c2.com/cgi/wiki) might be a solution for this, if it's not going too overboard. At least it'd be easy and very very quick to edit. Some publicly available plain text document is, umm, lighter, but a clumsy way...
http://c2.com/cgi/wiki?RunningYourOwnWikiFaq
-
I think poor documentation is one of the biggest problems with the SCP.
There are lots of features that people don't use cause they aren't sure how.
The documenting features
thread (http://www.hard-light.net/forums/index.php/topic,12771.0.html) is a step in the right direction though.
-
Any one of you are welcome to start a documentation project up...
;)
We're bogged down in graphicky mothballs right now
-
I know Ive not been much help lately. But things are moving along, just not as fast as I would like. :ick
The Wiki (Tiki, or some multiauthor service) would be the ideal here. There's alot of changes being done, If you subscribe to the CVS mailing list you'l know what I mean.
Goober, whats your say on this?
-
Well, the best way, I guess, if for each person to take one subject and be responsible for finding as much as possible, for example, one person might do the new sexp's, another the new graphics facilities and a third might take on new table entries etc. That way people won't be repeating other peoples work :) But the SCP guys do realise this will include annoying PM's about 'what does this mean?' etc? It would have to be done as though to a complete noob though, since it would need to be as accessible as possible :)
I'm willing to help, since I will be one of the people benefitting from the information :)
Flipside :D
-
I'd be willing to field emails about this stuff. It would probably expose some dumb decisions that have been made too.
-
I always thought the readme folks (bottomfan and whoever else) should be in charge of documentation... they'd do the research and interview the coders if they can't figure something out. There are plenty of threads with explanations on how to implement features, but they're scattered all over the forum and most coders don't have time to look for them.
bottomfan, if you wanted to get a documentation team together, we'd back you up on that... give you avatars and everything. ;)
-
Hell, if all it is is searching the forum, that's easy... even I[/i] could probably do that... :rolleyes:
-
Searching the forum and rewriting the information in an organized, concise, and easy-to-follow style. Which it won't be in. Oh, and including code samples, examples and/or screenshots.
-
Basically, a user manual. You'd be amazed at how much we all know as a group, that we never bother to write down, because it seems so obvious. What I think Kalfireth is looking for is an easy to read document that anyone can pick up, and be able to turn to a particular page and look up an index of, for example, sexp's and read a detailed description of it, it's format and what each variable for the sexp describes, so it will be quite an endeavour! :)
Flipside :D
-
A wiki would be easy to modify by anyone (and I mean anyone) noticing room for improvement... Even if it's just a small point, all that would eventually add up - and when it's more or less up to date, keeping it that way won't be taxing at all. If a coder doesn't have time to write there about a new feature himself, there will be hordes of fans that'll race to do it for him as soon as it's introduced... that's the usual effect in these things. :nod:
-
bottomfan, I will take up a section on getting started and using CVS
-
People do realise this will probably become ending up a complete Freespace 2 modding manual? ;)
Ah well.... I'll take on the new graphical effects and the relevant command line instructions for activation/control if you want?
Flipside :D
-
yes exactly, what i was thinking. i mean people will need instructions on how to make glow points for example.
Now is a modding manual really all the wrong? If you are concerned about that we could write 2 different ones. But a modding mannual for the SCP is a project in an of its self. We could through together the resources we have already. I mean we have a tutorial on modeling over at Volition Watch, a PCS tutorial also somewhere, a totorial on nameplates for the orion. We could just collect all these resources and bring them all together.
-
More or less, yes, but what it would really need to make it accessible would be for one person to read it all through and get text re-written when neccesary to make sure everything makes sense. For example, some people call them points, some call them vertices, a lot of people get these confused with paths etc etc... So language throughout would have to be consistent. Theres going to be terminology clashes between glowmaps and over-exposure etc as well.
So it would probably mean grabbing these tutorials, reading them and then re-writing them in your own words, crediting the original author for reference work.
Well, that's my opinion of what you would need anyway :)
Flipside :D
-
well yes. but the beneft is that we would already have the graphics. But then this would be a good new project for HLP. This would be alot of work. we would have to have to cater to people using different programs. Such as adobe photoshop and PSP.
-
the PCS thing is in my sig
-
well its a start.
-
:yes: Good on ya redmenace, keep me posted on how much progress you make, this'll make the news once it gets a certain distance. :)
-
REAL progress won't happen till Christmas break. But I will start writing the getting started section of the readme. But i need to research the Visual C++ project properties as well as build a new system.
-
I'm hopeing we get 3.6 done by christmas, we've come a long way, but there is still a lot of work to be done
-
What new is going to be in 3.6? I will be like a XMAS gift!!!
-
turrets postions other than straight up. Ok there will be alot of info we will need to write for the multi player code.oh ya to get ahold of my email my [email protected]
-
Setekh, what would you think of giving us another sub-forum dedicated specifically toward developing the readme? If bottomfan, Flipside, redmenace, and whoever else wanted to work on something, that might be a good base of operations.
-
Now that is a good idea. That way HLPers can poke at it and ask questions about the read me before it is done. Kinda like a Beta readme.
-
Sounds like a good idea! I'll have to get a look at this Wiki thing and try to get my head around it though ;)
Flipside :D
-
Now 4 comments:
We should concentrate on the SCP readme. This readme should contain, info on using new table entries, obviously new features, such as glowpoints, explain the new SEXPs, and so on. Also I think we should handle a subject at a time. Such as the Multiplayer stuff kazan added, then say a section on glowmaps, then a section for the new sexps, then a section for how to create shine maps and so on. Each section should include all information such as, warnings, trouble shooting common problems with that feature, sample of a the feature and so on.
2. We need to as well update the FRED2 Help html.
3. Is there some software that we could use to keep track of changes. or maybe we could just submit sections of the readme in sections. People could download the section they want.
4. I think this should be done in full disclosure. I think out forum needs differ greatly than that of the SCP.
-
redmenace, check your PM.
-
ok for a start we need to nominate a project head. I think bottom fan for one. Second we need an email list. Third we need to start listing all the current list of topics we need to include.
-
I think the best bet would be to subdivide into :-
Graphics additions
Sound additions (Nothing yet, but I remain ever hopeful)
Fred 2 Open (Sexp's, Background updates etc)
New Weapons Tags
New Ships Tags
Other stuff (HTL, No poly limits etc etc)
This way we can at least have a reference guide with listings of all the correct Sexp's, tags etc and their various uses.
Each one would have to come with instructions and an example or two, for example, Lens Reflections would require an example of the correct entries in the .tbl files etc.
Flipside :D
-
How detailed should this be? I mean should be also include tutorials on how to use say photoshop with say lense flare(I think you need external artwork). Or like the Fred_open section on name plates. Should we include a tutorial for photoshop of how to create name plates for the hectate and the orion. Maybe stuff like this should go into an long over due modding manual for FS OPEN. But before we start breaking up the manual into sections like that we need to first list all the of the subtopics.
-
I think the first step will be to create a reference manual for Modders, assume at first that people reading this document are familiar with 'Basic' Freespace Modding. I.e. How to extract files etc, and things like UV Mapping and creating Textures can wait, we will assume people know how to create the material, we just show them how to apply it for now :)
It would be nice to do a full comprehensive Freespace 2 Modding Encyclopedia, but I think we would be biting off more than we could chew at first.
Edit : As for the new features like nameplates, a more detailed description would be required to a degree, but only where it is relevant to the SCP, not standard Fredding, so, for example, Sexp's will have a name and a Description and a short example, that's all, I don't think we should go into how to use Sexp's in mission etc, at least not yet ;)
Flipside :D
-
Originally posted by Flipside
As for the new features like nameplates, a more detailed description would be required to a degree, but only where it is relevant to the SCP, not standard Fredding, so, for example, Sexp's will have a name and a Description and a short example, that's all, I don't think we should go into how to use Sexp's in mission etc, at least not yet ;)
Goober has already made a tutorial on how to make Orion Nameplates in Photoshop (I even linked to it in my FAQ). I doubt he'd mind contributing it to this project. All you would need to add is telling the user how to find the texture replacement button in FRED2_open :D
As for the FAQ itself I don't have much time to write much but I'm happy to help in any other way I can. Feel free to cut and paste anything you want from any part of my FAQ if it will help.
-
Exactly, we start with just providing info, not tutorials, but we can link to other peoples tutorials, with their permission for more detailed info. Personally I'd like to see that change later, so we have a full 'Modding bible', but that would be a project for the future :D
Flipside :D
-
Number one priority is to get a readme written. basically a referenece manual like Flipside said. What I am saying is immediatly we need a list of topic that need to be written about. Immediatly I think they should be written in word and then transferred to HTML later on.
-
Great guys! Thanks for going with me on this one - it'll be incredibly helpful in the long run :nod:
-
Whoops, missed this thread. :) Sounds quite reasonable (and in line with our goals) to me - I'll put it to the rest of the staff before making a final decision. :nod:
-
Thanks Setekh, we don't want to tread on peoples toes :D
I suppose the logical start point is doing a small user manual for RT's Launcher, explaining selecting your graphics settings, the '-' extensions etc and what they do. This is the first part of the SCP anyone encounters, so it makes sense to me :)
Flipside :D
-
erm well that is one thing that should be done immediatly but we still need some structure to this little subproject. But we need to start a running list of subjects I will start this list tonite in this thread.
-
here is the link to the current Readme file
http://fs2source.warpcore.org/readme/readme_3.6.txt
first we need to update this for H T&L
Part One
1. System Requirements
The original Freespace 2 required DirectX® 5. FS2: SCP requires Directx® 8.
It will probably work with later DirectX® versions (such as DirectX® 9) but its highly
recommended to use DirectX® 8. DirectX® is avalible at .
Minimum Configuration for Freespace 2: Source Code Project
• Windows® XP, Windows Me®, Windows 2000®, or Windows 98 SE®
Windows® 95 is reported not to work with this version of FS2:SCP.
• 300 – 400MHZ CPU (Depending on additional preformance factors).
• 128 MB RAM, at least, 256 MB RAM is highly recommended.
• 4x CD-ROM/DVD-ROM drive (CD-Rom drive only need for cutscenes).
• 1.3 GB free HD space for the original install and a minimum of 3 MB for the FS2:SCP files.
• 16 MB video card with DirectX 5 compatible driver. Recommend atleast 32 MB TNT2.
• DirectX 5 compatible sound card.
• Keyboard and Mouse.
Safe Configuration for Freespace 2: Source Code Project
• 700 Mhz Pentium 3 or faster processor.
• 256 MB SDRAM.
• 8x or faster CD-ROM/DVD-ROM drive.
• 64 MB GeForce 2 or greater video card with DirectX 8 compatible driver.
Recommended for Serving Multiplayer Games
• A Broadband Type Internet Connection or LAN Network: DSL, Cable, T1, T3, etc.
secondly this mess needs to be updated with the H T&L command line options in addition to such other command lines as -cell and I think there are some others involving multi player.
-standalone Starts FS2:SCP as a Standalone server. Not acctualy starting the game, a server
for multiplayer games.
-nosound All sound effects will be turned off.
-nomusic Music will be turned off.
-startgame
-gamename # Name of multiplayer game.
-password # Password requierd to join the game.
-closed
-restricted
-port # Forces FreeSpace 2 yo use a specific port on local games. # can be anything between
1 - 65556 as long as its not used by something else.
-connect # Connect to a host, # being the host IP number.
-multilog
-oldfire
-clientdamage
-pofspew
-32bit Run in 32-bit mode.
-coords
-timeout # How many seconds before network timeout. Default if 30.
-window Run in Window Mode.
-almission # Auto loads multiplayer mission #, where # is the mission file name without the extension.
-GF4FIX Enables the Geforce 4 fix for ani files.
-ALLSLEV Gives access to all singleplayer missions.
-phreak Gives access to Phreaks targeting-code and options
-mod # Switches on the mod system, where # is a subdirectory found in ../freespace2/
in case # = mymod, then the game will look in these directories for extra/replacement files:
freespace2/mymod/
freespace2/mymod/data/
freespace2/mymod/missions/
freespace2/mymod/tables/
and so on, all valid subdirectories in the mod directory will be read from.
In case of the mod flag, you must manually in some way create the mod directories player
sub-directories, you must do this before you run the game with the mod flag.
these are in case # = mymod
freespace2/mymod/players/
freespace2/mymod/players/single
freespace2/mymod/players/multi
freespace2/mymod/players/squad (This shouldend be needed, but be safe and create it anyway)
freespace2/mymod/players/images (Same as above)
So the mod directory if # = mymod would be freespace2/mymod
all valid subdirectories like data/missions found in the mod directory will be used
to be looked for files. If a file is found, and if a matching file exists in the normal
locations then the file found in the mod directory will be used.
VP files should be fully supported.
If a .VP file is found in the Mod directory then files found in that .VP file will be used
instead of the files found in VP files in other locations than the mod directory.
Should there be more than 1 .VP file in the mod directory containing matching files, then the file
found in the VP file that lexicographically comes first be used.
Plain files not packed(in both the mod directroy and the default directories) will be used instead of
matching files found in any .Vp file
Player directories in the Mod directory must at the present time, be created, manually
Those directories must exist or the game cannot write the pilot info when the player is being forced
To create a new pilot when running the game for the first time.
The game will ask for CD # 2 when you run the game with the mod-flag for a mod
if there is not any pilot (.plr) files present.
Do not use invalid signs such as "#¤%&/()=? `@£$€{[]}~|'*¨^ in your mod directory name
# must match the directory name to the point. Dont worry about directory seperators, the game adds them if needed.
-
Wait until i have to unleash the documentation dogs on FS Dev Studio .. right now some of the **** is bloody ugly until i get a lot more implementation done then I'll go about making it more friendly and pretty :D
-
Originally posted by Flipside
Thanks Setekh, we don't want to tread on peoples toes :D
I suppose the logical start point is doing a small user manual for RT's Launcher, explaining selecting your graphics settings, the '-' extensions etc and what they do. This is the first part of the SCP anyone encounters, so it makes sense to me :)
Flipside :D
That sounds pretty good to me - then build upwards and onwards. Right now the staff are chewing over a few options. :)
-
[B]
// here are the command line parameters that we will be using for FreeSpace
cmdline_parm standalone_arg("-standalone", NULL);
cmdline_parm nosound_arg("-nosound", NULL);
cmdline_parm nomusic_arg("-nomusic", NULL);
cmdline_parm startgame_arg("-startgame", NULL);
cmdline_parm gamename_arg("-gamename", NULL);
cmdline_parm gamepassword_arg("-password", NULL);
cmdline_parm gameclosed_arg("-closed", NULL);
cmdline_parm gamerestricted_arg("-restricted", NULL);
cmdline_parm allowabove_arg("-allowabove", NULL);
cmdline_parm allowbelow_arg("-allowbelow", NULL);
cmdline_parm port_arg("-port", NULL);
cmdline_parm connect_arg("-connect", NULL);
cmdline_parm multilog_arg("-multilog", NULL);
cmdline_parm server_firing_arg("-oldfire", NULL);
cmdline_parm client_dodamage("-clientdamage", NULL);
cmdline_parm pof_spew("-pofspew", NULL);
cmdline_parm mouse_coords("-coords", NULL);
cmdline_parm timeout("-timeout", NULL);
cmdline_parm d3d_window("-window", NULL);
cmdline_parm almission_arg("-almission", NULL); //DTP for autoload Multi mission
cmdline_parm gf4fix_arg("-gf4fix", NULL); //DTP for random tigers GF4fix
cmdline_parm allslev_arg("-allslev", NULL); //Give access to all single player missions
cmdline_parm phreak_arg("-phreak", NULL); // Change to phreaks options including new targetting code
cmdline_parm dnoshowvid_arg("-dnoshowvid", NULL); // Allows video streaming
cmdline_parm mod_arg("-mod", NULL); //DTP modsupport
cmdline_parm fps_arg("-fps", NULL);
cmdline_parm d3dlowmem_arg("-d3dlowmem", NULL); //DTP for random tigers GF4fix
cmdline_parm d3dmipmap_arg("-d3dmipmap", NULL);
cmdline_parm beams_no_pierce_shields_arg("-nobeampierce", NULL); // beams do not pierce shields - Goober5000
cmdline_parm fov_arg("-fov", NULL); // comand line FOV -Bobboau
cmdline_parm spec_exp_arg("-spec_exp", NULL); // comand line FOV -Bobboau
cmdline_parm spec_point_arg("-spec_point", NULL); // comand line FOV -Bobboau
cmdline_parm spec_static_arg("-spec_static", NULL); // comand line FOV -Bobboau
cmdline_parm spec_tube_arg("-spec_tube", NULL); // comand line FOV -Bobboau
cmdline_parm safeloading_arg("-safeloading", NULL); //Uses old loading method -C
cmdline_parm nospec_arg("-nospec", NULL); // skip specular highlighting -Sticks
cmdline_parm MissionCRCs("-missioncrcs", NULL);
cmdline_parm TableCRCs("-tablecrcs", NULL);
cmdline_parm nohtl_arg("-htl", NULL); //Use software HT&L
cmdline_parm cell_arg("-cell", NULL);
cmdline_parm textures_32bit("-t32",NULL);
cmdline_parm no_set_gamma("-no_set_gamma",NULL);
cmdline_parm d3d_no_vsync("-d3d_no_vsync", NULL);
[/B]
here is the most recent list of parameters pulled right from cmdline.cpp. If you don't want people to see this list of parameters then just pull this thread into the internal forum and give the few that are working of this access. Setekh, what did you mean by "Right now the staff are chewing over a few options."
-
Excellent list RM! I'm assuming that the non-commented ones are the default [v] ones?
Flipside :D
-
I've writen some instructions on how to configure the game in HTML. Its very image friendly and got a simple clean-cut design(there's enough eyecandy in-game :D )...
-
Flipside, you want to help out?
-
Originally posted by redmenace
Setekh, what did you mean by "Right now the staff are chewing over a few options."
He meant that we're pondering which method would be best to support the on-going documentation of the SCP. Basically it's a toss-up between forum-based and Wiki.
-
I'd be happy to help if I can BF, I suppose my 'speciality' would be the texture stuff if anything, but I can use the Search facility etc as well as anyone else :)
Flipside :D