I’m trying to fix the problem where objects don’t disappear from the map with the proper UI feedback.
Example: go to chest (hear sound, see all consecutive dialogs), choose option (see map), interact with map.

In HOMM3, it goes this way:
go to chest (hear sound, see all dialogs), choose option (hear pickup sound, see map with disappearing sprite animation), interact with map.

Right now, I’m trying to get the sound to work and I’m a bit confused abuot how server and client are separated.

What I figured out so far:

  1. Server drives the UI, including all dialogs, as well as it selects sounds.
  2. Client pretty much only draws what server tells it to draw.

I found out that the server removes the object the moment it’s touched, before choosing the option. So, to solve the problem, I have to ask the server to wait with RemoveObject until user confirms all dialogs, and then make the client handle the pretty removal - somewhere in MapHandler?

However, I don’t like this approach personally… Server sould know nothing about GUI, so I was thinking about a different solution (italics marks the change):
go to chest (client receives choice, client receives RemoveObject, client remembers object), choose dialog option(cliend sends reply, client shows the map, client actually deletes object with object-specific sound and animation), interact with map.

This approach needs to push some code to the UI portion, e.g. UI needs to discriminate between object types, and basically have 2 handler types: one for server (logic) and one for client (UI).

My question is: if I start splitting up code like that, is anyone going to welcome my patches :P?

I think the only change you need for this is to add waitWhileDialog() call in RemoveObject applier. Try this at first - this is how you can delay applying netpacks while there are waiting dialogs.

This bug and also a bug where disappearing hero wouldn’t make a sound are fixed. I’m pushing them to a separate branch since my last pull request hasn’t been merged and I can’t properly test AI myself :stuck_out_tongue:

Unrelated - did anyone have the idea to use .json files for UI elements like windows? That would be nice for scripting and awesome for experimenting.

Well, actually you now have many different issues in one branch as well as duplicated branch. In fact I can’t see the second pull request.

The other proble, is that branch wasn’t succesfully built with Travis. But it’s more like the problem with Travis :confused: than build.

Will merge that pull soon - it was OK last time I checked, including AI.

You mean something like this? … nmenu.json

However we have just too much hardcoded logic for this to be actually usable apart from some areas like main menu so json-only solution is not as great as it looks like.

Scripting on the other hand does sounds like a good addition to UI. I am thinking of exposing our base GUI widgets to scripting once we get scriptable map objects up and running so answer to your question is yes :slight_smile:
In fact right now I’m trying to get rid of some ancient issues with our UI in order to make it easy-to-use for scripts (and for c++ code as well).

I didn’t submit another pull request yet.
I think the idea behind pull requests was 1 issue = 1 pull request, but I don’t want to change my pull request every day, and can’t be bothered with separate branches with a different patch each.

This is beautiful.

Ok, so I’ll hold my horses and wait for the improvement to come before implementing an “upgrade all” button. Sure as hell I’m not going to hardcode UI in C++.