bluap

I've started a new topic to collect information on this issue, please consider adding your details there. Thanks.

I do not experience this at all. Could this something you have set differently to me in your Android input settings?

Are you using the Android Store version or the new development version? Does the crash happen before one of the fighters dies or mid combat? Have you tried the emotes and does it crash on any of those?

It does look like we could add a client side #command to do this. However, I'd like to check with Radu (@Entropy) that it would be OK to do because this may unexpected behaviour for the server. When you click a popup window option, it sends the sever a POPUP_REPLY message. In the case of the summoning menu the message { POPUP_REPLY, 0, 0, 1, 5} is sent for "Attack at will!" and { POPUP_REPLY, 0, 0, 1, 1} for "No Attack!". I've experimented sending those command directly to the server without first summoning a creature or opening the summoning menu and they both work as you'd expect. So if Radu is happy, its an easy change to make. Assuming that's OK, adding a hud indicator would be very easy in part. However, getting the current status of the summoning mode is not currently possible form the client. It's also persistent between client sessions. Therefore we'd have to do something like this; set the mode at client start then track changes through both the summoning menu and the new #commands. All doable but it would be easier if we could get the current state.

The latest build 1.9.5-20210808.1853 includes is form latest main client git including 1.9.6p9 changes. New to the Android version fix for exit when plugging in / removing a keyboard or mouse custom cloths (may have to be removed for the play store version) the EL logo toggles the on-screen keyboard (if not using it as a web link) a new option to set the time delay before a moving finger presses being interpreted as movement this improves the issue Codor was having I hope (the default is higher than before) access to the android system fonts

Yes, the input on Android uses different code so even with an external mouse, you can't right click. You can left click and hold as if you are going a long press.

You did not comment on what I said, you just implied that my option was not valid because, in your view, I do not play enough. That's absolutely personal. The actual topic has nothing to do with whether someone takes part in invasions or not.

Indeed. It's a shame we can't have a conversation without making it personal.

I agree with Burn, there should be reasonable notice before invasions start otherwise the game will be less playable for those of us that don't want to take part in invasions. It's even good for those that do want to take part as it gives them time get ready so they don't miss the start of the fun.

Is the "Relocatable Window" option enabled? If you turn that off the window position will be kept exactly in place.

I was trying to explain that you can do lots of improvements to the client that do not required server changes. There are also client only bugs that can be investigated and fixed completely client side. In this particular case, if there is a bug with progressing though the tutorial quest, then it is almost 100% likely to be a server bug. All the conversations with NPCs use the same method from the client perspective. The dialogue window is generic. When you click on an NPC to open the dialogue, the client sends information to the server about the NPC you clicked. The server sends the client the dialogue text and the options for the dialogue. The client displays this information in the dialogue window. When you click an option in the dialogue window, the client sends the server which option you clicked. The server then works out the response and sends the client the response text and any further options. The interaction continues in this way. In all of this the client simply displays the text and returns the option the player chooses. All the logical flow of how the chat progresses is done by the server. Many aspects of this game, like most others like it, are controlled by the server. This is necessary to enable the multi-player aspects of the game such as the shared world. It also prevents many aspects of cheating by people that would modify the client. For example, you cannot change the client to give your character additional exp or skills, or add items to your inventory. The client displays things depending on where the server tells it you are located. The client sends things like movement requests to the server, but the server works out if that movement is valid before sending the client information about your new location.

Grum said it very well. In addition I would add that, as you know, the client code is open and suitable contributions are welcome. Both Grum and I have contributed code to the client for many years. There is always plenty to do, especially if you play the game and imagine improvements or read these forum and listen to suggestions. Server changes are rarely needed and in the past Radu/Entropy has worked closely with the client developers to cover those cases. Today both Grum and I have commit permission to the client source, but that was granted after a long period, making many contributions that others reviewed before committing. Even with commit permissions, review is still done where possible as we always learn from each other and more minds make better code. This is how open source works and what makes it fun.

You can also use the version of nlohmann_json shipped with the client by including "-DLOCAL_NLOHMANN_JSON=On" on the cmake command line.

I've added a list of alternative Linux directories. If the current directory is in that list but does not exist, the correct one should be found and used instead. I've also added a check so that the option is highlighted red if the directory does not exist.

I've committed a fix to restore the old behaviour. The current menu window items are now saved and restored directly, rather then referencing a recipe.

As I said, the current method is unintentionally different. I'll look at restoring the previous behaviour for the new implementation. Thanks for reporting it.

The recipe file is called recipes_<character name>.json and will be in the personal setting directory, as show in the console when you start the client. Perhaps you could check if the file is saving the current recipe first. For the json format files, the current recipe is tagged with "current": true. You can open that file and find the entry with "current": true, the "name" field should match your expected recipe. Alternatively, you can copy/paste or upload the file https://jsonformatter.org/ then search the text. Actually, are you setting the manu window from a recipe? If you fill the manu window slots manually, that is not saved in the recipe file. I realise now, that that is different than before when using the old format files.

I presume the recipe still does not show once you have the items in your inventory? Are you using the option "Use New Format To Save User Files (.json)" located at the bottom of the Server tab? If not, I suggest you enable that. While the previous file formats tried to save/restore the current recipe, it was not reliable. The old format user files are deprecated and will be disabled for the 1.9.6 release (though the client will still import them). If you are already using the json files option, then we have a bug.

I'll take a look at some of the thresholds I have for detecting presses. The animation program is not enabled because support for that is not available using the openGL library on android. I should really remove the option.

OK. Is that because they are too small on your display and so take time to touch in the right place, or is it because they take multiple tries to function?

That's the same issue. Most sounds are positional, based on your x,y coords when the sound is created. When your character actor is removed and recreated (death, teleport, location change) those sounds can get muted if the sound update code runs while your character does not exist. Even if an update does not happen in that time, if your location change is out of range, the sound is muted, or at least made more quiet if to your change of coordinate is not far. The xml file work around makes the alert sounds non-positional. Unfortunately, battle sounds need to be positional. At this stage, I do not know how to fix the code.

Related to your question perhaps, there's a limit of 50 entries for sound_warnings.txt.

I don't think there's a limit on alerts as such, other the the 200 limit on total number of sounds. There's around 140 currently.

I've only added two new sounds to snds_client.xml , the alerts definitions were already there and I just modified them. I guess the order that the files are include from sound_config.xml is important, if you have both a snds_client.xml and a snds_alert.xml with the same definitions, one may just overwrite the other.

I don't have that file and its not in the sound pack. Is that one of your own making?