One of the worst feelings to have at the start of the game is when you've accidentally placed fac on your mex spot. While it doesn't happen too often, it's very frustating, and holds back your entire team. In 1v1, starting with one less mex can be hard to come back from. What are the reasons for letting people build on mex spots with things other than mex? I know that it's more realistic/consistent, but I would think quality of life more important? Cheers
+11 / -0
|
Would it be possible to highlight mex squares prurple whe building over them with anythihng other than a mex?
+0 / -0
|
Now that would be fun! Making a map that massively limits where you can place buildings by having 0.01 m mexes everywhere :D
+1 / -0
|
|
|
If you disallow building on metal, what are you going to do with maps covered with metal? I'm not talking only about SpeedMetal maps, but also those with variable and diffuse metal spots, like some versions of SmallDivide, where you get a large mex radius : http://springfiles.com/spring/spring-maps/smalldivideP.S.:I guess it could be a game option?
+0 / -0
|
I hadn't actually thought about speed metal... I dunno I sort of just assumed that it was changing a fundamental rule rather than placing mex spots over 100% of map. Which is the case? Large mex radius? Sorry I don't take your meaning. Room to build multiple mex in one spot?
+0 / -0
|
Mex radius is a BA thing. Featured and supported ZK maps don't (shouldn't) have metal radius and cloud maps, only discrete metal value points. Corollary 1: maps with cloud metal are not supported by ZK and are not a concern. Corollary 2: it should be possible to forbid non-mex building placement on metal points, for example, by having the gadget splat them with a special terrain type. Exceptions are "special" maps like speedmetal etc which could in this case have the restriction completely removed, liberating the players who pick such maps to build storages on metal spots. Should geospots be verboten in the same way?
+3 / -0
|
quote:
Should geospots be verboten in the same way? |
yes quote:
by having the gadget splat them with a special terrain type |
That's a bit extreme I think, why not just have the snap mex do the reverse check as well (snap outta mex).
+0 / -0
|
My thought was footprint, but then we already have stuff that interacts with footprint, e.g. skydust.
+0 / -0
|
In Spring all metal extractors have an extraction radius and metal is extracted from an area, not a point. (I suppose it works the same way for geothermal spots?) Those have just been both standardized in Zero-K to be the about the size of the metal extractor building (while if I'm not mistaken they can be modified by game options to be much larger to play on maps that don't have defined metal spots, see metalmap of the map I linked above, generally for that map the extractor radius was a bit smaller than that the range of a light turret).
+0 / -0
|
quote:
Now that would be fun! Making a map that massively limits where you can place buildings by having 0.01 m mexes everywhere :D |
There you go. I think many people hate that map. :)
+1 / -0
|
Zero-K does not have metal extractors. Blocking constructor on mex spots is fairly easy. Block structure placement in AllowCommand. Draw a red circle (or similar) when placing a structure on a mex spot. I'm not entirely sure that restricting placement is good but it is at least good to warn when placing on a mex.
+2 / -0
|
|
|
We just call that a metal extractor but actually it is not. In other words: Forall ud in UnitDefs, ud.isExtractor == false
+0 / -0
|
#00FPaladin, silly BingToad is talking about engine-definitions. ZK uses custom coded metal spot things, so the engine mex variable is not set. That means your second paragraph in [url=#140958]this post[/url] is wrong. In other words, we can "not have metal extractors", but when "Defender == LLT" then suddenly everyone panics 4nraisin. For more information see: https://github.com/ZeroK-RTS/Zero-K/blob/master/LuaRules/Gadgets/mex_placement.luahttps://github.com/ZeroK-RTS/Zero-K/blob/master/LuaRules/Gadgets/mex_spot_finder.lua
+1 / -0
|
Huh. What was the reason to introduce a new system? This feels like it has needed some extra work (and how does it even work with diffuse metal distribution maps like SpeedMetal?). Doesn't this create compatibility issues with Spring maps?
+0 / -0
|
quote:
What was the reason to introduce a new system? |
I assume multiple benefits like mex snap, custom metalmaps, one day the ability to just right click on spots to queue a mex and any other things that can now be introduced that were not possible before. quote:
and how does it even work with diffuse metal distribution maps like SpeedMetal? |
It disables itself for such maps. quote:
Doesn't this create compatibility issues with Spring maps? |
None that I know of. Most maps work, right? Many mappers happen to design their maps with simple metal spots that ZK can use anyway. Occasionally a map needs a few bug fixes and those are easy to create.
+0 / -0
|
It is hardly a new system, the gadget says that it is 3 years old. I forget the exact reasons at the time. Here is a list of what I can think of currently:
-
Spring extraction required some annoying hax in the overdrive gadget.
-
Once Area Mex (a required feature) is implemented, the whole extraction replacement system is not much more work.
-
We gained the ability to fix broken maps by overriding their metal map.
-
Mex circles and snapping are good UI.
-
Mex snapping widgets which are [u]not enforced[\u] by the game mechanics can create fighting against the UI. For example you may want to offset some mexes to protect against artillery. If the mechanics did not enforce particular mex placement then area mex and snapping would be a hindrance.
-
Cloud metalmaps were tried for several years and shown to have no merit.
+1 / -0
|
Relevant to the discussion :P  (Originally submitted by    Forever in the funny pic thread 29 months ago, bumped into it when rereading it. :) )
+3 / -0
|
I hate when I accidentally build storages on mex spots
+5 / -0
|
