That's fine with me, I was expecting this. Same would have to go for Gear Commander (centurion-1), Battletech (bobdinosaur), Gundam (Smoth) and GEM (Cadyr) though, which leaves out a lot of the high quality mods...Argh wrote:3. Lastly... I think that while people who're totally and legitimately Mod Developers exist who're using Other People's IP... they should never, ever be allowed SVN access for those projects. It is never going to be safe for GuessMyName's project to be on SVN. It's a 40K rip. I have no problems with it, and encourage his effort to succeed- which it appears that it is, and surprisingly quickly, from the screenies I've seen- but... you cannot put stuff like that into SVN. And, of course, there needs to be a practical upper limit on filesize, or Spring will become a bloated monster.
Mod development process.
Moderator: Moderators
- Guessmyname
- Posts: 3301
- Joined: 28 Apr 2005, 21:07
- Guessmyname
- Posts: 3301
- Joined: 28 Apr 2005, 21:07
- SwiftSpear
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
Until we have a mod that can verify that all their content was self produced or owned by the production team of the mod we really can't claim that any of them are entirely without breach of copy write... That being said, I don't think it's a great idea for any content to be included with the spring development kit due to the fact that spring in development is really more an engine, not a game.
It sounds like a good plan. Well written and easy to understand. The idea of a modders forum sounds good, as long as it isn't too exclusive.
I'm trying to understand the usefulness of having a project put on the SVN. It seems like it would probably result in a lot of bloat to the SVN log. I use that log as a tool to see what changes I need to make, and I'm sure I'm not the only one.
Most mod projects designed for Spring, as far as I know, are going to be pretty large. I do not have all the content for GEM done, and the filesize when zipped is somewhere around 50 megabytes. This is as a result of high-resolution textures, which are unavoidably pretty big... I don't see mods of this size ever being included with a Spring release, so why have them on the SVN?
I'm trying to understand the usefulness of having a project put on the SVN. It seems like it would probably result in a lot of bloat to the SVN log. I use that log as a tool to see what changes I need to make, and I'm sure I'm not the only one.
Most mod projects designed for Spring, as far as I know, are going to be pretty large. I do not have all the content for GEM done, and the filesize when zipped is somewhere around 50 megabytes. This is as a result of high-resolution textures, which are unavoidably pretty big... I don't see mods of this size ever being included with a Spring release, so why have them on the SVN?
The text files can be useful to have on SVN when you are working with multiple people, but since you're doing GEM and AA by yourself, and because GEM has a lot of data, there isn't much point in a public SVN I guess.
It can be useful to put it in a repository on your HD, since that is fast enough to handle large binary files.
It can be useful to put it in a repository on your HD, since that is fast enough to handle large binary files.
- Tim Blokdijk
- Posts: 1242
- Joined: 29 May 2005, 11:18
Xect v/s Mynn and NanoBlobs are clean, and it's "copyright"SwiftSpear wrote:text

