By using AWS re:Post, you agree to the Terms of Use

GameLift - Custom server executable can't seem to access a .dll in the game folder

0

Hello,

Here is my setup:

  • Using GameLift to host custom server for my game
  • Server is a headless Unity app
  • Server (and, therefore, client) uses Photon Fusion for simulation
  • I've integrated the SDKs, and everything works when testing with GameLift Local

My problem: When I create a build and deploy it on a GL fleet, the server app fails to start the Fusion server with the following error: EntryPointNotFoundException: nanosockets_address_set_ip

Of course, I've asked Photon for support first. They said that this error means that either the nanosocket .dlls are missing from my build or the executable can't access them. Since both .dlls are present in the correct locations, it seems like the app just can't access them.

The weird part is that they're both inside the C:\Game folder (2 or 3 levels down in subfolders, but still). From what I've read in the AWS docs, the app should be sandboxed but have access to its own folder (C:\Game). Does anyone have an idea why my app wouldn't be able to access the Fusion .dlls?

My team has been stuck on this issue for days, so any help or pointers would be appreciated.

Thanks in advance!

1 Answers
0

Hi IngDanko,

Sorry for the late reply, this seems to be a very specific use case since we have other users being able to bundle dlls in their build and access them successfully. Could you please reach out to AWS support so they can help facilitate more personalized support?

You also have sudo access to the gamelift instance, could you possibly debug your game server directly on the instance? (e.g. try changing file/directory permissions, try relocating the file, etc.)

Thanks,

James

answered a month ago
  • Hi James. We switched to Linux servers and the build works fine there. It also works on an unmanaged Windows EC2 instance with the same OS and instance type.

    The problem only occurs on a GameLift-managed Windows instance, and only for .dlls that need to be loaded in runtime.

    We have moved to using Linux instances for our use case (since that approach has no real downsides for us) but maybe this info is useful for your team to track down the issue.

    Best regards, Danko

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions