Wytter

Hey all, Due to programming concerns we had to change the map.def format a little. This will affect you and your map making, but hopefully it'll also make it easier for you to write and read .def files. The new .def format uses start and ending tags like the following: [general] allow_combat: 0 allow_rain: 1 map_name: `Snow Isla Prima` [/general] This is the entire list of options you can put in the different tags. It also includes the new area attributes. For many of the cases, 1 means Yes, 0 means No (as usual), so assume that's the case unless I specify differently. [general] map_name: <The name of the map> #If you just want the default attribute you don't have to write it here... allow_rain: <If it's going to rain on the map or not - default: 1> allow_combat: <Is it a PK map? Default: 0> allow_multicombat: <Allow multi-combat? Default: 0> allow_beam: <Max level allowed to beam from this map Default: 0 (means every player can beam)> allow_tport: <Is teleporting allowed on this map? Default: 1> allow_harvesting: <Is harvesting allowed? Default: 1> allow_manufacturing: <Is manufacturing allowed? Default: 1> allow_summoning: <Is summoning allowed? Default: 1> allow_spellcasting: <Can you use magic on this map? Default: 1> allow_potions: <Can you do potions on this map? Default: 1> timed_heat: <Heat damage per minute - between 0 and 100 - Default: 0> timed_cold: <Cold damage per minute - between 0 and 100 - Default: 0> timed_poison: <Poison damage per minute - between 0 and 100 - Default: 0> timed_corrosion: <Corrosion damage per minute - between 0 and 100 - Default: 0> timed_damage: <Damage per minute - between 0 and 100 - Default: 0> timed_radiation: <Damage per minute - between 0 and 100 - Default: 0> walk_heat: <Per step heat damage - between 0 and 100 - Default: 0> walk_cold: <Per step cold damage - between 0 and 100 - Default: 0> walk_poison: <Per step poison damage - between 0 and 100 - Default: 0> walk_corrosion: <Per step corrosion damage - between 0 and 100 - Default: 0> [/general] The teleport point is activated when you step on it - for instance when stepping on a teleporter [teleport_point] teleport_src_x: <The x coordinate the player needs to step on> teleport_src_y: <The y coordinate the player needs to step on> teleport_dst_x: <The x coordinate where you want the player to be send> teleport_dst_y: <The y coordinate where you want the player to be send> teleport_map: <The map where the player will be teleported to> type: <Is it going to sparkle when you teleport? Default: 0> [/teleport_point] The interdiction area creates a square where you have to specify the coordinates of the corners: y | y2 _____ | | | | | | y1 |_____| | |______________ x x1 x2 The above coordinate system is the same for every other area-based definition, so remember it :) The interdiction is being out-fased, so use the [attributes] instead - it's just here to reference how the .def files for the older maps are going to be rewritten. [interdiction_area] min_x: <The smallest x coordinate (X1)> min_y: <The smallest y coordinate (Y1)> max_x: <The largest x coordinate (X2)> max_y: <The largest y coordinate (Y2)> can_manufacture: <Is it possible to manufacture here?> [/interdiction_area] [text_area] min_x: <The smallest x coordinate (X1)> min_y: <The smallest y coordinate (Y1)> max_x: <The largest x coordinate (X2)> max_y: <The largest y coordinate (Y2)> call_small: <If it's going to call small - used for quests and other things (if you want a special effect such as a character suddenly showing up or something), but it's really nothing you should worry about as map makers, so just leave it out and speak with us if you want to use it> text: <The text that's going to appear on the players screen - max 250 characters> [/text_area] This is used to specify a special text that's going to be seen when the player clicks on the item with the eye icon. [object_name] object_id: <The object ID> object_name: <The text that'll appear - max 49 characters> [/object_name] This is used when you want to give an area a special name - it's the text appearing when you click on the compass. [location_info] min_x: <The smallest x coordinate (X1)> min_y: <The smallest y coordinate (Y1)> max_x: <The largest x coordinate (X2)> max_y: <The largest y coordinate (Y2)> text: <The name of the location> [/location_info] The use area is used to specify a special action that's going to happen when you click on an item. You can only click on the item from within the specified area. [use_area] min_x: <The smallest x coordinate (X1)> min_y: <The smallest y coordinate (Y1)> max_x: <The largest x coordinate (X2)> max_y: <The largest y coordinate (Y2)> teleport_x: <The x location the player is going to be teleported to on click - if he isn't going to be teleported, just leave this out> teleport_y: <The y location the player is going to be teleported to on click - if he isn't going to be teleported, just leave this out> teleport_map: <The map the player is going to be teleported to on click - if he isn't going to be teleported, just leave this out.> map_object_id: <The ID of the object the player has to click> inv_object_id: <The ID of an object the player clicks on the map object with> send_sparks: <Specifies if the teleport is going to send sparks when it's activated> too_far_text: <The text that's shown when you're too far away> wrong_object_text: <The text that's going to be shown when the use_area is activated, but the player uses the wrong object> use_text: <The text that's going to be shown when the item is used> open_book: <The book ID that's going to be opened when the use area is activated - you cannot teleport a person and have a book opened at the same time (the book will close if the player moves outside the area, so..)> [/use_area] [sound_area] min_x: <The smallest x coordinate (X1)> min_y: <The smallest y coordinate (Y1)> max_x: <The largest x coordinate (X2)> max_y: <The largest y coordinate (Y2)> min_minute: <The min minute the song will play> max_minute: <The max minute the song will play> min_hour: <The min hour the song will play> max_hour: <The max hour the song will play> positional: <If it's positional> radius: <The radius, where it's possible to hear the song> frequency: <The frequency - how many seconds that should go between trying to send the song to the different players - if 0, it will be random> chance: <The chance the for song to play - between 0 and 1000 - used when frequency is 0> loops: <The number of loops the song is going to play for> sound_name: <The filename of the sound> [/sound_area] For the attributes the syntax is a bit different, as it's a newer addition. The following tags are available: (<tag name> - <Description>) allow_combat - Is it a PK area? Default: 0 allow_multicombat - Allow multi-combat? Default: 0 allow_beam - Max level allowed to beam from this area. Default: 0 (means every player can beam) allow_tport - Is teleporting allowed on this map? Default: 1 allow_harvesting - Is harvesting allowed? Default: 1 allow_manufacturing - Is manufacturing allowed? Default: 1 allow_summoning - Is summoning allowed? Default: 1 allow_spellcasting - Can you use magic on this map? Default: 1 allow_potions - Can you do potions on this map? Default: 1 timed_heat - Heat damage per minute - between 0 and 100 - Default: 0 timed_cold - Cold damage per minute - between 0 and 100 - Default: 0 timed_poison - Poison damage per minute - between 0 and 100 - Default: 0 timed_corrosion - Corrosion damage per minute - between 0 and 100 - Default: 0 timed_damage - Damage per minute - between 0 and 100 - Default: 0 walk_heat - Per step heat damage - between 0 and 100 - Default: 0 walk_cold - Per step cold damage - between 0 and 100 - Default: 0 walk_poison - Per step poison damage - between 0 and 100 - Default: 0 walk_corrosion - Per step corrosion damage - between 0 and 100 - Default: 0 [attributes] [<tag name>] min_x: <The smallest x coordinate (X1)> min_y: <The smallest y coordinate (Y1)> max_x: <The largest x coordinate (X2)> max_y: <The largest y coordinate (Y2)> value: The value of the attribute text: The text that's going to be shown when the attribute is activated [/<tag name>] [/attributes] Example: [attributes] [allow_multicombat] min_x: 22 min_y: 44 max_x: 33 max_y: 55 value: 1 text: You enter a multicombat zone [/allow_multicombat] [allow_harvesting] min_x: 3 min_y: 4 max_x: 33 max_y: 44 value: 0 text: What? Trying to pick flowers from graves? You sick smeg! [/allow_harvesting] [rain_start_chance] min_x: 22 min_y: 4 max_x: 32 max_y: 14 value: 100 text: It's raining, as always... [/rain_start_chance] [/attributes] Here's an example - I rewrote the Isla Prima .def-file : [general] allow_combat: 0 allow_rain: 1 map_name: `Snow Isla Prima` [/general] ship "banner2" [use_area] min_x: 12 min_y: 18 max_x: 29 max_y: 29 teleport_x: -1 teleport_y: -1 teleport_map: -1 map_object_id: 441 inv_object_id: -1 send_sparks: 0 too_far_text: `You are too far away` use_text: `You've opened a secret scroll!` wrong_object_text: `Nothing happens.` open_book: 2 The above uses the new feature that lets the client open a book window on click. [/use_area] Text object"sign-to docks" [use_area] min_x: 28 min_y: 57 max_x: 36 max_y: 69 teleport_x: -1 teleport_y: -1 teleport_map: -1 map_object_id: 525 inv_object_id: -1 send_sparks: 0 too_far_text: `You can't read the sign from THAT far away!` use_text: `South- to the Docks` wrong_object_text: `Nothing happens.` [/use_area] [location_info] min_x: 11 min_y: 15 max_x: 36 max_y: 39 text: `- The docks` [/location_info] [location_info] min_x: 123 min_y: 96 max_x: 163 max_y: 163 text: `- The Woods` [/location_info] [location_info] min_x: 157 min_y: 33 max_x: 180 max_y: 67 text: `- A Sandy Beach` [/location_info] [location_info] min_x: 139 min_y: 70 max_x: 141 max_y: 84 text: `- A Bridge Over Nice Water` [/location_info] [text_area] min_x: 152 min_y: 114 max_x: 152 max_y: 116 text: `Get off my bones you stupid 3D model!` [/text_area] [text_area] min_x: 147 min_y: 127 max_x: 149 max_y: 130 text: `Have you no respect for the dead!?` [/text_area] Locked house "house3" [use_area] min_x: 81 min_y: 118 max_x: 81 max_y: 120 teleport_x: -1 teleport_y: -1 teleport_map: -1 map_object_id: 187 inv_object_id: -1 send_sparks: 0 too_far_text: `You are too far away from the door` use_text: `The door is locked` wrong_object_text: `Nothing happens.` [/use_area] "Tavern" [use_area] min_x: 63 max_x: 68 min_y: 132 max_y: 135 teleport_x: 20 teleport_y: 12 teleport_map: 2 map_object_id: 71 inv_object_id: -1 send_sparks: 0 too_far_text: `You are too far away from the door` use_text: `Welcome to Pula's Tavern` wrong_object_text: `Nothing happens.` [/use_area] "House5" [use_area] min_x: 89 min_y: 102 max_x: 91 max_y: 109 teleport_x: 53 teleport_y: 48 teleport_map: 2 map_object_id: 96 inv_object_id: -1 send_sparks: 0 too_far_text: `You are too far away from the door` use_text: `` wrong_object_text: `Nothing happens.` [/use_area] "House4" [use_area] min_x: 94 min_y: 161 max_x: 103 max_y: 163 teleport_x: 57 teleport_y: 13 teleport_map: 2 map_object_id: 72 inv_object_id: -1 send_sparks: 0 too_far_text: `You are too far away from the door` use_text: `` wrong_object_text: `Nothing happens.` [/use_area] "House2" [use_area] min_x: 72 min_y: 148 max_x: 76 max_y: 150 teleport_x: 17 teleport_y: 54 teleport_map: 2 map_object_id: 63 inv_object_id: -1 send_sparks: 0 too_far_text: `You are too far away from the door` use_text: `` wrong_object_text: `Nothing happens.` [/use_area] "white tower door" [use_area] min_x: 117 min_y: 151 max_x: 123 max_y: 156 teleport_x: 19 teleport_y: 66 teleport_map: 32 map_object_id: 797 inv_object_id: -1 send_sparks: 0 too_far_text: `You are too far away from the door` use_text: `` wrong_object_text: `Nothing happens.` [/use_area] boat north->south [teleport_point] teleport_src_x: 177 teleport_src_y: 141 teleport_dst_x: 78 teleport_dst_y: 57 type: 0 teleport_map: 0 [/teleport_point] boat south->north [teleport_point] teleport_src_x: 80 teleport_src_y: 58 teleport_dst_x: 176 teleport_dst_y: 139 type: 0 teleport_map: 0 [/teleport_point] secret room (map6nf_cave) [teleport_point] teleport_src_x: 166 teleport_src_y: 73 teleport_dst_x: 62 teleport_dst_y: 38 type: 0 teleport_map: 17 [/teleport_point] "newbie cave" [use_area] min_x: 35 min_y: 67 max_x: 42 max_y: 74 teleport_x: 60 teleport_y: 138 teleport_map: 43 map_object_id: 1348 inv_object_id: -1 send_sparks: 0 too_far_text: `Go into the cave, then click the rock above you again to enter the cave` use_text: `` wrong_object_text: `Nothing happens.` [/use_area] Making a needed level of attack to enter a map(please do not use this without asking Roja first!!) [general] allow_combat: 1 allow_rain: 1 allow_multicombat: 1 allow_beam: 0 min_level: 30 map_name: `Kilaran Field` [/general] A new summon area that decreases mana needed to summon: [attributes] [bonus_summoning_area] min_x: 90 min_y: 130 max_x: 100 max_y: 150 value: 1 [/bonus_summoning_area] [/attributes] USE WITH ID list: The first number here: http://el.other-life.com/downloads/item_info.txt

