Wytter

GCC lets you declare functions as inline in .c-files but they can only be used as inline functions in that file. If you call it from other files it will not be inlined, hence all inlines should be in .h-files. In this case, just remove the __inline__ and make it a normal func.

Doesn't have to be a widget - how many times will we need to use a text editor widget? Just needs to work...

Doesn't matter, it's an error hence it should be corrected. Thanks for pointing it out. Can anyone fix it if it hasn't been already?

1: No 2: Would be good 3: I do not think this would be necissary 4: See below 5: See below We are currently redefining the map format. I think that we should add music and/or sound effects to that map format, so it wouldn't require client/server interaction + we'd be able to make environmental sound (sound like the sound is coming from i.e. the upper right corner of the screen). This would require setting the sound source + a radius of which sound volume would be 100% and another which will make the the sound volume would go from 100 to 0%, and then of course the wanted sound, the initial sound volume from that object etc.

OK, I don't have much time these days, but I managed to go through the list of patches today and came up with these interesting patches that we should consider whether we should include or not (and decide soon). Should the local el.ini have higher preference than the one in ~/.elc/? https://developer.berlios.de/patch/index.ph...2&group_id=1256 How should channel names be handled? https://developer.berlios.de/patch/index.ph...5&group_id=1256 Should the custom clothing be accepted? https://developer.berlios.de/patch/index.ph...7&group_id=1256 Is this working? https://developer.berlios.de/patch/index.ph...3&group_id=1256 If this is going to be accepted it should be rewritten to not stand out as a patch like the current one does - has to look like we intended to do this from the start ;-) https://developer.berlios.de/patch/index.ph...5&group_id=1256 This might be a bit difficult to use since moving items from high to low in the items win could change the quickbar a lot - and that might not be what we want... https://developer.berlios.de/patch/index.ph...4&group_id=1256 Personally I still prefer the old quickbar where you manually put items in the quickbar... Is this working and should we use it? https://developer.berlios.de/patch/index.ph...4&group_id=1256 Huh? https://developer.berlios.de/patch/index.ph...6&group_id=1256 Should we have an #lc all? If so, it should be server based... (obsoletes #608) Should we have this url list? https://developer.berlios.de/patch/index.ph...9&group_id=1256 Should all logs have timestamps? https://developer.berlios.de/patch/index.ph...0&group_id=1256 Is the depth checking working as it should in all windows? https://developer.berlios.de/patch/index.ph...8&group_id=1256

0x00002aaaabc60b94 in memcpy () from /lib/tls/libc.so.6 (gdb) backtrace full #0 0x00002aaaabc60b94 in memcpy () from /lib/tls/libc.so.6 No symbol table info available. #1 0x000000000041b754 in update_bbox_tree (thread_args=0x4064fb0) at bbox_tree.c:1247 bbox_tree = (BBOX_TREE *) 0x161bdd0 new_bbox_items = (BBOX_ITEMS *) 0x38a0c60 new_bbox_tree = {root_node = 0x2aaaaaac05e8, items_count = 2863341894, items = 0x0, nodes_count = 0, nodes = 0x2, cur_intersect_type = 0, intersect = {{intersect_update_needed = 0, size = 0, count = 0, start = {0, 2866228458, 10922, 2866224128, 10922, 2866216616, 10922, 30, 0, 2908627192, 10922, 2908627696, 10922, 1082130592, 0, 2864469416, 10922, 145909, 0, 2863359471, 10922, 0, 0}, stop = {2908627696, 10922, 2863400424, 10922, 2863341894, 10922, 0, 0, 2863341566, 157882997, 2908618754, 10922, 2863342401, 10922, 0, 0, 1, 0, 2866228458, 10922, 2866224128, 10922, 2866216616}, items = 0x1e}, {intersect_update_needed = 2908627192, size = 10922, count = 2908627696, start = {10922, 1082130752, 0, 2864461472, 10922, 204894516, 0, 2864486727, 10922, 167118052, 0, 2863401264, 10922, 1082130816, 0, 1082130752, 0, 0, 0, 204894516, 0, 2908627696, 10922}, stop = {2863342401, 10922, 2908627696, 10922, 1, 10922, 0, 0, 1, 0, 0, 0, 1, 0, 2866222832, 10922, 0, 1, 2863401264, 10922, 1082130856, 0, 2863400424}, items = 0x2aaaaabc9947}, {intersect_update_needed = 2863400424, size = 10922, count = 2864486162, start = {10922, 2865892224, 10922, 2863353988, 10922, 1, 10922, 0, 0, 2863400424, 10922, 2866222832, 10922, 10, 0, 2863353650, 10922, 0, 0, 0, 0, 0, 0}, stop = {1082130812, 0, 2866219136, 10922, 2863401624, 10922, 2864470760, 10922, 2865885968, 10922, 23182800, 0, 4306660, 0, 23183536, 0, 4096, 0, 1082132832, 0, 2863353988, 10922, 1}, items = 0x0}}, bbox_tree_mutex = 0x1, update_condition = 0x2aaaaad70880, update_data = {bbox_tree_degeneration = 23103792, size = 0, index = 2863353650, list = 0x40800960}, done = 0, thread_id = 0x2} update_data = {bbox_tree_degeneration = 0, size = 0, index = 2863359471, list = 0x0} i = 0 index = 0 type = 627168 #2 0x00002aaaaac0f889 in SDL_RunThread () from /usr/lib/libSDL-1.2.so.0 No symbol table info available. #3 0x00002aaaaac0fa51 in SDL_KillThread () from /usr/lib/libSDL-1.2.so.0 No symbol table info available. #4 0x00002aaaaad750fa in start_thread () from /lib/tls/libpthread.so.0

