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

[zoot]

I honestly don't know why everything has to be conflated with triggers. Triggers are just a dumbed down way of doing scripting. There is nothing "powerful" about them other than the fact that it enables ordinary folks to create interesting maps.

They would not be suited for any of the issues listed above.

[Spahbod]

I think I found the cause of the problem. The line (or lines in some cases!) seem to be generated because the painter sees those tiles as "player tile class constraint". I'm not sure about the core of the problem so I'd leave this report just here for now.

I honestly don't know why everything has to be conflated with triggers. Triggers are just a dumbed down way of doing scripting. There is nothing "powerful" about them other than the fact that it enables ordinary folks to create interesting maps.

They would not be suited for any of the issues listed above.

Triggers are a way other than AI to change the simulation via scripting. As AIs are too specialized, they are of not much use in developing a "dynamic" scenario.

[zoot]

Triggers are a way other than AI to change the simulation via scripting. As AIs are too specialized, they are of not much use in developing a "dynamic" scenario.

Sure, as I said, they can be used to make interesting maps. But that's about it. They don't have any applicability to the tickets listed above.

[Spahbod]

OK. I fixed the problem in unknown maps. But it's just a hack and to be honest, I don't know why it worked. The core problem is still there and I am going to find it. The way it appears just in the northern sections of the map and that the lines are always horizontal convinces me that there is a problem in either tileclass or painter logic. Funny that we hadn't encountered them before.

[Pureon]

Thanks for looking into it Spahbod

[FeXoR]

Sure, as I said, they can be used to make interesting maps. But that's about it. They don't have any applicability to the tickets listed above.

No, that concerned general game rules. I though I said that.

Changing things ingame and having access to more things in RMGEN as well as AI API (so you load a set of triggers just into the map that manages the AI players rather than the current approach) could be done with triggers (If powerful enough). So all parts get all information (currently RMGEN has about zero information about anything outside the map like entity properties and cannot manipulate anything outside map generation e.g. the possible player settings or build restrictions or the chosen mod).

Edited February 3, 2013 by FeXoR

[zoot]

No, that concerned general game rules. I though I said that.

Changing things ingame and having access to more things in RMGEN as well as AI API (so you load a set of triggers just into the map that manages the AI players rather than the current approach) could be done with triggers (If powerful enough).

Why conflate it with triggers? Why not use regular function calls and argument passing?

[FeXoR]

That would be OK for me too but you'd have a great amount of data very close or even right inside the engine. I thought that would be not wanted and a layer between is already implemented (simulations). If it can be used easy to implement triggers there (or not even needed) we just have to change the map loading/random map generation part. But still that would be a lot of work. On the other hand it would still not work to restrict map/player settings dependent on the map used because simulations is started with the engine after game settings are chosen. So the engine has to run while map/player settings are chosen or a restriction for possible map settings has to be loaded before opening the settings screen (e.g. a settings file for all maps like for random maps it is JSON right now).

So back to your question: Because then we would have only one layer of code to maintain and in it very general functions that can be used by more than one part of the game (e.g. RMGEN/AI) instead of parsing data to every part separately. Another example is the terrain analysis that could be done right at map generation and then can be used by the AIs or even pathfinding.

You still might be right that I am overrating triggers. Perhaps because I loved how to manipulate maps in Warcraft III. But I'm not the only one. It was so simple and intuitive that a vast amount of maps came out of that some even followed by an own game for this map e.g. Defense of the Ancients: http://en.wikipedia....of_the_Ancients and here an in-game video:

...resulting in this game: http://blog.dota2.com/ and an in-game video:

NOTE: Wikipedia states DotA would be a mod but actually it's just a map. WC3 just allows wide manipulation of maps.

DotA 2 however is an entirely different game!

Edited February 3, 2013 by FeXoR

[Spahbod]

I found the core of it at last. The tileclass logic indeed has some problems as it can't handle decimal numbers as radius in "some" cases. Easy fix in the map itself.

[zoot]

So back to your question: Because then we would have only one layer of code to maintain and in it very general functions that can be used by more than one part of the game (e.g. RMGEN/AI) instead of parsing data to every part separately. Another example is the terrain analysis that could be done right at map generation and then can be used by the AIs or even pathfinding.

But why call it triggers when everybody understands something completely different by that term? Why not just call it 'a set of common functions' or 'an API' or something equally meaningful?

[FeXoR]

I found the core of it at last. The tileclass logic indeed has some problems as it can't handle decimal numbers as radius in "some" cases. Easy fix in the map itself.

Which lines?

Sorry edited my last post after you added your's but it's way OT anyway ^^.

EDIT: Oh, didn't read the last one.

But why call it triggers when everybody understands something completely different by that term? Why not just call it 'a set of common functions' or 'an API' or something equally meaningful?

Not sure. Perhaps because I'm in love with them ^^ (See the ending of my previous post).

Edited February 3, 2013 by FeXoR

[zoot]

That would be OK for me too but you'd have a great amount of data very close or even right inside the engine. I thought that would be not wanted and a layer between is already implemented (simulations). If it can be used easy to implement triggers there (or not even needed) we just have to change the map loading/random map generation part. But still that would be a lot of work. On the other hand it would still not work to restrict map/player settings dependent on the map used because simulations is started with the engine after game settings are chosen. So the engine has to run while map/player settings are chosen or a restriction for possible map settings has to be loaded before opening the settings screen (e.g. a settings file for all maps like for random maps it is JSON right now).

I'm not sure what you mean by 'engine' here? The engine is, AFAIK, generally considered to be the pyrogenesis executable. So it is already running at game setup and passing values from game setup to RMGEN should be quite trivial. Do we disagree on that?

Edited February 3, 2013 by zoot

[FeXoR]

