RANDOM MAPS: Suggestions, Bug reports and Ideas about random maps here.

[Mythos_Ruler]

Is there a particular reason why the Iberians in Acropolis 7 (the southern acropolis) don't get any gates, when the Iberians in Acropolis 2 (the northern acropolis) get gates? In Acropolis 7, the southern ramp can be walled off but the wall segment is too short to support a gate, while the northern ramp can't even be walled off without rebuilding the walls.

I may fix this.

Also, the default AI in Acropolis 7 is Aegis Bot when at least most of the other maps have qbot as the default AI instead.

Not sure why this is a problem.

[FeXoR]

Is there a particular reason why the Iberians in Acropolis 7 (the southern acropolis) don't get any gates, when the Iberians in Acropolis 2 (the northern acropolis) get gates? In Acropolis 7, the southern ramp can be walled off but the wall segment is too short to support a gate, while the northern ramp can't even be walled off without rebuilding the walls. Also, the default AI in Acropolis 7 is Aegis Bot when at least most of the other maps have qbot as the default AI instead.

First: Acropolis is a scenario, not a random map so I don't touch it and this thread is about random maps.

Perhaps Aegis Bot can handle adding gates to walls/closing walls? Not sure. Have you tried to play it with the Iberian player in question being Aegis Bot?

That the walls can's be closed/closed only with short/medium wall segments is indeed bad.

EDIT: I've tested it and indeed the bottom entrance can only be closed by a medium wall part directly. The top entrance can't be closed directly because some areas along the line is to step to build there.

However, you can build indirectly (with a corner) and so ensure a long wall part on both entrances.

I agree though that the gaps should be made so that closing the walls lead to a long wall part so gates are possible.

Edited December 20, 2012 by FeXoR

[Zeta1127]

The use of a different default AI is merely a curiosity, I am really just concerned about the gate situation.

Edited December 21, 2012 by Zeta1127

[Spahbod]

Fixed some of the bugs, including the chicken one and unreachable trees. Also fixed an ancient, annoying bug with placers that cause unusual behavior around the map edges (See the screenshot: Right:Before, Left:After).

[FeXoR]

Spahbod: Good job!

Have you seen this?: http://www.wildfireg...=60#entry257300

It does not seam to be added though you seam to want it ^^.

Edited December 21, 2012 by FeXoR

[Spahbod]

Spahbod: Good job!

Have you seen this?: http://www.wildfireg...=60#entry257300

It does not seam to be added though you seam to want it ^^.

It is already added in http://trac.wildfiregames.com/changeset/13004#file32

These should have been committed sooner (maybe before alpha 12) just if my python script didn't wreak havoc in my workspace.

[zoot]

On the random map "Canyon", I get this error when starting a match with just 1 player:

ERROR: JavaScript error: maps/random/rmgen/pathplacer.js line 62
Error: invalid arguments
  ([object Object])@maps/random/rmgen/pathplacer.js:62
  ([object Object],[object Object],[object Object])@maps/random/rmgen/map.js:238
  createArea([object Object],[object Array],null)@maps/random/rmgen/library.js:373
  @maps/random/canyon.js:335
ERROR: CMapGeneratorWorker::Run: Failed to load RMS 'maps/random/canyon.js'

[Spahbod]

On the random map "Canyon", I get this error when starting a match with just 1 player:

ERROR: JavaScript error: maps/random/rmgen/pathplacer.js line 62
Error: invalid arguments
  ([object Object])@maps/random/rmgen/pathplacer.js:62
  ([object Object],[object Object],[object Object])@maps/random/rmgen/map.js:238
  createArea([object Object],[object Array],null)@maps/random/rmgen/library.js:373
  @maps/random/canyon.js:335
ERROR: CMapGeneratorWorker::Run: Failed to load RMS 'maps/random/canyon.js'

Hmm. I think it is true for many other maps. The basic problem is that it doesn't understand how a canyon map with one player should look like. I don't know if it is worth a fix because 1:it's only in Atlas and 2:even if it doesn't return an error, still the result won't be playable.

[zoot]

It's not in Atlas - I can create 1 player games in-game.

[Spahbod]

Oh, you're right. But why should we be able to do such a thing ? I don't see any reason behind being able to create 1 player maps in gamesetup. Shouldn't we remove that option or something?

[zoot]

I agree, it probably should be removed (though I do use it for testing ).

[feneur]

It can be useful for "sandbox" games where the player just wants to experiment with basebuilding etc, but presumably it ought to be possible to have two players set, and then set the other player to unassigned. Hmm, just tried that and remembered that the other players starting units/buildings still get placed. Would it be possible to add a "Sandbox" game mode where enemy players are calculated, but their units/buildings aren't actually placed or something?

[zoot]

