help

[frankey]

I cant se the map folder I cant se the screenshot folder and i cant se the config in baseoa folder. WHY?? =)
I have tryed to create the folders by myself but it didnt work. Please someone help me:S...

[Blaenk]

It's because the developers thought they'd be convenient by making multi-user support. Some like Redshirt have contributed 'fixes' which allow you to choose whether or not you want this behavior, but people don't seem to care until they meet with the problem themselves.

Check your applications data folder.

[dmn_clown]

I cant se the map folder I cant se the screenshot folder and i cant se the config in baseoa folder. WHY?? =)
I have tryed to create the folders by myself but it didnt work. Please someone help me:S...

Because ioq3 is coded correctly for a multi-user system, now if Redmond had bothered to remove root privileges from the user by default and code their POS product with multiple users in mind you would be used to this behavior in all of your programs. 

Ioq3 by default has the correct and more secure behavior.  It is not about convenience as security is often inconvenient.  Blanky of course knows all about this, he knows everything he just didn't want to share that information.

[sago007]

As described in http://msdn2.microsoft.com/en-us/library/aa480150.aspx, should not write anything to its own directory anymore.

%APPDATA% is the recommended location. However, since the Application Data folder is hidden by default, this is a bad location for storing files that the user wants direct access to (such as screenshots and saved games). The Application Data folder is hidden by default. Therefore most games save there settings to My Documents\My Games\GAMENAME or just My Documents\GAMENAME. (The 'My Games' folder is not an official MS folder and therefore is not translated, but I prefer it as it makes less mess in the Documents folder)

The mentioned article says that the applications data should be saved to %APPDATA% and files the user saves should be in My Documents. Since screenshots are saved by the user, storing them in the APPDATA folder is actually a doubtful decision. But so would saving in different locations be.

I once programmed a game myself and the last time I updated it I moved the saved games from APPDATA to MyDocuments\My Games. There is a strong tendency and I'm not fighting it.

EDIT: In fairness to ioq3: Mods downloaded would quickly make the My Documents folder to big to allow regular backups. Users should just get used to start looking in Applications Data on regular intervals.

[Ylle]

Gee I dunno, I like keeping my C: drive small and my D:, E:, F:, G:, etc drives bigger.

[Blaenk]

There's nothing wrong with all this, but possibly a cl_multiuser command like Redshirt posted a patch for, but I guess it's not in dmn_clown's interest. Just create a shortcut to the folder within your baseoa folder.

[dmn_clown]

So, Blanky, when are you going to stop violating the terms of the GPL and distribute source and diffs of everything in "your" game?

[Blaenk]

What do you mean by everything? My sources are on the svn and there's information on how to get everything on my wiki.

[dmn_clown]

Everything that you've changed from it's original needs a notification of what has been changed and the time it was changed, this is usually done by providing patches in the form of .diff files with an attached time stamp. 

You are patching the ioq3 engine, but where are the patches that you are using?  What about your other code?  Where is _your_ changelog?   Those need to be included in your svn.

[Blaenk]

Well, then sorry, I didn't know I needed to do that. At least I acknowledge my faults, I have no major ego problem. I was never aware about having to have patches available, I always thought the source would suffice.

[dmn_clown]

I was never aware about having to have patches available, I always thought the source would suffice.

If your game was entirely written by you it would be, but when you re-use other's code you have to document it and the changes made to it.  Hence the patches. 

It's cool, just fix it

[Blaenk]

No problem, will do. I'll just run diff on the whole thing and the version of the engine I got and then save it as a patch. As for the changelog, is that necessary as well? I honestly don't really remember everything I've done specifically but I do know most of everything and probably the diff will help with that, though it also won't be as specific as I think it needs to be. You have an example of what you mean by this? I don't think it's anything too complicated though, so it shouldn't be too hard to fix or do. Thanks again for letting me know.

[dmn_clown]

Making a huge patch like that may make it difficult to work with.  Patches should be kept as small as possible to make your code easier to work with.

A good example of a changelog can be found in ioq3 itself, the changelog goes all of the way back to when loki software was porting quake3 to Linux.  Though usually it's just something like this:

Code:

2.5.16 (2004-10-18)

- New: -fixaas mode to reassociate an AAS file with a changed BSP
- New: -nostyles switch on light phase disabling lightstyles
- Using libmhash cryptographic hashing library instead of md5lib


