Mood is a thing for

[Google_Frog]

Your gadget breaks ZK pretty badly. I'd happily add a modside gadget that blocks construction on certain terrain if you would be willing to add a configuration file to tell it which terrain types to block.

[knorke]

That would be best.
But instead of a config file (that is loaded once I suppose), I would say have the map include some function. That function would then be called by the mod.
So that the mod gadget would be like

Code: Select all

AllowUnitCreation(...)
return doesModAllow (...) and doesMapAllow (...)
end

So that the map can dynamically change where you can build. (like melting ice or a map where you have to capture something to build near it or building is only allowed in the first 5 minutes etc,..)

[zoggop]

Having a mod-side gadget sounds great. Would that mean that players would actually be shown where they can't build in the normal manner (with red footprint squares), and AIs wouldn't fail utterly? I like knorke's flexible implementation idea. Overkill for this map, but would allow for interesting future projects.

Of course, I went a little hack-happy and wrote a widget to generate a giant (4mb lua file ) build-order redirection matrix, and a gadget to use it via AllowCommand, so that bots can play on the map. Could the map somehow check if the mod is compatible with doesMapAllow() (or whatever it ends up being called), and use my nasty solution if the mod isn't compatible?

On an unrelated note, I'm making some changes to the map itself, mostly to make the southern rocks a more viable option.

[knorke]

Would that mean that players would actually be shown where they can't build in the normal manner (with red footprint squares),

No, but that could be done as well.
Here is some something half-done and some blabla:
http://springrts.com/phpbb/viewtopic.ph ... e+#p493354

and AIs wouldn't fail utterly?

It would require changes on the AI side as well. For RAI, KAIK,..it atm seems a bit unlikely that somebody will do it.
The LuaAIs eg CAI from zK might be easier to edit.
---
On the map itself, it looks ok from far-medium distance but near-up the edges of some rock areas look a bit ugly. Jagged/"saw-toothed" never look very good in Spring, so maybe smooth it out a bit. Then could add some features to bring back the spikeness.
I do not like the slowdown on sand, the sand covers like 80% of the map and so it is snailspeed anywhere outside your base..

[zoggop]

Thanks. The whole drawing of building placement may be a bit over my head, but I'll probably fiddle with it at some point.

Noted. The next release will be smoother (I applied a box blur to the rock masks).