I think it would be most robust to agree to the convention that all maps should be able to support 0 to 8 players. I can't imagine that it would be outright impossible to fix Canyon (and others?) to support less than 2 players. It can just be a lower priority thing, if Spahbod doesn't have time right now.

[Spahbod]

I think it would be most robust to agree to the convention that all maps should be able to support 0 to 8 players. I can't imagine that it would be outright impossible to fix Canyon (and others?) to support less than 2 players. It can just be a lower priority thing, if Spahbod doesn't have time right now.

It can be done. Only that the map layout will be broken in this case so not much of good use.

[Zeta1127]

Should I make a thread like this about scenarios then, because I know of a few more scenario issues?

[FeXoR]

Sounds good to me. Not sure who has most experience/organizes scenarios and if he would like so say some words in the opening post.

[Zeta1127]

It would probably be best for someone who has actually made scenarios to create such a thread, but I will gladly provide my observations on maps.

[Pureon]

Could this map (part of Unknown Land) have the horizontal straight line of land removed:

The same line can be seen in this video of a different game:

http://youtu.be/LrUQ2TIHpwI?t=1m16s

Thanks

[Spahbod]

Could this map (part of Unknown Land) have the horizontal straight line of land removed: The same line can be seen in this video of a different game: http://youtu.be/LrUQ2TIHpwI?t=1m16s Thanks

This is the weirdest thing I have ever seen in random maps. Thank you for your report. I'll see if I can find the cause.

[Pureon]

Sorry I forgot to specify the map was a 3 player game on medium size. Maybe that'll help track down the error.

[FeXoR]

It happens on: Unknown Land, Medium, 3 Player, Seed 2560 (Just an example of cause. In this case it closes the gulf instead of only dividing it though)

I think the code for this is line 949-1054.

This seams to be a Gulf of Bothnia map though the bug seams never to appear on this map. The difference seams only to be the chosen biome and that the gulf is always opened to the south on Gulf of Bothnia but Unknown Land can have the gulf be opened anywhere.

Hope that helps.

Investigating further...

NOTE: For maps like The Unknown/Unknown Land it would be good to be able to call a random map instead of putting all the code in one map IMO. That way we wouldn't have to debug two or more maps but only the map called (in this case Gulf of Bothnia) that doesn't seam to even be buggy at all.

Edited February 3, 2013 by FeXoR

[Pureon]

NOTE: For maps like The Unknown/Unknown Land it would be good to be able to call a random map instead of putting all the code in one map IMO. That way we wouldn't have to debug two or more maps but only the map called (in this case Gulf of Bothnia) that doesn't seam to even be buggy at all.

Yes I completely agree. Not only because it's easier for you guys to debug, but also because we can include other land maps to the mix. Unknown land is probably the most widely used option for multiplayer games now, so adding more variety to it would be great.

Another task for you guys to look into would be to add restrictions to random map options. For example some maps, if not all, shouldn't be able to have 8 players on the smallest map sizes. Other maps only work with 4 or more players...

[FeXoR]

Yes I completely agree. Not only because it's easier for you guys to debug, but also because we can include other land maps to the mix. Unknown land is probably the most widely used option for multiplayer games now, so adding more variety to it would be great.

Another task for you guys to look into would be to add restrictions to random map options. For example some maps, if not all, shouldn't be able to have 8 players on the smallest map sizes. Other maps only work with 4 or more players...

I totally agree ^^. But AFAIK there's no way to limit options by the random map right now. I think this should be included in the random maps JSON file because it's the only thing loaded (if at all? Hope...) before map generation. Not sure who did the JSON approach in the first place. Maybe he could look at it. I have no idea how to do this. If no one is willing to do this I'll look into it though when I have time.

Edited February 3, 2013 by FeXoR

[wraitii]

I believe this was discussed and agreed upon at some point, but it has not been implemented (at all) now.

[FeXoR]

This all would be so easy if everything was trigger based (Just dreaming I guess ^^).

For example it would be nice to have an array "players" in RMGEN that has properties like e.g. "slotStatus" that shows if the player is a person or an AI.

Not to mention the entity properties that would help a lot to have access to in RMGEN...

Well, guess we should focus a bit and for now on performance:

http://www.wildfireg...showtopic=16991

...and cleaning up the general game rules (that are pretty a mess right now IMO):

http://www.wildfireg...showtopic=16986

http://www.wildfireg...?showtopic=6352

...among others causing e.g.:

http://trac.wildfire...com/ticket/1496

http://trac.wildfire...com/ticket/1537

http://trac.wildfire...com/ticket/1010

...among others.

Still a wide variety of "features" (indeed most tickets issues) could be easily fixed by having triggers (which ofc. would take a huge amount of work and time to implement that widely/powerful in the first place) but would interfere with the actually implemented mod design (suggesting a much less powerful trigger approach like http://www.wildfireg...showtopic=16887).

Edited February 3, 2013 by FeXoR