Svn arrangement: Documentation and graphics

Luke-Jr · Post by **Luke-Jr** » Mon Jun 05, 2006 9:05 am

/me thinks we should move docs and graphics out of the current modules and into their own.

Website · Post by **Z-Man** » Mon Jun 05, 2006 9:20 am

Umm, why? You mean armagetronad/sounds, armagetronad/textures and armagetronad/src/doc, right? I think everything that goes into the tarball should be part of the armagetronad module, and if possible, arranged exactly the way it is in the unpacked tarball. Which reminds me, sortresources.py could now use "svn mv" to actually move the resources to their right place in the repository.

If you just don't want the daily, expensive updates of our multi-GB graphics, svn switch them to a tag.

Luke-Jr · Post by **Luke-Jr** » Mon Jun 05, 2006 10:39 am

Mostly, I was referring to armagetronad/doc and icons/banners/etc-- not so much textures and such.
eg, anything not important to building the game itself.

Website · Post by **Z-Man** » Mon Jun 05, 2006 11:44 am

There is no armagetronad/doc, and the banners are only in the windows build modules (where they're required), so I don't know what you're taling about there

armagetronad/tron.ico and and armagetronad/textures/kgn-logo.png are unused now. They can go, but not into a separate module. They can be deleted.

Luke-Jr · Post by **Luke-Jr** » Mon Jun 05, 2006 11:58 am

z-man wrote:There is no armagetronad/doc,

src/doc, whatever...

z-man wrote:and the banners are only in the windows build modules (where they're required), so I don't know what you're taling about there

They can be copied there, unless they're specific to the build...

z-man wrote:armagetronad/tron.ico and and armagetronad/textures/kgn-logo.png are unused now. They can go, but not into a separate module. They can be deleted.

I was specifically thinking of build/codeblocks/icons, but there's no reason eg tron.ico should be deleted instead of going to a module specifically for non-game images. Along with other general art we use on webpages and such.

Website · Post by **Z-Man** » Mon Jun 05, 2006 12:56 pm

I would say src/doc is an essential part of the distribution. Granted, the way it's compiled is not optimal, but nevertheless, it's essential.

And tron.ico isn't used any more at all (I think). Joda made new icons for Windows in build_codeblocks. Therefore, delete.

Images for the websites are a totally different topic

I don't care much where they're stored, but a SCM not optimized for binaries seems the wrong place.

Luke-Jr · Post by **Luke-Jr** » Mon Jun 05, 2006 4:09 pm

z-man wrote:I would say src/doc is an essential part of the distribution. Granted, the way it's compiled is not optimal, but nevertheless, it's essential.

Part of the distribution, sure-- but not part of the game itself.

z-man wrote:And tron.ico isn't used any more at all (I think). Joda made new icons for Windows in build_codeblocks. Therefore, delete.

Not used by the game installers, you mean. Who knows if some Joe Player likes to use that classic icon?

I'm thinking of just a graphics place to throw anything that might be useful in general purpose areas, even if it isn't currently. Probably outside the game release hiearchy.

z-man wrote:Images for the websites are a totally different topic I don't care much where they're stored, but a SCM not optimized for binaries seems the wrong place.

Makes it simple to have everything in one place, and allows someone to keep a checkout of all graphics.

joda.bot · Post by **joda.bot** » Mon Jun 05, 2006 6:13 pm

I'm going to collect all loose windows resources that might be used in winlibs...

joda's plan:
winlibs/common/res/icons/*.ico
winlibs/common/res/banner.svg
winlibs/common/res/banner.bmp
winlibs/common/armagetronad.nsi
winlibs/common/armagetronad_dedicated.nsi
winlibs/common/makedist.bat
winlibs/common/python.bat
winlibs/common/status.bat

The module "winlibs" might be renamed to "winbase" to reflect that it does not only contain libraries IMHO.

But I'll help to add or write a tutorial on basic hud elemets and rules for netplay, also documentation and wiki should really be synchronized.
How about translating the help to all languages, at least the non development related help (if we have any). Perhaps some players can help out in adding some content. a general FAQ of the most common problems should be included (e.g. how can I restore 0.2.7.1 camera glancing?).

I'll talk to wrtl about that later, he had some idea about using the wiki to generate documentation.

Post by **Lucifer** » Mon Jun 05, 2006 6:29 pm

Anyone object to thinking about putting all this stuff in the armagetronad module? I have a strong preference for putting everything needed to build a distribution into the core module, which would be most of armagetronad_build. And then the source distribution gets built from that and includes pretty much everything so that someone who gets a source distribution can build any of the packages we support, if they have the tools installed to do so.

Website · Post by **Z-Man** » Mon Jun 05, 2006 8:07 pm

Luke and Lucifer: my position is quite well defined. Exactly that which goes into the tarball belongs into the main armagetron module.

So, tron.ico is out, the docs are in.

The Windows build files are a corner case. They go into the zip source distribution right now, so it can be argued they also belong into the tarball. I don't mind, as long as they don't pollute the main directory there with tons of files. If they go into the VisualC subfolder where they once were (or rather, a codeblocks subfolder), it's fine by me, because by any argument that says they should stay outside, we'd also have to ban the Makefiles and the OSX project stuff.

But not everything belongs there. I hold that the "build" module needs to be separate. If you remember the discussion back then, that module contains spec files for debian, redhat and autopacke. It is common procedure to not include them into the tarball, because the real debian folks, making a real debian package with a different specfile, would get into trouble. Likewise for autopackage and redhat and of course, the aabeta upload script and the freshmeat announcement make target.

build_eclipse is actually a meta-build tool. It clearly belongs out of the main module.

Joda: I think the logical thing to do, then, would be to move the code blocks build files all neatly into a subfolder in the armagetronad module and leave winlibs as winlibs. But that's another point I don't really mind, as long as you don't make winlibs part of the main AA module

Do what's easiest to work with for you and K later.

Luke-Jr · Post by **Luke-Jr** » Mon Jun 05, 2006 10:54 pm

Lucifer wrote:Anyone object to thinking about putting all this stuff in the armagetronad module? I have a strong preference for putting everything needed to build a distribution into the core module, which would be most of armagetronad_build. And then the source distribution gets built from that and includes pretty much everything so that someone who gets a source distribution can build any of the packages we support, if they have the tools installed to do so.

So in other words, you'd like the source releases to be the entire <branch> directory, not just <branch>/armagetronad ?

Releasing winlibs with all source releases would get annoying, though...

Luke-Jr · Post by **Luke-Jr** » Mon Jun 05, 2006 11:02 pm

z-man wrote:Luke and Lucifer: my position is quite well defined. Exactly that which goes into the tarball belongs into the main armagetron module.

Why not have a separate src tarball for docs?

z-man wrote:If you remember the discussion back then, that module contains spec files for debian, redhat and autopacke. It is common procedure to not include them into the tarball, because the real debian folks, making a real debian package with a different specfile, would get into trouble.

I would argue that some random Debian person shouldn't be doing a separate package and should just include one we build...

Website · Post by **Z-Man** » Tue Jun 06, 2006 12:05 am

Would your argument with the random Debian guy go as well as that with the Gentoo guy? BTW, how is it going?

Debian has every right to make a .deb package that fully fits their needs. Ours will, for example, install into /usr/local (well, our RPM does). No, package specs don't belong into the tarball. Another reason: if one package spec is buggy, you don't want to make a new tarball. You just fix the spec and build the buggy package again with a bumpled build count.

About the docs: because it's silly. You separate your docs and your main program if the docs are an unbearable download burden. That's not the case here.