I don't understand why Spring would just be an engine, you can't play an engine you need content.
I do agree that it's a different way to organize things but as long as it's done gradually and with some care we will manage fine.
If needed the svn log can be split up so you would still have the information you need.Caydr wrote:text
Svn is not the magic tool, but in combination with something like WebDav you get a development environment quite suited for team based development. People can write a patch (for text files) update a texture or include a unit. Also engine dev's can migrate mods to new formats removing the need for backwards compatibility.
Including a mod with Spring is another discussion, you really need to see svn as a development tool not a way to get your mod in a Spring release.
Large files will make it more difficult for people on dial-up but still not impossible, svn is set up in a way now that content won't be downloaded when you check out trunk for the engine code.
Having the photoshop and gimp files on WebDav will prevent bloating the reposetory for a large part.
The only thing left is that you can't diff a binary file so you have to communicate a bit about what files your working on.
I know project orange (Blender's "Elaphants Dream") used a little webapp to communicate what files they were using as they found locking the files in svn circuitously.
But we still need to find out how we are going to deal with this in an effective manner, there are no open source gaming projects of this size (as far as I know) so we will have to figure out how to do this step by step ourselfs.
Boson (another open source 3D engine) has its content in svn.
"svn co https://svn.sourceforge.net/svnroot/boson/trunk/ Boson" for those that care.
I know I don't always have the most reasonable requests, but I try to keep things within the scope of, as far as I am aware, possibility. Although I am not really familiar with the inner workings of C+ and all that stuff, I do know how to make realistic suggestions. Rather than say, I think units should be able to fly and have a GUI button to do so, I'd say, can we have a way to have a unit switch automatically to "off" after a predetermined wait period and not be able to turn back "on" until another predetermined period has been completed.
That way, it's flexible and can be used for any number of new things. For jetpacks, you switch the unit to ON, a hidden timer starts counting down from 10, the base object is moved 50 units upward, 10 seconds later it automatically turns off and the unit moves back to ground level and cannot be activated again for 15 seconds, instead of the hard-working developers who probably, as it is now, have to work for 10 minutes to find an idea that isn't ridiculous.
...Actually could that be implemented? Sounds cool!
Well my point was, a closed development forum could help to keep realistic and useful suggestions (like the one in the second paragraph) at the forefront, while modders such as myself would be the ones damned to sift through all the things in the first paragraph.
That way, it's flexible and can be used for any number of new things. For jetpacks, you switch the unit to ON, a hidden timer starts counting down from 10, the base object is moved 50 units upward, 10 seconds later it automatically turns off and the unit moves back to ground level and cannot be activated again for 15 seconds, instead of the hard-working developers who probably, as it is now, have to work for 10 minutes to find an idea that isn't ridiculous.
...Actually could that be implemented? Sounds cool!

Well my point was, a closed development forum could help to keep realistic and useful suggestions (like the one in the second paragraph) at the forefront, while modders such as myself would be the ones damned to sift through all the things in the first paragraph.
That's pretty easy to do in a script:
Most likely you could just write the jetpack stuff in there instead of calling a separate script. You could also put the jetpack stuff into a function you call with call-script that includes the ten second wait and have Deactivate() send a signal that kills the called script and makes Activate() proceed with the landing and deactivation stuff. Unless I'm mistaken about the signal not killing the parent function or the Activate/Deactivate stuff but here are ways around both.
EDIT: But of course it can only change the speed the unit can move at, not its movement type so it can't climb slopes it previously couldn't climb. Would probably work for movable buildings (jumping fusion plant?), though.
Code: Select all
static-var State; //0=Ready, 1=Active, 2=Recharging
Activate()
{
if(State) {
if (State==2) set ACTIVATION to FALSE;
return FALSE;
}
State=1;
start-script JetpackStuff();
sleep 10000;
State=2;
start-script UndoJetpackStuff();
sleep 15000;
State=0;
}
Deactivate()
{
if(State==1) set ACTIVATION to 1;
}
EDIT: But of course it can only change the speed the unit can move at, not its movement type so it can't climb slopes it previously couldn't climb. Would probably work for movable buildings (jumping fusion plant?), though.
thx for answering...Tim Blokdijk wrote: @ maestro: I consider you a mod developer, but I also know you are protective of your content. Now you are free to be protective but if you like to do this and have the proposal work (some of) your (future) work needs to be released under an open source license. I'm responding to you here but this is actually more a general remark, I expect that some people have to ponder this requirement.
I dont want to join the proposal, just curious why im not mentioned as modder

mainly coz i dont understand what u talking about


- Tim Blokdijk
- Posts: 1242
- Joined: 29 May 2005, 11:18
Well, I expect that many other modders don't fully understand what my proposal is about but expect that more involvement won't be bad. 
Then again, I to don't know how all the details are going to work out, it will take a little "trial and error" and good communication to sort it out.
Argh is no stranger to trial and error and he has shown he can communicate problems effective without getting bitchy about it.
Once it's clear how things should work it's far easier for others to follow up.
And for me to write a clearer, more specific document.

Then again, I to don't know how all the details are going to work out, it will take a little "trial and error" and good communication to sort it out.
Argh is no stranger to trial and error and he has shown he can communicate problems effective without getting bitchy about it.
Once it's clear how things should work it's far easier for others to follow up.
And for me to write a clearer, more specific document.
- Tim Blokdijk
- Posts: 1242
- Joined: 29 May 2005, 11:18
I think I'm can conclude this topic was useful and that the proposal can be implemented.
Feel free to comment on this further, but I think there is enough consensus for this proposal.
I think Argh should get access to svn and NanoBlobs uploaded.
A WebDav server still needs to be set up so large files will still have to wait for now.
Once that is settled I suggest we start the new sub-forum and give people post access once they can show of some good content.
Feel free to comment on this further, but I think there is enough consensus for this proposal.
I think Argh should get access to svn and NanoBlobs uploaded.
A WebDav server still needs to be set up so large files will still have to wait for now.
Once that is settled I suggest we start the new sub-forum and give people post access once they can show of some good content.
- Tim Blokdijk
- Posts: 1242
- Joined: 29 May 2005, 11:18
-
- Posts: 47
- Joined: 26 Jun 2005, 05:02