I'm not sure what you mean by 'engine' here? The engine is, AFAIK, generally considered to be the pyrogenesis executable. So it is already running at game setup and passing values from game setup to RMGEN should be quite trivial. Do we disagree on that?

OK, maybe I mean the game engine (simulations?) that is not run when pyrogenesis is executed but after the map is loaded (or loads the map). And in case of a random map it is first generated by RMGEN and then loaded AFAIK. Not sure how to name it, I'm very bad of following naming conventions, sorry.

If parsing data to RMGEN is trivial please tell me how to get the data for entities inside RMGEN.

Edited February 3, 2013 by FeXoR

[zoot]

OK, maybe I mean the game engine (simulations?) that is not run when pyrogenesis is executed but after the map is loaded (and in case of a random map it is first generated by RMS and then loaded). Not sure how to name it, I'm very bad of following naming conventions, sorry.

If parsing data to RMGEN is trivial please tell me how to get the data for entities inside RMGEN.

What kind of data do you need?

[FeXoR]

Mainly the entity data from the entity templates e.g. from binaries/data/mods/public/simulation/templates/structures/athen_defense_tower.xml

Of cause they have to be chosen from the used mod.

The ticket for that is: http://trac.wildfiregames.com/ticket/1589

Edited February 3, 2013 by FeXoR

[zoot]

Mainly the entity data from the entity templates e.g. from binaries/data/mods/public/simulation/templates/structures/athen_defense_tower.xml

Of cause they have to be chosen from the used mod.

The ticket for that is: http://trac.wildfire...com/ticket/1589

(I've left a response on the ticket.)

[Pureon]

Moving back to restrictions on the random map setup screens -

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.

Spahbod, wraitii, or zoot - Have any of you worked on this previously? Should FeXoR look into this task if he has time? Please let us know your thoughts.

[zoot]

I've looked through the code dealing with map setup in relation to triggers, and I don't think adding a few additional variables to the JSON should be too difficult, if FeXoR is willing to do it. Maybe Spahbod can implement it in the game setup UI, since he wrote it (I believe) and probably has the best overview of how it works.

Edited February 4, 2013 by zoot

[Spahbod]

I may not be able to do anything serious until early spring (in our calender) because university work is taking some time. So it would be good if FeXoR can do it if he has time.

Maybe Spahbod can implement it in the game setup UI, since he wrote it (I believe)

I didn't write the UI, just modified it (I think Brian was the main designer), but I agree that it should be implemented in the JSON files. Maybe an array like this:

"MaximumPlayers" : [3, 4, 5, 6, 7, 8, 8],

Should be added to the .json representing the maximum available players in each map size respectively (tiny, small, etc...). Gamesetup UI code will remove the extra options upon selecting size. Then all that remains is finding and adding the best max player choices for each map.

[Pureon]

Thanks for helping out guys.

Then all that remains is finding and adding the best max player choices for each map.

We can create a default setting that's automatically assigned to all random maps. If a specific map requires its own restrictions then it needs to be assigned manually to the map. The default setting would have minimal restrictions, something like:

8 players - medium or larger

6 players - medium or larger

4 players - small or larger

2 players - tiny or larger

[FeXoR]

(I've left a response on the ticket.)

For some reason I can't log into track ATM. The function should take the entity type string e.g. athen_wall_long (The base name of the xml file) and return an associative array including the data. To pick the right mod it would be handy to have the mod path as a variable or constant (not sure here, see below) or another identifier that takes care the right xml from the right path is chosen.

AFAIK it is planned to make a map enforce the use of a specific mod. So if the mod identifier should be a constant or a variable depends on when the RMGEN code is loaded (every time a RMS is loaded or only the first time?).

I may not be able to do anything serious until early spring (in our calender) because university work is taking some time. So it would be good if FeXoR can do it if he has time.

I didn't write the UI, just modified it (I think Brian was the main designer), but I agree that it should be implemented in the JSON files. Maybe an array like this:

"MaximumPlayers" : [3, 4, 5, 6, 7, 8, 8],

Should be added to the .json representing the maximum available players in each map size respectively (tiny, small, etc...). Gamesetup UI code will remove the extra options upon selecting size. Then all that remains is finding and adding the best max player choices for each map.

Agreed. Where do I find the Gamesetup UI code and the code that loads the RMS JSON files?

Edited February 4, 2013 by FeXoR

[zoot]

For some reason I can't log into track ATM. The function should take the entity type string e.g. athen_wall_long (The base name of the xml file) and return an associative array including the data. To pick the right mod it would be handy to have the mod path as a variable or constant (not sure here, see below) or another identifier that takes care the right xml from the right path is chosen.

I'll see what I can find.

AFAIK it is planned to make a map enforce the use of a specific mod. So if the mod identifier should be a constant or a variable depends on when the RMGEN code is loaded (every time a RMS is loaded or only the first time?).

I don't think we'll need to mess around with mods, the VFS deals with that.

[zoot]

I'll see what I can find.

The relevant function is here: https://github.com/0ad/0ad/blob/master/source/simulation2/components/CCmpTemplateManager.cpp#L202

So we just need to yank that out of CCmpTemplateManager and put it somewhere where both CCmpTemplateManager and RMGEN can access it.

[FeXoR]

The relevant function is here: https://github.com/0...anager.cpp#L202

So we just need to yank that out of CCmpTemplateManager and put it somewhere where both CCmpTemplateManager and RMGEN can access it.

You hit it! And I have no clue how to do it the non-hacky way.

Edited February 4, 2013 by FeXoR

[zoot]

You hit it! And I have no clue how to do it the non-hacky way.

It shouldn't have to be too hacky. We just need to agree with other developers here on the place to put it. So, anyone else, suggestions?