Illusion of seamlessness

[youngneil1]

So, after many words, something to play around with a little :

https://www.dropbox.com/s/9ykbtqdj4ccp7 ... s.rar?dl=0

It's just a mess of a WIP cohesive, seamless city map (just copied chaos for demo purpose, ignore this when it comes to how the real city will be), covering 9 submaps (16x16) in total. They are like the number keys on the keypad, palyer starts on central map (key 5). Just run around a little to get a feel for it. Hopefully it conveys the illusion of a big 30x30. It has a fog border, like a wall around it. This border is good suited for orientation / measuring its size. This is just the concept idea, 30x30 is no limit at all. It's basically limitless (well, until app max size is reached, e.g. some 1.7 GB or so).

So, far the only niggle is that view range is 2 squares which will cause a little inconsistency in known fields when traversing to another submap. This will be remedied once I can increase view range to three.

Next step for me is to significantly increase the ease and speed with which the seamless map can be setup in the toolset. The next iteration will have a "transition" ring that's actually just one large trigger that calls a logic tree. The logic tree will receive four string vars as parm input, each of them containing the area name of the top, down, left and right neighbor map. The logic tree will get party location via script and based on that info transition the party to the correct square on the correct neighbor map. Beauty is that it will take only four edits (i.e. enter names of the neighbouring maps) to integrate a new map into the seamless system.

[youngneil1]

[youngneil1]

[youngneil1]

So, with only view range adjustment to 3 squares as last to do point for optical seamlessness of the static world, I will try to tackle seamlessness for dynamic parts, i.e. movers, too.

I will start with movers in patrol mode, non chasing, non world time driven:

I will expand the transitionSystem logic tree above to do the following on contact:

1. Iterate though props on the old submap via loop and get each props location
2. Compare each props location with party location (transSysX, transSysY).
3.If prop is within 3 squares range from party location:
a. Get value of props local string "identityGroup"
b. Iterate through props on target submap
c. If prop on target submap has same identity group, set that props location to the graphically same square that the sister prop on the old submap was on
4. Furthermore, all patrol mover props on the old submap within two squares from the transition ring (towards) center, must be moved out of this zone more towards the center. Otehrwise, the situation can occur that a prop blinks into existence when entering a map.

The system requires a clone, same identity group local var, prop on each map where the patrol route leads the prop.

Excited to see if this will work out ...

Edit: Added the re-location operation for props on the old map.
Edir2: For later: static props isShown state adjustment.

[youngneil1]

So, been thinking a little based on our exchange about the engine doing a similar trick for area maps as for wm_ maps:

Mayhaps ideal size would be 9 tiles of 5x5 squares. That's like a 15x15 map, very similar memory usage as standard 16x16. The 5x5 size - in contrast to 3x3 - is to limit the number of new load operations. It's likely a balance of tile size based memory consumtion and frequency of reloads.

It would be very helpful if map graphics could be updated / exchanged anytime. Like load map button now. Probably called something like "Load tile group".

Would the tiles be autoarranged by the engine then? I imagine feeding the toolset a large map to a new wizard, like Cutter Wizard/Editor. On press of button it would cut the map into e.g. 250x250 px tiles and automatically name them to form a tile group. Likely it's best if each such tile group is stored in an own subdirectory of the graphics folder. The naming convention would give tiles names based on their position in the uncut map. The engine would load tiles based on these names and automically recreate the whole uncut image piece by piece. The load tile group button would load the map then by name of the tilegroup subfolder.

Ideally the area size could be expanded anytime by adding rows/columns of 5x5 chunks anytime, like the wm_ editor right now. In case the area sizes mismatches the number of tiles, any excess tiles are not loaded (overhangs in x/y direction). Missing tiles are loaded as black default images.

Will we run into technical troubles on toolset level? It would probably load/unload the chunks as the engine does, based on which chunk is currently centered in the area editor?

Oh, and will we stay with 50x50px per square in such system? With 5x5 chunks we likely have to in order to have comparable memory usage than beforehand. With 3x3 chunks we might do the step to 100x100, which should result in sharper image quality? Like props using 100x100 as default for the same reason?

The prospect of having such flexible map size handling is breath taking . Go, killer, go

