Verified, the effects are meticulously linked correctly.
Verified, problem exists only when running the map from the Mod file while referencing the map as the test map document default map.
Yes, I added a CrtPersistant to add offsets to the 2nd LM effect. The problem continues with or without that CrtPersitant effect (tested) when running from Mod but not when running directly from map. The problem is consistent.
I believe its a bug when running a map from a Mod file. My solution is to separate these effects into 2 separate autocast abilities.
I merged them together to avoid 1 unnecessary autocast scan, but I can't condone inconsistent results between map and mod, so I will separate them.
If the mod is on your test map, the game will actually load the mod twice. This will double any triggers, along with the contents of any effects (like set as you mentioned, but also things like persistents), and upgrades etc.
Basically you need a test version of your map, with the mod removed. Awkward I know.
That is terrible news. But, thanks for the info; it restores confidence and predictability to the data editor
This also means, I cannot test my project from my mod file. I cannot remove the mod dependency because my map triggers has many links to the data mod -it would break triggers.
Testing using a basic test map would work, but defeats the purpose of testing the project map by launching from the mod (to reduce load time).
There needs to be a switch or option within the editor to load a default test map that does not double load the matching mod dependency. -we would think this is kinda crazy obvious. awkward indeed.
BTW, I'm a fan of your maps and I wondered why your mapster account does not have your name in green font -as an author.
You *can* however, modify triggers in your mod file from your map using extra data... unless your using a purely data mod, in which case this doesn't help you at all.
i would suggest testing all data related stuff and libraries on a sandbox map. try to move as many triggers as you can into the mod. then just use test cheats to force run triggers and create units and actors
Wow, thats a good idea. I did not consider that. That would reduce alot of reliance on the project map file while making the mod more versatile. I would need to pre-plan that implementation for future projects to leverage it properly.
Also, it gave me another idea, to separate my mod into 2 mods. -Or more like daisy chain them. I could make 1 for data, another for Trig Lib.
The project map would access the Trig Lib only, while the Trig Lib accesses the Data Mod.
I would then use the extra-data'-modify option to force the Trig Lib Mod to access several optional Data Mods, but only 1 at a time. To make things neat, I could make several record arrays to store all data links for each mod to ensure I don't mixup my mod dependencies. That would give tight control for easy expansion.
Of course, this all based on whether or not the extra-data-modify option works the way i think it does, and also if its reliable.
I have a Launch Missile Effect. The Impact Effect is a Set Effect. There is another LM Effect 'within' the set.
The second LM effect (within the set) has a create unit effect as the impact effect.
That specific LM effect within the set is running twice. I have looked at this thoroughly, I have no idea.
Does anyone know whats causing this?
EDIT: It gets wierder, this set effect runs once (correctly) if i run the map from the actual map file.
But this problem exists when i run the map from my mod file.
Sure you are not accidentally linking to the other LM effect?
Probably a bug. Just delete the LM effect and make a new one from scratch.
Any Create Persistent effects involved?
Contribute to the wiki (Wiki button at top of page) Considered easy altering of the unit textures?
https://www.sc2mapster.com/forums/resources/tutorials/179654-data-actor-events-message-texture-select-by-id
https://media.forgecdn.net/attachments/187/40/Screenshot2011-04-17_09_16_21.jpg
@DrSuperEvil: Go
Verified, the effects are meticulously linked correctly.
Verified, problem exists only when running the map from the Mod file while referencing the map as the test map document default map.
Yes, I added a CrtPersistant to add offsets to the 2nd LM effect. The problem continues with or without that CrtPersitant effect (tested) when running from Mod but not when running directly from map. The problem is consistent.
I believe its a bug when running a map from a Mod file. My solution is to separate these effects into 2 separate autocast abilities.
I merged them together to avoid 1 unnecessary autocast scan, but I can't condone inconsistent results between map and mod, so I will separate them.
Maybe your mod is equivalently loading it twice so that the set effect has the effect from the map and the mod as separate effects?
Contribute to the wiki (Wiki button at top of page) Considered easy altering of the unit textures?
https://www.sc2mapster.com/forums/resources/tutorials/179654-data-actor-events-message-texture-select-by-id
https://media.forgecdn.net/attachments/187/40/Screenshot2011-04-17_09_16_21.jpg
If the mod is on your test map, the game will actually load the mod twice. This will double any triggers, along with the contents of any effects (like set as you mentioned, but also things like persistents), and upgrades etc.
Basically you need a test version of your map, with the mod removed. Awkward I know.
@TyaArcade: Go
That is terrible news. But, thanks for the info; it restores confidence and predictability to the data editor
This also means, I cannot test my project from my mod file. I cannot remove the mod dependency because my map triggers has many links to the data mod -it would break triggers.
Testing using a basic test map would work, but defeats the purpose of testing the project map by launching from the mod (to reduce load time).
There needs to be a switch or option within the editor to load a default test map that does not double load the matching mod dependency. -we would think this is kinda crazy obvious. awkward indeed.
BTW, I'm a fan of your maps and I wondered why your mapster account does not have your name in green font -as an author.
@TerraAzure: Go
You *can* however, modify triggers in your mod file from your map using extra data... unless your using a purely data mod, in which case this doesn't help you at all.
@PirateArcade | I make games | Ask me things on Discord
@greythepirate: Go
I read your thread a while back, but I did not understand it until now.
The modifiable extra data allows modifying only trigger libraries within the mod, but that's still very useful. thanks!
However at this time, I am modifying a pure data mod that I intend to re-use for future projects.
i would suggest testing all data related stuff and libraries on a sandbox map. try to move as many triggers as you can into the mod. then just use test cheats to force run triggers and create units and actors
Go play Antioch Chronicles Remastered!
Also, coming soon, Antioch Episode 3: Thoughts in Chaos!
Dont like mapster's ugly white? Try Mapster's Classic Skin!
@Alevice: Go
Wow, thats a good idea. I did not consider that. That would reduce alot of reliance on the project map file while making the mod more versatile. I would need to pre-plan that implementation for future projects to leverage it properly.
Also, it gave me another idea, to separate my mod into 2 mods. -Or more like daisy chain them. I could make 1 for data, another for Trig Lib.
The project map would access the Trig Lib only, while the Trig Lib accesses the Data Mod.
I would then use the extra-data'-modify option to force the Trig Lib Mod to access several optional Data Mods, but only 1 at a time. To make things neat, I could make several record arrays to store all data links for each mod to ensure I don't mixup my mod dependencies. That would give tight control for easy expansion.
Of course, this all based on whether or not the extra-data-modify option works the way i think it does, and also if its reliable.