Yeah, the sand being so slow has been more aggravating than interesting in play. What do you think about keeping the sand at default, and making the rocks a little faster? (I'll always make these things possible to disable via a map option like the sand slowdown is.)

Google_Frog, whatever form your gadget takes, just point me to it if you make it, and I'll make a config (or function).

[knorke]

function gadget:AllowCommand(unitID, unitDefID, unitTeam, cmdID)
....
Spring.Echo("Invalid build command: Only metal extractors can be built on sand.")

You should really remove the echo because it will spam its message to every player whenever somebody tries to build on sand.
To signal the nonbuildable sand to players, better change the mouse cursor or something like that. Or have buildings slowly sink into the sand, that way it is most obvious.

[zoggop]

I didn't realize it echoes to every player, but that makes sense. LOL buildings sinking into the sand. It seems cruel to make players learn the hard way, but it's awfully tempting. Changing the mouse cursor is a good idea.

Here's what the layout looks like now:


Whenever I finish with the new gadget, and Google Frog lets me know how the zK gadget will work, I'll post the new map.

[zoggop]

Rather than a mouse cursor, how about this as a visual signal for "building here would be BAD":



because if you do...

[Google_Frog]

If you're going to handle the behaviour in a special way that may be map specific a modside config may be superior.

How about I add a customparam override. The customparam would tell your gadget that the unit is not considered a normal structure. The creation of these units should not be interfered with.

Does ignoreplacementrestriction sound like a good name? It can take effect if set to "true".

[zoggop]

That would certainly be the easiest solution at this point. I'm hesitant to say superior because as cute as the sinking into the sand thing is, it's kind of pointless. If it creates the effect it's supposed to ("oh, building there was a bad idea"), then I may as well have just blocked the build command anyway.

To clarify, would all moveable units have ignoreplacementrestriction=true? Would ignoreplacementrestriction be set to false on all other units ("normal" structures that should be restricted), or nil?

[Google_Frog]

To clarify, would all moveable units have ignoreplacementrestriction=true? Would ignoreplacementrestriction be set to false on all other units ("normal" structures that should be restricted), or nil?

I set them all to "true" just to be safe although I don't think you should rely on it. Just add ignoreplacementrestriction to your current test to keep it compatible with games that do not use the customparam. If your check allows placement then ignoreplacementrestriction has no effect.

I have not set ignoreplacementrestriction for normal structures which means whether to allow placement is entirely up to you.

[zoggop]

Oookay, thanks. Map forthcoming.

[zoggop]

New version up for download. Widget informing players where not to build, sand-sinking, and AI build command redirection have been implemented. ignoreplacementrestriction has also been put into the UnitDefs check. Let me know if you find any bugs.

[knorke]

Did not play it yet, so just something on lua:
When run via spring.exe map&modoptions are nil. So things like this will cause error:

Code: Select all

if Spring.GetMapOptions().allow_sand_building == "1"

As result this might break too I think:

Code: Select all

line 129: if isNotValid[-cmdID] and teamInfo[4] then

Code: Select all

function widget:DrawWorld()
  if Spring.GetMapOptions().allow_sand_building == "1" then return end

widget could use widgetHandler:RemoveWidget() to disable itself maybe.

Code: Select all

  for uDefID, uDef in pairs(UnitDefs) do
    local customParams = uDef.customParams
    if (customParams) then
      if customParams.ignoreplacementrestriction then
        break
      end
    end
    if (uDef.extractsMetal == 0) and (uDef.maxAcc < 0.01) then --if it's not a metal extractor and does not move, it is not valid
      if string.find(uDef.tooltip, " Mine") == nil then --if it's a mine, it is valid
        isNotValid[uDefID] = true

This part is in both widget and gadget..imo not so nice because you have to pay attention to keep them identical.

Using echo to display messages at GameStart is mostly useless imo. Usually there is so much chat and spam from other lua that nobody reads it Do not have a better idea though :/

There is a AllowStartPosition callin that you could use to warn players who want to start on sand.

[zoggop]

All excellent points. Lol, I should have posted my lua code before the map to springfiles.

This in particular would make things so much cleaner:

widget could use widgetHandler:RemoveWidget() to disable itself maybe.

There is a AllowStartPosition callin that you could use to warn players who want to start on sand.

Ah yes, the dreaded start box.

Using echo to display messages at GameStart is mostly useless imo. Usually there is so much chat and spam from other lua that nobody reads it Do not have a better idea though :/

True. Maybe I can use openGL to post a giant centered message at the beginning of the game.

As for the isNotValid array creation in both widget and gadget... I suppose I could pass the array from the gadget to the widget via SendToUnsynced somehow, but I'm a bit confused as to if that would use bandwidth in a networked game.
edit: If so, not enough to matter (it's a 1-bit array).

[Google_Frog]

Start boxes are the standard. I have not used fixed or random in years.

[zoggop]

Start boxes are the standard.

I suppose because it's too much of a pain to put everyone in the right fixed start positions playing games on the internet? (Mostly I play LAN games.) I would say it would be easier to use fixed or random on this map, since it's 1v1 and there are only two start positions, but the last time I played on one of the major hosts I couldn't figure out how to even use anything but start boxes.

Anyway, however much start boxes irritate me, I'm writing some Lua for a visual warning on start positions in the sand when sand build restriction is turned on.

[zoggop]

wheeee


edit: so I was thinking... changing the movement speed on the rock with Lua is a terrible idea, because the pathcosts will be calculated before LuaRules takes effect. Anyone have a way around this?

[Anarchid]

I wonder if wrecks should sink into the sand, too.

On the rocks: are you generating them procedurally somehow? Otherwise, what's to prevent you from just setting a terrain-type with a speed-modifier there?

[zoggop]

I wonder if wrecks should sink into the sand, too.

Oh, yes, I wondered that too but had forgotten. Thanks for reminding me!

what's to prevent you from just setting a terrain-type with a speed-modifier there?

Well, this is already the case. But I want to be able to turn the speed-modifier off with a map option without compromising pathfinding. Or, you know, I could just pick one (speedy rocks or no). :-P