Map edges, how can they be fixed?

[smoth]

I cannot control what others do but how about this:



SUGGESTION FOR MAP EDGE WIDGETS:

ALL MAP EDGE WIDGETS MUST DISABLE THEMSELF IF THE MAP CONTAINS THE FILE:

NOMAPEDGEWIDGET.TXT

it will be located in the base map directory..

I cannot control everyone but I will go ahead and add support for it this weekend some time.

that fair enough?

I kindly request that others making a map edges widget do the same.

[knorke]

idea:
widget looks for config file named mapedges_config.lua in root folder of the map.

mapedges_config.lua looks like this:

options =
{
enabled = true, --should mod draw mapedges?
gridColor = {red=128,blue=64,green=255}, --color of the grid
gridTexture = "blub.png", --what texture to use (first look in map, then in mod)
tileSize = 64, --resolution of the grid
drawRange = 1000, --how far beyong map edge the grid is drawn
}
return options

The file returns a table with various entries:
The purple stuff is entirely optional - it is just so that mappers can adjust the look of the grid a bit. (think of it how sky or water color is adjustable)
If certain games/widgets do not use all entries that is okay too.
The important part is the enabled=true/false
enabled=false -> game widget disables itself

In case that is not clear: If a map does not want the game to draw mapedges:
Include such file:
mapedges_config.lua:
options ={enabled = false, }
return options

[smoth]

whatever, I don't care.. just so people are happy and I can move along.

[zwzsg]

knorke: That seem very specific to grid based map edge cover solutions. What about mods that cover the map edges with noise, fog, the minimap texture, or novel exotic solutions?

Smoth's way seem more generic.

[knorke]

if the widget is looking for "gridColor" but only finds "noiseColor" then it simply uses its default for "gridColor." (and other way around)
or only do the enabled=true/false thing if you dont care about the rest.
But since it is a lua file you could also do configs like
if game=="the cursed" then enabled=true --cursed's widget looks ok with this map!
if game=="kernel panic" then enabled=false --kp's widget looks bad with this map!
and thus allow some games to draw stuff but overwrite it for others.

[zwzsg]

If the mapper has a precise idea of the kind of grid he wants, he'll put a nomapedgewidget.txt and his own grid widget anyway.

Also, jK tells me VFS_MAP not only doesn't work, but will never be implemented. So my idea of having the mod check if the map archive contains Lua folder or files is not possible.

So I say we go with smoth's idea, simple and more future-proof than complex config files:

Code: Select all

function widget:Initialize()
  if VFS.FileExists("nomapedgewidget.txt") then
    widgetHandler:RemoveWidget()
    return
  end
  -- rest of Initialize ....
end

[knorke]

If the mapper has a precise idea of the kind of grid he wants, he'll put a nomapedgewidget.txt and his own grid widget anyway.

true.
And if the mod wants different looking mapedges for different maps (eg red edges on "red mars", yellow edges on "banana dunes") then the mod can include its own config stuff.

So nomapedgewidget.txt it is?
A Spring.Echo ("found nomapedgewidget.txt, removing myself") before the
widgetHandler:RemoveWidget()
might be good.

[luckywaldo7]

Pfff, you programmers and your difficult solutions.

Take a texture like Forb's and change the white to transparency, and magically get grid color matching to maps:

[PicassoCT]

