Cold War Rearmed – Talk

Management Software

I would assume BIS already has all the appropriate software, and would prefer to use it for this project as well?

If not, here are the discussions regarding possible solutions:--Kronzky 21:44, 6 December 2006 (CET)

The software we have requires per-user licensing, and therefore is not suitable for an open project like this. --Suma 12:36, 7 December 2006 (CET)

Project Repository

The project repository will be on a central server e.g.CVS.

I strongly suggest to use subversion instead. TortoiseSVN is a great windows based GUI client. --WGL.Q 18:44, 1 December 2006 (CET)

I agree on Subversion. It would also allow for easy MS reporting services implementation to keep track of stats and work for the project managers --SniperAndy

Subversion handles binary files without any special work, while same cannot always be said about CVS. Also having changesets instead of CVS way of individual file revisions and tagged builds is more suitable for project like this. Feersum 13:51, 7 December 2006 (CET)

I just wanted to add another good SVN client is RapidSVN. It's not as robust as Tortoise, but still is highly configurable and works on Linux and Windows. Pennywise 21:21, 7 December 2006 (CET)

Subversion usage requires very strict and disciplined usage, otherwise it spirals out of control when you're working with a project such as this with primarily binary data. Additionally, as both working copy and base repositories are stored locally, your client-side storage requirements will be approximately double that of the actual unpacked content. If you use the BIS tools as presently constituted, plan on a total client-side minimum storage requirement of approximately five times the raw data size.

If you use SSH tunneling, the authorization controls are fundamentally different, and care should be particularly taken to ensure proper access controls and hook script functionality. Regardless of the access method implemented, upload bandwidth requirements are significant, especially with multiple concurrent users. It's strongly recommended that you provide weekly diff'ed snapshot extracts on a high-capacity FTP server for users not requiring constant updates of all content. You can also build a daily-synced read-only mirror to handle alternate content (such as maps data for users focusing on vehicles.)

Processed data should not be commited to subversion, only the raw source data (ie tga masters, not paa's). There's an arguement for commiting the true master psd's, however for all practical purposes those should be seperately managed, and only the functional masters commited. The processed data can then be generated dynamicly by the individual developers, and also by the designated distribution packers. Shinraiden 13:10, 8 December 2006 (CET)

Bug Tracking

Despite the Wiki being used (abused?) for bug reporting right now, it would probably be preferable to use some dedicated bug-tracking software. I've had some pretty good experiences with the open-source Mantis. It's powerful enough to handle most tasks, but not so complex as to scare off non-programmers. --Kronzky 21:44, 6 December 2006 (CET)

Bugzilla might be suitable as well. --Kamran 19:38, 7 December 2006 (CET)

Have you ever seen a "normal" user (untrained, non-computer expert) use Bugzilla? Not a pretty sight... They're just TOTALLY overwhelmed, and will more likely than not just not bother report a bug. Good idea though if you want to keep the bug reports down... ;) --Kronzky 21:00, 7 December 2006 (CET)

Trac is the new king. Live Demo here. --WGL.Q 20:05, 7 December 2006 (CET)

Looks interesting! Any experience with it yet (installation, reliability, etc.)? (This is probably a better link for the demo. When I first went to the demo I thought the whole thing was just another Wiki-abuse, without any structuring whatsoever, until I finally found the actual tickets...) --Kronzky 21:00, 7 December 2006 (CET)

Don't bother with bugzilla for this project, it's a 900lb gorilla that requires a significant amount of management to be functional. Trac and Mantis offer varying degrees of subversion integration, however the functionality I think for that is somewhat limited given the primarily binary content nature of this project. Shinraiden 13:10, 8 December 2006 (CET)

From what I see this is some sort of project management cms systems. Never really worked with them for a project. To manage timelines, tasks, stats, reports etc. and have a independend and smal discussion board I would recommend something like dotProject for example. But I'm not sure if it would work with Subversion. PHPproject is quite good as well. But all a matter of what is needed and how it is run by the project managers. --SniperAndy

Call To Arms

I guess this discussion page might serve to gather the people who would like to be involved and how. If anyone feels like participating, write your area of interest/expertise here. Currently most needed are people for the Preparation phase (some experience with CVS or Subversion needed to start the repository).--Suma 11:26, 6 December 2006 (CET)

-I could assist in doing the CVS, Subversion. Would have to read up on it again but shouldn't take up to much time. --SniperAndy

-I've setup several SVN repositories. It's really quite simple. You can install it via cygwin, which is what I usually do. Otherwise, CollabNet offers a windows install. You can also install from tigris manually, but I recommend the Cygwin or Collabnet versions. Pennywise 22:43, 7 December 2006 (CET)

-I am pretty experienced in modelling , unwrap ,normal(bump)maps and specularmaps. If you need a hand , let me know. Metalchris

Add yourself to the Coalition of the willing below. ;) --Sniperwolf572 15:38, 7 December 2006 (CET)

