Kay so my ideal goal: Setting up some Game Attributes within a Module which in turn can be setup in the lobby of any map that uses the Module.
What I've got so far: Basically it works, but there are some strange behaviors that I'm not quite figuring out why they do what they do. The attributes from the module definitely show up in a map that uses the mod but they directly overlap on any Game attributes the map itself also uses. IE I can tell something is doubled up but its showing the same name of the map's attribute for both it and the one I'm pulling it from the module, I can tell they're different though because one of them only has three options (the way the map;s was setup) and the other has four(the amount I gave to the one in the module), and while the first three of that one are the same names as the map's, the fourth is definitely the name of the fourth option I'd given to the module's attribute.
Follow? So I think this is probably treading new ground here and I won't be terribly surprised if this functionality isn't 100% working(I was kinda just impressed it works at all), but does anyone have any prior experience with this they'd like to share?
ED: Further playing around with it reveals that if I remove any game attributes from the map's own box it'll then let the ones the module owns show up properly with proper name, yah it really looks like they inadvertantly overlap one another so realistically you can only have attributes coming from either a mod or the game and if you try both you gotta be very careful about which one's which since the map's ones over-write the module's ones.
Well I hit another snag and after plenty of experimentation found a solution to said snag:
The Snag: Game Attributes you create inside a module are not the same references when you then run a map that's using that module, the side effect is while things all look like they should, any functions from that module's library cannot properly match up the attribute to the game's lobby so they never successfully catch the ones that map's instance creates and thus they never work. I'm pretty sure this is a flaw in the inheritance that modules give to maps when it comes to these things, again its a little explored area so I'm not really surprised.
The Solution: Create your functions that do whatever needs to happen for each game attribute inside your module's library but be certain to give these actions a parameter which is a game attribute value. Next inside your map you need to call these actions and give them the map's interpretation of those game attributes as their parameters(one per lobby setting), voila the module's library can now properly see the setup your map's lobby created before launching it on battle.net and do what it needs to for those game attributes to affect the game as you wanted them to.
Very simple example:
I have a game attribute called Fog of war with two settings, on and off that you can toggle in the lobby.
In the library I have an action Lobby Setup - Fog of War(attribute value) that will true/false a boolean that is used elsewhere in the library.
In every map based on this library there needs to be a call to that action in its triggers and its parameter is the lobby game attribute for fog of war.
Now the library can successfully use this game attribute and the true/false boolean gets properly toggled for the places where it uses it.
This does take away from the all encompassing module owns all the game engine concept and adds a little more trigger creation to each map based upon it, but so far its the best solution I've been able to come up with. I'm Currently researching templates to at least reduce the amount of stuff a new map needs manually adjusted to fully use such a library.
For anyone who is running into this problem I want to take a second to further clarify exactly what it is and what BumpInTheNight's solution was.
Basically the problem is that when you use game attributes in a mod file, they will show up in the lobby for the map using the mod file, but the selections people make using your game attribute will not get carried over to any actions in the mod file naturally. You have to create an action definition in your mod file with parameters of the type "Attribute ID (Game)"
You need to USE these parameters inside the action definition for any calls to the game attribute. In the map file you need to use your action definition and select the equivalent parameters in the map. This way when you call the game attributes in your action it is using the ones from the map and not the ones from the mod file (they appear to be different instances of the same attributes). Hopefully that is understandable. If you have any questions please feel free to email me at [email protected] or add me on skype as 'rtschutter' because I do not check sc2mapster very often.
BumpInTheNight - I know this thread is 3 years old and you haven't signed in for more than 2 years, but I wanted to take a second to thank you for your post. So often people run into a problem, ask about it on the forum and then when they get no reply they never come back and report any solution they may have found.
But your post saved my ass. And I would like to paypal you $20 to grab lunch or a couple of beers with. I will send you a PM as well and hope it shows up in your email or something.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Kay so my ideal goal: Setting up some Game Attributes within a Module which in turn can be setup in the lobby of any map that uses the Module.
What I've got so far: Basically it works, but there are some strange behaviors that I'm not quite figuring out why they do what they do. The attributes from the module definitely show up in a map that uses the mod but they directly overlap on any Game attributes the map itself also uses. IE I can tell something is doubled up but its showing the same name of the map's attribute for both it and the one I'm pulling it from the module, I can tell they're different though because one of them only has three options (the way the map;s was setup) and the other has four(the amount I gave to the one in the module), and while the first three of that one are the same names as the map's, the fourth is definitely the name of the fourth option I'd given to the module's attribute.
Follow? So I think this is probably treading new ground here and I won't be terribly surprised if this functionality isn't 100% working(I was kinda just impressed it works at all), but does anyone have any prior experience with this they'd like to share?
ED: Further playing around with it reveals that if I remove any game attributes from the map's own box it'll then let the ones the module owns show up properly with proper name, yah it really looks like they inadvertantly overlap one another so realistically you can only have attributes coming from either a mod or the game and if you try both you gotta be very careful about which one's which since the map's ones over-write the module's ones.
Well I hit another snag and after plenty of experimentation found a solution to said snag:
The Snag: Game Attributes you create inside a module are not the same references when you then run a map that's using that module, the side effect is while things all look like they should, any functions from that module's library cannot properly match up the attribute to the game's lobby so they never successfully catch the ones that map's instance creates and thus they never work. I'm pretty sure this is a flaw in the inheritance that modules give to maps when it comes to these things, again its a little explored area so I'm not really surprised.
The Solution: Create your functions that do whatever needs to happen for each game attribute inside your module's library but be certain to give these actions a parameter which is a game attribute value. Next inside your map you need to call these actions and give them the map's interpretation of those game attributes as their parameters(one per lobby setting), voila the module's library can now properly see the setup your map's lobby created before launching it on battle.net and do what it needs to for those game attributes to affect the game as you wanted them to.
Very simple example:
I have a game attribute called Fog of war with two settings, on and off that you can toggle in the lobby.
In the library I have an action Lobby Setup - Fog of War(attribute value) that will true/false a boolean that is used elsewhere in the library.
In every map based on this library there needs to be a call to that action in its triggers and its parameter is the lobby game attribute for fog of war.
Now the library can successfully use this game attribute and the true/false boolean gets properly toggled for the places where it uses it.
This does take away from the all encompassing module owns all the game engine concept and adds a little more trigger creation to each map based upon it, but so far its the best solution I've been able to come up with. I'm Currently researching templates to at least reduce the amount of stuff a new map needs manually adjusted to fully use such a library.
For anyone who is running into this problem I want to take a second to further clarify exactly what it is and what BumpInTheNight's solution was.
Basically the problem is that when you use game attributes in a mod file, they will show up in the lobby for the map using the mod file, but the selections people make using your game attribute will not get carried over to any actions in the mod file naturally. You have to create an action definition in your mod file with parameters of the type "Attribute ID (Game)"
You need to USE these parameters inside the action definition for any calls to the game attribute. In the map file you need to use your action definition and select the equivalent parameters in the map. This way when you call the game attributes in your action it is using the ones from the map and not the ones from the mod file (they appear to be different instances of the same attributes). Hopefully that is understandable. If you have any questions please feel free to email me at [email protected] or add me on skype as 'rtschutter' because I do not check sc2mapster very often.
BumpInTheNight - I know this thread is 3 years old and you haven't signed in for more than 2 years, but I wanted to take a second to thank you for your post. So often people run into a problem, ask about it on the forum and then when they get no reply they never come back and report any solution they may have found.
But your post saved my ass. And I would like to paypal you $20 to grab lunch or a couple of beers with. I will send you a PM as well and hope it shows up in your email or something.