2.5.15 (2004-07-08)

- New: q3map_rgbGen, q3map_rgbMod or q3map_colorGen, q3map_colorMod
- New: q3map_alphaGen const (like q3map_alphaMod set)
- New: q3map_noVertexLight to suppress overwriting of vertex rgb
- q3map_backShader now works again, can be used instead of
  q3map_cloneShader + q3map_invert on the target shader
- q3map_alphaMod volume brushes in func_group entities will now only
  affect that entity's surfaces
- q3map_clipModel now works on trans/nonsolid shaders, allowing
  simplified clipping surfaces in models
- Fixed bug in alphaMod code where only the first vertex was being
  modded (thanks Ratty)
- Vis exits instead of crashing with divide-by-zero when there are
  no portals on simple box maps
- All of a surface's lightmaps must be solid or not solid, fixing
  ST coord problem with non-Raven games using lightstyles
- Reverted a change in the meta code which was causing lightmap coord
  overflows and ugly self-shadowing errors on surface boundaries
- Any use of lightstyles automatically sets -nocollapse to reduce
  total shader counts
- Tenebrae lightmap size changed to 512x512

[Blaenk]

Oh okay, should be easy then.

I don't really know what you mean about the patches. How can I keep them small? Or do you mean each change I make should be a patch, wouldn't that mean tons of patch files? Isn't that what we have SVN for? Just kinda confused.

[dmn_clown]

hmm...  the problem with large patches is that certain patch utilities don't work well with them.  The best example that I can think of is Debian's xorg 6.9 patch which can be viewed here http://backports.org/debian/pool/main/x/xorg-x11/xorg-x11_6.9.0.dfsg.1-6~bpo.4.diff.gz it won't apply with the normal patch utility, you need to install a separate utility to apply the patch.

Basically the goal of it is that someone can download the original source, apply your patch, and then have your binary.  If you can make a large patch and still get it to work with the normal patch utilities then it should be alright.

[Blaenk]

Oh okay I get it now thanks.

[meshomorph]

hello dmn_clown,

i'm learning to code in c and i want to tinker with the ioquake3 engine. it'll probably just be something i do as a hobby, but just in case i come up with anything useful what do i need to do to comply with gpl?

from your posts it looks like i need to
1. make a time stamped diff file every time i changed something and
2. write down what i've done in a changelog

is there anything else i need to do or is that it?

also, how often would you reccomend making a diff file? say if i was trying to add a new feature, would i wait until i had the feature complete and working before making a diff file? or is it worth making regular diff files as i went along as a kind of backup in case i break anything?

if, as i work on my project, the ioquake3 team make some improvements, do i
a. apply the diff file of the latest change to my project and make a note of it in the changelog or
b. get a fresh subversion update of the ioquake3 engine and apply all my diffs to that to ensure they work on the latest code?

sorry about all the questions, but i'd like to do this right.
thanks.

[dmn_clown]

i'm learning to code in c and i want to tinker with the ioquake3 engine. it'll probably just be something i do as a hobby, but just in case i come up with anything useful what do i need to do to comply with gpl?

from your posts it looks like i need to
1. make a time stamped diff file every time i changed something and
2. write down what i've done in a changelog

I would suggest that as you make changes to the code, you keep track of them in a changelog.  Don't worry about creating a diff until after you compile and see that everything works.  If it works and is useful and you wish other's to use your code, then make a diff.

also, how often would you reccomend making a diff file? say if i was trying to add a new feature, would i wait until i had the feature complete and working before making a diff file? or is it worth making regular diff files as i went along as a kind of backup in case i break anything?

if, as i work on my project, the ioquake3 team make some improvements, do i
a. apply the diff file of the latest change to my project and make a note of it in the changelog or
b. get a fresh subversion update of the ioquake3 engine and apply all my diffs to that to ensure they work on the latest code?

sorry about all the questions, but i'd like to do this right.
thanks.

Like I said above you should only make a diff file when your code compiles and runs the way you expect it to and you want others to see what you've done.  As to a. and b. that would really depend on what is easiest for your project.  If you've made heavy changes to the code it might be easier to just apply any upstream changes to your project.  If you've made minor changes it is probably easier to apply your changes to the upstream code.

[meshomorph]

thanks for the advice dmn_clown.