Spring RTS Engine

I have just implemented a metalmap replacement for ZK. In other words the metalmap now has no use beyond metal spot generation. Game-side overrides and map configs have been included.

What does this mean for mappers?

• Mappers can ignore the metalmap and instead include a config file.
• Broken metal layout it can be fixed gameside.
• Cloud metalmaps are even more unwanted.

I don't know if a standard was proposed when Evo included easymetal but in any case there doesn't appear to be anything in use. So I made one myself based on what was convenient.

Basically the config file looks like this, is called map_metal_layout.lua and should go in the base directory of the map. If that is a bad name or location it can go somewhere else but I would rather not change the return format. The metal variable is optional. If it is not present the metal value will be read from the metalmap and if that is 0 it will be set to a default value.

So, there it is if anyone wants to use it.

What does mapper benefit from this? Besides the difficult way of configuring metal spots with coordinates.

Editing a text file is way more time consuming than clicking a spot in the metal map image.
I love how ZK labels everything they dont like as 'broken' (see wind, gravity, maxmetal).

I hope you realize this can result in samey and stale 'flat' gameplay on every map.

So you're not interested, that's fine. Detection works with most of the current maps and aims to retain the metal distribution balance of a map. There are still super mexes.

As for placement you wouldn't edit a text file. You'd use an as yet unwritten widget to click on the map a few times to send properly formatted coordinates to a file.

Beherith wrote:Editing a text file is way more time consuming than clicking a spot in the metal map image.
I love how ZK labels everything they dont like as 'broken' (see wind, gravity, maxmetal).

I hope you realize this can result in samey and stale 'flat' gameplay on every map.

would take me 1 hours to add support for metal spot placement in feature placer..

Google_Frog wrote:I have just implemented a metalmap replacement for ZK. In other words the metalmap now has no use beyond metal spot generation. Game-side overrides and map configs have been included.

What does this mean for mappers?

• Mappers can ignore the metalmap and instead include a config file.
• Broken metal layout it can be fixed gameside.
• Cloud metalmaps are even more unwanted.

I don't know if a standard was proposed when Evo included easymetal but in any case there doesn't appear to be anything in use. So I made one myself based on what was convenient.

Basically the config file looks like this, is called map_metal_layout.lua and should go in the base directory of the map. If that is a bad name or location it can go somewhere else but I would rather not change the return format. The metal variable is optional. If it is not present the metal value will be read from the metalmap and if that is 0 it will be set to a default value.

So, there it is if anyone wants to use it.

I want to have your children. As of my next map I will be using it. If there is already a metal map will the lua override it (this owuld be preferable)?

smoth wrote: would take me 1 hours to add support for metal spot placement in feature placer..

Won't even take me that long. You knwo the metal spot feature in spring features? I'm going to start lying that feature, then strip it out of the dumped features txt and use it for mex spot configs.

Metal map creation in less than 1 minutes? Yes please.

Changing it later by editing a file? Yes please.

The epicly sexy part of this is that the game can change the layout on it's own. So different games could have different metal layouts of the same map.

Does this create the potential for dynamic metal maps that can alter during a game?

The support for dynamic metal maps has been in since .83

good idea.
Actually thought about that a while ago too:
http://springrts.com/phpbb/viewtopic.ph ... p&start=31

Since it would be possible to have different metalspot layouts in the same map, also come up with a standard for mapoptions for this?
---

Jazcash wrote:Does this create the potential for dynamic metal maps that can alter during a game?

Possible "since forever", in various ways. Spring gives complete enough controll about resources for that.
also play on mah maps.

This would be a good idea if googlefrog hadn't swapped out my easymetal algorithm for his new one. Instead of

Google_Frog wrote: What does this mean for mappers?

• Mappers can ignore the metalmap and instead include a config file.
• Broken metal layout it can be fixed gameside.
• Cloud metalmaps are even more unwanted.

It would be

What does this mean for mappers?

• Mappers can ignore the metalmap and instead include a config file.
• Broken metal layout it can be fixed gameside.
• Cloud metalmaps are instantly fixed

Beherith wrote:Editing a text file is way more time consuming than clicking a spot in the metal map image.
I love how ZK labels everything they dont like as 'broken' (see wind, gravity, maxmetal).

I hope you realize this can result in samey and stale 'flat' gameplay on every map.

fixing the unpolished aspects of the engine doesn't really affect gameplay (unless you hold that 'bugs are features' mindset).. the only effect this really has is to give metal extractors a standardized radius and allow the snap-to-position mex placement (which is awesome).

1v0ry_k1ng wrote:the only effect this really has is to give metal extractors a standardized radius and allow the snap-to-position mex placement (which is awesome).

I find it irritating that Evo has had this for over a year and no one bothers to notice, but zk adds it and it's a "Brand new feature to the engine omgomgomgomimgoingtocumimgoingtocumimgoingtocum!!!!111eleventyone1!"

To be fair CarReparirer made easy metal years ago for CA and CAK..

More interesting if modified to allow for multiple map-based resources (though without proper engine support for that it'll always fall short - For some game designs 'cloud' maps would be quite nice indeed)

Related: now that we're getting coordinates of the metal at start up, could we get a gameoption to add a graphical patch for maps that have invisible or poor-visibility metal patches? Many old maps have invisible metal.

Pxtl wrote:Related: now that we're getting coordinates of the metal at start up, could we get a gameoption to add a graphical patch for maps that have invisible or poor-visibility metal patches? Many old maps have invisible metal.

I believe there already is such a thing, ask forb.

Pxtl wrote:Related: now that we're getting coordinates of the metal at start up, could we get a gameoption to add a graphical patch for maps that have invisible or poor-visibility metal patches? Many old maps have invisible metal.

There is already a map widget that does it (and btw the way it does it is fucking retarded).

The only thing left to do is to have a widget that places geovent textures where geovents are, because we can now place geovents with lua.

I started on one, but I couldn't get any further with it due to lack of knowledge/experience working with lua. The sauce is in the lua forum.

Licho wrote:To be fair CarReparirer made easy metal years ago for CA and CAK..

Yeah, and you guys snubbed your noses at it. Your loss is my gain.

There can only be 1 reason Car cares so much about cloud metal maps: Azure Rampart is his favorite map!