Modders Code and Conduct

Hydromancerx

C2C Modder
Joined
Feb 27, 2008
Messages
16,281
Location
California, USA
I have done this before myself and have had it happen to me. Where someone else on the SVN modifies stuff you have been working on in your folder. I would like to apologize for any times I have done it to others (Sorry DH :( ) and request that if you want to edit someone else folder you ask or at least warn them before you do so. In case they are currently working on the files you are altering.

Today Thunderbrd did this to many of my files. While I was not working on anything at the time, I could have been. It was only by chance I was working on new animals instead of new buildings.

I also have an offline copy of all my files separate from the SVN. Now that he changed it i will have to back up them and then replace. In short I would much rather alter my own files if I can help it.

So please respect each modders own folder so we don't get conflicting files or files that get reverted because they did not realize you altered their files.

Thank you.
 
Not practical for the DLL since it's not modular. AIAndy and I have a reasonable general idea of what each other are doing though, so I think we're ok and talking when we need to.
 
I'll try to keep everyone in the loop a bit more but I didn't realize we were being territorial about our files, particularly when it comes to debugging for the need of the whole of the mod. Not to say that I don't understand how you must feel and I'm giving that some thought and consideration. Just keep in mind that the SVN is there to make sure we can do these things and alerts are given us when we attempt to push files that are now in conflict. At that point, there are ways the SVN helps us to merge and address those conflicts as well.

It might be helpful for us to get comfortable with how the SVN handles these conflicts. I know I had to work with one from DH's file right away - there were still some bugs in the Louvre file after he had fixed the readily apparent one and he did so after I had taken the last update on that file. So I had to fumble around a bit to figure out what the SVN was doing to help me resolve the conflict but I think if its methods were clearly understood, we'd have little to fear in such an accidental conflict.

Now, if I were going in and directly manipulating your creations without some discussion with you, that'd be a different matter, I'm sure... that would certainly be treading into rude territory. But some minor debugging like that... well, it reveals the concerns we have with the mysteries of the SVN functions, that's understandable.

So that you are aware of why I needed to debug those files, Hydro, and no they weren't JUST your files by any means, I'm trying to get this spreadsheeting tool to work to capture all building data on all buildings in the mod so we can draw some comparisons. Hopefully this tool will aide you as much as I assume it will aide me in my economic audit goals.

Turns out that spreadsheeting tool is a hell of a debug mechanism when used to find them... I found so many little xml errors in our files it was exhausting to go through (though in some ways I'm impressed even more by how FEW of those easy mistakes to make there actually were). They were almost ALL just duplications of the same xml tags under one entry (aka one building might be listing two civilopedia entries... not kosher for our tool at least and I suspect causes some issues where we may think we're adjusting something only to find our adjustments not working because they are being overwritten into the game by the old data further down the list that hasn't been removed or replaced correctly.)

So yeah, sorry... didn't mean for any of it to come across personally nor for it to cause any inconvenience. And as a warning... I'm looking to create a unified C2C Building Schema next so as to make sure I've captured ALL fields in ALL building files... I noticed I was missing some along the way last night. Those would cause extensive minor edits in all building files so be forewarned this will be taking place soon. I'll be updating, as always, just before any changes are made and making them in one quick swoop so as to be as little intrusive as possible.
 
Not practical for the DLL since it's not modular. AIAndy and I have a reasonable general idea of what each other are doing though, so I think we're ok and talking when we need to.

I did not mean the core stuff. I ment folder called like "Hydro", "DancingHoskuld" or "StrategyOnly" where the stuff in them is obviously stuff they made (and assume are working on).

@Thunderbrd

I was aware you were just tiding the code up and not changing things. In fact I was glad you were It just took me by surprise. I also still don't understand how to "merge" files. So any explanation on how you do that would be appreciated.

Sorry for sounding territorial, it was more of me freaking out saying "He changed all the stuff and I have no idea how to merge my changes with his!"

I'm looking to create a unified C2C Building Schema next so as to make sure I've captured ALL fields in ALL building files.

This is probably a bad idea. I can understand having the "Afforess_CIV4BuildingsSchema.xml" as the most up to date one. But if every mod had the same one then if someone forget to update just one of the scehemas then it will create errors.

This is why each of us maintain our own schemas within our own folders. We can make sure all our folders within our folder are up to date and the same name. Which means there will be no conflict if the core schema is updated and ours are not (however I usually update mine anyways). Note that updating can take awhile since I have around 33 building schemas to update.

EDIT: The other issue is since I have the separate copy, I could have just as easily wrote over all you changes without knowing it. Thus making me aware that your changing stuff allows me to keep a non-SVN copy up to date without having to update it all the time.
 
Ok, so first of all, the SVN will let you know if you are updating with changes on files that weren't updated since the last time those files were updated in the SVN and there happen to be conflicts. It WILL flag these before it allows you to just update over the top of another modder's changes.

2nd, WinMerge is free and extremely easy to use as a merging program. The SVN apparently has an onboard merging software but I'm not familiar with its use at all so its just easier to NOT update when you have a flagged conflict and first go in and use the merge program. Usually, this would be so fast and easy to do you would hardly notice the effort.

3rd, I do understand what you mean about the schema, but again, we're using an SVN here so such update issues wouldn't be problematic I don't think. If the core schema is updated and yours are not, it doesn't really matter any more that way than it would the way we currently have it because the info file will only look at the schema within the same directory regardless of name. It might be a bit misleading but it certainly is possible that there are multiple versions of the Afforess schema as well. Nevertheless, I believe it would make it easier for us all if we have unified schemas because only a few of us can even add or change tags and if we do we can just update the schema file and overwrite it in every directory it exists in currently by doing a quick search of the mod file for the one schema file name and overwriting it in all those locations - simple.

I certainly mean no disrespect to say that your concern about forgetting to update your own files would be a moot point given the first and second points made here - this just means you need to update frequently or keep an eye on the SVN log which I think we all do already, right?
 
Ok, so first of all, the SVN will let you know if you are updating with changes on files that weren't updated since the last time those files were updated in the SVN and there happen to be conflicts. It WILL flag these before it allows you to just update over the top of another modder's changes.

Not true. I have had it tell me when conflicting but I have also had it where I knew it would conflict but it did not. I am thinking may it has something to do with the date and if you had already updated.

3rd, I do understand what you mean about the schema, but again, we're using an SVN here so such update issues wouldn't be problematic I don't think. If the core schema is updated and yours are not, it doesn't really matter any more that way than it would the way we currently have it because the info file will only look at the schema within the same directory regardless of name. It might be a bit misleading but it certainly is possible that there are multiple versions of the Afforess schema as well. Nevertheless, I believe it would make it easier for us all if we have unified schemas because only a few of us can even add or change tags and if we do we can just update the schema file and overwrite it in every directory it exists in currently by doing a quick search of the mod file for the one schema file name and overwriting it in all those locations - simple.

Ok lets say we all used a building schema with the same name. Instead of Hydro_CIV4BuildingsSchema.xml or Subdue_Animals_CIV4BuildingClassInfos.xml they were all called C2C_CIV4BuildingClassInfos. Cool right? Nope. If just one of them doesn't have the same info as the other they get a weird error! However if you name them different things and they do not have the same info they will not give a weird error. Thus if you want to have them all with the same name then you better remember to update them all.

I certainly mean no disrespect to say that your concern about forgetting to update your own files would be a moot point given the first and second points made here - this just means you need to update frequently or keep an eye on the SVN log which I think we all do already, right?

Well I am only human and I try to keep up to date on the SVN, however I do miss some things sometimes. Thus if you are messing with stuff in the Hydro folder PLEASE tell me. I just wanted to be sure I know in case I miss it for whatever reason. Same should be done if you mess with DH's or SO's folders.
 
Point 1: Interesting... Koshling, can you weigh in on that? How does this take place?

Point 2: Worthy of note for sure. It may be good to adopt a naming scheme that bases itself on the file the schema is in. Would vastly increase the time it would take to update schemas across the board but I can see the point in doing so. (I will probably prove anal when adding tags anyhow that ALL schema files of the same sort will be updated across all mod files. I would be terribly afraid not to actually... would feel like setting up a problem for the future.)

Point 3: Sure, understood. So once files have been adjusted, should we post that we'd like to update the SVN before we push a change? Is that what we're saying? I hadn't really set forth intending to mess with those files but they ended up being on the list of those needing some minor fixes so I could press onward. Had I not pushed them to the SVN I would've felt as if I were being all the more rude to have found complex and difficult to isolate bugs, eliminate them, and then just letting them sit unchanged for the rest of you. I had thought of it as a courtesy at the time... lol!
 
Point 3: Sure, understood. So once files have been adjusted, should we post that we'd like to update the SVN before we push a change? Is that what we're saying? I hadn't really set forth intending to mess with those files but they ended up being on the list of those needing some minor fixes so I could press onward. Had I not pushed them to the SVN I would've felt as if I were being all the more rude to have found complex and difficult to isolate bugs, eliminate them, and then just letting them sit unchanged for the rest of you. I had thought of it as a courtesy at the time... lol!

Yeah. Warn us before. If we are working on something with those files then we can figure out how to merge them. If not then you can just update as usual and I can make sure my private copy is up to date as well.

Note that if they are just a few minor bugs more often than not we can fix it and you don't even have to do it. For example there was a cross mod thing between DH's religions and my culture buildings. DH warned me ahead of time he was doing this and he fixed the problem. I made sure I was not altering any of the files and updated my stuff when he was done. Thus benefiting both our mods and C2C as a whole.
 
Point 1: Interesting... Koshling, can you weigh in on that? How does this take place?

Point 2: Worthy of note for sure. It may be good to adopt a naming scheme that bases itself on the file the schema is in. Would vastly increase the time it would take to update schemas across the board but I can see the point in doing so. (I will probably prove anal when adding tags anyhow that ALL schema files of the same sort will be updated across all mod files. I would be terribly afraid not to actually... would feel like setting up a problem for the future.)

Point 3: Sure, understood. So once files have been adjusted, should we post that we'd like to update the SVN before we push a change? Is that what we're saying? I hadn't really set forth intending to mess with those files but they ended up being on the list of those needing some minor fixes so I could press onward. Had I not pushed them to the SVN I would've felt as if I were being all the more rude to have found complex and difficult to isolate bugs, eliminate them, and then just letting them sit unchanged for the rest of you. I had thought of it as a courtesy at the time... lol!

The SVN will flag a conflict when yuo try to commit (or Update) if someone else has committed a change SINCE you LAST did an Update. If you do an Update and make a change you can commit it even if other poepl have uncomitted changes since THEY will get the conflict report when they commit.
 
The SVN will flag a conflict when yuo try to commit (or Update) if someone else has committed a change SINCE you LAST did an Update. If you do an Update and make a change you can commit it even if other poepl have uncomitted changes since THEY will get the conflict report when they commit.

Right. So it won't allow one user to change a file and commit it when the file has been changed by another user since you updated WITHOUT addressing the fact that there will be a need to do a merge first.

So then when you attempt to commit a file that has been changed on the SVN since you updated, it will flag it, but then what exactly?

My experience was that it actually placed lines of code in my file to point out where my file differed from the one in the SVN.

But what is the proper procedure for resolving that from there then?
 
@Koshling, I have a conflict state that I can't resolve. Climat made a change to some text in one of "my" folders which I did not notice. I then deleted that folder only to get a conflict. Nothing I do seems to fix the problem and I don't know if it is on the SVN or not.

Can you remove the Modules/DancingHoskuld/xtras/flightlessbirds and komodo folders? The animals in there now have proper graphics and are in my main folder now. Thanks.
 
I just did a recent update and I'm not showing those files as being in the mod. You must've done it right for the SVN.

I take it now that you've removed them from your own files, you can't seem to commit to the svn? Right click on the main mod repository and do a cleanup once they've been removed from your files I think.

But you're saying you've done that and you still can't do any further commits? Why? What is the message you're getting?
 
I just did a recent update and I'm not showing those files as being in the mod. You must've done it right for the SVN.

I take it now that you've removed them from your own files, you can't seem to commit to the svn? Right click on the main mod repository and do a cleanup once they've been removed from your files I think.

But you're saying you've done that and you still can't do any further commits? Why? What is the message you're getting?

Whenever I try and do a commit it adds in the delete of those folders and then fails.:crazyeye:
 
It shouldn't be problematic when this happens but we're all new to the svn and that's what causes concern. When we figure out how to traverse these sorts of issues quickly and easily, we won't have fear of anyone touching each other's files (unless they really mess with the MOD in undesireable ways... lol!)
 
Back
Top Bottom