Current CVS errors

[ttlanhil]

I don't know what's going on with your build, because it should default to using "./" (ie current directory) as datadir if not otherwise specified...

Might be able to help more if you actually post the message or where in the code it comes from (this is the important part).

 

It's actually bad design to require everything to be in the same place.

Using a different datadir on Windows is possible, but every needed .dll has to either be in the search path or the same dir as the executable. So it's not really that practical for most users.

 

ed: Oh, and CK, unless EL is provided by your distro (or perhaps you provide your own distro, as in LFS), you should probably be installing stuff into /usr/local/bin and /usr/local/share or /usr/local/games or similar (depending on setup). Not that it's a big problem, of course, unless something else wants to call its exe 'el'

Edited July 2, 2007 by ttlanhil

[crusadingknight]

ed: Oh, and CK, unless EL is provided by your distro (or perhaps you provide your own distro, as in LFS), you should probably be installing stuff into /usr/local/bin and /usr/local/share or /usr/local/games or similar (depending on setup). Not that it's a big problem, of course, unless something else wants to call its exe 'el'

Not to disrupt the thread, but Archlinux doesn't have a /usr/local, since all of /usr is assumed to be local. Plus, I install everything through the PKGBUILD (somewhat like a simplified ports system), so I'll know if anything tries to install over the executable. The default Archlinux PKGBUILD for EL actually includes a 'patch' to el.ini (either a sed script, or a modified file, can't remember which) to change the data_dir to /usr/share/eternal-lands.

 

Since we are on/around the topic of global.h anyway, has anyone looked into possibly reducing the amount included by default in it, like Vegar started on a while ago? Especially now, where my local installation of OpenAL doesn't cooperate with g++ 4.2.0, and I can't disentangle it since it's included through global.h (Not exactly the best example, since updating to revision 3 of the package fixed it, but you can see the problem). It also tends to be annoying as every source file is dependent on every header, which results in a make clean sometimes when something completely unrelated changes (recompiling the hud to deal with sound changes, anyone?). At my current estimation, there are about 85 headers local to elc alone included through global.h...

Edited July 2, 2007 by crusadingknight

[kibora]

I've been having the same problem as Beaverhunter for the last week or so. When i somehow walk around the errors and build el, it starts and auto exits before the login screen. But i get nothing in the error log (I deleted error_log.txt and it doesn't recreate)

[Grum]

Since we are on/around the topic of global.h anyway, has anyone looked into possibly reducing the amount included by default in it, like Vegar started on a while ago?

I'm slowly removing #includes of global.h in header files as they lead to the kind of problems you describe. I only do that when I run into compile problems, though, so not much of an organized effort. ttl has some plans for taking all the platform dependent stuff out of global.h and moving it into a separate file.

 

At this point I'd like to climb on my soapbox and stress that people should not include global.h in other header files since that very quickly leads to circular dependencies of header files (a.h includes global.h, global.h includes b.h which requires a.h, and any include of just a.h won't work anymore). If you think there's a definite advatage of using global.h in your .c(pp) files, go ahead, but please, not in the headers.

[kibora]

Ok, i managed to compile elc in debug mode so the problem occurs at fp=open_file_data("e3dlist.txt","r"); in init.c.

 

The locbuffer variable in open_file_data_updates function has the following value:

C:\Documents and Settings\Admin.ASD\Application Data/elc/updates_1_4_0_0e3dlist.txt

 

And since such file does not exist, SDL_Quit() is called.

[Grum]

I've added the missing path separator in open_file_data_updates(), but I'm still unsure why it would give up. If it can't find updates, it should fall back to the default data path, I think.

 

ttl, some minor nitpicks:

• I think judicious use of safe_snprintf could save a lot of lines in elpathwrapper.
  
• Since you're using a fixed size buffer in get_path_config() anyway, and I don't suppose you'll overwrite the string anyway, it could return a const char* to a local static buffer, so ppl don't have to remember to free it after use.
  

Edited July 2, 2007 by Grum

[Beaverhunter]