Coalition of the willing

All people who sign up here show that they are willing to contribute work. The CWR team will sooner or later contact them to get more detailed information about their capabilities and on that basis CWR will decide if he/she(/it) can join the team. If your Wiki name is different then your forum name then please specify this in your user page so that you can be contacted.

A LEGITIMATE COPY OF ARMED ASSAULT IS REQUIRED

Intially we'll only need a handfull of people, so if your not contacted right away then don't give up hope. We may not yet be at the stage requiring your respective skillsets.

The project does not accept additional signups at this time If you have signed up, and not yet been contacted, you will be if/when your skillset is required.

Communicaton Channel

Following communication channels which I think could serve well:

1. dedicated private forum on the BI forums - Created.
2. wiki talk pages (I guess a separate wiki would be needed for this, perhaps with access restricted to people accepted as participants of the project)
3. any combination of above --Suma 11:37, 6 December 2006 (CET)

Would it be possible if private forum or something could be made read only to non CWR team or the ones waiting to be called up? Point of this being able to observe progress of the project, and maybe learn something about ArmA modding while observing. This would be also useful to anyone who joins the project later on, as one wouldn't need to catch-up with the rest of the team. --Sniperwolf572 22:26, 7 December 2006 (CET)

I agree completely. Rather than hide, share the knowledge --WGL.Q 07:54, 8 December 2006 (CET)

There should be some form of hidden decision board though, in order to effectively make the decisions required to make this project a success, without the nonsense meddling and uninformed and juvenile harassment that would inevitablely ensue. Shinraiden 13:10, 8 December 2006 (CET)

That's why I stated that board should be read-only to everyone except CWR members, everybody is able to view, only team members are allowed to post. With all the elitism and fright of stealing in the community at present times, everyone is encrypting everything in attempts to stop it, and no-one cares about the ones that actually try to study someones work in order to learn. --Sniperwolf572 14:04, 8 December 2006 (CET)

I'm sorry to say that, but the forums will be only available for members. The addons won't be encrypted (beside you call binarizing encryption). This biki is still the best place to share knowledge ;) --raedor 16:19, 8 December 2006 (CET)

Thanks for the reply, and, no, I'm not a novice at addon making, I'm OK with binarizing and understand what it does, I was talking about .pbo encryption that was recently introduced. --Sniperwolf572 18:42, 8 December 2006 (CET)

There is no encryption introduced to PBOs, new cryptographic signing of addons is used to check and authenticate that PBOs have not modified after being signed and released by author. --Feersum 11:48, 9 December 2006 (CET)

*Sigh* I wasn't talking about ArmA, I know about keys. I was talking about current OFP addons, I didn't want to point the finger at anyone, but for better understanding, I'm talking about the kind of encryption (or whatever you call it) that OWP used on some of their addons, and then some of the other addon makers followed after them. --Sniperwolf572 12:06, 9 December 2006 (CET)

There has never been any PBO encryption of any kind outside of VBS addon encryption. If addons were actually encrypted, then OFP or ArmA would be unable to read the pbo's. Rather, close inspection of the pbo's in question shows that simple hex editing was done to inject invalid data into the I/O processing of the community PBO tools, while still allowing the more lenient OFP engine to properly access the filestream. And to echo what feersum said, pbo signing is not a protection against accessing the pbo content, it's protection against unverified differenttial data ingame. Shinraiden 18:27, 9 December 2006 (CET)

Thanks for explaining that, I never knew how it was done, but it prevented regular user to unpack .pbo, I guess I used the wrong term to describe it. And as I already stated, I wasn't talking about ArmA, and I comprehend what signing the addons actually does. --Sniperwolf572 20:01, 9 December 2006 (CET)