That would be bad, what if I want to include a widget with maps, pfft too bad not included.

evorts/grts: game devs are also map makers -> can do whatever they want
kernel panic: only played on specials maps: should be no conflicts
S44: only played on specials maps: should be no conflicts, game devs also make the maps (i think)

So it is only really a problem for games that use the big pool of old "one size fits all" maps.
Since none of those maps include a mapedge widget, it would have to be in the game anyway. At that point it makes sense that this game-widget "listens" for maps "trying to turn it off" via config files. And new maps with such widgets should include such files.

But so far, no mapedge-widget-map has been made for any mapedge-widget-mod. And I guess not many mapedge-widget-maps will be made. Mods could also include a list on which maps to disable the widget. (eg on Beheriths asteroid map, maps that have a fog widget etc)

No, the problem is what I want the maps I make to be playable with the Cursed, EvoRTS, and even GRTS, without having the VR grid forced on me.

z, at what point does the project get to have control over it's world?

what if something like a noborder.txt was all you needed to add to ensure I don't do any grid shit to your map?

What is to keep players from installing it into their luawidgets and saying lol at your maps?

If that happens the widget should read the configfile in the map and turns itself off. Atm the widget does not have that function, so it should ideally not be spread among players.

and what if they disable the check. that is my point.

I would assume how the map looks belongs to the map. I'm ok with Forb's widget being used mod side as a failsafe when it's an old map that surely has unpretty border. I just want all you guys to settle on a method to autodisable it from the map when the map know what it does.

Tonight I tried my map project with the newly released Cursed, and was greeted by:



So I'm not bitching just for the fun of it, I want to release V3 of that map in the next few days, and I want it to look pretty with The Cursed, EvoRTS, GRTS, etc... without the player having to fumble with the widget list.

Sure, whatever, as long as everybody agrees to follow it.

I'm asking for all coders to find a solution NOW, hopefully before map edge widgets have spread to far, to make sure every map edge widget thing will follow the same standard way to get disabled.


Yes, if someone really wants to, he can always disfigure our work locally. That is not the point. The point is when a naive player download mod X and map Y, by default it works reasonably well without conflicts.

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:

Quote:

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.

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

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

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.

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.

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:

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.

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:

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

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.

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


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.



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

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.

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?