Hey all, This note on debugging methods is primarially targetted at GNU/Linux and *BSD users but should also work for Windows users who use a Cygwin environment (if you don't know what it is, this doesn't apply to you at all). The pre-requirements for helping debugging the EL client is: *) The latest CVS client - If you run into an error, try doing a new checkout and see if the problem persists. If it's still there, it will most likely be a bug and if you are not able to see a bug report describing the error you're experiencing on these forums, you should report it. *) The GCC compiler or similiar capable of compiling with debugging flags. - For GCC you only need to add the -ggdb keyword to the compiler flags. The default target in the Makefile.linux and Makefile.bsd already use these keywords. *) The GDB (The GNU Project Debugger) or similiar - http://www.gnu.org/software/gdb/gdb.html If you run into an error and you're willing to help us more than just reporting the bug, you can help us fix it by using a debugger and learning some simple commands. This small crashcourse should be able to give you the info you need to debug the EL client and give us sufficient information to find the source of the error. Keywords: Debugging: Debugging is the concept of finding and resolving bugs/crashes etc. Backtrace: Through a backtrace we can obtain information of what happened before the crash. Through this, we can see what happened prior to the crash and where the crash happened. Step 1: Compile the client with the default flags: make clean make -f Makefile.linux Step 2: Open the client in the GDB debugger: gdb el.x86.linux.bin Here's how the console should be looking: bjorn@darkhelmet elc $ gdb el.x86.linux.bin GNU gdb 6.2.1 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) Step 3: Let's run the beast. To run the client, you just need to write "run". If you wish to run the game with some command line arguments, you should put these after "run". (gdb) run <arguments> You should see the following window: Starting program: /home/bjorn/elsrc/dev/elc/el.x86.linux.bin warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. [Thread debugging using libthread_db enabled] [New Thread 182915818272 (LWP 2867)] [New Thread 1082128736 (LWP 2870)] [New Thread 1090517344 (LWP 2871)] [Thread 1090517344 (zombie) exited] Step 4: Shit! The client crashed. But where and how? If the client crashes the window will not close, however you will get info that an error has occured. In this case I made a mistake on purpose (tried accessing a NULL-pointer) and caused the client to crash. You'll see something similiar to the following: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 182915818272 (LWP 2867)] 0x000000000043a436 in HandleEvent (event=0x7fbffff2d0) at events.c:46 46 actors_list[200]->x_pos=0; (gdb) Of course the location of the error will not be the same - the main idea is just that you remember to copy the lines "Program recieved signal ..." to (gdb) (the debugger console). Step 5 (Optional): Getting variables values Now, the first thing you'd do to check what could cause this to happen would be trying to get the value of the variable that caused the crash. (gdb) print actors_list[200] $1 = (actor *) 0x0 (gdb) Oh, so we tried accessing a NULL-pointer - that'll explain the error If you do not know how to do this or if this step confuses you due to lack of programming experience, you can jump to the backtrace. Step 6: The backtrace Now, in most cases the error will not be that obvious, and we'd need a backtrace to figure out what happened. To get a backtrace do the following: (gdb) backtrace #0 0x000000000043a436 in HandleEvent (event=0x7fbffff2d0) at events.c:46 #1 0x000000000044de05 in start_rendering () at main.c:48 #2 0x000000000044e106 in main (argc=1, argv=0x7fbffff3f8) at main.c:149 (gdb) It'll simply show the latest function calls, and that can be used to locate the error. ---- There's a more thorough guide here: http://www.delorie.com/gnu/docs/gdb/gdb_toc.html If you want a debugging GUI, I will recommend the DDD debugger: http://www.gnu.org/software/ddd ---- Now, this was a short introduction to debugging. If you have any questions or additions, feel free to post below.

