It took me about an hour, but I found your problem.
You happen to have used "Terrain Objects" to make your buildings, and there is a weird longstanding bug with them where they can end up being duplicated without you knowing. Blizzard really needs to get around to fixing this bug, it is really very insidious.
Opening up the map in Ladik's MPQ viewer and looking at the file labeled t3Terrain.xml shows there are 2156 "cliffDoodads", aka Terrain Objects. Almost all of them are just erroneous duplicates made by the editor.
Removing each duplicate entry by hand from t3Terrain.xml will make the map load immediately in the editor again. Just make sure to change the 2156 number to match the number of entries you have after you remove the duplicate lines.
Avoid using events that occur very often. ie avoid 'Any unit dies', 'Any unit is issued an order to attack', etc. This may require some creativity.
You can test if actors are destroyed properly by using 'ActorInfoDisplay' when testing your map.
If your map has very large numbers of units:
Use Slow(but probably not Slower) Gamespeed.
Disabling blob shadows for each unit will lower the number of actors used for people who have to run on low graphics. I have lowered my graphics down to low and had my FPS drop simply because the game now had to keep track of a blob shadow actor for each unit.
Be conscious of the vertex/poly count of the models you are using. Zerglings are 5.5x less detailed than ultralisks for a good reason. Use less detailed models for the unit types you make swarms of.
When you make a new map, check 'Use Campaign Data'. This will set up the map to use the campaign dependency which is where the data for all sorts of campaign specific stuff is. Alternatively, add the campaign dependency manually to a map already in progress via clicking File - Dependencies.
Yeah if there is only ever one squad of zerglings they way you suggest should work fine. Also I can't seem to figure out how you know which unit owns a magazine unit in triggers anyway.
It might be possible to get loading to work by having the squad unit be a transport itself. Then when you loaded the squad unit into the medivac it would then load the marines into the squad unit. Then the squad would just appear as the single unit in the medivac's cargo bay.
BTW, Both the burrow and the transport functionality should be fine to implement in a way which uses triggers. Burrowing and loading/unloading do not happen that often; there would be negligible lag.
There comes a point when you are better off just banging out a trigger-based solution rather than trying to contort the data editor to do things it is ill-suited for.
The main trouble with a data solution is being able to validate which units actually correspond to the specific squad rather than just happen to be in the vicinity.
Ok, I got it to work for you.
I changed the suicide behavior to be periodic; it is now trying to suicide every period. The requirement will keep it disabled so long as there are any marines.
I didn't see anywhere that the behavior was being applied, so I added it to the unit behaviors for the squad unit.
The requirement was also a little wrong; you do not want to count queued units. The squad is constantly trying to fill its queue, so it will never be empty. You only want to ask about how many completed units there are.
I think that the underground footprint simply forces units to be able to walk over it, even allowing burrowed units.
ie, it just overrides all normal collision.
Excellent point. If I understand correctly, footprints basically paint the pathing layer so no ground pathing whatsoever is allowed underneath them. So yes you will need to remove the footprints for the structures/doodads, or at least remove the pathing layer of the footprints they use.
Did you try using fancy collision flags? Units should only collide with eachother if they share at least one collision flag. So pick an otherwise unused ground collision flag and make it the only collision flag for your unit and then give it as well to every kind of structure. Now that unit should collide only with structures since nothing else shares that collision flag. Do the same with a different unused flag for the other unit and the doodads or whatever.
The game gives a warning whenever more than one unit actor exists for the same unit. This is because 95% of the time this is indicative of the map maker having messed up. Yours seems to be the unusual case where you have a legitimate reason to have more than one unit actor, since using a model actor would not automatically animate properly, I think. I don't know how to suppress the warning from showing up, or if it is possible to suppress it. Perhaps it is acceptable for you to just ignore the warning message?
As for the sphere thing: you appear to have forgotten to set the Actor: Model to Marine for the MarineTower actor, doh! It is set to the default 'MarineTower' which doesn't exist so it falls back to the sphere. You set it correctly in all the other places it asks for the model, so that is why it is different in the game from in the editor. This has nothing to do with that warning.
I think that Moship cores are intended to not turn toward their targets.
If you want to use it with the Moship core then you should just set the Arc for the Clone Ability to 360.
Looking at how the clone ability works, it uses the Create Unit Effect with the Fallback Set to Target as I suggested.
I am unsure what was preventing you guys from having it work before, I tried resetting all the other fields to defaults and it still worked.
That is actually not a shadow. The photon cannon has a custom splat actor which darkens the ground underneath it in the shape of photon cannon.
You can delete your duplicated version of that splat actor and it should go away. Actual shadows are dynamically generated from the models at anything but lowest settings, so you should see the shadow of a dark templar automatically by just using the dark templar model.
I actually have no idea why this splat exists for the photon cannon in the first place.
I will try to explain it better this time, and I realize now that something subtle may be going wrong.
Burrowed zerglings use the same actor as their unburrowed counterparts. This makes sense because a unit actor is just the thing in charge of the how the unit's model should be behaving during the game, and burrowing just results in the model applying the burrow attribute to its animations. This isn't always how things are set up with other morph abilities, but it is how burrow tends to be set up by Blizz.
When you duplicated the zergling unit and actor and what not it does not automatically set up the proper behavior of the new actor with respect to burrowing. In the Events for the new zergling actor it likely has lines that still reference the original burrow ability and the original burrowed zergling unit. These should be changed to the new burrow ability and the new burrowed unit.
So whats going on here?
The Events for an actor controls how the actor responds whenever something happens in the game. One example is unit creation. When a unit is birthed in the game, the unit does not automatically create its corresponding unit actor. In a weird feat of pulling-itself-up-by-its-bootstraps it is infact the unit actor(say a zergling) typically which creates itself in response to a unit of that type is birthed event. So to understand what may be happening first understand that the original zergling actor is set up to create itself in response to an original BURROWED zergling being created(it also creates itself whenever an unburrowed zergling is created). Now when you duplicate the zergling unit and actor the duplicator understands that you want the duplicate zergling to create itself whenever a duplicate-type zergling unit is birthed and not whenever an original-type zergling unit is. However the duplicator does not understand the same thing about how things should work for the burrowed zergling, at least not properly. It is not entirely sure who it should refer to, since it can only guess as to the name of the new burrowed unit. When I do it in the editor it automatically sets things up so that the new zergling actor will create itself whenever a unit called Zergling2Burrowed is born. This would all be fine and good if the guess happened to be correct and there is such a unit type which exists. Hilariously enough however, when you duplicate the burrowed version of the zergling unit you end up with a unit type called ZerglingBurrowed2 by default. OOPS, LOL BLIZZ YOU SO SILLY.
I don't really know what happens in this case if there is no unit-type by the name Zergling2Burrowed. I would guess that the event would either now happen when ANY unit is birthed, or it would never happen. The fact that you are getting multiple actors persisting suggests to me that it is the former.
Anyways enough on speculating about what is going wrong. What you need to do is manually go through the events for your actors and make sure they make sense. There should be no references to the original zergling unit or abilities, and you will need to make sure that it doesn't reference fictitious things that it incorrectly guessed the name of.
Good luck =) Please don't make a new thread and just post in here if you still can't get it to work.
My guess is that what eluded you the first time is just the ridiculous fictitious name issue, and understandably so. I would probably stare at Zergling2Burrowed for hours and not realize it was different from the ZerglingBurrowed2 that I really had.
However what would tip me off is that while it says UnitBirth.Zergling2Burrowed on the left, when selected, on the right it just says Unit Birth, ANY, ANY. Instead of something like Unit Birth, Zergling Copy(Burrowed), ANY.
0
It took me about an hour, but I found your problem.
You happen to have used "Terrain Objects" to make your buildings, and there is a weird longstanding bug with them where they can end up being duplicated without you knowing. Blizzard really needs to get around to fixing this bug, it is really very insidious.
Opening up the map in Ladik's MPQ viewer and looking at the file labeled t3Terrain.xml shows there are 2156 "cliffDoodads", aka Terrain Objects. Almost all of them are just erroneous duplicates made by the editor.
Removing each duplicate entry by hand from t3Terrain.xml will make the map load immediately in the editor again. Just make sure to change the 2156 number to match the number of entries you have after you remove the duplicate lines.
0
Avoid using events that occur very often. ie avoid 'Any unit dies', 'Any unit is issued an order to attack', etc. This may require some creativity.
You can test if actors are destroyed properly by using 'ActorInfoDisplay' when testing your map.
If your map has very large numbers of units:
0
@Nallethe: Go
When you make a new map, check 'Use Campaign Data'. This will set up the map to use the campaign dependency which is where the data for all sorts of campaign specific stuff is. Alternatively, add the campaign dependency manually to a map already in progress via clicking File - Dependencies.
0
@urzaiz87: Go
I think that things might get sticky no matter how you go about it...
This might prove helpful:
When units are loaded into transports it tends to disable all the abilities of the cargo unit so long as they are inside.
You can force an ability to be reenabled by giving the unit a buff which enables that ability.
This might enable a cargo unit to be able to load units itself despite being inside a transport.
Good luck
0
Yeah if there is only ever one squad of zerglings they way you suggest should work fine. Also I can't seem to figure out how you know which unit owns a magazine unit in triggers anyway.
It might be possible to get loading to work by having the squad unit be a transport itself. Then when you loaded the squad unit into the medivac it would then load the marines into the squad unit. Then the squad would just appear as the single unit in the medivac's cargo bay.
BTW, Both the burrow and the transport functionality should be fine to implement in a way which uses triggers. Burrowing and loading/unloading do not happen that often; there would be negligible lag.
0
@urzaiz87: Go
There comes a point when you are better off just banging out a trigger-based solution rather than trying to contort the data editor to do things it is ill-suited for.
The main trouble with a data solution is being able to validate which units actually correspond to the specific squad rather than just happen to be in the vicinity.
0
@urzaiz87: Go
Ok, I got it to work for you. I changed the suicide behavior to be periodic; it is now trying to suicide every period. The requirement will keep it disabled so long as there are any marines.
I didn't see anywhere that the behavior was being applied, so I added it to the unit behaviors for the squad unit.
The requirement was also a little wrong; you do not want to count queued units. The squad is constantly trying to fill its queue, so it will never be empty. You only want to ask about how many completed units there are.
0
I think that the underground footprint simply forces units to be able to walk over it, even allowing burrowed units. ie, it just overrides all normal collision.
0
@gerudobombshell: Go
2 things which I believe affect whether units try to path around other units:
1. Hold Position. If you give the blockers the move ability and order them to hold position (via trigger) units should path differently around them.
2. Push Priority. Setting the push priority of the blocker higher than the unit should affect pathing.
I tried these out and they didn't seem to help sufficiently =/
0
@Kueken531: Go
Excellent point. If I understand correctly, footprints basically paint the pathing layer so no ground pathing whatsoever is allowed underneath them. So yes you will need to remove the footprints for the structures/doodads, or at least remove the pathing layer of the footprints they use.
0
@gerudobombshell: Go
Did you try using fancy collision flags? Units should only collide with eachother if they share at least one collision flag. So pick an otherwise unused ground collision flag and make it the only collision flag for your unit and then give it as well to every kind of structure. Now that unit should collide only with structures since nothing else shares that collision flag. Do the same with a different unused flag for the other unit and the doodads or whatever.
0
The game gives a warning whenever more than one unit actor exists for the same unit. This is because 95% of the time this is indicative of the map maker having messed up. Yours seems to be the unusual case where you have a legitimate reason to have more than one unit actor, since using a model actor would not automatically animate properly, I think. I don't know how to suppress the warning from showing up, or if it is possible to suppress it. Perhaps it is acceptable for you to just ignore the warning message?
As for the sphere thing: you appear to have forgotten to set the Actor: Model to Marine for the MarineTower actor, doh! It is set to the default 'MarineTower' which doesn't exist so it falls back to the sphere. You set it correctly in all the other places it asks for the model, so that is why it is different in the game from in the editor. This has nothing to do with that warning.
0
I think that Moship cores are intended to not turn toward their targets.
If you want to use it with the Moship core then you should just set the Arc for the Clone Ability to 360.
Looking at how the clone ability works, it uses the Create Unit Effect with the Fallback Set to Target as I suggested. I am unsure what was preventing you guys from having it work before, I tried resetting all the other fields to defaults and it still worked.
0
@staminized: Go
That is actually not a shadow. The photon cannon has a custom splat actor which darkens the ground underneath it in the shape of photon cannon. You can delete your duplicated version of that splat actor and it should go away. Actual shadows are dynamically generated from the models at anything but lowest settings, so you should see the shadow of a dark templar automatically by just using the dark templar model.
I actually have no idea why this splat exists for the photon cannon in the first place.
0
@Azizh: Go This thread appears to be a continuation of this other one: Previous Thread
I will try to explain it better this time, and I realize now that something subtle may be going wrong.
Burrowed zerglings use the same actor as their unburrowed counterparts. This makes sense because a unit actor is just the thing in charge of the how the unit's model should be behaving during the game, and burrowing just results in the model applying the burrow attribute to its animations. This isn't always how things are set up with other morph abilities, but it is how burrow tends to be set up by Blizz.
When you duplicated the zergling unit and actor and what not it does not automatically set up the proper behavior of the new actor with respect to burrowing. In the Events for the new zergling actor it likely has lines that still reference the original burrow ability and the original burrowed zergling unit. These should be changed to the new burrow ability and the new burrowed unit.
So whats going on here?
The Events for an actor controls how the actor responds whenever something happens in the game. One example is unit creation. When a unit is birthed in the game, the unit does not automatically create its corresponding unit actor. In a weird feat of pulling-itself-up-by-its-bootstraps it is infact the unit actor(say a zergling) typically which creates itself in response to a unit of that type is birthed event. So to understand what may be happening first understand that the original zergling actor is set up to create itself in response to an original BURROWED zergling being created(it also creates itself whenever an unburrowed zergling is created). Now when you duplicate the zergling unit and actor the duplicator understands that you want the duplicate zergling to create itself whenever a duplicate-type zergling unit is birthed and not whenever an original-type zergling unit is. However the duplicator does not understand the same thing about how things should work for the burrowed zergling, at least not properly. It is not entirely sure who it should refer to, since it can only guess as to the name of the new burrowed unit. When I do it in the editor it automatically sets things up so that the new zergling actor will create itself whenever a unit called Zergling2Burrowed is born. This would all be fine and good if the guess happened to be correct and there is such a unit type which exists. Hilariously enough however, when you duplicate the burrowed version of the zergling unit you end up with a unit type called ZerglingBurrowed2 by default. OOPS, LOL BLIZZ YOU SO SILLY.
I don't really know what happens in this case if there is no unit-type by the name Zergling2Burrowed. I would guess that the event would either now happen when ANY unit is birthed, or it would never happen. The fact that you are getting multiple actors persisting suggests to me that it is the former.
Anyways enough on speculating about what is going wrong. What you need to do is manually go through the events for your actors and make sure they make sense. There should be no references to the original zergling unit or abilities, and you will need to make sure that it doesn't reference fictitious things that it incorrectly guessed the name of.
Good luck =) Please don't make a new thread and just post in here if you still can't get it to work.
My guess is that what eluded you the first time is just the ridiculous fictitious name issue, and understandably so. I would probably stare at Zergling2Burrowed for hours and not realize it was different from the ZerglingBurrowed2 that I really had. However what would tip me off is that while it says UnitBirth.Zergling2Burrowed on the left, when selected, on the right it just says Unit Birth, ANY, ANY. Instead of something like Unit Birth, Zergling Copy(Burrowed), ANY.