Fomenting Mutiny

[Legacy_meaglyn]

               

pope_leo wrote...

Tarot raises a good point, I think.  It is worth keeping in mind that binary files are not going to merge, I'm not sure how much of cep resources that might include -- edit: even decompiled mdls might not be mergable -- , so if you use a DVCS like git or mercurial and have multiple people working on the same binary files at the same time, someone is going to have a bad time.

This is why most game studios seem to use Perforce for binary stuff, it lets you lock assets (so only one person can check them out at a time), among other things.

He does, and I'm not trying to dismiss them out of hand. I jus think that using a centralized version control system
for this nascent distributed development effort does not make sense.

Binaries are an issue anywhere.  I suspect these game studios are mostly local or VPN accessible
and have an IT staff to make sure everyone can always reach the repo.  you'd also have to deal with
people who lock things and never unlock them. 

Text files also fail to merge at times. And someone has to fix that too.

In these cases the onus should be on the people who both editted the file, not the gatekeepers. git complains if you try to push and there is a conflict.  You then have to  pull changes down and merge locally before pushing to the incoming branch of the master.  It would effectively be on the person who pushes second to do the merge in this case.
               
               

               
            

[Legacy_Shadooow]

               

henesua wrote...

I have wondered about how tracking changes in a decompiled mdl works as well. I figured that since they are text they'd work fine.

i dont think you could merge/view changes in mdls. Unless they are edited by someone with notepad, Max totally rebuilds the file usually.
               
               

               
            

[Legacy_Zarathustra217]

               I honestly believe you might be overthinking it a bit here. This isn't about merging a large amount of code. Most of the CEP is made up of model files, and for most fixes it would entail no more than changing a few details in a model. It's a lot of little things. Unless two people within some brief moment of time decide to fix the same thing, there wouldn't be any issues (except the .set and .2da files as I mentioned above).

Personally, I feel TortoiseSVN might be a good choice since it's so simple to use.
               
               

               

                     Modifié par Zarathustra217, 22 janvier 2014 - 04:38 .
                     
                  

            

[Legacy_henesua]

               While i like version control, something as simple as possible - like dropbox simple - is probably the way to go so that ancillary systems don't get in the way. Most artists just want to play with models. All the other technical things become barriers to entry as they have no patience for them.
               
               

               
            

[Legacy_The Amethyst Dragon]

               Is the CEP really such a complicated thing that it requires tools designed for multiple software developers to manage?

It's just a (big) set of haks, a .tlk file, and a starter module.

Why not do something simpler?

Made a fix?  Added something via 2da?  Submitting something brand new?  Just zip/rar/7z it up, attach it to an email, and send it to nwncep@gmail.com.  I download it into my "CEP Pending" folder, do an online backup (I've got like 198 extra GB on my website account I already pay for), get things merged in, and backup the merged haks.  Every once in a while post an update on the new Vault.

I looked at Dropbox, but a free account is only 2 GB and I don't feel like spending money for a "premium" account.  While the 7z-compressed CEP (currently) comes in at under 800 MB, I could see multiple people putting stuff in the dropbox account quickly swelling it beyond the limit.
               
               

               
            

[Legacy_Zarathustra217]

               My main reservation with that is that unless you want to keep everyone constantly posted on what's been updated, fixed and whatnot, people will feel alienated to the process and thus not participate as easily. It's basically how the old CEP team worked.

TortoiseSVN is very much like dropbox (it even use the same icons!), and anyone able to use dropbox should have no issue with that.
               
               

               

                     Modifié par Zarathustra217, 22 janvier 2014 - 06:19 .
                     
                  

            

[Legacy_meaglyn]

               

Zarathustra217 wrote...

My main reservation with that is that unless you want to keep everyone constantly posted on what's been updated, fixed and whatnot, people will feel alienated to the process and thus not participate as easily. It's basically how the old CEP team worked.

TortoiseSVN is very much like dropbox (it even use the same icons!), and anyone able to use dropbox should have no issue with that.

I agree that people doing the work should have access to the latest state of things, not the last released state. This could be mitigated by AD posting very regular (daily, weekly?) snapshots, but that's a lot of bandwidth for people if only a little bit changes each time.

TortoiseSVN is a windows only interface to SVN. It's not what the project would be in (that'd be SVN itself). TortoiseSVN would just be the client you may choose to access it with.

Those of us who do most everything on Linux probably won't bother with that one '>
               
               

               
            

[Legacy_Zarathustra217]

               Right, of course, but there's still some considerations to be made if it's made the "standard solution" (rather than the other proposals). I'm sure the linux folks will know how to navigate the SVN in their own way, but the point is to focus on what methods we can adapt to make it easily accessible for all (i.e. not just those more used to work with SVN).

