ET: Legacy

ETJump-Zero · 2012-05-05 08:34:39 UTC

I believe he did answer but the problem is related to copyrights

morsik · 2012-05-05 09:51:18 UTC

That’s why other option is to write our pro mod…

Shownie · 2012-05-05 11:03:17 UTC

Try contact N!trox* about that matter. He was working on compET which has the same goal as your ETLPro!

Radegast · 2012-05-05 15:43:21 UTC

Beta 6 is out. Texture anisotropic filtering was added (more details in the first post), many bugfixes by morsik and Sol, a lot of clean ups by IR4T4 and other changes. Please see the first post for more details. Sol and morsik are now working on the TB support and altered guid checking.

Shownie: I think N!trox* is quite busy with the new Zombie mod (which sounds really cool) Edit: …

You can now also post your questions/feedback/etc. in our new support forum: http://etlegacy.com/projects/etlegacy/boards

Edit: sv_timeout is set way to low in this release. If you plan to host a server, set sv_timeout at least to 120 or 240 seconds otherwise some clients will not be able to connect.

s11 · 2012-05-06 12:42:14 UTC

After i downloaded this file - http://fotoo.pl//out.php/i225769_przechwytywanie.png

Dragonji · 2012-05-06 17:57:55 UTC

I’m wondering why downloaded files aren’t saved in main W:ET directory.

Dushan · 2012-05-07 09:22:56 UTC

You should beck APPDATA folder inside (on Windows, its hidden )

Dragonji · 2012-05-07 14:05:28 UTC

I’ve noticed that already Dushan, but just wanted to ask why they aren’t saved in main W:ET directory as in vanilla ET.

Dushan · 2012-05-07 14:13:17 UTC

By default, new home folder is located in APPDATA

Radegast · 2012-05-07 14:37:34 UTC

Mistake thanks to the fact that I’m not a windows user. It was set like this by default. Dushan already told me about this some time ago, but I forgot. Now we have Sol who uses windows, so I think he will fix it. Our windows release certainly deserves to receive some more work. Thank you for reporting, Dragonji.

I compiled that lib myself from the official source release, so unless our server got hacked I think it is a false alarm. If you are still afraid, download and replace the lib from http://curl.haxx.se/libcurl/. Just for laughs: Eugene Kaspersky, the author of your antivirus said “Mac security is ‘10 years behind Microsoft’”. Funny guy.

iDan · 2012-05-07 14:46:47 UTC

[QUOTE=Radegast;399271]Mistake thanks to the fact that I’m not a windows user. It was set like this by default. Dushan already told me about this some time ago, but I forgot. Now we have Sol who uses windows, so I think he will fix it. Our windows release certainly deserves to receive some more work. Thank you for reporting, Dragonji.

I compiled that lib myself from the official source release, so unless our server got hacked I think it is a false alarm. If you are still afraid, download and replace the lib from http://curl.haxx.se/libcurl/. Just for laughs: Eugene Kaspersky, the author of your antivirus said “Mac security is ‘10 years behind Microsoft’”. Funny guy.[/QUOTE]

Virtual OS ftw :), our releases are the opposite and are aimed at the Windows enviroment, that being said our Mac & Linux compiles are flawless.

morsik · 2012-05-11 23:45:09 UTC

Ok guys. I and Paul worked together hard and we finished Trackbase support.
You can see results on my server: http://et.trackbase.net/index.php?mod=serverinfo&idx=41043

