Installing mod over svn vegastrike?

[safemode]

Is there a howto anywhere on getting say, the latest remake mod or GG mod to be put on top of a locally compiled SVN pull of vegastrike? The only thing i can find are binaries of everything together, or patches to those binaries/previous binaries. There doesn't seem to be a separate source type install of the mod to be done on top of a local vegastrike tree. Any pointers?

[ace123]

it's really simple with a SVN version. Mods are only data changes, and at the moment, they contain full datasets. The packaged versions happen to include compiled executables, but other than that they are exactly the same as any other dataset.

On Winbows, just copy your SVN compiled binary into te "bin" folder and run.

On Linux, just go into the folder for your mod, and instead of running ./vegastrike, type the path to your compiled binary (i.e. ../../vegastrike/vegastrike or /home/myuser/VegaSvn/vegastrike/vegastrike)

The only thing that matters is that the current working directory is in your mod folder/install.

[safemode]

sweet deal, thanks.

[Melonhead]

Is there a howto anywhere on getting say, the latest remake mod or GG mod to be put on top of a locally compiled SVN pull of vegastrike?

Hmm...this sort of implies you're looking at doing some mods to the code? (Or that you take Sourceforge's advice and never just install the executables. )

Did I just hear a new developer? Any ideas on what you want to work on?

[safemode]

I do a lot of C/C++ and perl...not so much python yet...but it seems easy enough to catch onto. I've had my own little gtk+ utilities and i've done some patches to mplayer and bits and pieces to various other linux projects.

My current plan is to figure out why vegastrike SVN doesn't handle parallel builds (make -jN) and to fix it. Currently it fails to compile if you use N > 1, at least on debian unstable here.

I dont want to commit to anything further right now, since i have a lot of job work that takes away my free time, but with any luck i'll get some actual code cleaning underway. I've browsed around some of the files and there seems to be a good amount of work to be done in that area.

I hope to get in a bunch of patches that have to do with readability and simplicity, and little bugs until i get familiar with things.

Readability patches involve keeping the source files under the same code guidelines.. These patches are usually very large and many projects hate them when they've become as big as vegastrike has.

Simplicity patches to me involve changing things like "for(;something;)" into "while (something)". Removing obvious things like "if(something == true)" and making them "if(something)". Other little minor fixes.

The rest i initially want to do is fix some things like "using std::" in header files and fixing includes in general so that things aren't redundent or "missing".

Little stuff for now. I've always been a big fan of WC for almost 12 years and vegastrike has let me bring that to linux. With any luck, it'll let me play people online one day. So i have a vested interest.

[ace123]

That's really strange, because make -j2 works for me... (I'm on Debian unstable).

Make sure that you are using the real Makefile (in the vegastrike root) rather than the fake one in src...

The makefile in src calls the parent makefile manually for each program to be built, and that might be causing "vegastrike" to be built simultaneously with "vegaserver"... which might mean that the common source files are built at the same time3168731687

I haven't tried it, but I have a feeling that makefile will cause two instances of make -j2 to run on the same source tree.

The parent makefile is a properly generated one that uses dependencies on .o files, and therefore make should handle those fine.


Patches are always welcome... one reason that a lot of things go unfixed (and why you see extern's and nastiness) is that people don't like to modify header files unless it's necessary.

I'm going to get multiplayer finalized this summer (it's mostly there, but there are still many small and large things that need to be fixed).

Also, if you come up with a good style guide, feel free to post it in our wiki.

[safemode]

That's really strange, because make -j2 works for me... (I'm on Debian unstable).

Make sure that you are using the real Makefile (in the vegastrike root) rather than the fake one in src...

The makefile in src calls the parent makefile manually for each program to be built, and that might be causing "vegastrike" to be built simultaneously with "vegaserver"... which might mean that the common source files are built at the same time3168731687

I haven't tried it, but I have a feeling that makefile will cause two instances of make -j2 to run on the same source tree.

The parent makefile is a properly generated one that uses dependencies on .o files, and therefore make should handle those fine.


Patches are always welcome... one reason that a lot of things go unfixed (and why you see extern's and nastiness) is that people don't like to modify header files unless it's necessary.

I'm going to get multiplayer finalized this summer (it's mostly there, but there are still many small and large things that need to be fixed).

