Set the Search Area's "Impact Location - value" to "Source Unit". If the search is triggered by a behavior applied on your missile unit, it will search around the missile's location.
Create a missile with a behavior calling a periodic effect every 0.0625 second, make that periodic effect a Search Area that returns a maximum count of one. In the search area's effect, link to set of effects that would deal damage in area, self-destruct the missile, etc. You may want to periodically check for cliff levels (validators) if it should impact against walls.
P.S. If I were you, I would make sure the map's concepts are playable through the battle.net latency...
Unload animations for all transport abilities are stored in an event macro which is referenced by the units able to be loaded into a transport. Have a look at the event macro actor "UnloadDropAnim", which activates the unit unload animations.
If you created a new unload ability, you may want to add the events to that macro or create your own macro and add that macro to all relevant unit actors.
Edit: Forgot to mention, also have a look at the actor "UnloadFX" too for the complete animation.
Terrain deformers are actors. All actors affect what you see and hear, but they never change the actual game state, so you'll never be able to see the effect/state of actors in triggers.
Unfortunately, there's no way to dynamically modify the game state terrain at this time.
"Are Top View Shooters playable with Battle.net Latency?"
All the traffic goes through the battle.net servers, so there is definitely some latency. That being said, for some kind of shooter where units can act by themselves to an extend ( such as firing at stuff in sight ), it should be playable.
"Are there good Top View Shooter maps around?"
A lot of people have attempted to create first person shooter ( or third person ) maps, with WASD motion and so on. It might look good in single-player, but you seriously need to think about latency for anything multiplayer. It's not going to feel responsive and that could be terribly annoying. I haven't seen any good or popular shooting map, probably for these reasons.
"Has anyone figured out a good way how projectile cliff collision works in a fast and good (working) way?"
I haven't done precisely that, but a periodic check every 0.0625 second ( from a behavior ) on the missile to make sure it never goes to a cliff level above its starting cliff level should work well enough. You may want to check the point just ahead of the missile, rather than the actual point of the missile's position.
"Can it work for the SC2-Engine without starting to lag because there are too many projectiles around?"
Projectiles that constantly scan around for targets demand more processing than typical source-target missiles. With properly designed data, I'm sure you could safely have 100 of these flying around at the same time, but if you expect to have more, it would require some performance testing.
I wouldn't personally recommend to make a WASD with fire control map. All traffic goes through the server, unlike real FPS engines where clients anticipate the future and smoothly interpolate to hide the latency... Playing a non-responsive shooting game could easily turn to be a rather frustrating experience.
Wow, ouch! I have no idea how things could go so wrong from removing dependencies. In the worst case, I really thought some data objects and models would go missing, this is very surprising. (I would be curious to see if the map still explodes just with a different MPQ's DocumentHeader without the dependencies )
Perhaps a simpler solution : since 4 of the mods have been made by you, could you just merge their content? Merge the data files, the Galaxy scripts, I can't see what could go wrong with that.
There are many issues with actors and unit revival.
The UnitDeath message is *not* sent for units with a -1.0 revival time, since the unit never really dies. The ActorDestruction message is only sent when the unit is actually revived, as the "corpse" lay around indefinitely even if it isn't visible. Instead, there are special revival messages to handle.
Because of this, all kinds of actor attachments (including turrets) tend to break with unit revivals.
If you want to use unit revival, do it with custom made units designed to handle all the relevant events.
I replied to your other post about the mothership's attacks and carrier's interceptors, though the reply wasn't something a complete beginner would fully understand.
It would take a long time to explain every detail, you need to familiarize yourself with the editor first, then the answers you'll get will make a lot more sense.
P.S. Data editor, open Game Data->Requirement tab, open the requirement called "Arm Interceptor". Modify the field Requirement - Node Link, select the constant 8 and modify that number to whatever you want.
1) 26 fully random lasers? Have the weapon linked to a Create Persistent executing 26 effects with a period of 0.0. Have the Create Persistent call a Search Area, define search filters, set TSRandom as sort method, set Maximum Count of 1. Then have the search call a launch missile linked to the proper impact effects and relevant actors. There are other ways to do that, such as just one Search Area returning up to a Maximum Count of 26 if you don't want 2 lasers to be able to pick the same target.
2) Update the carrier's relevant Requirement that checks for count of interceptors being <8 to allow building more.
This is quite clever! And I thought it was impossible to produce randomly generated terrain...
I'm not sure it would be usable in real maps since this is mostly a visual artifact. We would need to dynamically add path blockers and many features of real terrain would be impossible to reproduce as far as I know (such as multiple cliff levels). Still, maps could include some regions of dynamic terrain to add a little dynamism.
Very imaginative approach to the problem, good thinking!
As I have said before in earlier posts, these are the two limitations to the data obfuscation :
1) All objects must be new rather than modified ones, as it just renames everything by default. An user can manually provide a list of object names not be renamed, as the program doesn't have a list of all built-in objects.
2) No implicit references must be used, anywhere. For example, an actor based on the GenericAttack parent assumes that any missile actor will be named ##id##Missile, which means the same name with a "Missile" suffix. If the missile actor is named as such, no explicit reference actually exists in the XML files. The data obfuscation program will not create a new reference, and hence the link will be broken.
Do not scrap your map and do not start from scratch!
Get a MPQ editor ( http://www.zezula.net/en/mpq/download.html ) and open your map with it. Look into the files t3Terrain.xml and Objects, and clean up any terrain objects that shouldn't be there. Then, open the map again with the map editor.
Regarding time of day, you can have multiple lights and interpolate between them with triggers. For some obscure reason, the interpolation timer seems to use "real" seconds instead of game seconds, watch out for that... The built-in "time of day" functions ( and associated time-based lights ) don't work at all as far as I can tell.
As far as I know, lighting is global for the whole map, and there's no way to have local lighting except by having doodads that contain local lights.
Reducing sight vision for units in an area is quite possible, applying some behaviors to said units.
Last note : if trying to edit the lights through the built-in lighting editor proves a frustrating experience ( it's not keeping values, modifying wrong light, etc. ), just edit your lights in the XML files directly. The lighting editor was really buggy and, unless it was fixed with 1.2.1, it probably still is.
0
Set the Search Area's "Impact Location - value" to "Source Unit". If the search is triggered by a behavior applied on your missile unit, it will search around the missile's location.
0
Create a missile with a behavior calling a periodic effect every 0.0625 second, make that periodic effect a Search Area that returns a maximum count of one. In the search area's effect, link to set of effects that would deal damage in area, self-destruct the missile, etc. You may want to periodically check for cliff levels (validators) if it should impact against walls.
P.S. If I were you, I would make sure the map's concepts are playable through the battle.net latency...
0
Unload animations for all transport abilities are stored in an event macro which is referenced by the units able to be loaded into a transport. Have a look at the event macro actor "UnloadDropAnim", which activates the unit unload animations.
If you created a new unload ability, you may want to add the events to that macro or create your own macro and add that macro to all relevant unit actors.
Edit: Forgot to mention, also have a look at the actor "UnloadFX" too for the complete animation.
0
Terrain deformers are actors. All actors affect what you see and hear, but they never change the actual game state, so you'll never be able to see the effect/state of actors in triggers.
Unfortunately, there's no way to dynamically modify the game state terrain at this time.
0
"Are Top View Shooters playable with Battle.net Latency?"
All the traffic goes through the battle.net servers, so there is definitely some latency. That being said, for some kind of shooter where units can act by themselves to an extend ( such as firing at stuff in sight ), it should be playable.
"Are there good Top View Shooter maps around?"
A lot of people have attempted to create first person shooter ( or third person ) maps, with WASD motion and so on. It might look good in single-player, but you seriously need to think about latency for anything multiplayer. It's not going to feel responsive and that could be terribly annoying. I haven't seen any good or popular shooting map, probably for these reasons.
"Has anyone figured out a good way how projectile cliff collision works in a fast and good (working) way?"
I haven't done precisely that, but a periodic check every 0.0625 second ( from a behavior ) on the missile to make sure it never goes to a cliff level above its starting cliff level should work well enough. You may want to check the point just ahead of the missile, rather than the actual point of the missile's position.
"Can it work for the SC2-Engine without starting to lag because there are too many projectiles around?"
Projectiles that constantly scan around for targets demand more processing than typical source-target missiles. With properly designed data, I'm sure you could safely have 100 of these flying around at the same time, but if you expect to have more, it would require some performance testing.
I wouldn't personally recommend to make a WASD with fire control map. All traffic goes through the server, unlike real FPS engines where clients anticipate the future and smoothly interpolate to hide the latency... Playing a non-responsive shooting game could easily turn to be a rather frustrating experience.
0
Wow, ouch! I have no idea how things could go so wrong from removing dependencies. In the worst case, I really thought some data objects and models would go missing, this is very surprising. (I would be curious to see if the map still explodes just with a different MPQ's DocumentHeader without the dependencies )
Perhaps a simpler solution : since 4 of the mods have been made by you, could you just merge their content? Merge the data files, the Galaxy scripts, I can't see what could go wrong with that.
0
There are many issues with actors and unit revival.
The UnitDeath message is *not* sent for units with a -1.0 revival time, since the unit never really dies. The ActorDestruction message is only sent when the unit is actually revived, as the "corpse" lay around indefinitely even if it isn't visible. Instead, there are special revival messages to handle.
Because of this, all kinds of actor attachments (including turrets) tend to break with unit revivals.
If you want to use unit revival, do it with custom made units designed to handle all the relevant events.
0
You can name the attachment points whatever you want.
The default Attach Method filters may not work if they are looking for names such as "Weapon", but that's no big deal. Create your own attach methods.
0
Don't take it the wrong way, pieceofshota...
I replied to your other post about the mothership's attacks and carrier's interceptors, though the reply wasn't something a complete beginner would fully understand.
It would take a long time to explain every detail, you need to familiarize yourself with the editor first, then the answers you'll get will make a lot more sense.
P.S. Data editor, open Game Data->Requirement tab, open the requirement called "Arm Interceptor". Modify the field Requirement - Node Link, select the constant 8 and modify that number to whatever you want.
0
1) 26 fully random lasers? Have the weapon linked to a Create Persistent executing 26 effects with a period of 0.0. Have the Create Persistent call a Search Area, define search filters, set TSRandom as sort method, set Maximum Count of 1. Then have the search call a launch missile linked to the proper impact effects and relevant actors. There are other ways to do that, such as just one Search Area returning up to a Maximum Count of 26 if you don't want 2 lasers to be able to pick the same target.
2) Update the carrier's relevant Requirement that checks for count of interceptors being <8 to allow building more.
0
If you reference a larger image, does it still get scaled down to a maximum width of 160?
If not, you could include a magnified version of the texture in the map.
If yes, you could try cutting the larger image into multiple smaller textures and packing them together.
0
This is quite clever! And I thought it was impossible to produce randomly generated terrain...
I'm not sure it would be usable in real maps since this is mostly a visual artifact. We would need to dynamically add path blockers and many features of real terrain would be impossible to reproduce as far as I know (such as multiple cliff levels). Still, maps could include some regions of dynamic terrain to add a little dynamism.
Very imaginative approach to the problem, good thinking!
0
As I have said before in earlier posts, these are the two limitations to the data obfuscation :
1) All objects must be new rather than modified ones, as it just renames everything by default. An user can manually provide a list of object names not be renamed, as the program doesn't have a list of all built-in objects.
2) No implicit references must be used, anywhere. For example, an actor based on the GenericAttack parent assumes that any missile actor will be named ##id##Missile, which means the same name with a "Missile" suffix. If the missile actor is named as such, no explicit reference actually exists in the XML files. The data obfuscation program will not create a new reference, and hence the link will be broken.
0
Do not scrap your map and do not start from scratch!
Get a MPQ editor ( http://www.zezula.net/en/mpq/download.html ) and open your map with it. Look into the files t3Terrain.xml and Objects, and clean up any terrain objects that shouldn't be there. Then, open the map again with the map editor.
0
Regarding time of day, you can have multiple lights and interpolate between them with triggers. For some obscure reason, the interpolation timer seems to use "real" seconds instead of game seconds, watch out for that... The built-in "time of day" functions ( and associated time-based lights ) don't work at all as far as I can tell.
As far as I know, lighting is global for the whole map, and there's no way to have local lighting except by having doodads that contain local lights.
Reducing sight vision for units in an area is quite possible, applying some behaviors to said units.
Last note : if trying to edit the lights through the built-in lighting editor proves a frustrating experience ( it's not keeping values, modifying wrong light, etc. ), just edit your lights in the XML files directly. The lighting editor was really buggy and, unless it was fixed with 1.2.1, it probably still is.