Author Topic: minimap bricks  (Read 750 times)

basically 3 types custom bricks which are 1x1 plates:

start node - the origin of the 'map' boundaries
end node - the end point of the map boundaries

display node 1/16 - the point in which the player positions will be shown as a small minimap
display node 1/32
display node 1/64

place start node at point 0,0 in the world, place end node like 20,60. color them the same color.
place display node somewhere (same color as start and end node) and it will display any players that are within the start and end node boundaries (and their slayer team color) relative to the display node size (1/16 will be 1x1 stud for every 16x16 studs on the map, 1/32 is 1x1 for every 32x32, etc. so the 1/16 display map is larger than the 1/64 map)

this should be easy to code. when a start and end node is planted, just do a variable like $startnode[color] = X SPC Y; $endnode[color] = X2 SPC Y2;
when a display node is planted, run a loop that checks the transform of every player on the server and if they are within the start and end node boundaries, it'll display a little static object of their position but divided. so if the map boundaries are like 256x256 studs in size, and you place a 1/16 display node, the minimap will be 16x16 studs in length. from there you can build a little scale model of the map

this is the most intuitive way i can think of to show player locations (maybe at the spawn or whatevrr)

I got inspired by this and kind of went crazy with it. I invested quite a bit of time into this proof of concept, but I coded it really well so hopefully its more adaptable later on.

While I am currently low on time, how exactly do you see this working? Before I take this any further and make any major changes unfeasible, it's good to have an end-goal in mind. Including what the end-user experience is going to look like


left square: parent
right square: child

The child square can be set to track anything, right now its set to player.
In addition to this, I set it up so you can create multiple separate display instances, each with different size, height and color marker so that's going to be an option as well.

With a little bit of reworking and tweaking I can make this track and display in scaled 3D as well.

thats pretty much it. for easy use of the mod i'd suggest the two parent and 1 child node all use the same color to register, also a second child node isn't really necessary, because you only need one origin point for it to display

it would mainly be good for people to build like tiny scale models of their dm map or like battle royale map and then they put the child node over it and it would just show where brothers are

another cool concept is the ability to click on a teammate on the minimap and teleport near or to them on the map or some stuff, kinda like the spawn-in feature on battlefield. it's a feature but it would be really cool, at least as a hook for mod developers

I think you misunderstood what I meant about the colors. Right now the whole registering of the squares is done manually, it is the marker in the child square that can be customized with different size and color.

To better explain how the image is currently created on the child, i made this quick mind-map:


In the above demonstration, parent square would be projection 1 and child square would be projection 2. In the example, projection 2 only has 1 projectionDisplay and that is set to track player objects.

It is possible for me to make it so, for example, one projectionDisplay tracks the blue team and creates markers of blue color and another projectionDisplay tracks the red team and creates markers of red color.

If you understand in more technical terms, every time I update the minimap, I delete the currentDisplay object and since it is a ScriptGroup, all of the static shapes are deleted as well. Immediately after that, a new search is conducted using a method on projectionDisplay. This creates a new currentDisplay with new static shapes in updated positions.


Sorry for the long post, but I feel as if you understand what stage this is at, you can suggest more things that you feel would be cool y'know.

Also, a second child node is in fact necessary in order to scale the minimap. Otherwise the dimensions of it would be fixed/need to be changed in some weird way. Also, with this, you can stretch the map to different aspect ratios while remaining in the brick-grid, which should help build an actual minimap in practice.
« Last Edit: January 17, 2018, 12:15:23 PM by Dannu »

this would be so cool for servers that use territory (trench, dogfight)