Jump to content
Eternal Lands Official Forums

bluap

Moderators
  • Content count

    2985
  • Joined

  • Last visited

Everything posted by bluap

  1. If any windows users want to try the latest client with this fix then here's a executable + DLL only package. https://twinmoons.org.uk/el/git/el_win_x86_64.zip I can do other builds (Windows and Linux) if people want them.
  2. Yep, that looks to have fixed it. Pity the original author didn't use proper C++ casting as this would never have slipped through. I checked a couple of the other uses of ->shift with casting and they would appear to always be a valid type. There are plenty of other C style casts of objects in the code though and I wonder if we shouldn't spend a bit of time checking and replacing those too.
  3. Sorry I've been quiet on this for a few days, just too much RL stuff this week. I'm using Ubuntu 21.10 on the Raspberry Pi 400 by the way. I'm still thinking its the particle positions that are going astray, they are not NaN but very large e+30s for one or more of the coords is typical when the blackout happens. It is totally predicable that a blackout will happen if these large values are seen, and the blackout are reliably prevented if I "continue" the "// Draw Lights." loop in eye_candy.cpp when I see such values. A quick hack logging but excluding and coords with fabs() > 1e12 stops the blackouts. As a minimum work around I will look at the threshold some more and we could use that to prevent the blackouts. My preferred option is to find the underlying reason for the large values and fix that. I will be able to spend time this weekend on this but would be more than happy if someone else found the underlying fault before me Here is my hacky patch with debug. diff --git a/eye_candy/eye_candy.cpp b/eye_candy/eye_candy.cpp index b1781240..01128d54 100644 --- a/eye_candy/eye_candy.cpp +++ b/eye_candy/eye_candy.cpp @@ -2023,6 +2023,11 @@ namespace ec std::min(p->color[2] * brightness, 1.0f), 0.0 }; + if (!(p->pos.is_valid()) || (fabsf(p->pos.x) > 1e12) || (fabsf(p->pos.y) > 1e12) || (fabsf(p->pos.z) > 1e12)) + { + std::cout << "Invalid Pos " << p->pos.x << " " << p->pos.y << " " << p->pos.z << std::endl; + continue; + } glEnable(light_id); glLightfv(light_id, GL_POSITION, light_pos); glLightfv(light_id, GL_DIFFUSE, light_color);
  4. Cautiously optimistic that the problem is due to invalid particle positions , I'm just looking for the underlying cause or if I can just trap the values.
  5. Nothing odd about the brightness, no sign of NaNs. However, I think have a work around for the black screen problem. In lights.c init_lights() change the ec_add_light() calls to use lights greater than 8. This could be done conditionally based on GL_MAX_LIGHT which is way greater than 8 on all my systems but the minimum is 8 according to the documentation so it might not work on all systems. I've hacked being able to change these lights without restarting the client and I can turn the problem on and off in this way so it looks like a fix of sorts. However, it is only a work around and something is clearly messing with the lights. I've looked though the code and found a possible bug in draw_lights() where GL_LIGHT4 is used sometimes but fixing this does not fix the problem so it could be down to more than one bug. I'll carry on looking.... I think all my change was doing was just disabling the lights for eye candy. Perhaps that's the solution, add a "trouble shooting" option to disable lights use with eye candy.
  6. Unfortunately, I'm still seeing the issue after the patch. I've also been looking at the lights code but my time is limited currently, there's a great deal we could clean up there I think. One thing I've yet to try is to adjust the randomness elements of the eye candy effects to made things a bit more repeatable for debugging. Also, we've seen bugs with the eye candy code previously due to extremely large or small values, this could be another reason why its difficult to reproduce reliably.
  7. A little more debugging on my Raspberry Pi: I'm seeing the screen going black when using the eye candy debug window so can save on essence. I'm seeing the effect when using the Teleport-to-Range and Life-Drain effects too. It also happens outside with a single creature. TTR is particularly repeatable. It's not consistent between runs though, perhaps suggesting uninitialized memory as the cause.
  8. Just visited the cave and I've been able to reproduce the screen going black during the MD spell; this was running the client on my Raspberry Pi 400. I'll investigate further but its a good step.
  9. Counter and spells copy to new client

    Adding to what Kaddy said, once you have your data restored, you should re-select the "Use New format to save user files (.json)" option. The old data file formats are being phased out. Also for others, if you place the old files into the folder before starting the new client for the first time, the conversion would be automatic.
  10. Water display

    On the GFX options tab, do you have "Show Reflections" on?
  11. Water display

    I presume you have the shaders installed? There should be a sub-directory of the data called shaders, that contains these files: anim_depth.vert anim_ghost_shadow.vert anim_ghost.vert anim_shadow.vert anim.vert reflectiv_water_fs.glsl water_fs.glsl
  12. Current day info

    There's always https://holy-eternalland.de/eldata.php I use this source for https://launchpad.net/el-time-applet
  13. Water display

    On the Video tab of your options, you need to have "Toggle Frame Buffer Support" ticked and the "water shader quality" setting underneath needs to be greater than zero.
  14. Como colocar me Português?

    From the options window, server tab, enter pt as the language setting then restart the game. Only some text will have the translations, and they have not been updated for a long time. Google translate: Na janela de opções, guia do servidor, digite pt como a configuração de idioma e reinicie o jogo. Apenas alguns textos terão as traduções, e elas não são atualizadas há muito tempo.
  15. Not sure how that could be due to a client bug. Does it work OK on the desktop?
  16. I've not seen anything like this. Does it make any difference if you're not wearing the medallion?
  17. Grum has hopefully fixed this (thanks) and I've updated the build. Version 1.9.5-20210921.1411 also includes all the latest changes from the main client git.
  18. Can't connect

    Are you trying over a mobile connection or wi-fi? Some mobile providers block connections to the EL server (it uses a non-standard port). Do you get an error message?
  19. Thanks both for the info, nothing obvious jumps out. Have either of you played around with the Eye candy test window? If you enabled ECDEBUGWIN and rebuild, you can open the test window using ctrl+alt+c. You can then generate EC effects without needing to cast the spells. Obviously, only you see them. It would be interesting if you experience the problem using this method. Perhaps even build with debug and the ADDRSANITISER library option or using valgrind. After editing CMakeLists.txt to uncomment "-DECDEBUGWIN", to build with debug and the ADDRSANITISER library option using CMAKE you can something like this in the source directory: cmake -B debug-build -DCMAKE_BUILD_TYPE=debug -DADDRSANITISER=On make -C debug-build/ # assuming you have #data_dir properly defined in el.ini..... debug-build/el.linux.bin test
  20. Summoning menu

    I've also added "#sa" as a shortened version of the "#summon_attack" command.
  21. Summoning menu

    I checked with Radu and he was happy with me doing this. I've just committed a change to add a new #command and a hud indicator. Here's the commit message that hopefully explains what I've done. Let me know if you want any changes. Forum #61629: Added #summon_attack command and hud indicator. Provides control for attack mode of summoned creatures. #summon_attack options: * a-f set the mode * no parameters, toggle between attack at will and no attack * otherwise show help for the modes The hud indicator toggles between attack at will and no attack. On start the current attack mode is unknown until set. If the popup menu is used, the change of attack mode is tracked.
  22. Bigger Buddy List

    Assuming you mean the colour you can set for each buddy, that is currently limited by the "#change_buddy <player> <colour>" server command which only accepts the limited set of colours. If that was changed, the client would have to be modified to to display the new colours and also to enable selection from the GUI.
  23. Bigger Buddy List

    The client window can handle 100 buddies currently, this could easily be increased. The client could potentially be changed to remove the limit and just allocate more memory as required. However, I do not know if the client is the limiting factor. How many buddies can a player actually have from the server perspective?
  24. Bigger Buddy List

    Nope, sill not clear. I guess you could just answer my simple question.
  25. Bigger Buddy List

    Bigger in what way? More buddies? A bigger window?
×