Yes, I compiled with FRUSTUM_THREADS.

In 1.0.2 trading will change slightly, i.e. to make quantities 32-bit instead of 16 bit, and to reduce the chance of scamming. When you want to trade with a player it will be the normal procedure: str[0]=TRADE_WITH; *((Uint16*)(str+1)) = 5; *((Uint32*)(str+3)) = player_id; This will cause the other player to get the same trade request string as with 1.0.1. str[0]=127+c_yellow2; *((Uint16*)(str+1))=length; str+3="<player_name> wants to trade with you. Use the trade icon then click on him/her in order to accept the trade."; With multi-channel chat it will be sent to CHAT_SERVER. Once both parties have accepted the server will send GET_YOUR_TRADEOBJECTS in order to make sure that the items are in sync: str[0]=GET_YOUR_TRADEOBJECTS; *((Uint16*)(str+1)) = length; *((Uint8*)(str+3)) = no_items; ptr=str+4; for(i=0;i<no_items;i++){ *((Uint8*)(ptr+i*8+6))=pos;//The position in the items list *((Uint16*)(ptr+i*8)) = item_list[pos].image_id; *((Uint32*)(ptr+i*8+2)) = item_list[pos].quantity; *((Uint8*)(ptr+i*8+7)) = item_list[pos].flags; } If you are near a storage, the server will also send the storage categories (see http://www.eternal-lands.com/forum/index.php?showtopic=16313 for more info): *((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); } If you've previously opened a category it'll send you the items in that category as well: *((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); } } Next you will recieve the name of the trade partner. This has changed slightly, since the server will actually tell you whether you have storage available or not (a bit redundant): str[0]=GET_TRADE_PARTNER_NAME; *((Uint16*)(str+1))=length; *((Uint8*)(str+3))=storage_available;//0 for FALSE, 1 for TRUE ((Uint8 *) str+4)="<trade partner name>";//Terminated by \0 Once this is in place, the trade session can begin. You add an item to trade using this: str[0]=PUT_OBJECT_ON_TRADE; *((Uint16*)(str+1))=7 *((Uint8*)(str+3))=ITEM_INVENTORY || ITEM_BANK; //Depending on whether you're adding an item from your bank or from your inventory. *((Uint8*)(str+4))=pos;//The position in either your inventory or your bank *((Uint32*)(str+5))=quantity; Adding an object to the trade will either remove it from your inventory or storage or just reduce the quantity. If the quantity is 0 after adding the item, it will be completely removed from your inventory: str[0]=REMOVE_ITEM_FROM_INVENTORY; *((Uint16*)(str+1))=2; *((Uint8*)(str+3))=pos; If the quantity is >0 after adding the item the inventory item will be updated str[0]=GET_NEW_INVENTORY_ITEM; *((Uint16*)(str+1))=9; *((Uint16*)(str+3))=image_id; *((Uint32*)(str+5))=quantity; *((Uint8*)(str+9))=pos; *((Uint8*)(str+10))=flags; If it's a storage item and you are in the same category as the item, the following will be sent: str[0]=STORAGE_ITEMS; *((Uint16*)(str+1))=10; *((Uint8*)(str+3))=255;//Indicates an update *((Uint8*)(str+4))=category; *((Uint16*)(str+5))=image_id; *((Uint32*)(str+7))=quantity; *((Uint8*)(str+11))=pos; To remove a tradeobject do the following: str[0]=REMOVE_ITEM_FROM_TRADE; *((Uint16*)(str+1))=6; *((Uint8*)(str+3))=pos; *((Uint32*)(str+4))=quantity; This will add an item to the inventory or storage: str[0]=GET_NEW_INVENTORY_ITEM; *((Uint16*)(str+1))=9; *((Uint16*)(str+3))=image_id; *((Uint32*)(str+5))=quantity; *((Uint8*)(str+9))=pos; *((Uint8*)(str+10))=flags; The storage item will only be sent if you are in that category. str[0]=STORAGE_ITEMS; *((Uint16*)(str+1))=10; *((Uint8*)(str+3))=255;//Indicates an update *((Uint8*)(str+4))=category; *((Uint16*)(str+5))=image_id; *((Uint32*)(str+7))=quantity; *((Uint8*)(str+11))=pos; If you want to see the item string for that given object, do the following: #define YOUR_TRADE_LIST 0 #define OTHERS_TRADE_LIST 1 str[0]=LOOK_AT_TRADE_ITEM; *((Uint16*)(str+1))=length; *((Uint8*)(str+3))=pos; *((Uint8*)(str+4))=YOUR_TRADE_LIST || OTHERS_TRADE_LIST;//Whether you want to see the item from your or the others trade list. Whenever a trade object is added the following will be sent to the client: str[0]=GET_TRADE_OBJECT; *((Uint16*)(str+1))=10; *((Uint16*)(str+3))=image_id; *((Uint32*)(str+5))=quantity; *((Uint8*)(str+9))=type; *((Uint8*)(str+10))=pos; *((Uint8*)(str+11))=YOUR_TRADE_LIST || OTHERS_TRADE_LIST; If an object is removed the following will be sent: str[0]=REMOVE_TRADE_OBJECT; *((Uint16*)(str+1))=7; *((Uint32*)(str+3))=quantity; *((Uint8*)(str+7))=pos; *((Uint8*)(str+8))=YOUR_TRADE_LIST || OTHERS_TRADE_LIST; To accept the trade, send the following to the server: str[0]=ACCEPT_TRADE; *((Uint16*)(str+1))=1; If you have already accepted the trade once, you have to send the targets for all of the items as well: #define ITEM_INVENTORY 1 #define ITEM_BANK 2 str[0]=ACCEPT_TRADE; *((Uint16*)(str+1))=17; for(i=0;i<16;i++){ *((Uint8*)(str+3+i))=ITEM_INVENTORY || ITEM_BANK; } Whenever a trade accept is recieved by the server it will send the following to the clients: str[0]=GET_TRADE_ACCEPT; *((Uint16*)(str+1))=2; *((Uint8*)(str+3))=YOUR_TRADE_LIST || OTHERS_TRADE_LIST;//Whether it's you or your trade partner that has accepted. In 1.0.2 the accept works slightly different than in 1.0.1. As soon as both parties have pressed ACCEPT_TRADE, the trade session will be locked - this means that nothing will be put on trade or removed from the trade - this will give you time to evaluate all items and see that they are correct. Once you've evaluated the trade session and accepted it you can send another ACCEPT_TRADE, then wait for your trade partner to do the same - once this is done you will get your new items: str[0]=GET_YOUR_ITEMS; *((Uint16*)(str+1)) = length; *((Uint8*)(str+3)) = no_items; ptr=str+4; for(i=0;i<no_items;i++){ *((Uint8*)(ptr+i*8+6))=pos;//The position in the items list *((Uint16*)(ptr+i*8)) = item_list[pos].image_id; *((Uint32*)(ptr+i*8+2)) = item_list[pos].quantity; *((Uint8*)(ptr+i*8+7)) = item_list[pos].flags; } And the last storage category you opened will be resend: *((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 wish to reject the trade, send the following to the server: str[0]=REJECT_TRADE; *((Uint16*)(str+1))=1; Whenever the server recieves a REJECT_TRADE it will send the following to the clients: str[0]=GET_TRADE_REJECT; *((Uint16*)(str+1))=2; *((Uint8*)(str+3))=YOUR_TRADE_LIST || OTHERS_TRADE_LIST;//Whether it's you or your trade partner that has rejected. Once rejecting your trade partner will also automatically reject the trade in order to reduce scamming. When the trade has ended you'll recieve: str[0]=GET_TRADE_EXIT; *((Uint16*)(str+1))=1; Hope this will help you.

Back in the days I remember planning guild bots that were working as quest bots as well - was a way to implement our quests without having a server dev spend his time on it. It's definately possible and I don't think it's a bad idea - guild quests can be fun, but would of course cause less problems for the guild members if bots were handling the event instead of real people

We do not plan to send the unique item id.

Happens with Intel i845G integrated graphics on my notebook with Xorg's drivers as well. It's a driver error.

? 214084[/snapback] No. Which version of cal3d do you have installed?

OK, Xaphier and I have discussed the problem more indepth and decided to go with adding a new queue for object changes. This way we solve the problem with the timer thread deleting particles and we avoid a lot of problems with add/removes in the new frustum system. Plus it's a much simpler approach so it should be a lot easier to get it working. From queue.h: typedef struct node { void *data; struct node *next; /* Pointer to the next node */ } node_t; The data will in this case be: typedef struct { Uint8 type; //OBJ_2D_ADD, OBJ_2D_REMOVE, OBJ_3D_ADD, OBJ_3D_REMOVE, OBJ_LIGHT_ADD, OBJ_LIGHT_REMOVE, OBJ_PART_ADD, OBJ_PART_REMOVE Uint16 offset;//The offset in obj_2d_list[], objects_list[], lights_list[], particle_list[] } object_change; We'll have a global array: #define MAX_OBJECT_CHANGES 3000 object_change object_changes[MAX_OBJECT_CHANGES]; int object_change_offset; And then when doing the queue_push it will add the data of &object_changes[object_change_offset]; and next increase object_change_offset. We also need a function that can read the current queue without popping it.

To create an overview of the problem: Renderer thread needs read/write access to the particles - it will add particles when asked by the server Timer thread needs read/write access to the particles - it will change and delete particles We could solve the problem by moving the deletion of particles to the renderer thread...

ls -lh ~/Games/el/animations ~/Games/el/meshes ~/Games/el/skeletons It really makes no sense that it doesnt find the skeletons...

Yes, you have to use cal3d-0.10.0

Does anyone have the time to look this patch over? If you do, fix those 3 warnings and check if it's indeed stable enough for going into CVS - if it is, feel free to commit it. I like the looks of the patch but sadly I cannot test it myself from here.

Yumm, I have to try that recipe! *Ohh Tanyia, I have a particle accelerator you can try*

ATI OpenGL driver trouble again Zep. *Cough* nVIDIA *Cough*

Nope, I said _both_ <spell id="34"> <name>Fire storm</name> <ingredient id="12" quantity="1"/> <ingredient id="15" quantity="3"/> <ingredient id="11" quantity="2"/> </spell> Where the name would just be overwritten if there's a file in languages describing that id... All it'd take would be to have the IDs of spells to be constant.

Yep Zep. I like the patch... Haven't been able to try it but I will by the end of the week. However we plan to add a widgets directory where each widget will have it's own file so don't worry about elwidgets.[ch] - the current widgets.c is simply too large. (Same goes for hud.c)

Well, if the gnomes don't want to be eaten they have to come up with better alternatives...

I am fairly sure that this is not EL related, but a driver or xorg CVS issue.

Actually we can do both... Just have the ID in the spell file and we can easily put up an array with replacable strings and still have it written in the spell file (but as a note to what it is rather than the exact name as it will be seen ingame)

Could just put it in languages/ - if it's not found in the $LANG it will just use the english...