Mac M1 architecture problem or Qt5 problem?

[magicgnome]

I've got showeq running in an Ubuntu 20.04 VM using Parallels on an Apple M1 Max machine. I can only find Qt5 support, so that is what I've compiled with. Showeq runs pretty much and is useful, but there's an annoying problem.

It doesn't show my character in Spawn List 2. It draws an empty circle where my character zones into the zone. If I hover over that, it will show info about my character. But, it does not track my character's movements. It will show my pet. It will show my familiar. Those move to wherever I am in zone. It just never moves the empty circle nor track my character.

It doesn't do "Select on Target".

It does do "Select on consider". If I consider another PC or an NPC, it will draw a line from wherever my character entered the zone to the selected character. So, it seems to know a little bit about my character.

Weirder: If I consider myself, it will draw the circle with direction indicator on the map at the place I spawned in the zone. It will add my character to spawn list 2. But it still doesn't track my character's movements.

If figure this is either an incompatibility with the Apple Arm architecture or Qt5 support. I would hope the latter.

Any idea on what/where the problem is? Is there anything I can do to help isolate the problem? I've not really looked at your code base, so I wouldn't know where to start with debugging.

[cn187]

This doesn't sound like a Qt or Mac issue to me. I think it's more likely that one of your movement structs aren't correct. Likely PlayerSelfPosStruct. Did you get any error or warning messages when you applied the last patch?

[magicgnome]

Just pulled the new fixed tarball and recompiled. I have to use the config.guess and config.sub files from GNU, otherwise ./configure cannot guess the system type. It compiles with system type aarch64-unknown-linux-gnu.

I get the same behavior from the newly compiled copy. The compile doesn't show anything other than the typical warnings, like things initialized and not used or signed vs. unsigned compares.

The only unusual things I see on the console log are these messages:

Warning: OP_Action2 (0x69a2) (dataLen: 8) doesn't match: sizeof(action2Struct):40

General: Unknown: 3c

To constrain the unknowns a bit, I compiled showeq on an Ubuntu 22.04 i386 vm (on an intel Mac) and it worked fine. I then configured an Ubuntu 22.04 arm vm (on an M1 Mac) identically and compiled showeq. It showed the same aberrant behavior and gave the same messages as above.

[cn187]

I think the opcode for OP_Action2 should be 60e5. If you change it in $prefix/share/showeq/zoneopcodes.xml (or in the src tree conf/zoneopcodes.xml and then re-install) then that should fix that warning. But I don't think that's at all related to your issue. (I got that warning on my install as well, and my char location tracking is working fine).

The Unknown messages have been there for quite a while, and I haven't quite been able to track down the cause yet. It doesn't seem to have caused any issues in the past, so I don't think it's related to your problem, either.

Unfortunately, I don't have an M1 system to use to troubleshoot this, so I'll set up a generic aarch64 vm using qemu emulation to see whether or not I can reproduce it there. But it will probably be tomorrow or wednesday before I can really test it.

In the mean time, since M1 is a relatively new target for linux, you might try building without compiler optimizations (configure has a --disable-optimization flag to simplify this) and see if that changes any of the behavior.

[magicgnome]

I recompiled with optimizations disabled and had the same results.

I'm poking around the code now. If I find anything that looks like it could help, I'll post it here. Since I don't know the code, the chances are slim I will find anything useful.

[magicgnome]

Okay, I figured out the problem. It isn't the code. It was in the gateway.

I figured out how to look at a packet log and starting dumping it. I noticed it was getting packets from the server, but not from the client. Once I reconfigured the gateway to allow everything to flow to the showeq vm, it started working correctly.

So, this is the first thing you tell any Mac use who has a problem:

Check your network bridge device, bridge100 using ifconfig. Make sure *EVERY* interface connected to the device has "learn" mode disabled and then perform a "flushall" on bridge100.

I can't fault apple for optimizing packet flow within logical networks on their machines. But they don't document when they change the way this stuff works. Apparently it changed a couple of releases back, but until now I've been using an old machine that can't run the newer OSs.

Thank you for responding and the info you gave me. Sorry for causing you work.

[cn187]

Yes, that makes sense. The PC position and what you target are both reported by the client, while consider targets and mob positions are reported by the server.

Glad you got it figured out!