I think that editing triggers via a multi-user editor would be more annoying, I mean, think about it, you both start working on the same thing, and then you accidently get 2 copies, and then you also don't know what everyone else is doing.
None.
That's precisely what SVN is for.
Version control.
None.
You still don't know exactly what is going on.
None.
How can you get 2 copies of the map in a multi-user editor? Such an editor surely wouldn't allow conflicts to happen by keeping everyone into the same copy. That's kinda the point of a multi-user editor to begin with, right?
No, maybe I don't understand what you're saying.
SVN is just designed to handle conflicts from separate copies. You'd definitely still want to have it even with a multi-user editor, unless everyone can be expected to have the editor open for the same map at all times (or at least always at the same times).
Post has been edited 1 time(s), last time on Mar 29 2008, 12:25 am by Tuxedo-Templar.
None.
I mean you both try to make the same trigger at the same time, then you both end up making one.
None.
Oh. You mean IN the editor.
That's just standard organizational stuff. That's not a problem with the editor itself. You'll want to have everyone, say, in a chat program while using the editor at the same time, so you can talk and work out stuff like that. Plus you'll want to have your project outline well drafted and tasks delegated beforehand as well to avoid real-time conflicts like that.
No biggie.
None.
Nonetheless, even if you do that, you still might get bugs from not knowing exactly what other people are doing in their triggers.
None.
Yeah, which is why you also need to keep good track of nearly all the map information separately. Things such as counters, locations, unit usage, etc. Doing that, and more importantly, USING the information (the most current information you can get) before venturing into creating new triggers ought to prevent significant conflicts most of the time.
The rest of the time it's just about communication and standard debugging.
None.
Meh, I guess I'm just a mapping loner then
None.
Well most of those methods aren't stuff people would think to formally use. In which case yes, they'll run into those problems you mentioned. But inevitably they'll likely learn from trial and error basically those same methods.
There are things you can do on the software level to accommodate that, but really it should come down to development practices to be doing that instead. Software can't magically plug all the holes no matter how good it is.
None.