Wind_of_Change

When looking at elconfig.c I was kind of wondering why there is the need to use queues to store the options. I thought queues were something you could use to push and pop stuff in a thread safe way (for example for messages). Here they are used to store min/max values or options. Is their complexity really needed here? I mean for example you need to initialize them and clean them up in the end. Wouldn't it be easier to use a union like: typedef struct { option_type type; /*!< type of the variable */ char *name; /*!< name of the variable */ int nlen; /*!< length of the \a name */ char *shortname; /*!< shortname of the variable */ int snlen; /*!< length of the \a shortname */ void (*func)(); /*!< routine to execute when this variable is selected. */ void *var; /*!< data for this variable */ union { int len; //For OPT_STRING and OPT_PASSWORD struct { float min; float max; float interval; } f; //For OPT_FLOAT struct { int min; int max; } i; //For OPT_INT and OPT_INT_INI struct { int len; char **options; } m; //For OPT_MULTI and OPT_MULTI_H struct { float (*min)(); float (*max)(); float interval; } f_f; //For OPT_FLOAT_F struct { int (*min)(); int (*max)(); } i_f; //For OPT_INT_F } data; int saved; // char *message; /*!< In case you want a message to be written when a setting is changed */ dichar display; struct { int tab_id; /*!< The tab ID in which we find this option */ int label_id; /*!< The label ID associated with this option */ int widget_id; /*!< Widget ID for things like checkboxes */ } widgets; } var_struct;

EL uses some combination of C and C++. I don't think "monster" is the right word^^ You just need to manage the memory yourself. In the queue approach, pointers for the multi options are put on the queue and poped then to give them to the multi option widget (which makes copies of them). In the function approach the functions will only be called for the creation of the multi option widget. In both cases the allocated strings have to be freed in the end. (for example in cleanup_mem in main.c) Those queues are also misused to store 3 floats... I see the point for the multi_options though. Is the "dichar display" actually intended to use for localization?

Thanks for your answers. I saw these things in the code as well and agree with you that such things should be added dynamically at runtime. Queues do what is wanted hiding some complexity, reallocs for every addition does work but not seem good for those. But how about a new type especially for those dynamic variables needing additional data like: struct { int (*len)(); char* (*str)(int i); }; That is even more dynamic than the queue approach. The corresponding fsaa functions do already exist! (EDIT: Not quite, the functions work a bit different than I expected) Ok, but I was actually thinking about something more radical, when looking at the magnitude of add_var calls. That is having a gigantic constant array instead, for which there is no need to initialise at runtime. (Only the widgets would need to be initialised, but that can happen quite late in the loading of the client.) Since the variables are only used indirectly outside elconfig.c that would involve only (huge) changes in that file. Sure. The FSAA indices may have different meanings if a different set of FSAA modes is supported like after a driver update. But this is not related to using a queue or a fixed lenth array. Of course your right. Wouldn't storing this kind of stuff in form of strings solve this "problem"? (Creating string parsing complications...)

Apart from the multithread stuff. But its hidden in queue.c anyway. In MULTI, too? As far as I see it dynamical feature is only used for the fonts. (Isn't actually the number of fonts artificially restricted by FONTS_ARRAY_SIZE?) But isn't is kind of inappropriate to store only indices for multioptions (which might be variable) in the config file?

Sorry for replying tot this topic with something only slightly relevant to this topic and somewhat cosmetic. For consistency, could we only accept options given in this form? Right now we accept for example: -fps=1 -fps1 -fps 1 Wouldn't it be more consistent only to accept 1.? (The second option makes the command parsing harder/hackier than it should be.)

Hi, when looking at the source the today for the first time, I was wondering why there are different "el.ini" files for each server. Does anyone use this option? I thought that one could alternatively make a global "el.ini" file and add a command line option to use a different configuration file. This would simplify the treatment of the command line arguments in the code (look at the "check_server_id_on_command_line" function in "main.c"). Some additional thoughts: Add an "--help" option, which would display a short help text Make the server name an extra option, which also could be added to "el.ini" Show some info about the game and where to find the error log on each start I will do the changes myself, if they may be implemented.

Here I am again... Removing per server configuration files would simplify the code somewhat. For your legimate reasons to have a per server configuration one could use scripts like: #!/bin/sh ln -f ~/.elc/test/el.ini ~/.elc/el.ini el $@ test If you use more than one client at the time, you should however only change settings in the last client you have started... Alternatively one could add an option to use a different configuration file and change the script to something like: #!/bin/sh el $@ --config=~/.elc/test/el.ini test (Adaptions to other platforms are left as an easy exercise to the reader...) As said before an early server selection window would likely involve several hacks, because nothing is initialized at that time. I would prefer a startup like: Load and initialise stuff Optionally: Show language window Optionally: Show rules window Optionally: Show server selection window Try to connect to server Show login window Then it would be no problem to go back to the server selection to change servers. What do you think?

If I change the resolution in the login screen and go to the character creation screen after that, all the icons are gone (as well as the compass and the clock). This bug is reproducible. I'm using Linux. EDIT: It seems to be an issue with the window system. When creating the icon bar without the ELW_SHOW_LAST attribute it doesn't disappear.

Just something minor: When compiling the client with PNG_SCREENSHOT defined I get deprecation warnings. These small modifications should fix them. diff -u -r1.83 misc.c --- misc.c 12 Jul 2010 20:28:25 -0000 1.83 +++ misc.c 29 Dec 2010 15:43:16 -0000 @@ -311,7 +311,7 @@ } /* Set error handling. */ - if (setjmp(png_ptr->jmpbuf)) + if (setjmp(png_jmpbuf(png_ptr))) { /* If we get here, we had a problem reading the file */ IMG_SetError("Error writing the PNG file"); @@ -360,8 +360,8 @@ if (row_pointers != NULL) free (row_pointers); - if (info_ptr != NULL && info_ptr->palette != NULL) - free (info_ptr->palette); + if (info_ptr != NULL) + png_free_data(png_ptr, info_ptr, PNG_FREE_ALL, -1); png_destroy_write_struct (&png_ptr, (png_infopp)NULL);

Out of curiosity: "Dynamic map loading" means that the maps will be dynamically loaded as walk around in them? But the concept of game maps (instead of a huge world map) will stay?

Could you maybe update "new_character.c" so that it works with both "NEW_TEXTURES" and "NEW_NEW_CHAR_WINDOW"? (This means little changes at about line 1720 to 1900)

Found something more specific: On every resolution change init_hud_interface will be called, in order to resize the hud-elements. That function again calls init_newchar_icons which will create the icon window before the new char windows was created. So later the new char window (which contains that horizontal bar in the bottom) will be drawn over the icon window and hide it.

The hide_window function hides all child windows, but the destroy_window function doesn't destroy all child windows. Interesting... BTW: Could you move the code which resizes the new window from switch_video() in elconfig.c to resize_all_root_windows() in interface.c. That seems to be the right place for it.

I also don't think that there is actually anything to free, but according to the libpng manual png_free_data does do the job and in the case that there is nothing to free it will do nothing. But I'm no expert in this subject as well...

Thanks for committing the changes. I'm sorry for having caused you these inconveniences and of course the changes to the #defs don't bother me. There was already some code for displaying the console text in the window, but it was only displayed if windowed_chat is 0. I thought that this behavior wasn't deliberate... Usually there shouldn't be any text in the console anyway. Why is actually not the complete new_char_root_window hidden when logging in with the new char? I falsely assumed that...

Uploaded a new patch. The warnings should hopefully be gone now. Put the error strings concerning name and password beneath the corresponding controls. Made bluap's help texts be drawn in two lines if necessary. Currently two strings are used. One each for appearance and UN/PW. In my lack of inspiration they are however still the old strings. Do you have any suggestions for them?

Thanks for testing! Removing the alpha border is a matter of 1 second. I'll edit the lines causing warnings if I find them... You are right about the messages at lower resolutions. (At least they don't hide anything:) The problem of making the messages be displayed in two lines is that I know no function that displays multilined text adjusted centrally. Doing that yourself is not that easy because you have to takeinto account the special characters for the colored text. So the help/error texts are problematic... Some thoughts: Put the messages concerning name and password into a box under the controls. Use console messages for the other error messages? Remove the messages at the bottom completely and give the buttons mouseover texts instead?

Updated patch. Maybe someone can try it out?

This seems more natural then it is right now. Maybe that's already intuitive enough. Some other question: Should those buttons be displayed at the same position for appearance and UN/PW? Right now they aren't. If so, should they be placed at the bottom or a bit beneath the other controls?

Uploaded a new patch. It was not that easy to use the original code so I started from the old patch. This is why the error strings are not displayed in a box but at the bottom. Right now there is a "Done" button for the appearance window and a "Done" and a "Back" button for the account window. The first "Done" button moves you to the account window, with the second "Done" button you can create your character and the "Back" button moves you back to the login window. I think that there should also be a button to get from the account window back to the appearance window, but then there would be two "Back" buttons in that window. Maybe put an icon somewhere for the back to login screen button?

That seems to be a very easy solution. I think that this can be done with very little modification to the old code. But before I start just some questions for clarification: Should a title like "Choose your name and password" be displayed on the top? How many Buttons with what captions are actually needed? It would be easiest to have the error messages back in the box. Is that desirable? The window should be behind the icons bar so that the text in that bar is visible?

Then obviously everything fits. It is one of the advice messages bluap created and it's basically the only one which would make sense after the change to the new character creation screen. For the other string (which is displayed when pressing the done button for the first time) there is however a Spanish translation which is even longer. For all resolutions but 640x480 and 800x480 one might put the error strings back into a box as they were before.

It nearly fits on 800x600 or 800x480. Some characters are hidden, but it should still be understandable, e.g. "en ready, click "Done" to create your character and enter the gam" or "ck done again to create a character with that name and appearanc". However, the stings might be longer in other languages. Still looking for a nice color for the background...

Back to the text at the bottom: I tried to make it two lines. Right now it might look like (ignore the colors) |Click done again to create a character | |with that name and appearance. | Notice that the text in the second line is not centered. What color (RGB) would you actually like for the background? Should it have some alpha? What about the "To zoom in/out..." text at the bottom?

Two pictures for illustration: The window does hide some text, but you can make it move to the right. For example by moving your mouse out of the window or clicking a button or something like that. Just a thought...