Wind_of_Change

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?

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;

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.)

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?

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.

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.

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...

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);

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?