Also, if you come up with a good style guide, feel free to post it in our wiki.

Sorry. I think i hit a bug late last night with the posix threaded server and i fixed it (gcc hiccup with wait being overloaded). That must have been why the build failed... I also had multiple SDL installations but i've since fixed that. the build seems to be going fine now at -j3

[safemode]

Since the makefile issues are mostly warnings, and not very interesting to me right now. I started looking into the code and I'm seeing something a tad bit ugly that i'm not sure of it's purpose.

The following code is used in many places to traverse the unit linked list. My problem with it is that it seems to re-invent constructs that are easier to use.

UnitCollection::UnitIterator iter = getSubUnits();
Unit * un;
while (NULL!=(un=iter.current())) {
...
iter.advance()
}

It looks like it should be something like this

UnitCollection::UnitIterator iter = getSubUnits();
Unit * un;
if(iter.empty()) return;
for( un=iter.current(); iter.notDone(); un = iter.next() ) {
....
}


There are many places where it seems for loops were purposely avoided for more obfuscated while loops. Even in cases where it seems the for loop was recreated verbatim.

like in collection.cpp
ConstFastIterator it=constFastIterator();
while (it.notDone()) {
if (it.current()==unit)
return true; else
it.advance();
}
return false;


Why is that not

for(ConstFastIterator it=constFastIterator();it.notDone();it.advance()){
if(it.current()==unit)
return true;
}
return false;



Any reason why for loops are hated on besides some weird preference for while loops ? Is there an actual performance difference between the functinos with while loops vs for loops?

[ace123]

Really, I'm not sure why they did it that way... IMO "for" loops are cleaner.

The two methods should expand to the same code...

Sometimes, however, it is easier to initially write a loop in while form when you are not sure of the logic.

A lot of the time, code that was written messy has been left that way because of the "don't fix it if it isn't broken" attitude. Unit Collections, for example, are fairly simple.

In the first example, I don't know how much clearer your version makes it... the if (iter.empty()) is redundant as the for loop condition would fail in that case. Also, some might consider (NULL!=(un=iter.current())) to be more elegant than un=iter.current(); iter.notDone().

Anyway I don't see any reason not to make this code more understandable.

For example:
http://c2.com/cgi/wiki?WhileNotDoneLoop

[safemode]

In the first example, I don't know how much clearer your version makes it... the if (iter.empty()) is redundant as the for loop condition would fail in that case. Also, some might consider (NULL!=(un=iter.current())) to be more elegant than un=iter.current(); iter.notDone().

just reread the code, didn't realize that they always return non-NULL even in an empty situation.

I dont know though, I consider elegance to be very dependent on utilizing the api's you've created as best as possible. If there are better ways to do something like check to make sure we haven't reached the end of our list, then maybe we need to change the api so that there are less redundent functions like iter.NotDone/isDone. When you get to the point where you have no redundant functions and your code is streamlined to use everyting you've created the way it was meant to, that makes the code elegant to me.

[safemode]

Also, before i head off to work i wanted to ask. Is there a reason why we dont use STL's list template to handle the linked list? There doesn't seem to be a reason why we can't ditch all the code related to creating our own linked list for our template Unit class and use STL's which should handle our template class just like any other datatype. Is it just a matter of difficulty of porting the code to use STL or is there another reason we dont want to us

[safemode]

I'm sure this is far offtopic for now but Since it has the attention of at least one major developer i'll continue this last time before starting a new thread.


The more and more I look at the Unit linked list class, the more and more it annoys the bejesus out of me.
I keep thinking to myself, there must be something I'm missing that explains why we just dont use STL's list template and be done with it. There has to be a really good reason why we go through all the trouble of maintaining our own linked list rather than using a much more optimized and fully featured linked list given by STL.

I understand that it's more than a trivial change to move to STL from the current implementation....but that's something I think i'd like to get dirty with. Slowly moving the implementation to STL, and then one by one, removing the layers and fixing the code that uses it to use the new setup. Hopefully start out with something that's completely compatable, but uses STL (it'll add rather than reduce code and it'll be slower) Then if all goes well with that, start removing all the layers of classes that are used to make the linked list and simplify it all with stl's list template. Eventually it should be a great improvement unless i'm missing something.