[MENTION=23394]Zhi Kang Shao[/MENTION]:
I’m finally getting my hands on your Plugin (it was a tought half-year for me, didn’t quite have the time before) and I’m experiencing a weird behavior: I attached a MapView to my Character but its location appears to be offset when displayed on the minimap.
Here are screenshots of the behavior / my setup:
**Map says I’m out the world **(Black areas = dungeon)
Zoomed in / out
Map View / Icon on my Character
Map View set to Background
Map View manually set to Character
I can’t wait to know what’s wrong to continue toying around with the map, in the mean time I’ll check out Fog of War
Thanks in advance and have a nice week-end!
EDIT: I would also like to know how to generate a snapshot of the map at runtime!
Great to hear from you and nice that you’ve found time to use the minimap! From your screenshots (very helpful, ty) it seems that the minimap center (controlled by the MapView comp) and the character’s icon (controlled by the MapIcon comp) are both at wrong positions. Can you please post a screenshot of your character’s component hierarchy? Are the MapView and MapIcon currently direct children of the character’s mesh? If they aren’t, perhaps that would help.
You can call the MapBackground actor’s GenerateSnapshot() function to recapture the image at run-time. You can also check its SceneCaptureComponent’s setting bCaptureEveryFrame if you want the minimap to show a live image, although obviously that renders the scene twice every tick.
I got a question from someone via e-mail and I thought this could be useful info to everyone. The question was whether it is possible to render only the navigation mesh. This can result in a clearer outline of the walkable area, especially if your world has rooftops, trees and other meshes that appears in the render but are basically noise when you’re trying to render an outline of the walkable area.
This is certainly possible. To do this, select the CaptureComponent2D on the MapBackground actor and add the “RecastNavMesh-…” actor from your level to the list, like shown here:
Can you check whether the Map Background’s aspect ratio is 1:1?
The aspect ratio shouldn’t be a problem, because I built in a correction for when the minimap’s aspect ratio doesn’t match the MapBackground volume’s, but if you can please check ti rule it out.
Then, can you place a BP_MinimapExample_Basic actor into your map?
This is in the folder “MinimapPlugin Content/Examples”, you must have View Options > Show Engine+Plugin Content checked in the content browser to see the folder. That helps me determine whether maybe the minimap has initialized its own size with the wrong values. Are you doing any dynamic resizing of the minimap during the game?
Finally, can you add a BillboardComponent as a child to your character mesh and place it above the character’s head, uncheck “Hidden in game” and see if it appears above your character’s head in-game?
I don’t see anything wrong with your setup, this will confirm that the input positions are correct and then we can look into why the rendering is off.
Thanks for your patience! My goal was to make this minimap usable out of the box, so whatever the cause of this issue turns out to be, I’ll get it fixed in a next update.
I feel like a complete beginner. Everything is solved now.
The problem was:
the component “Area Map View” was offset by 1500 / 200 in the MapBackground actor
I must have moved it by mistake while I was selecting it for discovery reasons (I click everywhere like a madman :x)
It’s really silly and I feel a bit sorry for the screenshot spam these past two days when it was so simple!
But! To make it sure nobody makes the mistake again, I suggest you to set the relative position of the “Area Map View” component to 0;0;0 in the Construction Script.
Another thing that bothered me was the weird relative location / rotation of the “Capture Scene Component”. I resetted it but nothing was captured after that so I dropped another Map Background just to see what its original Transform. And it is indeed a very weird transform Maybe you should also add it to the list of things you set in the Construction Script to avoid people from resetting it thinking they have modified it by mistake.
Thank you very much for your support and your time You put me back on track with your answers (it was in fact the first suggestion of your previous message that made me think of this fix).
I can’t wait to try things out now
PS: You can change the color of the Navmesh if your project settings!
Actually I have another question [MENTION=23394]Zhi Kang Shao[/MENTION]!
I rotated the Widget Minimap by -45 Angle (in Widget, tried both the minimap widget directly and a box containing it). Here are the results (the red Arrow is the character):
You can see the Character Icon is offset by an amount on the minimap but everything else works fine!
No problem, I have experience myself with issues that turn out to be that something was moved accidentally. That is a good suggestion, I will set that AreaMapView to (0, 0, 0) in the C++ BeginPlay, as there is no benefit to moving it off center. I won’t make an update purely for this but it will be part of the next one.
Hmm, if changing the render angle of a parent widget doesn’t affect the children correctly, I think that is an issue with UMG. I had noticed another issue when rotating things in UMG: any canvas clipping is applied before the render rotation so when I rotated an icon that is near the edge of the minimap, sometimes half the icon wasn’t visible (because that part would fall outside the minimap canvas if the icon wasn’t rotated). This is why for this plugin I made a material based workaround. Bottom line, UMG render transform has some known issues. I believe they are going to be fixed as part of UE4.17, because there was a recent Epic blog post about that.
Something you can try instead of using the render transform:
Make a duplicate of the BorderedMinimap widget asset and in that, rotate only the border image (not the internal Minimap widget) by -45 degrees. (Edit: I suggest not modifying the existing one because those changes can be lost when you download an update)
At the character’s BeginPlay set his MapView to the right world rotation (so that the minimap’s North marker aligns with what you want to be north).
Make sure the MapView doesn’t inherit yaw by unchecking the built-in setting, but you’ve probably found that already.
First off thank you for purchasing the plugin and for bringing this bug under my attention. I know what is causing the fog of war revealer not to be round. UE4.16 changed the behavior of one of the most basic material nodes (BreakOutFloat2Components) to lose information about negative values. This affected some other parts of the plugin too which have been fixed, but it seems I’ve missed a material. I will be submitting an update to fix this issue, but in the meantime you can fix it locally by replacing the first part of that M_Revealer_Circle material with this:
As for the flickering, I’m not sure. Let me think about that some more.
Thanks for the prompt reply. Your suggestion has fixed the Revealer and it works as intended now, thanks very much. I am still noticing the flickering that I previously mentioned but will continue to look and see if I can find the root of the problem.
Glad to hear the fog of war works now. I haven’t gotten any ideas on what can cause the flickering yet. Increasing the resolution of the fog of war texture on the MapFog actor might reduce the issue. If you find out anything else that might hint at what causes the issue, please let me know.
A small update should be coming online soon for engine versions 4.15 and 4.16. This update will also make the plugin compatible with 4.17. Here are the changes:
Minor code changes to compile without issue for 4.17
Fixed circular fog revealer not being a complete circle
Fixed issue causing loading errors after adding minimap components to a blueprint and restarting editor
Fixed issue causing the minimap background texture not to show correctly after manually calling RerenderBackground
Added a MapBackground C++ and blueprint event OnMapBackgroundRendered that fires whenever the background is rerendered with scene capture. Use this event to manually render extra items into the render target.
I have had questions about Mac support. The marketplace page does not list Mac as a supported platform, because I haven’t tested for Mac OS. People have reported that the 4.15 worked fine for development on Mac, but 4.16 didn’t. I’m not sure why this is the case, because the plugin doesn’t do OS specific calls. I will be borrowing a MacBook to ensure that development on Mac will also be supported for 4.15, 4.16 and 4.17. Please look forward to that if you develop on Mac.
Thanks for the kind words. The data of what fog is cleared is stored and updated client-side. Clients will see the same minimap if they entered the game at the same time and the same fog revealers are enabled i.e. the client-side executed game code marks all team mates of the local player to grant vision and marks all enemies to not grant vision.
I’m afraid the provided implementation does not process fog on the server. This has two consequences that you must be aware of:
A) A later joining client does not automatically receive what fog has been cleared.
B) There is no “true” version of a team’s fog data.
You can implement a manual solution for issue A. For example, when a player joins a team the server requests all fog data from team members’ clients and sends the combined result to the new team member’s client. From there on, all game clients will update the fog locally again.
Issue B can be worked around depending on your requirements. If you simply want all fog maps to look the same to the pixel, you can periodically sync the render target data via RPCs, but the plugin does not do this yet, currently. If you want fog data to only be updated by the server, I’m afraid this is not possible if you plan to run dedicated servers on machines without GPUs. Fog is updated by drawing to render targets, which is great for efficiency (its an ideal task for the GPU) but can’t be run without a GPU.
With code changes, you can let a server track fog data for both teams, but this will only work on servers hosted on machines with a GPU:
Modify the “MapFog” to have render targets for both teams and the fog updating code to pick a render target depending on the fog revealer’s team.
Implement a way to send each team’s fog data to the clients. Since render targets (texture data) can be quite large, it would have to be something smarter than just sending the data every tick. This step isn’t required if the reason you want fog data on the server is not authority, but just as a convenient server-side vision system.
I know some people have used this minimap in combination with another system that checks whether actors are visible to each other. If you have such a system in place, you can make that an additional requirement for showing an icon on the minimap. In that case you can call SetIconFogInteraction( VisibleWhenRevealed ) to only show an icon when its not inside fog and call SetIconVisible( true or false ) based on the result of your own vision system. That vision system can be server authoritative and the icon will only show when not in fog AND deemed visible by the server.
I submitted the 4.17 update on August 14. I’m afraid Epic marketplace staff hasn’t processed it yet despite a reminder I sent. More marketplace sellers seem to be waiting for their 4.17 update to go through.
If it is an option for you, download the 4.16 version of the plugin. It is compatible with 4.17 after you remove the line saying “private_subobject” in MapBackground.h and MapAreaBase.h and recompile. If compiling is not an option for you, know that the update is in Epic’s hands and should be out soon.
Done. If anyone else needs the 4.17 version of the minimap urgently, send me an email (zhikang [dot] shao [at] gmail [dot] com) with:
A screenshot of your Epic Games Receipt for the plugin
A screenshot of the plugin in your Epic Games Launcher > Library > Vault
and I will send a 4.17 compatible version of the minimap to you. It is now exactly one month since this version has been in the hands of the marketplace team. I don’t want this to hold back your development.