0ctane Report post Posted May 29, 2007 How severe are the OSX problems? Is the game playable or not? Because if it is, we might have to release it anyway, and have a patch for OSX later on.. As mentioned by Florian, the bugs all seem to be related to shadowing. Shadow mapping causes severe problems. Regular shadows are messed up since the switch to NEW_E3D_FORMAT, but the game can (sadly) still be played by turning them off too. These are not deal-breakers. They just suck monkey nuts, especially since shadows had just started working for PowerPC users. Sorry guys. Share this post Link to post Share on other sites
Entropy Report post Posted May 29, 2007 Well, there will be time to look into it after the update and release a patch. Too bad not many of us have an OSX system.. Share this post Link to post Share on other sites
KarenRei Report post Posted May 29, 2007 (edited) Not bad defaults. Defaults designed for a system with a faster CPU than yours. You can't lower the max below the minimum. There's also, if I remember, the fact that someone had briefly hard coded a range for max and min that weren't realistic, which I reverted to the proper range. The real min/max should be from 0/1 to maxint-1/maxint. Particle pecentage: if it's not on the eye candy tab, it's not part of eye candy. Edited May 29, 2007 by KarenRei Share this post Link to post Share on other sites
Sayre Report post Posted May 29, 2007 (edited) About the slowdown at pv sto and other places. My hardware is not what I would call uber, but neither is is particularly slouchy (AMD 1.5ghz cpu and 256M nvidia 7600GS vid card, 1gb 400 ram. ) The slowdown has never bothered me terribly (I cap fps at 30 and it slows down to around 18ish fps at that place) but I piped up when I found that others were having similar issues there. S. Edit: Learner: yep run in perspective mode, but the fps is still borked even when looking from as above as possible and zoomed right in. Dunno if that changes anything. Also happens no matter which way I am facing there (North,south,whatever) Edited May 29, 2007 by Spleenfeeder Share this post Link to post Share on other sites
Entropy Report post Posted May 29, 2007 So the particle percent thingy is for when the eyecandy is off? Share this post Link to post Share on other sites
Florian Report post Posted May 29, 2007 How severe are the OSX problems? Is the game playable or not? Because if it is, we might have to release it anyway, and have a patch for OSX later on.. As mentioned by Florian, the bugs all seem to be related to shadowing. Shadow mapping causes severe problems. Regular shadows are messed up since the switch to NEW_E3D_FORMAT, but the game can (sadly) still be played by turning them off too. These are not deal-breakers. They just suck monkey nuts, especially since shadows had just started working for PowerPC users. Sorry guys. That's how bad shadows are: - shadows depend on viewpoint, not on lightsource click and click - objects sticking out of the ground have weird shadows click Share this post Link to post Share on other sites
Entropy Report post Posted May 29, 2007 @Florian Those stencil shadows that we are using are, and always were obsolete. There were allways problems with them, which is the reason why we want to remove them altogether. After this update, we'll have to do some more work and see what is the problem with the shadow maps for OSX. Maybe we should contact Apple about it, since if they crash the whole computer it is their fault, not ours. Share this post Link to post Share on other sites
KarenRei Report post Posted May 29, 2007 I don't know what particle percentage is; it's not mine. I guess it's part of the old system. Share this post Link to post Share on other sites
bluap Report post Posted May 29, 2007 (edited) I'm getting a client freeze (of sorts). Latest CVS on Linux, Nvidia graphics, latest RC data files. I say sort of freeze as the client does not respond or redraw the main window but it is still running, just stuck in a loop. The freeze is 100% repeatable, my location "You are in 'The Wyrmgoth Underground' [180,33]" The client starts OK, but when I spin the camera round, it always freezes, facing nearly east. I think this is a similar problem to one I reported about a year ago, that time sitting in PL storage. At the time no-one else could reproduce the problem. And it only occurred if I had my perspective set really high. This time perspective is set to its normal 0.45. I'll go check if the old problem still occurs with this client and dig out the forum thread too... I've traced the problem to the loop in main.c (line 100) that handles SDL events. The code never breaks out of the loop: // handle SDL events while( SDL_PollEvent( &event ) ) { done = HandleEvent(&event); } I've added some crude debug: SDL_Event event; Uint8 lasttype = 0; int eventcounter = 0; printf("in SDL_PollEvent()\n"); // handle SDL events while( SDL_PollEvent( &event ) ) { if (event.type != lasttype) { printf("HandleEvent type=%d old counter=%d\n", event.type, eventcounter); lasttype = event.type; eventcounter = 0; } else { eventcounter++; if (eventcounter>100) { printf("HandleEvent 100 of type=%d\n", event.type); eventcounter = 0; } } done = HandleEvent(&event); } printf("out SDL_PollEvent() counter=%d\n",eventcounter ); He is the output: .... in SDL_PollEvent() HandleEvent type=24 old counter=0 HandleEvent type=4 old counter=2 HandleEvent type=24 old counter=0 HandleEvent type=4 old counter=3 out SDL_PollEvent() counter=6 in SDL_PollEvent() HandleEvent type=24 old counter=0 HandleEvent type=4 old counter=11 HandleEvent type=24 old counter=10 HandleEvent type=4 old counter=8 HandleEvent type=24 old counter=8 HandleEvent type=4 old counter=9 HandleEvent type=24 old counter=9 HandleEvent type=4 old counter=10 HandleEvent type=24 old counter=9 HandleEvent type=4 old counter=6 HandleEvent type=24 old counter=1 HandleEvent type=6 old counter=9 HandleEvent type=24 old counter=0 HandleEvent type=4 old counter=36 HandleEvent type=24 old counter=3 HandleEvent type=4 old counter=8 HandleEvent type=24 old counter=9 HandleEvent type=4 old counter=9 HandleEvent type=24 old counter=10 HandleEvent type=4 old counter=8 HandleEvent type=24 old counter=9 HandleEvent type=4 old counter=8 HandleEvent type=24 old counter=0 HandleEvent 100 of type=24 HandleEvent type=1 old counter=64 HandleEvent type=24 old counter=0 HandleEvent type=1 old counter=18 HandleEvent type=24 old counter=0 HandleEvent 100 of type=24 HandleEvent 100 of type=24 HandleEvent 100 of type=24 HandleEvent 100 of type=24 HandleEvent 100 of type=24 HandleEvent 100 of type=24 HandleEvent 100 of type=24 HandleEvent 100 of type=24 HandleEvent 100 of type=24 HandleEvent 100 of type=24 HandleEvent 100 of type=24 HandleEvent type=4 old counter=82 HandleEvent type=24 old counter=0 HandleEvent 100 of type=24 HandleEvent 100 of type=24 [1] Killed ./el.x86.linux.bin -sp 2001 If I de-focus the window, I get none type 24 events for a bit, like here when I killed the client. edit: This is the old bug report. The client no longer freezes in PL storage for me. This could be because I can no longer see the particles on the distance - the detail culling code cutting in may be? edit2: If I set perspective to 0.40, the client does not freeze but CPU usage jumps from near zero to ~100% at the camera angle that previously locked the client (at perspective 0.45). Edited May 29, 2007 by bluap Share this post Link to post Share on other sites
Entropy Report post Posted May 29, 2007 If the code doesn't break out of that loop, it's either a problem with SDL, or a problem with your particular system. Share this post Link to post Share on other sites
bluap Report post Posted May 30, 2007 If the code doesn't break out of that loop, it's either a problem with SDL, or a problem with your particular system. Great Anyway, if I disable the call to update_fire_sys() in particles.c then I'm fine. Also if I cap the maximum number of new particles (hacking the code rather than in config), then I'm fine. While looking at the code I also noticed a some nested calls to LOCK_PARTICLES_LIST() and UNLOCK_PARTICLES_LIST() - which appear to result in the releasing of the mutex before intended. I tried playing around with this but to no effect. May be it just means the outer calls are redundant. I'd have to study the code some more. If this problem is limited only to me then I guess I'll just have to be careful. Share this post Link to post Share on other sites
Entropy Report post Posted May 30, 2007 Well, no one else reported it.. Besides, the game is not currently designed for very big views. Share this post Link to post Share on other sites
Torg Report post Posted May 30, 2007 This problem could be related to this thread. Share this post Link to post Share on other sites
Entropy Report post Posted May 30, 2007 That was old, many things changed since then. But I'd be interested in hearing about others having a similar problem. Share this post Link to post Share on other sites
Alia Report post Posted May 30, 2007 If the code doesn't break out of that loop, it's either a problem with SDL, or a problem with your particular system. Great Anyway, if I disable the call to update_fire_sys() in particles.c then I'm fine. Also if I cap the maximum number of new particles It is not problem with SDL. elc design allows this situation: if we update particles too slow (for example >20ms) then timer adds new SDL_Event to the queue, that requires new update of particles. The most strange thing here is that there is no fire particle source in that map, at least I haven't found it Maybe we have wrong fires in map file, as wrong lights? bluap, can you figure out coords of that fire? Share this post Link to post Share on other sites
Entropy Report post Posted May 30, 2007 Wait, is that with the new EyeCandy, or with the old particles too? Share this post Link to post Share on other sites
bluap Report post Posted May 30, 2007 Wait, is that with the new EyeCandy, or with the old particles too? Default CVS make options with NEW_E3D_FORMAT enabled, AUTO_UPDATE and CUSTOM_UPDATE disabled. "Toggle Special Effects", "Point Particles", "Enable Eye Candy" non of these change the problem. Lowering Perspective stops the freeze but I still get increasingly high CPU as I approach the freeze value. Setting "Particle percentage" to zero (particles off) fixes the problem but even a value of 1 causes the freeze. bluap, can you figure out coords of that fire? Not sure how to do that but I'll have a look later today. Share this post Link to post Share on other sites
KarenRei Report post Posted May 31, 2007 The sort of stuff he was mentioning was old particle systems. Share this post Link to post Share on other sites
bluap Report post Posted June 1, 2007 bluap, can you figure out coords of that fire? This may be what you were asking for. Same location "You are in 'The Wyrmgoth Underground' [180,33]". I've printed out a section of the x,y,z values from the particle_sys structure passed to update_fire_sys(). The values are all about the same. These are the values when the loading peak hits and the client gets stuck on the loop. I'm using the pre-download update and the latest CVS client on Linux with the version numbers changed so I can run on the test server. I might not be able to get back with answers to any other questions for a day or so. x=121.38 y=27.68 z=-0.11 x=123.13 y=27.56 z=-0.10 x=123.61 y=29.77 z=-0.10 x=125.30 y=26.70 z=-0.10 x=125.36 y=28.96 z=-0.10 x=127.23 y=29.19 z=-0.10 x=127.42 y=27.02 z=-0.10 x=125.34 y=31.51 z=-0.10 x=120.65 y=14.57 z=-0.20 x=118.68 y=17.89 z=-0.20 x=119.37 y=19.91 z=-0.20 x=120.48 y=16.23 z=-0.20 x=120.54 y=17.95 z=-0.20 x=119.15 y=22.15 z=-0.20 x=122.53 y=14.00 z=-0.10 x=124.27 y=15.97 z=-0.10 x=122.59 y=16.17 z=-0.10 x=122.55 y=18.15 z=-0.10 x=124.68 y=18.26 z=-0.10 x=126.58 y=18.46 z=-0.10 x=121.62 y=20.20 z=-0.20 x=123.39 y=20.07 z=-0.10 x=126.53 y=20.57 z=-0.10 Share this post Link to post Share on other sites
cho-yun Report post Posted June 2, 2007 (edited) bluap, can you figure out coords of that fire? This may be what you were asking for. Same location "You are in 'The Wyrmgoth Underground' [180,33]". I've printed out a section of the x,y,z values from the particle_sys structure passed to update_fire_sys(). The values are all about the same. These are the values when the loading peak hits and the client gets stuck on the loop. I'm using the pre-download update and the latest CVS client on Linux with the version numbers changed so I can run on the test server. I might not be able to get back with answers to any other questions for a day or so. x=121.38 y=27.68 z=-0.11 x=123.13 y=27.56 z=-0.10 x=123.61 y=29.77 z=-0.10 x=125.30 y=26.70 z=-0.10 x=125.36 y=28.96 z=-0.10 x=127.23 y=29.19 z=-0.10 x=127.42 y=27.02 z=-0.10 x=125.34 y=31.51 z=-0.10 x=120.65 y=14.57 z=-0.20 x=118.68 y=17.89 z=-0.20 x=119.37 y=19.91 z=-0.20 x=120.48 y=16.23 z=-0.20 x=120.54 y=17.95 z=-0.20 x=119.15 y=22.15 z=-0.20 x=122.53 y=14.00 z=-0.10 x=124.27 y=15.97 z=-0.10 x=122.59 y=16.17 z=-0.10 x=122.55 y=18.15 z=-0.10 x=124.68 y=18.26 z=-0.10 x=126.58 y=18.46 z=-0.10 x=121.62 y=20.20 z=-0.20 x=123.39 y=20.07 z=-0.10 x=126.53 y=20.57 z=-0.10 wrong sorta coord lol at least it seems Edited June 2, 2007 by cho-yun Share this post Link to post Share on other sites
RallosZek Report post Posted June 2, 2007 Just found a new bug, cvs of yesterday, verified on test server with Aislinn. When you increase the quantity to something larger then 65k, then put 65k of something in the trade window (or more) then decrease the ammount with the 65k, it will instead substract some random number. Tried it with various ammounts, 65k still works, so it's most likely some integer going outof bounds, only when decreasing the number. Share this post Link to post Share on other sites
sithicus Report post Posted June 2, 2007 that looks like an old bug, also in version 1.3.3 Share this post Link to post Share on other sites
RallosZek Report post Posted June 2, 2007 Yep, tested more with Alia: 65535 = ok 65536 = no action (so 0) 65537 = -1 65538 = -2 and so on. Share this post Link to post Share on other sites
jamincollins Report post Posted June 2, 2007 Looks like this bug is quite noticeable in trades with bots even on the main server. RallosZek and I tried it with my bot, having the bot attempt to remove 66000 gc from it's trade resulted in the server sending back a removal of only 464gc: 20070602 17:57:59 [2329] - Attempting to remove 66000 20070602 17:57:59 [2329] - Inventory fully updated... 20070602 17:58:00 [2329] - Received command GET_NEW_INVENTORY_ITEM 20070602 17:58:00 [2329] - Working with slot 1 according to packet parsing. 20070602 17:58:00 [2329] - Current - Slot: 1 Qty: 64270 Item: Gold Coins 20070602 17:58:00 [2329] - Recieved - Slot: 1 Qty: 64734 As you can see from the above logs, the gold on the bot only increased by 464gc (64734-64270). I've double checked my code and I am sending the removal amount as an unsigned long (4 bytes). However, if the server were treating this as only an unsigned int it could explain the oddity we are seeing since 66000 stuffed into a unsigned integer is only 464. Share this post Link to post Share on other sites