I have read something about it elsewhere on the forum but well what is it really good for to have a data dir? Why would anyone have eternallands.exe in another directory? Lazyness of some sort?

So that you don't have to be in the directory to execute it? Not all operating systems stick the executable into a folder along with the data - *nix systems generally put them in /bin or /usr/bin, where the executable can be called from anywhere (much like System32 on a windows machine).

Here, I'd run 'el', which is located in /usr/bin, while my data is actually located in /usr/share/eternallands . On windows, I could theoretically have something like this as well.

 

Well why seriously would you ever want to do that? Maybe with Linux you guys are used to having all in black and white and consoles all over the place.... in Windows there is a thing called Shortcuts, I have a folder on my desktop basicly called Games and from there I can access everything I need.

And if Linux works like that it seems to suck quite badly, there are good reasons to why you shouldn't put everything in one folder. But well I guess its up to you to use Linux or not, I'm not at least.

 

Kibora:

As I said I only encountered the problem at first then I checked error log and it said something about cannot find some sound in usr/bin or something so I opened el.ini, went for #data_dir and put in my path to EL folder. So for me this now works without any exits at login or alike, I haven't done anything but harvesting lately though so I cannot speak for if the CVS version is bugfree in the other departments and with the new features.

But at least I know the shaders ain't working (see previous posts), but I can live without that for now.

[Grum]

So that you don't have to be in the directory to execute it? Not all operating systems stick the executable into a folder along with the data - *nix systems generally put them in /bin or /usr/bin, where the executable can be called from anywhere (much like System32 on a windows machine).

Here, I'd run 'el', which is located in /usr/bin, while my data is actually located in /usr/share/eternallands . On windows, I could theoretically have something like this as well.

 

Well why seriously would you ever want to do that? Maybe with Linux you guys are used to having all in black and white and consoles all over the place.... in Windows there is a thing called Shortcuts, I have a folder on my desktop basicly called Games and from there I can access everything I need.

And if Linux works like that it seems to suck quite badly, there are good reasons to why you shouldn't put everything in one folder. But well I guess its up to you to use Linux or not, I'm not at least.

Thanks for a well-informed rant. There are actually some good reasons for the Unix file system layout, such as being able to share libraries between programs, programs between machines, etc. If you really want to know the rational for the current "standard" Linux file hierarchy (which I doubt), then I suggest you read http://www.pathname.com/fhs/pub/fhs-2.3.html .

 

Now for a more direct advantage: the setup that ck describes allows me to have several different development trees sharing the same program data. Yes, that can all also be realised using links, but this is a lot more convenient.

[ttlanhil]

I've added the missing path separator in open_file_data_updates(), but I'm still unsure why it would give up. If it can't find updates, it should fall back to the default data path, I think.

Yes, it should.

I think judicious use of safe_snprintf could save a lot of lines in elpathwrapper.

Yes, I'll replace the code. Originally I wanted the code I wrote to be as generic as possible, it didn't even #include anything beyond a few system headers. But now it #include's global.h in order for errors.h to work properly so it can log_error() *groan*

Since you're using a fixed size buffer in get_path_config() anyway, and I don't suppose you'll overwrite the string anyway, it could return a const char* to a local static buffer, so ppl don't have to remember to free it after use.

Good point, I'll make the changes

<clueless garbage snipped>