If there are no players - bots have K/D = 0/0, but when someone will connect, there will be correct value. This is limitation of some engine things, but maybe i’ll hack that too later, but this is not that important (-;

As you can see, new thing are classes icons!

Radegast · 2012-05-17 12:59:19 UTC

Paul created a new repository “tools” which contains Visual Studio 2010 project files along with preconfigured ET:L dependencies. So now even Microsoft’s slaves, eh, I meant to say Windows users, can compile ET:L by themselves!

Everyone knows that statistics is fun, so here are some numbers for you: during the first months of development I removed 51427 lines of code, 25296 lines of comments and 19059 blank lines, but that was mostly bundled deps and unused files and functions. The real change came when IR4T4 joined the project and removed 55333 lines of code, 20789 lines of comments and 5886 blank lines - this code was actually used in the form of botlib and single player code that had to be surgically removed from the engine and I hear the server is now much faster because of this removal.

To sum it up, ET:L’s codebase is lighter by 33% than ET-GPL and that’s including the stuff we added to it. Further statistics are at Ohloh.com.

Shownie · 2012-05-17 17:43:07 UTC

It is really great to see this project going so well. I mean over the time we saw new engines like XreaL and OpenWolf this is by far the best if you ask me.

I have one little question though. Jaybird said he rewrote some codes from C to C++. I am not that into those kind of changes or what language is used in ET:L. But does it have any effect if all the code was in C++ only?

Cheers!

morsik · 2012-05-17 18:25:44 UTC

[QUOTE=Shownie;400105]
I have one little question though. Jaybird said he rewrote some codes from C to C++. I am not that into those kind of changes or what language is used in ET:L. But does it have any effect if all the code was in C++ only?
Cheers![/QUOTE]

ET:L is written in C like original Enemy Territory. There is no general difference between C and C++ in speed. There some measurements on the internet about some specific things, but in general both have the same speed.
Also, creating objects (classes etc.) is slower than static allocation (which is now), but static allocation gets more RAM. You must choose: memory or performance (-;

ETJump-Zero · 2012-05-17 23:43:10 UTC

[QUOTE=morsik;400107]ET:L is written in C like original Enemy Territory. There is no general difference between C and C++ in speed. There some measurements on the internet about some specific things, but in general both have the same speed.
Also, creating objects (classes etc.) is slower than static allocation (which is now), but static allocation gets more RAM. You must choose: memory or performance (-;[/QUOTE]

You need to include programmer productivity in there aswell. Also why wouldn’t you be able to allocate memory in C? Afaik it wasn’t a good idea with QVM (atleast I read about it from somewhere, not sure) but since ET doesn’t use it I guess there’s no problem in doing so. Also I don’t think performance (especially compared between C/C++) really matters nowadays. (not talking about faulty code)

It does take quite a lot of time to convert the source to C++ aswell so you need to take that into account aswell. I’d love to see that being done (and the game logic code being public). Did it once (compiled on windows just fine) but GCC just gave me way too many errors that I couldn’t be arsed to finish it

Radegast · 2012-05-17 23:59:13 UTC

You are going to get that in OpenWolf when Dushan releases it. Parts of ET-Xreal were already written in C++, but Dushan said he converted everything from C into C++. Maybe sometime in a very distant future this may be done to ET:Legacy, but definitely not now. I’ve been learning C just for a few months and I looked at C++ as well, but more advanced objective-oriented programming stuff and things like lambda functions are way beyond my abilities.

dutchmeat · 2012-05-18 11:11:28 UTC

Actually converting it to C++ does slow it down since the whole engine is optimised to work in the NON-OOP ‘C rules’.
I’ve had the pleasure of converting ET-GPL to C++ for a study assignment and it’s really terrible. You take a working, optimised engine and create a frankenstein monster out of it. We’ve got it semi-working, it compiles(windows), it even runs but there are still some bugs.
Adding OOP to the mix makes it even worse, and quite unnecessary.
The only reason you should add C++ components is when you want to add features that are already programmed in C++.

If you want to convert IDTech3 to C++, you better start over and create a new engine, or take IDTech4 :).

Shownie · 2012-05-18 12:15:41 UTC

[QUOTE=dutchmeat;400131]Actually converting it to C++ does slow it down since the whole engine is optimised to work in the NON-OOP ‘C rules’.
I’ve had the pleasure of converting ET-GPL to C++ for a study assignment and it’s really terrible. You take a working, optimised engine and create a frankenstein monster out of it. We’ve got it semi-working, it compiles(windows), it even runs but there are still some bugs.
Adding OOP to the mix makes it even worse, and quite unnecessary.
The only reason you should add C++ components is when you want to add features that are already programmed in C++.

If you want to convert IDTech3 to C++, you better start over and create a new engine, or take IDTech4 :).[/QUOTE]

If that is true. I am glad you posted it. But I still wonder what Difference it made for Jaybird in jaymod?

ETJump-Zero · 2012-05-18 12:45:18 UTC

Well I’d just like to be able to compile it with a C++ features. Converting the whole codebase to c++ would be QUITE time consuming. Wasn’t really hoping for the whole thing to be OOP or anything. It is not necessarily the best way to do things anyway. There’s plenty of C++ features that would make developing stuff a lot faster. Sure it would affect performance a bit but we are not really talking about getting 1*10^832th prime number :>

@Dushan, that’s exactly the reason why I’d love to be able to compile it with C++ compiler, C++ features. Also I don’t really care about converting the engine, I’d just like to see the game logic being converted as that’s what I work with.

P.S. creating a new engine like IdTech3 would be very stupid. By the time you finish it there’s IDTech 75.