Wytter

Greetings, Compile without -Werror and see if it compiles - the signedness are definately not issues, but GCC4 will show them by default. I do not know how much the EL API has changed during the past 6 months, but perhaps it will compile (doubt it). If it does, it should be usable, but needs some more work.

I like your poem Minion. I also prefer expressing myself through poetry when I experience strong feelings - I hope it helps you to find yourself again. Keep walking down the road called life.

You need to get the Cal3D development libraries (version 0.10.0). What operating system are you using?

Dream Theater and Symphony X.

The map-editor is currently unmaintained (it's been discontinued). You should try compiling map_editor2; although not completely done, it is functional. You could however try removing those defines...

Hmm, yes - we could have an event queue for that. That way it can be send in a different thread, hence networking delays will not have an effect on the renderer.

No, that was for the elc implementation of the network. If someone comes and wants to just replace the networking part (either with a single-player engine or make it use a different network protocol etc.), that can easily be done by just rewriting the network if the gui only calls high-level network functions, hence all changes that are done in the gui will still be done in his part, as he only replaced the networking. It will lead to a lot less maintaining, and more development.

Yes, that's what it says Radu The reason why I want i.e. load in a different directory is that we might want to later on create external tools that don't use the renderer but just loads the files. They can still use the code that are in the load directory but don't have to depend on the core renderer. The cal3d actors could also be put in an additional sub-directory of the renderer, since we could have support for several formats in the engine. As for the configuration, the game-specific configuration options and functions should be in the game's own directory. However the higher level functions for i.e. adding a configuration, parsing the configuration files etc. is a part of the engine. The functions in gui should call high-level network functions that set the protocol and then use a send_tcp_message(Uint8 type, Uint8 * data, Uint32 data_length), where the lower-level function handles the package structure. This way the lower-level function could for instance pack messages together, choose not to have a length parameter on some functions with fixed lengths (hence saving bandwidth), etc. (Will be a lot easier to maintain like this) Only the high level network functions should call the low-level network function. Example (pseudo code): gui: struct recipe_struct { Uint8 pos; Uint16 qty; } manu_recipe; int mix_clicked() { mix_items(manu_recipe); return 1; } high-level network: int mix_items(recipe_struct * recipe) { char data[MAX_RECIPE*(sizeof(Uint8)+sizeof(Uint16))]; int i; for(i=0;i<MAX_RECIPE;i++){ data[i*sizeof(recipe_struct)]=recipe[i].pos; Write_Uint16(&data[i*sizeof(recipe_struct)+sizeof(Uint8)],recipe[i].qty); } send_tcp_data(MIX, data, sizeof(data)); } low-level network: int send_tcp_data(Uint8 type, Uint8 * data, Uint32 size) { char out_data[MAX_OUT_DATA]; Uint16 out_size = size+sizeof(Uint8)+sizeof(Uint16);//type (Uint8) + length (Uint16) + data length (size) out_data[0]=type; Write_Uint16(out_data+1, out_size); memcpy(out_data, data, size); return SDL_send(out_data, out_size);//Yea whatever, I don't recall the name of the func;-) } I believe that in the core renderer, all debugging functions should follow an assert-like pattern: int add_character(actor *act) { if(actor_is_null(act == NULL)) return; ... } static __inline__ int actor_is_null(int true) { if(true){ #ifdef DEBUG log_error("Tried to add a NULL actor"); #endif return 1; } return 0; } These debugging functions would then be put in a .h, so they can be more easily maintained and not pollute the renderer with tons of #ifdef DEBUG's.

Defines to be applied (remove the #else): WIDGETS_FIX NETWORK_THREAD GLUT Defines to be removed: STRONG_SIT_LOCK SERVER_DROP_ALL ENCYCLOPEDIA ELCONFIG - elconfig is obsolete now To be replaced by run-time loading of library (if available). If we don't want to distribute the png dll, just try loading it on run-time - if it fails, disable the screenshot ability, otherwise enable it. PNG_SCREENSHOT WINDOWS can be replaced by _WIN32 BUG_FIX_3D_OBJECTS_MIN_MAX - is a bug fix for 3D objects bounding box - there's a bug with the current e3d objects and currently it is necissary. Work has been done onto a new e3d format, and when all files are converted into this, it will be removed.

Forwarding a message from Xaphier: cvs up If you get more crashes, please post the error_log.txt as well as the backtrace - it will contain some information about the bbox tree that he can use for debugging.

Gravito: I have already proven that it is possible to share a lot of the base code in map_editor2, this is just taking it to the next step. ttl: I think that i.e. the queue should be a part of the core functions. Could be in a tools directory, but not sure how necissary that should be... As for init... I follow you, but thing is that I don't want code duplication, and the functions for setting up GL are needed in any of the games based on ELC, while the init functions for each game will be slightly different (loading an ini-file different than el.ini etc.) Entropy: Yes, I have been thinking about that as well. Simply creating a new module for the core engine containing the core and load directories, and then have a network, init and gui directory in the elc module would work fine, and probably cause less confusion. The code will not really be changed, and especially not in that way; they will become a bit more generic though, such as functions for reading el.ini would have to be called with the name of the el.ini you wish to read (that can be "el.ini", "mapedit.ini" etc.) and in functions for creating the window would get the window name, window icon specified. I have a week off uni in late january, during that week I can put most of the ideas into place. However, it should not happen at the same time as the update since there may be introduced some new bugs. So we'll have to coordinate that.

Greetings, I have given some thought into the modularization of elc that we have talked about before. I think that it would be wise to modularize ELC in order to reduce code duplication between different parts of EL (and even different forks). In order to do this I decided to split up elc into 5 main components: core, gui, init, load and network. The code in core and load will easily be shared between different forks/parts of elc, while gui, init and network are implementation dependant. By dividing the elc into these different components, we will make sure that all clients/the map editor based on elc benifits from the improvements done to the core renderer and loading engine, hence encouraging more cooperation between the different elc forks. elc core Contains the core renderer Contains the window manager Contains the widgets - the single widgets will be in an additional directory, with one file per widget Contains the core sound engine Contains the timers for updating the scenery (animations etc.) Contains a main thread checking the update queue, containing data from the network thread (or map editor or single-player engine) Contains the functions for initiating OpenGL, creating the windows etc. [*]gui Contains the different windows for the client. Contains the HUD Contains the command callbacks (both #command and hotkeys), which will manipulate states in the core or call commands found in network. [*]init Initiates the client - calls the functions for loading configuration files etc. All functions for GL initiation are in core Contains the command list for the client Contains the configuration init (add_var()...) for the client [*]load Map loading/saving. Contains the different versions of the map formats for each of EL's forks Object loading/(saving - for i.e. particles) Texture loading Configuration/saved data file loading Language file loading Music/sound loading [*]network Contains the functions for network interaction: Recieving and pre-processing (before displaying) and sending. The package reciever will run in a seperate thread like in the current thread implementation. The reciever would parse the network data, and then send a pointer to the parsed data to the renderer through a queue. This way we could easily remove the network and replace it with a single-player engine. [*]map_editor2 init Initiates the map_editor. Calls the functions from elc/core for initiating GL. Contains the command list for the map_editor Contains the configuration init (add_var()...) for the map_editor [*]gui Contains the windows used in the map_editor Contains the HUD for the map editor Contains the command callbacks (both #command and hotkeys), which will manipulate states in the core/call functions in load. [*]Imaginary single-player EL init Can possibly use most of the functions from elc/init, but also needs to initiate the single-player engine, script loader etc. [*]gui Additional GUI files + commands + hotkeys for the single-player game [*]engine Works sort of like the network in the client, interacting with the core through a queue structure. Contains support for the scripting language of choice Please give me some comments on this structure.

lmao

Plus we would not be able to dynamically add new items (Unless an update mechanism is implemented, and this has some other issues).

First of all, I don't think it's wise to compile with experimental features like NEW_FRUSTUM. I'd do a compile using: -DWINDOWS -DELC -DLOAD_XML -DOPTIONS_I18N -DPNG_SCREENSHOT And possibly -DNEW_ACTOR_ANIMATION, but only if it is working as intended...