As for hosting, wouldn't it be possible to use sourceforge?
               
               

               
            

[Legacy_Tarot Redhand]

               Sorry about this but I think I just realised another (but at least in part, easier to solve) problem. It has to do with textures and other images within the CEP. The thing is that a number of models use the same texture or to put it another way one texture may be used by 2 or more models. Not only that but some outside projects (I'm thinking of the CCP here as an example) use textures from within the CEP and will not work properly without them.

So before any models and associated textures are stored, in whatever manner, I think someone will need to write some sort of program to go through all of the models to find out which textures they use and to produce a report on it so that fixing something in one place doesn't break something else that appeared to be working before. Not only that but it might be well mannered to include the CCP in this process. And that doesn't even cover the icons and portraits...

TR
               
               

               

                     Modifié par Tarot Redhand, 22 janvier 2014 - 11:27 .
                     
                  

            

[Legacy_Builder__Anthony]

               i dont see how anyone can complain.
               
               

               
            

[Legacy_Pstemarie]

               

The Amethyst Dragon wrote...

Is the CEP really such a complicated thing that it requires tools designed for multiple software developers to manage?

It's just a (big) set of haks, a .tlk file, and a starter module.

Why not do something simpler?

Made a fix?  Added something via 2da?  Submitting something brand new?  Just zip/rar/7z it up, attach it to an email, and send it to nwncep@gmail.com.  I download it into my "CEP Pending" folder, do an online backup (I've got like 198 extra GB on my website account I already pay for), get things merged in, and backup the merged haks.  Every once in a while post an update on the new Vault.

I looked at Dropbox, but a free account is only 2 GB and I don't feel like spending money for a "premium" account.  While the 7z-compressed CEP (currently) comes in at under 800 MB, I could see multiple people putting stuff in the dropbox account quickly swelling it beyond the limit.

I tend to agree with you once again. The only reason I suggested some kind of tracker was so other people looking at submitting fixes or addons have some idea what others are working on. This could be as simple as a table on a wiki where users submit basic information about what they are doing. However, the bottom-line is that, despite the best intentions of everyone posting in this thread, TAD will most likely be the person doing ALL the fixes and addons. I have no doubt people will step-up to help, but, in my expereinces, the majority of them will wander off to personal higher-interest projects after a short-time or get recalled by real-life priorities.

The reality of the NWN CC Community is that we are a conglomerate of individuals with our own pet projects that will take precedence over anything else we do. For me its my LAN world and Project Q; for TAD its Aenea; For Henesua its Vives Reborn; for Barry1066 it was Annoklia, etc. etc. 
               
               

               
            

[Legacy_Tiberius_Morguhn]

               

Tarot Redhand wrote...

Sorry about this but I think I just realised another (but at least in part, easier to solve) problem. It has to do with textures and other images within the CEP. The thing is that a number of models use the same texture or to put it another way one texture may be used by 2 or more models. Not only that but some outside projects (I'm thinking of the CCP here as an example) use textures from within the CEP and will not work properly without them.

So before any models and associated textures are stored, in whatever manner, I think someone will need to write some sort of program to go through all of the models to find out which textures they use and to produce a report on it so that fixing something in one place doesn't break something else that appeared to be working before. Not only that but it might be well mannered to include the CCP in this process. And that doesn't even cover the icons and portraits...

TR

I did a quick and dirty export of all textures from CEP 2.1 (the latest I have) - converting DDS to TGA.  I did an md5sum on each image file and then just compared them to every other image file.  I only found ~72 duplicated image files (ie. files that are named different but have the same data - I did spot check several of these visually to make sure....).  I didn't calculate the amount of space/file sizes, but this probably isn't a whole lot of savings.

To help decode (since I did some shorthand), the number\\\\ (ie. 0\\\\) indicates CEP core0 file.  So 1\\\\ indicates CEP core1 file and so on.

0\\\\c_trollwara_be.tga matches: 0\\\\c_trollwarb_be.tga,0\\\\c_trollwarc_be.tga,
0\\\\c_trollwara_fo.tga matches: 0\\\\c_trollwarb_fo.tga,
0\\\\c_trollwara_hl.tga matches: 0\\\\c_trollwarb_hl.tga,0\\\\c_trollwarc_hl.tga,
0\\\\c_trollwara_le.tga matches: 0\\\\c_trollwarb_le.tga,0\\\\c_trollwarc_le.tga,
0\\\\c_trollwarb_be.tga matches: 0\\\\c_trollwarc_be.tga,
0\\\\c_trollwarb_hl.tga matches: 0\\\\c_trollwarc_hl.tga,
0\\\\c_trollwarb_hr.tga matches: 0\\\\c_trollwarc_hr.tga,
0\\\\c_trollwarb_le.tga matches: 0\\\\c_trollwarc_le.tga,
0\\\\f_ayala_hair.tga matches: 1\\\\f_ayala_hair.tga,
0\\\\f_ayala_head.tga matches: 1\\\\f_ayala_head.tga,
0\\\\f_f_robe_001.tga matches: 1\\\\f_f_robe_001.tga,
0\\\\f_irb_fur.tga matches: 1\\\\f_irb_fur.tga,
0\\\\pdag_black.tga matches: 0\\\\wmb_blackback.tga,
0\\\\wmi_c1ar0100_r.tga matches: 0\\\\wmi_c1ar0100_r2.tga,
0\\\\wmi_c1ar0500.tga matches: 0\\\\wmi_c1ar0500_r.tga,
1\\\\aged_steel_dk.tga matches: 1\\\\aged_steel_dk_bu.tga,
1\\\\Ant_legs2.tga matches: 1\\\\c_wasp_legs2.tga,
1\\\\arthur_forer.tga matches: 1\\\\tyr_forer.tga,
1\\\\arthur_shinr.tga matches: 1\\\\tyr_shinr.tga,
1\\\\AShLw_RB.tga matches: 1\\\\texbuck.tga,
1\\\\bay_tail.tga matches: 1\\\\blackhrse_tail.tga,
1\\\\bzm_fore.tga matches: 1\\\\gzom_fore.tga,
1\\\\bzm_hands.tga matches: 1\\\\gzom_hands.tga,
1\\\\bzm_neck.tga matches: 1\\\\gzom_neck.tga,
1\\\\c_orca_frun.tga matches: 1\\\\c_orcb_frun.tga,
1\\\\c_pudding-wht.tga matches: 1\\\\c_slithtrack.tga,
1\\\\c_sf_Kakkuu.tga matches: 1\\\\c_sf_Spithriku.tga,
1\\\\c_visage.tga matches: 2\\\\c_shadow.tga,
1\\\\cc_gntfireadpa.tga matches: 1\\\\cc_gntfiresora.tga,
1\\\\cc_gntfireadpb.tga matches: 1\\\\cc_gntfiresorb.tga,
1\\\\cc_gntfireadpc.tga matches: 1\\\\cc_gntfiresorc.tga,
1\\\\cc_gntfrostadpa.tga matches: 1\\\\cc_gntfrostsora.tga,
1\\\\cc_gntfrostadpb.tga matches: 1\\\\cc_gntfrostsorb.tga,
1\\\\cc_gntfrostadpc.tga matches: 1\\\\cc_gntfrostsorc.tga,
1\\\\dk_water01.tga matches: 1\\\\water.tga,
1\\\\Drid_Abody.tga matches: 1\\\\Drid_FBodyC.tga,1\\\\Drid_Mbody-C.tga,
1\\\\Drid_ACbicep.tga matches: 1\\\\Drid_FbiceplA.tga,
1\\\\Drid_ACBody.tga matches: 1\\\\Drid_FBodyA.tga,1\\\\Drid_Mbody.tga,
1\\\\Drid_ACchest.tga matches: 1\\\\Drid_FchestA.tga,
1\\\\Drid_ACfhead.tga matches: 1\\\\Drid_FheadA.tga,
1\\\\Drid_ACfore.tga matches: 1\\\\Drid_FforerA.tga,
1\\\\Drid_AChand.tga matches: 1\\\\Drid_FhandrA.tga,
1\\\\Drid_AChelm.tga matches: 1\\\\Drid_Ahelm.tga,
1\\\\Drid_ACpelvis.tga matches: 1\\\\Drid_FpelvisA.tga,
1\\\\Drid_FBodyA.tga matches: 1\\\\Drid_Mbody.tga,
1\\\\Drid_FBodyC.tga matches: 1\\\\Drid_Mbody-C.tga,
1\\\\fleebitten_tail.tga matches: 1\\\\greyhrse_tail.tga,1\\\\whitehrse_tail.tga,
1\\\\fxpa_deawea_bla.tga matches: 2\\\\c_dea_staff.tga,
1\\\\fxpa_flame00.tga matches: pheno2\\\\fxpa_flame00.tga,
1\\\\fxpa_flamegd.tga matches: pheno2\\\\fxpa_flamegd.tga,
1\\\\gd_cav.tga matches: pheno2\\\\gd_cav.tga,
1\\\\greyhrse_tail.tga matches: 1\\\\whitehrse_tail.tga,
1\\\\leopardapp_tail.tga matches: 1\\\\quagga_tail.tga,
1\\\\lupinal_bicep.tga matches: 1\\\\lupinal_hoof.tga,1\\\\lupinal_shin.tga,
1\\\\lupinal_hoof.tga matches: 1\\\\lupinal_shin.tga,
1\\\\marl_tail3b.tga matches: 1\\\\marl_tail4b.tga,1\\\\marl_tail5b.tga,
1\\\\marl_tail3c.tga matches: 1\\\\marl_tail4c.tga,1\\\\marl_tail5c.tga,
1\\\\marl_tail4b.tga matches: 1\\\\marl_tail5b.tga,
1\\\\marl_tail4c.tga matches: 1\\\\marl_tail5c.tga,
1\\\\nm_cav.tga matches: pheno2\\\\nm_cav.tga,
1\\\\sella.tga matches: pheno2\\\\sella.tga,
1\\\\sella_1.tga matches: pheno2\\\\sella_1.tga,
2\\\\c_elemash.tga matches: 2\\\\c_elemsmoke.tga,

One thing that was more concerning is that in several cases the TGA version of a texture is in a higher order hak than the corresponding DDS version.  For example c_ginger is found as a large DDS in CEP core 1, but the smaller TGA is found in CEP core 2.  The ordering of the haks for CEP is descending so conetent in core 2 overrides core 1, etc.  I don't know how that affects DDS versus TGA though since the engine is supposed to use DDS first.  May require some testing.......
               
               

               
            

[Legacy_Zarathustra217]

               

Pstemarie wrote...
I tend to agree with you once again. The only reason I suggested some kind of tracker was so other people looking at submitting fixes or addons have some idea what others are working on. This could be as simple as a table on a wiki where users submit basic information about what they are doing. However, the bottom-line is that, despite the best intentions of everyone posting in this thread, TAD will most likely be the person doing ALL the fixes and addons. I have no doubt people will step-up to help, but, in my expereinces, the majority of them will wander off to personal higher-interest projects after a short-time or get recalled by real-life priorities.

The reality of the NWN CC Community is that we are a conglomerate of individuals with our own pet projects that will take precedence over anything else we do. For me its my LAN world and Project Q; for TAD its Aenea; For Henesua its Vives Reborn; for Barry1066 it was Annoklia, etc. etc. 

Well, my hope is that if it's made a lot easier to contribute and take part in the development, more people are likely to contribute and continue to do so. Speaking for myself, I likely wouldn't have time to take part in the large central tasks (should they be undertaken), but I can definitely contribute with correcting the shadows or a stretched texture on a model. And I know many members of our PW community already are doing the same.

I might be naive though, and perhaps a SVN repository wouldn't affect how much people contribute - but then again, I don't see any loss in trying. I expect it would be much easier for TAD to even manage his own work that way, especially since it's so simple and easy to use.

Anyway, that's my 2 cents. I'll try to send in any fixes I have no matter what. But if you want to try setting up a SVN and tortioseSVN locally, I'm sure quite many of us (myself included) would be ready and willing to help.
               
               

               

                     Modifié par Zarathustra217, 23 janvier 2014 - 01:36 .
                     
                  

            

[Legacy_Tarot Redhand]

               @Tiberius_Morguhn I think you may have misunderstood what I was getting at. To be honest I hadn't even thought about duplicate image files. What I am worried about are those image files that are used by more than one model - the old 1 to n problem. Where more than one model uses the same texture. Say someone comes along and quite legitimately, in an effort to improve the placeable or whatever, alters a texture which in turn ruins the look of some other model because both models were using the same texture.

TR
               
               

               

                     Modifié par Tarot Redhand, 23 janvier 2014 - 02:27 .
                     
                  

            

[Legacy_henesua]

               

Pstemarie wrote...
The reality of the NWN CC Community is that we are a conglomerate of individuals with our own pet projects that will take precedence over anything else we do. For me its my LAN world and Project Q; for TAD its Aenea; For Henesua its Vives Reborn; for Barry1066 it was Annoklia, etc. etc.

This is one reason why I put forth both of my proposals: a more inclusive CEP group with a low bar to participation, and an actual modular approach to CEP in which each HAK can stand alone without the others. One of The the goals is to increase participation, and to reduce the amount of work required on each project.

Obviously no one is having it, and I suppose thats fine. But if anyone puts forth an idea that at least takes a baby step towards those goals, I'm going to cheer, because it makes it easier for me to help.
               
               

               

                     Modifié par henesua, 23 janvier 2014 - 02:57 .