Spring currently assigns each map texel a metal value. While that sounds theoretically like a great idea in practice it falls flat, maps either paint small blobs in the spots they want taken (with only limited control over how much they're worth) or produce a big mess and noone wants to play them. Meanwhile a lot of widgets and gadgets want to use the metal spot positions for autoplacing mexes or flags, requiring a big parse of the metal map to find the mex spots.
The whole metal map concept is a failure IMO and should be replaced with an old fashioned list of metal locations (or features that mark them for easier map design) that could easily be retrieved by widgets and gadgets. Sure, the old system can't be removed since that would break every damn map in existence but I hope we can switch this over so this whole mess gets resolved.
Metal spots instead of metal map
Moderator: Moderators
Re: Metal spots instead of metal map
what if we have a central metal-map parser in place?
make it globaly available to the engine, unitsync, AIs and al the LUa stuff.
If not to replace your idea, it could at least ease shifting to what you want a lot easyer, right?
The main problem that your suggestion solves and this one not, is the lack of controll the map makers have over the metal, as i see it.
make it globaly available to the engine, unitsync, AIs and al the LUa stuff.
If not to replace your idea, it could at least ease shifting to what you want a lot easyer, right?
The main problem that your suggestion solves and this one not, is the lack of controll the map makers have over the metal, as i see it.
Re: Metal spots instead of metal map
You mean as a way to automatically grab the mex spots from the metal map? I suppose that could be used as a fallback but there are many cases where automatic detection wouldn't really work (mostly when the metal on the map isn't distributed in spots). Also an automatic detection wouldn't have an easy time determining where on the blob on the metal map the mex should go.
Re: Metal spots instead of metal map
While we cannot manipulate the value of the metalmap (directly) we can already read its values via Lua and in the AI interface.what if we have a central metal-map parser in place?
make it globaly available to the engine, unitsync, AIs and al the LUa stuff.
If not to replace your idea, it could at least ease shifting to what you want a lot easyer, right?
The main problem that your suggestion solves and this one not, is the lack of controll the map makers have over the metal, as i see it.
The problem there is...
1. The insane system of multiples applied vs. metalmap values (i.e., mappers don't use anything like a consistent system) means that we're getting arbitrary values returned.
On one map, a metalmap pixel may come out as 50.321321, on another, it's 12398.2312, and that's entirely in the hands of the mappers. It's a terrible system. The idea was to provide flexibility, but in actuality, it means that mappers haven't gotten together and established anything like common standards- they have standards for what values they want to see, for *output*, but they do not use standard values for *input*.
2. I've developed various algorithms in World Builder over the last year to read these values and "find the metal". It's completely frustrating, tbh. On some maps, the mappers got "clever" and used wildly different values per spot, in order to "shape the gameplay", and on others, the mappers were just plain sloppy, and have fuzzy metal spots, that actually deliver a lot more metal than they would appear to, from a single-sample analysis (and doing analysis on every single metalmap pixel is pointless, since it's both very expensive timewise and tells us very little about where "spots" are- most AIs take so long to start in great part because of their heightmap and metalmap analysis stages).
So, even if I know the value of the multiple, and can then derive a metal output value... I still don't know if it's actually valid or not, according to the mapper.
In P.U.R.E., I decided to just ditch metal spots entirely. I think they're a stupid model, distract mappers from their main job, and interfere with the prerogatives of game designers. We'll see if it catches on or not- it'd only require very minor changes to OTA-style games to adjust their gameplay, and now that we have SpringMapEdit... we can actually remake old maps to not suck, without having to remake the diffuse texturemap, which is a very big deal- we no longer have to live with, "omg, all the maps will be obsolete", if we can re-adjust them and re-release them in less than 20 minutes.
I intend to release a new version of DSD made for P.U.R.E., to see if people enjoy that idea, since that seems to be the nub map of choice.
In terms of Spring... meh... there are no real fixes that wouldn't involve a new map format entirely. Meh... I want a new map format for various reasons anyhow, but I think it's more important that we get SMF / SM3 basically functional first. Meanwhile, we can do various things in Lua, including using Lua-based objects (i.e., World Builder, or something very like) to build entirely alternative models. We're really not stuck with Spring's current choices, by any means.