On another note: It would be helpful to be able create folders and subfolders, subsubfolders etc. in the area list in the toolset (like e.g. blueprints have already). This would make sorting of maps and their sibling maps much easier. I would e.g. give each map with sibling maps a folder who might contain more folders for siblings of siblings etc. Same is actually true for convos, logic trees, containers and also encounters (not when it comes to siblings, but for grouping in general, each of these could e.g. go into a folder with the relevant map name where the convo, encounter, container, etc. is located). The scrollable lists will get very long otherwise, as will the names. Please note that the map name must still be unqiue and does not have to incorporate the folder path. Still, with telling folder names folders and grouping orientation, are map names can be shorter in general, which is a great help.

[youngneil1]

An addendum concerning the Cutter Wizard:

So far I imagined that one .jpg is fed to it, then cut into pieces, numbered in its file name in a way that the engine as well as the area editor will load the pieces correctly to recreate the correct order and finally saveall the pieces in a subfolder for that specific map within the graphics folder. The cutter wizard would expect a square shaped graphic of any size, minimum size of 9 pieces likely, for its cutting operation. Length of the squares side also would likely have to be a multiple of one pieces's pixel count.

Now, the largest image I can edit on my note4 in photoshop touch is 4096x4096, i.e. 4000x4000. Thats a 80x80 or 40x40 map, depending on the pixel count of one square (like now 50x50 px or as discussed above 100x100 px). With 50x50px size per square I think that this is enough space for one map. With 100x100px it feels a little to restraint.

Ideally the Cutter Wizard would allow to load several different .jpg images into the subfolder for that specific map. It could work like this:
1) we get rid of the square shape requirement for the .jpg. Rectangular is enough. The cut pieces will of course still be square shaped.
2) each cut and store (another) map (part) operation requires the author to specify at which x,y coordinate in px the top left corner of (new) map (part) shall be placed within the fictive sorting grid. Default is 0,0 for those coordinates. This might very well lead to overwriting already existing pieces (thats cool for later edits).

Let me provide an example: I did a 4000x4000 map for city (already run through the Cutter Wizard), then I realize I need an additional city quarter of e.g. 1000x1000px (would be a multiple of one piece's length in px). I would draw that map and re-open the cutter wizard. A click on the cut and store map button would ask me to name the subfolder where to store the cut pieces (I would choose the already existing subfolder for my city) and ar which coordinates to place the new map. I would e.g. choose 4001px for x and 0px for y to have the new pieces appear in the northeast part of the city.

[youngneil1]

Picking up work on the seamless map system here (it might be redundant soon, but nevertheless it's an excellent logic tree usage /scripting exercise for me):

Current challenge for me is that I can neither get a prop's name (based on known index) nor can I read a local var on a prop via index alone. This makes it difficult for me to identify a prop of the same identity group on the target map. Have found no solution for this so far.

[youngneil1]

Hehe, I think it will work via onHeartBeat tree hooks of each prop and prop specific globals as connecting bridge, using ogGetPropLocation to check whether a prop is in the map's border zone.

[youngneil1]

Notes for myself:

I. Procedure for filling outer area of border zone of current map (three squares from edge: squares 1, 2, 3):

1. Upon each step - within 4 squares from any border - transition party secretly to each of the four neighbour maps.
2. Go through neighbour maps prop list and check for props in the shared border zone, inner area (arrival square and following two squares towards center: squares 4, 5 and 6 from border).
3. Transition the party again on top the found props: now one can set and get that props local vars.
4. Find the local string identityGroup and store its value in a global as temporary value holder.
5. Store the props position to synch location globals for x and y, converting coordinates to the mirror location on the current map
6. Third party transition: back to current map (all within the runnig loop for the neighbour map)
7. Go through prop list of current map and transition party on each prop found
8. Check each prop whether its local var identityGlobal matches the value stored in the temporaray global, likely via a second temporary global
9. In case of match, move the prop to the synch location x,y

II. Procedure for copying over inner area of border zone of current map:

[youngneil1]

Just a link for a good texture collection:
http://www.cgtextures.com/

(including tutoruial on seamlessness, note: not in the original sense of this thread, but fitting noetheless ).

And especially this one:
http://www.pathofexile.com/forum/view-thread/55091