Here's a fix for people who run into the problem with: undefined reference to _imp_xmlFree(); When linking the client. Open $DEVCPP/libxml/xmlexports.h Edit every line that says: #if defined(IN_LIBXML) && !defined(LIBXML_STATIC) And change it to: #if !defined(LIBXML_STATIC) And press recompile all. At least that worked for me.

Hey all, I was wondering if you'd be interested in a different GUI (graphical user interface) for the storage. Personally I'd like a system where the storage opened a window similiar to the inventory window with item pictures instead of the current NPC dialogous - the different items will still be in different categories to make it easier to get an overview. But are you interested in this at all or do you have any different ideas?

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.

Greetings all, After the release of 1.0.2 I will work on adding terrain support to the map editor. This will be a major change and will require many changes in the code - So I figured that I'd just redesign it and bring it up to date with the new HUD, new optimizations and capabilities of the client etc. So I wonder - what do you hate about the current map editor? What should be done better? Do you have any ideas for additions?

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?

Here's how the new storage will work in 1.0.2: All categories in the storage will be defined by one of these: typedef enum { STORAGE_FOOD = 1, STORAGE_COINS, STORAGE_FLOWERS, STORAGE_ORES, STORAGE_METALS, STORAGE_MINERALS, STORAGE_TOOLS, STORAGE_WEAPONS, STORAGE_ARMOR, STORAGE_MAGIC, STORAGE_ESSENCES, STORAGE_POTIONS, STORAGE_ANIMAL, STORAGE_CLOTHES, STORAGE_MISC, STORAGE_JEWELRY, STORAGE_BOOKS, STORAGE_QUEST, STORAGE_END, STORAGE_ALL=0xffffff } client_categories; We may add more later. A storage may not have all storage types. On open you'll recieve the storage categories in pseudo C: *((Uint8*)(str+0)=STORAGE_LIST; *((Uint16*)(str+1)=length; *((Uint8*)(str+3)=no_categories; ptr=str+4; for(i=0;i<length-3;i++){ *((Uint8*)(ptr+0))=category_id; ((Uint8*)(ptr+1))=category_name; //terminated by \0 increase(ptr); } Now, to see what's in a category you have to send: *((Uint8*)(str+0))=GET_STORAGE_CATEGORY; *((Uint16*)(str+1))=2; *((Uint8 *)(str+3))=category; When you receive the category it will be packed like this: *((Uint8*)(str+0))=STORAGE_ITEMS; *((Uint16*)(str+1))=length; *((Uint8*)(str+3))=no_items; if(no_items==255){ //It's just an update containing 1 item for the current category *((Uint8*)((str+4))=category; *((Uint16*)(str+5))=image_id; *((Uint32*)(str+7))=quantity; *((Uint8*)(str+11))=storage_pos;//Position in the server-side storage } else { *((Uint8*)(str+4))=category; ptr=str+5; for(i=0;i<no_items;i++){ *((Uint16*)(ptr))=image_id; *((Uint32*)(ptr+2))=quantity; *((Uint8*)(ptr+6))=storage_pos; increase(ptr); } } If you want to look at a storage item use: *((Uint8*)(str+0))=LOOK_AT_STORAGE_ITEM; *((Uint16*)(str+1))=2; *((Uint8*)(str+3))=storage_pos; Then you'll recieve: *((Uint8*)(str+0))=STORAGE_TEXT; *((Uint16*)(str+1))=length; ((Uint8*)(str+3))=string; To withdraw an item use: *((Uint8*)(str+0))=WITHDRAW_ITEM; *((Uint16*)(str+1))=length; *((Uint8*)(str+3))=storage_pos; *((Uint32*)(str+4))=quantity; You have to be in the same category as the item to withdraw it. To deposite an item use: *((Uint8*)(str+0))=DEPOSITE_ITEM; *((Uint16*)(str+1))=length; *((Uint8*)(str+3))=inventory_pos;//Position in the items_list *((Uint32*)(str+4))=quantity; You have to be in the same category as the item to deposite it.

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

Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 46912541991488 (LWP 19468)] 0x00000000004092ee in draw_3d_objects (object_type=5926) at 3d_objects.c:342 342 cache_use(cache_e3d, objects_list[l]->e3d_data->cache_ptr); (gdb) backtrace full #0 0x00000000004092ee in draw_3d_objects (object_type=5926) at 3d_objects.c:342 start = 100 stop = 101 i = 100 l = 5926 is_selflit = 1 is_transparent = 0 is_ground = 5926 #1 0x000000000040a017 in display_objects () at 3d_objects.c:715 No locals. #2 0x00000000004339fb in display_game_handler (win=0x15f1b60) at gamewin.c:643 main_count = 62 times_FPS_below_3 = 0 next_fps_time = 8083 last_count = 60 fps = {1, 1, 100, 0, 0} fps_average = 20.3999996 shadows_were_disabled = 0 str = "8}P\001", '\0' <repeats 12 times>, "\b\000\000\000\000\000\000\000\0001\026\uffff\uffff*\000\000\000 \000@\000\000\000\000v\231\022\uffff\uffff*\000\000\000 \000@\000\000\000\000\000 \000@\000\000\000\000\001\002\000\000\000\000\000\000\000\000\001\000\000\000\000\000\001\000\000\000\000\000\000\000I\"\023\uffff\uffff*\000\000\000 \000@\000\000\000\000]\025\ubb2a*\000\000\000 \000@\000\000\000\000`\033_\001", '\0' <repeats 28 times>, "]\025\ubb2a*\000\000\000 \000@\000\000\000\000\uffff\uffff\uffff\uffff\000\000\000\000\001\000\000" y_line = 2 i = 74571040 any_reflection = 2 mouse_rate = 74571040 #3 0x0000000000429d5a in draw_window (win=0x15f1b60) at elwindows.c:1032 ret_val = 1 W = (widget_list *) 0x0 #4 0x000000000042a14f in display_window (win_id=22821632) at elwindows.c:1182 No locals. #5 0x0000000000428134 in display_windows (level=1) at elwindows.c:54 id = -1 next_id = -9999 i = 0 #6 0x0000000000424144 in draw_scene () at draw_scene.c:94 No locals. #7 0x000000000044472b in start_rendering () at main.c:123 event = {type = 3 '\003', active = {type = 3 '\003', gain = 0 '\0', state = 0 '\0'}, key = {type = 3 '\003', which = 0 '\0', state = 0 '\0', keysym = {scancode = 62 '>', sym = SDLK_RSHIFT, mod = KMOD_NONE, unicode = 0}}, motion = {type = 3 '\003', which = 0 '\0', state = 0 '\0', x = 62, y = 0, xrel = 303, yrel = 0}, button = {type = 3 '\003', which = 0 '\0', button = 0 '\0', state = 0 '\0', x = 62, y = 0}, jaxis = { type = 3 '\003', which = 0 '\0', axis = 0 '\0', value = 62}, jball = {type = 3 '\003', which = 0 '\0', ball = 0 '\0', xrel = 62, yrel = 0}, jhat = {type = 3 '\003', which = 0 '\0', hat = 0 '\0', value = 0 '\0'}, jbutton = {type = 3 '\003', which = 0 '\0', button = 0 '\0', state = 0 '\0'}, resize = {type = 3 '\003', w = 62, h = 303}, expose = {type = 3 '\003'}, quit = {type = 3 '\003'}, user = {type = 3 '\003', code = 62, data1 = 0x12f, data2 = 0x0}, syswm = {type = 3 '\003', msg = 0x12f}} done = 0 music_thread = (SDL_Thread *) 0x18ff570 #8 0x0000000000444953 in main (argc=22821632, argv=0x15c2200) at main.c:229 No locals. Build options: OPTIONS=-DLINUX -DELC -DPNG_SCREENSHOT -DX86_64 -DNEW_FRUSTUM -DBUG_FIX_3D_OBJECTS_MIN_MAX -DUSE_SHADER #-DUSE_LISPSM

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.

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.

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

Greetings all, Since I'm currently working my way through the 1st round of chemistry exams, so I've gotten a lot of chem in my head... With the risk of seaming like a chem-geek, I propose a change in Alchemy and Potions to include some laboratory work. My idea is that you'd have a small laboratory where you'd go mixing different substances using a new interface. This interface would have pots, glasses and you'd be able to access i.e. vials and other chemicals that are in your bank. Now you'd have to extract substances from different plants, dirt and liquids to use for your potions. For instance, to create a basic salt (NaCl) you'd heat up water, untill there's only a heated substance left - to do this you'd start a fire, put the water in a pot (this would be the normal method for boiling), and then add a fire essence. Once that's extracted, you could create hydrochloric acid by pouring sulfuric acid on the salt. The different acids and bases would be used for extracting substances from i.e. herbs, which would then be used to create potions. When mixing the ingredients used for creating the different potions, you'd get n (i.e. 15) vials filled from each batch to make up for the longer creation time. You'd be able to create recipés with max 6 different ingredients, and only some of the recipés would work - if you put in an item before something else, it might ruin the potion, or make it stronger. If you try making something using a recipé that doesn't exist, the result would be either a failed potion, or you could get lucky and get a very strong/rare potion... Was just a random idea, but think it could be a hell of a lot more fun (and challenging) than clicking "Mix".

2 el_osx.exe 0x0001dd38 change_projection_float + 0x50 (elconfig.c:440) Add this to the beginning of change_projection_float and post the output: printf("%p %p %g %g", var, value, var?*var:0.0f, value?*value:0.0f);

Hmm, I would check the licensing issues before doing a compile with static libraries...