I know, it's a horrible topic name, but I couldn't think of a better one.
It would be nice if the map could communicate locational information to Lua gadgets. This allows for mappers to communicate gadget-specific information to (presumably) mods, without actually including the content themselves and thus being drawn into a whole host of quandaries, including making sure that their maps are still compatible with all mods and ensuring that the content is up-to-date and the like.
Say you have a mod set in a fantasy setting and you want to spawn "wizard towers" at specific strategic points across the map. Naturally you'd need to know where to spawn the wizard towers on every map, so either you or the mapper would have to include that information somewhere that is accessible to the Lua gadget controlling wizard towers.
I figure that a separate map would be appropriate for this. The map would make RGB values of each pixel available to Lua, and presumably Spring would do some simple sorting for you on request i.e. returning a table with the xz coordinates of every pixel of a certain RGB value. The gadget then does with the values what it wishes. Of course, maps should not be required to provide a Lua map.
Naturally someone would have to maintain a list of who has claimed what values, so there's no overlap. (No worries about running out, there's over 16 million possible 8-bit RGB values, and if we are worried about running out of those the amount could be increased to over 4 billion by including an 8 bit alpha channel.)
This would be nice for lots of things - campaigns and mod-specific behaviors come to mind.
Map Lua Map
Moderator: Moderators
Cripes people, DO YOU LIKE MAKING FINICKY TEXTURES?
All you need is 1 simple text file to go with the map
All you need is 1 simple text file to go with the map
It's simple, it's clean, it's easy to maintain, it's compatible with whatever mods you want without having to "reserve space"... sorry... I'm still mad about having to compile feature-placement into the freaking map file even when I haven't made a map in like a year.modfeatures.txt wrote: [XTAPE]
OBJECTNAME,OWNER,X,Y,Z;
OBJECTNAME,OWNER,X,Y,Z;
OBJECTNAME,OWNER,X,Y,Z;
OBJECTNAME,OWNER,X,Y,Z;
OBJECTNAME,OWNER,X,Y,Z;
[SWS]
OBJECTNAME,OWNER,X,Y,Z;
OBJECTNAME,OWNER,X,Y,Z;
OBJECTNAME,OWNER,X,Y,Z;
OBJECTNAME,OWNER,X,Y,Z;
OBJECTNAME,OWNER,X,Y,Z;
[FUNTA]
OBJECTNAME,OWNER,X,Y,Z;
OBJECTNAME,OWNER,X,Y,Z;
OBJECTNAME,OWNER,X,Y,Z;
OBJECTNAME,OWNER,X,Y,Z;
OBJECTNAME,OWNER,X,Y,Z;
- Felix the Cat
- Posts: 2383
- Joined: 15 Jun 2005, 17:30
Textures are quite a bit more intuitive...
...and map compilation being bitchy is a whole other issue.
TBH with a small utility you can go back and forth anyways, so it's not a huge issue what the final file is.
If it were a text file I would be looking for something more like this:
It's more portable, if you then want to make a fantasy mod that uses wizard towers too, you can just copy-paste the gadget into your mod. Then if n00berhack wants SUBER UBAR DFENS TOWARS at the same places as the wizard towers, its relevant gadget can reuse the tag. Keeping tags generic and relevant to widget instead of mod also frees mappers from having to keep track of every mod's requirements and ever-changing content. Obviously some of this is still necessary but hopefully generic tags will encourage re-using of similar tags for different purposes.
...and map compilation being bitchy is a whole other issue.
TBH with a small utility you can go back and forth anyways, so it's not a huge issue what the final file is.
If it were a text file I would be looking for something more like this:
Code: Select all
//map -> lua definitions
//format:
//[tag #]
// x, z, [flag1, flag2, ...];
// x, z, [flag1, flag2, ...];
//[tag #]
// ...
//[END]
[1]
341, 118, 2
781, 229, 6
[2]
blah
[3]
blah
[END]
1. Might as well use the lua format
(then you don't need to write a custom parser, just Include() the file).
Note that the raw form for many of the definitions files is now lua
(ex: the unit FBI files are actually parsed by lua in SVN before being
passed on to the engine).
2. You could easily write a lua text / image converter using lua
itself and the lua GD library binding (it's what I used for the flag
atlas generation code in SVN)
3. There is a customParams section in unitdefs that might be handy
for defining the role of unit types for this sort of application. There's
also a "gaia" tag, that is yet to be used.
(then you don't need to write a custom parser, just Include() the file).
Note that the raw form for many of the definitions files is now lua
(ex: the unit FBI files are actually parsed by lua in SVN before being
passed on to the engine).
2. You could easily write a lua text / image converter using lua
itself and the lua GD library binding (it's what I used for the flag
atlas generation code in SVN)
3. There is a customParams section in unitdefs that might be handy
for defining the role of unit types for this sort of application. There's
also a "gaia" tag, that is yet to be used.
One thing you could do (and I think I tried this and it worked OK) is to include in your map archive a lua file something like:
LuaGaia\strategic_points.lua
And have this lua file define a lua table something like:
Then, in your gadget in your mod, you have the following kind of code in your gadget:
Now your gadget has a table named map_strategic_points that has a couple of coordinates for you to use, such as to spawn towers.
Of course, I was only messing around when I tried this and I don't know how well it would go in a proper mod.
Cheers.
LuaGaia\strategic_points.lua
And have this lua file define a lua table something like:
Code: Select all
map_strategic_points =
{
{100, 100},
{400, 100}
}
Code: Select all
function gadget:Initialize()
if not VFS.FileExists("LuaGaia/strategic_points.lua") then
' No information from the map - do something else?
else
VFS.Include("LuaGaia/strategic_points.lua")
end
end
Of course, I was only messing around when I tried this and I don't know how well it would go in a proper mod.
Cheers.
1. You might want to use pcall() around the VFS.Include()
call to make sure that any errors in the file are caught.
2. I generally find it cleaner to use the returned params
from VFS.Include() rather then generating globals (even
if the globals are only widget/gadget space globals).You
can see an example of this pattern if you trace the defs
parsing coding, starting at gamedata/defs.lua.
def.lua:
using.lua:
call to make sure that any errors in the file are caught.
2. I generally find it cleaner to use the returned params
from VFS.Include() rather then generating globals (even
if the globals are only widget/gadget space globals).You
can see an example of this pattern if you trace the defs
parsing coding, starting at gamedata/defs.lua.
def.lua:
Code: Select all
return {
key = value,
etc...
}
Code: Select all
local success, tbl = pcall(VFS.Include, "def.lua")
if (success) then
...
end
Such data would be of immense value to AIs.
Trepan is right a lua feature placement script is far superior.
However one can totally bypass the text editing and image editing stage entirely by writting a widget that autogenerates them and lets you use point and click style interfaces to place features ingame and export them.
The generated data can then be packaged with the map, and best of all its user friendly for noobs.
Trepan is right a lua feature placement script is far superior.
However one can totally bypass the text editing and image editing stage entirely by writting a widget that autogenerates them and lets you use point and click style interfaces to place features ingame and export them.
The generated data can then be packaged with the map, and best of all its user friendly for noobs.
Something like smoth mentionned a while ago:
http://spring.clan-sy.com/phpbb/viewtop ... 874#195874
I wasn't advocating a lua script over the current system texture placement
system, but rather was advising the use of the lua format instead of a custom
file format if such a thing is done. Note that the SMF format (and probably the
SM3 format), contains the raw feature data extracted from the texture, and
doesn't actually use the texture (afaict; trace the GetFeatureInfo call).
http://spring.clan-sy.com/phpbb/viewtop ... 874#195874
I wasn't advocating a lua script over the current system texture placement
system, but rather was advising the use of the lua format instead of a custom
file format if such a thing is done. Note that the SMF format (and probably the
SM3 format), contains the raw feature data extracted from the texture, and
doesn't actually use the texture (afaict; trace the GetFeatureInfo call).