Never has a new mod announcement been so unloved =(

Dont saying anything about such a new mod, without a Lawyerlayer between me and my post

As my mandate said allready, we remain silent until our iNoSense is proofen.

[Forboding Angel]

Excellent solution waldo.

I dunno why everyone jumped on the bandwagon that they had to do it exactly the same as I did or else.

What is proper and good for evo may not be proper and good for every other game out there.

[zwzsg]

And if the mod wants different looking mapedges for different maps (eg red edges on "red mars", yellow edges on "banana dunes") then the mod can include its own config stuff.

There are varied advanced techniques to let the map read colors of the map textures. No need for config.

So nomapedgewidget.txt it is?

Yes. Let's just go with it.

Maybe you noticed Smoth used upper case and I used lower case? That is, because, from the mapper perspective, the file can be created with any case. But Spring VFS converts all to lowercase. So in the Lua, it has to be lowercase. I just tried and the Lua callout VFS.FileExists doesn't care about case either.

A Spring.Echo ("found nomapedgewidget.txt, removing myself") before the
widgetHandler:RemoveWidget()
might be good.

Modders / Edge Widget Coders are free to change the details of the implementation, as long as they adhere to the specification.

[smoth]

Take a texture like Forb's and change the white to transparency, and magically get grid color matching to maps

Not everyone wants a grid.

forb:
No one jumped a band wagon, as usual people are ignoring the rest of the thread.

z/k:
I think it should not be called grid in the config, just mapborder.
There are 3 map border widgets not all of them are grids.

the problem with those tags being named grid anything is that it assumes a grid. I also think it is dangerous to add tags to a config for features not yet implemented... however, it makes sense in this occasion I feel. Like I said, I am not particular for either way so if you and knorke want to debate this and decide a solution I am down with that, I don't want another map options debaucle.. I am tired of re-re-redoing shit.

[zwzsg]

To plan an interface to let the map configure the mod widget is insane!

- We cannot predict now all the kind of map-border-cover that will emerge.
- We cannot predict now all the kind of customisation people will want.
- The more complicated an interface, the less people use it right.
- If the mapper already know what kind of map-border-cover he wants, he can, nay, he'd better, implement it map side.

Can we just agree on the "NoMapEdgeWidget.txt" thing and move along?

[smoth]

Fine with me.

[azaremoth]

Can we just agree on the "NoMapEdgeWidget.txt" thing and move along?

That sounds good to me - I`ll include whatever working widget in my game.

[smoth]

I cannot make any promises, but I will try and get kr's widget working a bit better this weekend. If I do succeed I will post the updated source.

Also don't forget pako's widget:

other stuff.
The lack of fog on your terrain really hurts it imo.

I fixed it and few other bugs but now engine(84.0) fog shaders are all fogged up.

I am still awaiting the update, I will include both in grts and will add the check code to both. personally, I think they are both nice, so I want to see them both working :)

[Pako]

Less than final version of the fixes.

[Mr. Bob]

I still don't understand why using models wouldn't work.

It's possible I'm missing something horribly obvious here...

[smoth]

Your post is hard to follow, what tool flow are you describing? how do you think maps work in games?

[Mr. Bob]

The workflow chain would look something like this:

1.) Conceptualization/Mechanical-Theory - Self explanatory. How would it look and how would it behave etc. Basic layout and art direction. (No tools needed yet.)

2.) Graybox Interior Map Model - This would include the bit of the map that the units actually walk on etc. (Any sculpting program would work here. Even a terrain editor would work, provided you can export the mesh.)

A. Note that if your map is irregular in design when it comes to the actual environment (like a map made entirely out of metal with mechanical parts everywhere and no real hill/mountain structure) you could simply combine this step with "3)" and separate the "map" mesh with the "decor" mesh.

3.) Graybox Exterior Mesh Model - This would be everything outside of the walkable map on to the horizon. This would also be the "edge" structure of the map. (Cliffs, walls, ravines, etc.) It's nice to have an obvious edge to the playable map as it let's players know where their bounds are exactly without having some ugly fog/mask effects. (Any modeling software. Max, maya, mudbox, softimage, etc. Depending on the art style for the environment, you may or may not need a sculpting program.)

A. Note that if your map is something like an island, or on the coast, your outside mesh doesn't need to go on to the horizon as the water does that for you.

B. The "edge" structures can intrude on the "map" boundaries itself, as you can just block off those areas in the pathing map.

4.) Planar wrap the Interior Map Mesh - For the obvious reasons. Don't paint the texture yet though. Just wrap it.

5.) Wrap the Exterior Mesh Model - The way you wrap this depends on what is in the model itself. If it's it a hill/mountain esque mesh then planar is probably the way to go. If it's more complex, then piece-by-piece mapping is probably needed.

6.) Temporarily Combine the Interior and Exterior for the Texture - For this you'd combine both the map mesh and the outside mesh for texturing. Don't paint using a 2d paint program like photoshop. That would be silly. Use a 3d sculpting program that supports painting. (Mudbox, zbrush, etc)

A. Make sure the texture for the exterior mesh is somewhat scaled correctly to the texture of the interior mesh. This will vary depending on the complexity of the outside mesh.

7.) Paint Pathing/Feature/etc maps onto the UVW of the Interior Map Mesh - Using a 2d painter program is preferred here, I guess.

8.) Separate the Exterior and the Interior Mesh - Prep for baking and exporting.

9.) Bake from the Interior Map Mesh - Now bake the interior mesh for the heightmap. (Use whatever modeling program you are using to achieve this. Either do a distance bake or just wrap it cylindrically with a grayscale and render it orthographically from the top.)

10.) Export the Exterior Mesh - Prep your exterior mesh and texture for usage. Use it as a feature, and place it at the exact center of the feature map.

A. Make sure to keep everything scaled correctly. It would be undesirable to have the interior and the exterior not correspond.


----

It sounds a bit overkill sure, but that's because there is no editor that can do these basic operations for you. You'd have to do them manually.

The reason this would be so much better, is that it brings artistry back into the art itself. I think a big problem with the way maps are being made here, is that it's so code driven that there is no real art aspect to them. Now, this is not to say good jobs haven't been done. No disrespect meant there ofc, as there have been numerous amazing maps made. But this would just be a more streamlined and logical approach to it. Art should be made artfully.

As for how other games do it, to my knowledge, it's mostly done the way I mentioned above. The difference is that there is an editor that does a lot of the menial operations for the artist. (Things like generating the heightmap for the playable area and separating the two mesh structures.)

LOT'S OF TEXT.



Here's the condensed version.

Since the outside map isn't interacting with the units, it can just be a big feature.

Any part of the feature that is inside the map bounds can be blocked using the pathing map.