Okay, let me put it this way. Unix design worked decades ago, and it has worked *well* probably since before you were born. Windows still has not caught up in the important areas... Multiuser support? Pfft, still not working well. Security? Maybe with Vista, except that they want you to do the equivalent of sudo (yes, it's an idea from Unix from many years ago, what was the quote? "Anyone who doesn't understand Unix is doomed to reinvent it, poorly"? Roughly correct and true) any time you want to do anything, it's not cleanly done like in Unix.

 

Now. Until you have a PhD in computer science or are a recognised OS developer, how about you don't spout off about Window's broken design (and the inflexible design that requires you to put things together is broken. Oh, and shortcuts? No, windows doesn't have them. Unix file systems do, done properly; but in windows those are _executable_files_ . Yes, that's right, your shortcuts are designed to be virus friendly. You can't even tell windows to show extensions and assume it's safe, because shortcut and one other executable type (.pif, I think, which is program settings) as set up to hide the extension, even when you tell windows to show them. You have to edit the registry to not have "my_photo.jpg.pif" show up as "my_photo.jpg")?

 

If you want to speak any more on the issue, get yourself a blog.

Because I assure you, making such outrageously wrong and potentially offensive comments like you have about things you don't know will further decrease your standing amongst the developers (and others), and possibly lose your posting rights if you continue to offtopic in areas like programming.

 

Done? Done.

Now lets stick to actually improving the way EL works.

[Torg]

Well why seriously would you ever want to do that? Maybe with Linux you guys are used to having all in black and white and consoles all over the place.... in Windows there is a thing called Shortcuts

LOL!!! That is the most n00b comment I have ever seen!

 

As one of the client developers, I compile my clients under both Linux and Windows for testing.

I can be working on 3 or 4 things at once, say NEW_SOUND, MINES and maybe a bug fix or 2. Because of this, I have several different directories which contain the different changes to parts of the client, depending on what I am working on.

 

This is so that I don't confuse different versions of the files, and *most importantly*, that I don't confuse source files with data files. For this reason, my client needs to reside in a different directory to the data directory.

 

When I compile a client under Windows, I have to manually rename (so I don't overwrite another test client) and copy that client to the data dir. Personally, its not a big deal, but it would be that little bit easier (which is what Linux provides) if I could just compile whichever client I'm working on and run it without the extra steps. Having this option means that I *can* have a list of shortcuts that I just click on once finished compiling.

[Beaverhunter]

Win vs Linux:

Yes we shouldn't discuss this here I guess but in very short my point is/was:

Windows does everything you need and can do even more, and 95-99% of the world uses it and likes having working programs and games in front of overdriven security. I have no problems with any security issues and I use the comp ALOT, that's good enough for me, end of topic.

 

EL path:

Torg: It was meant to be abit of a joke but at the same time it's true, the everyday windows user doesn't need anything else but a few shortcuts on the desktop, while linux users seems to need a 1500page manual in their knee to come up with every command needed for the features that differs from what windows allready has.

 

And well if it shares settings, will it also share the port setting? If so that would mean I cannot have one folder with test server stuff and one with real server stuff, which I have now (or before at least), working flawlessly.

 

But well I guess there are bigger issues to take care of, but I'm abit suprised to see that features barely needed (in my opinion) are being prioritized for the first time now (don't mean to be offending about this but there are several times in the past I'm refering to (but no I won't give you those examples, you should know that it's true)).

 

But well keep up the good work. I'll post if I get any compile errors, sorry for going abit offtopic.

Edited July 2, 2007 by Beaverhunter

[Torg]

And well if it shares settings, will it also share the port setting? If so that would mean I cannot have one folder with test server stuff and one with real server stuff, which I have now (or before at least), working flawlessly.

Actually, that already exists. If you edit some of those hidden, scary advanced settings that even Windows provides (do you have your 1500 page manual, and 3000 page bug workarounds list ready?), you can change the options for your lovely shortcuts and add a command-line option (wow, scary idea) to specify the port.

 

(Just teasing you... have a look around the forums for info on command-line options for the client)

 

But well I guess there are bigger issues to take care of, but I'm abit suprised to see that features barely needed (in my opinion) are being prioritized for the first time now (don't mean to be offending about this but there are several times in the past I'm refering to (but no I won't give you those examples, you should know that it's true)).

I do actually take offence at this. You are talking about a bunch of people who are giving up their time to work on something because they consider it *fun*.

 

If we decide we don't want to think to hard and tackle a complex problem that might have a higher priority for you, then too damn bad. Things in the client get done when someone wants to do it. Without being paid, that's just the way things are. If Ent considers something a priority then he pays for someone to do it. If you consider something a priority and it isn't getting worked on, maybe you should consider providing someone with some incentive to work on it.

 

Please remember we are volunteers here, and hence we have no obligations to do anything, except what we want to do.

[Florian]

Typo in CVS:

temlates instead of templates

[kibora]

Hmm yes changing the path worked. Thanks

[Florian]

Typo in CVS:

temlates instead of templates

 

io/memorybuffer.hpp:

#ifndef USE_TR1

#include "../temlates/el_shared_ptr.hpp" <--- !!! templates

#else

#include <tr1/memory>

#endif

[kibora]

Found a bug when passing argv and argc from WinMain to main (for windows that is). Currently it doesn't pass anything. It should be changed to:

 

int APIENTRY WinMain (HINSTANCE hInst, HINSTANCE hPrev, LPSTR lpCmd, int nShow)

{

char **argv= NULL;

int argc;

 

win_command_line= GetCommandLine();

argc = makeargv(win_command_line, " \t\n", &argv);

...

 

And btw bbox_tree.h still need uint32_t, uint16_t and uint8_t typedefed.

[Grum]

I've fixed the templates typo and the WinMain arguments. I've left the uint types in bbox_tree for now, until we decide what to do with them.

 

Replace them by SDL's Uint types, perhaps?

[Florian]

I've fixed the templates typo ...

No you didn't:

 

cvs up

...

cvs server: Updating io

P io/memorybuffer.hpp

...

cvs server: Updating shader/data/shader

cvs server: Updating temlates <--- !!!

 

[Torg]

#include "../temlates/el_shared_ptr.hpp" <--- !!! templates

Actually, if you look closely, it is correct because the directory he made in CVS is '/cvsroot/elc/elc/temlates'. I'm guessing the whole lot needs to be fixed. :-S

[Florian]

#include "../temlates/el_shared_ptr.hpp" <--- !!! templates

Actually, if you look closely, it is correct because the directory he made in CVS is '/cvsroot/elc/elc/temlates'. I'm guessing the whole lot needs to be fixed. :-S

Exactly that's what I mean. I first noticed the typo in the dir (7 post up), then I noticed the typo in the .hpp file.

[Grum]

Argh, crap.

 

At times like this I really miss a "cvs mv" command. Well, there wasn't much history for the template anyway, so I removed the temlates directory, and readded it as templates.

[kibora]

So bbox_tree.h has been fixed.

 

But now zipfilesystem.cpp needs uint32_t and uint16_t defined/replaced as well and SDL_SwapLE32 defined. The second could be done by adding #include "SDL_endian.h" on top

 

Edit: Oh and one more thing related to NEW_SOUND. When initializing an array in MSVC (actor_scripts.c) {0} should be used instead of {}. That's on lines 103 and 1955

Edited July 3, 2007 by kibora

[Torg]

Edit: Oh and one more thing related to NEW_SOUND. When initializing an array in MSVC (actor_scripts.c) {0} should be used instead of {}. That's on lines 103 and 1955

Thanks, those should now be fixed. One thing however, it was line 103 of cal.c. ;-)

[Beaverhunter]

Oki, not many new errors lately but these showed up some day ago:

 

1>Compiling...

1>elpawn.c

1>.\pawn\elpawn.c(305) : error C2065: 'EVENT_PAWN_TIMER' : undeclared identifier

1>amxel.c

1>.\pawn\amxel.c(110) : error C2065: 'M_PI' : undeclared identifier

 

Am I missing some file or how can this have passed through your compilers? Is doesn't look like the general MSVS thing?

Edited July 10, 2007 by Beaverhunter

[Grum]

First issue: those files should only be compiled when PAWN is enabled in the configuration options. Not compiling them will also get rid of the second issue, but...

Second issue: hmm...does MSVC not declare M_PI? damn...will add an ifdef for it.

 

I should probably also add guards in all files in the Pawn directory. Sigh...oh well, here we go, another intelligent commit coming up.

 

EDIT: should be fixed now.

Edited July 10, 2007 by Grum