Yeah, thought that was likely, so it's probably that you don't have the story dependency added... you can still use the model, just copy the location above and paste it directly into the "Model" field of a Model. It'll show as that ugly sphere in the editor, but if you run a map test it should show correctly.
Take a look at Assets\UI\Helpers\HelperEmitterSelectionArrow\HelperEmitterSelectionArrow.m3 ... if you don't see it, you probably need to have the Liberty Story campaign dependency. It's bright green :P
I guess that means you'd have to fiddle around with a Buff behavior that disables the load/unload ability? I don't know if that would then preserve units in cargo, or drop them immediately, or kill them, etc... but I suppose you could also set a trigger to move units from the cargo of the unit into an area somewhere else... maybe making the "transported" no longer visible or uncommandable, etc, till you need them dropped. Do they actually need to be transported, or is it mostly just for story reasons?
I'd given some thought to combining items, and found inventory indexes nightmarish. So, because my current project allows it, I completely avoid them.
Concept: Use an item container bound to a neutral static unit... let's say it's a unit with a Chest actor, called Horadric Chest. The inventory for that unit only has one space, and any time it picks up an item, a trigger drops it and relocates it to a region in a secluded area of the map. From there, it's a simple matter of using a trigger to check the number and type of all items in that region whenever the user "Transmutes," regardless of how that event happens (a single UI button is probably easiest). That way, it doesn't matter what order the player puts them into the Chest. This should also make creating new recipe triggers a lot easier than all that index garbage.
You'll probably want to add a second "Dump" UI button to return all items in the area to a point nearby, and set the two buttons as visible when a unit enters a region around the Chest. You could even set a condition that rejects an item and drops it in the dump zone if too many items exist in the mixing region.
Pros:
Triggers are less complicated, indices aren't even used.
Duplicate items in Horadric Trigger Region won't cause headaches.
Cons:
Can't mix from anywhere unless the single slot inventory is on the hero, which might confuse the player.
Thoughts:
Use a global variable to count the items added to the region, and place them at different locations based on this value. This would let you put the items at specific points in a transmutation circle, altar, or around a smith's shop. Might want to make these areas inaccessible (or set Triggering Inventory Items to a state that prevents normal interaction) to preserve the effect.
This would allow multiple players to add items into your Horadric Stew, without showing everyone what they've added. Could result in comedy.
If you need it to do this for a cinematic or scripted drop off or something, you can use a trigger action to make the unit uncommandable/commandable or set the Uncommandable flag in the unit properties. You should still be able to control the unit with triggers.
Temporary workaround: Setting the Editor Prefix to "ZZ -" on a single item, filtering data to Liberty Story, selecting everything, and while in table view selecting all of the editor prefix fields (click the first one, scroll all the way over, hold shift, click the last field) and then PASTING the value will set all of the selected items prefixes at once (the editor will hang for a few seconds... ::cough::) WITHOUT setting their source to your map. This means all of your custom units/actors will be at the top of the list, you can still jump through them alphabetically, and you can still filter data to only objects from your map. Not a perfect solution since having the story dependency still adds about 300mb to the editor's memory usage (thereabouts), and load times aren't improved, but you'll spend less time scrolling through junk you don't need.
Unfortunately, triggers won't let you change a part of the model. The Ghost model will always be holding a rifle as long as he is tall, even if you wanted him to use the reaper's pistols granted by items. Without 3ds Max, the best you can do would be to find a model with an attack animation and use a ModelAddition actor either attached to the hands or existing weapon of the unit.
That'll all change when Blizzard gives us proper model/animation support, or when someone figures out a .m3 export tool for Blender.
Looking at the Civilian/Colonist actor events, it seems that you can change animations by giving the unit a behavior and using an event to apply the animation group. For example, the civilian normally walks. In the actor's Events, there's two that look like:
Behavior.Run.On
AnimGroupApply Fast
Behavior.Run.Off
AnimGroupRemove Fast
What that means is if you either start the unit with the Civilian - Run ("Civilian -" is just the editor prefix, it isn't there when looking for it in an event response, which is confusing) or add the Civilian - Run behavior with a trigger, the unit will use the run animation instead of walk. The problem with that is when adding this behavior to a non-duplicated actor instead of using a dupe, it lets you pick from all possible animation groups from some core definition (I think), meaning you'd have to use trial and error to find which one is the one you want. (Unless it gives you the actual group name somewhere in the previewer?)
Move Immediately now has to target a point, not a region,I think. If you use an Issue Order to Triggering Unit action instead of the teleport, and if your map will have air units (or buildings with liftoff), you'll also want to define no-fly zones everywhere but your normal choke point unless you also want to surround your base areas with additional iterations of b0ne123's trigger example, otherwise, an air unit entering from the back/side will fly completely through the base (if entering from the back) or along the entire side of the region on their way to the destination.
I'll be honest, I look at the Host/Hosting tab for a unit, and I pretty much completely disregard it. I've seen Hosted Attachments used in a tutorial about attaching turrets to a unit, but when attempting to create my own such creations, I got the effect I wanted before I needed to bother with it. As with everything in the editor, trial and error and nothing and error seems to be the only way to get anything done... but I don't even know where to start with Hosted Attachments since there's no documentation I'm aware of explaining the function.
Unless Blizzard gives us a GUI point-and-click attachment editor, (fingers crossed :D) using Site Operations and Actor/ModelAddition seems to be the only good way to do it. The map I'm working on will end up using hundreds of model additions... after you create a few, it just seems pretty normal. You can pull off some pretty sweet effects using model additions and events without a bunch of messy and performance hogging triggers.
I think I understand what you're talking about, and if I do, you'll want to look for the turret actor and model in the data editor (it should actually be separate and created using actor events, if it's anything like normal turrets) and uncheck any scale flags in Accepted Property Transfers, then set the minimum/maximum scale value on the model data tab to the same scale that you want the tank at. That should allow it to scale independently of the unit it becomes attached to.
There are some basic-sounding things that would greatly improve usability for entry-level mappers, but more importantly, speed up the process for vets:
Ability to add more class attributes like Armored, Biological, Heroic, etc., because Validators just suck.
Ability to browse all assets without needing to add dependencies, OR let us individually remove them from the data browser:
The game WILL load them anyways
Why slow down the editor/mapping because you need to scroll through a MILLION SS_QueenSpitsOnStetmansCat or MissileTychusPantscrap or SOpZeratulBeltBuckle or CreatPersistantValerianStillLookLikeArthas?
This would mean you can use the Civilian model (everyone uses it anyways) for a guy named Tucker and not have to scroll through hundreds of Tal'Darim, Tarsonis, Tech, Traffic, and Tosh entries before you can pick a unit for his actor.
Has anyone figured out a way to either remove or hide datum added by a dependency?
I've noticed that nearly a third of the time I'm working in the data editor (or in the trigger editor selecting values) is spent scrolling through the millions of data entries added by the campaign dependency. For that matter, about half of my editor crashes occur when opening a dialog to pick a button or some such due to the quantity of useless additions. The only problem with simply not using the campaign dependency is the inconvenience of the editor denying you the selection of assets outside a dependency despite the game still loading assets correctly.* That'd be fine if you could select any model asset in the browser, but you'd have to manually type in/paste the value from somewhere else... additionally, in a map with dozens of custom units, seeing each one in the editor as the placeholder gets a bit confusing.
Unfortunately, Removing Object in the data editor doesn't seem to work for blue/grey data... changing any value on a blue object turns it green and adds it to the map assets; however, removing that item is pointless since they seem to be recreated whenever a data filter changes.
Anyone have any ideas? "Hopefully Blizzard will change X" isn't quite what I'm looking for... but it's the best I've been able to come up with. I'd love it if I could just specify assets from a complete browser without needing the dependency simply because the whole editor seems to run much faster without that massive pack loaded.
Example: Without the campaign dependency, setting a Model to Assets\Units\Terran\ColonistMale\ColonistMale.m3 shows as the sphere placeholder in the editor, but when the map is loaded in game, the model shows correctly. If the game can load the asset without the dependency, isn't it only slowing down and cluttering the editor?
0
Yeah, thought that was likely, so it's probably that you don't have the story dependency added... you can still use the model, just copy the location above and paste it directly into the "Model" field of a Model. It'll show as that ugly sphere in the editor, but if you run a map test it should show correctly.
0
Take a look at Assets\UI\Helpers\HelperEmitterSelectionArrow\HelperEmitterSelectionArrow.m3 ... if you don't see it, you probably need to have the Liberty Story campaign dependency. It's bright green :P
0
I guess that means you'd have to fiddle around with a Buff behavior that disables the load/unload ability? I don't know if that would then preserve units in cargo, or drop them immediately, or kill them, etc... but I suppose you could also set a trigger to move units from the cargo of the unit into an area somewhere else... maybe making the "transported" no longer visible or uncommandable, etc, till you need them dropped. Do they actually need to be transported, or is it mostly just for story reasons?
0
I'd given some thought to combining items, and found inventory indexes nightmarish. So, because my current project allows it, I completely avoid them.
Concept: Use an item container bound to a neutral static unit... let's say it's a unit with a Chest actor, called Horadric Chest. The inventory for that unit only has one space, and any time it picks up an item, a trigger drops it and relocates it to a region in a secluded area of the map. From there, it's a simple matter of using a trigger to check the number and type of all items in that region whenever the user "Transmutes," regardless of how that event happens (a single UI button is probably easiest). That way, it doesn't matter what order the player puts them into the Chest. This should also make creating new recipe triggers a lot easier than all that index garbage.
You'll probably want to add a second "Dump" UI button to return all items in the area to a point nearby, and set the two buttons as visible when a unit enters a region around the Chest. You could even set a condition that rejects an item and drops it in the dump zone if too many items exist in the mixing region.
Pros:
Cons:
Thoughts:
0
If you need it to do this for a cinematic or scripted drop off or something, you can use a trigger action to make the unit uncommandable/commandable or set the Uncommandable flag in the unit properties. You should still be able to control the unit with triggers.
0
Temporary workaround: Setting the Editor Prefix to "ZZ -" on a single item, filtering data to Liberty Story, selecting everything, and while in table view selecting all of the editor prefix fields (click the first one, scroll all the way over, hold shift, click the last field) and then PASTING the value will set all of the selected items prefixes at once (the editor will hang for a few seconds... ::cough::) WITHOUT setting their source to your map. This means all of your custom units/actors will be at the top of the list, you can still jump through them alphabetically, and you can still filter data to only objects from your map. Not a perfect solution since having the story dependency still adds about 300mb to the editor's memory usage (thereabouts), and load times aren't improved, but you'll spend less time scrolling through junk you don't need.
0
Unfortunately, triggers won't let you change a part of the model. The Ghost model will always be holding a rifle as long as he is tall, even if you wanted him to use the reaper's pistols granted by items. Without 3ds Max, the best you can do would be to find a model with an attack animation and use a ModelAddition actor either attached to the hands or existing weapon of the unit.
That'll all change when Blizzard gives us proper model/animation support, or when someone figures out a .m3 export tool for Blender.
0
Looking at the Civilian/Colonist actor events, it seems that you can change animations by giving the unit a behavior and using an event to apply the animation group. For example, the civilian normally walks. In the actor's Events, there's two that look like:
What that means is if you either start the unit with the Civilian - Run ("Civilian -" is just the editor prefix, it isn't there when looking for it in an event response, which is confusing) or add the Civilian - Run behavior with a trigger, the unit will use the run animation instead of walk. The problem with that is when adding this behavior to a non-duplicated actor instead of using a dupe, it lets you pick from all possible animation groups from some core definition (I think), meaning you'd have to use trial and error to find which one is the one you want. (Unless it gives you the actual group name somewhere in the previewer?)
0
Move Immediately now has to target a point, not a region,I think. If you use an Issue Order to Triggering Unit action instead of the teleport, and if your map will have air units (or buildings with liftoff), you'll also want to define no-fly zones everywhere but your normal choke point unless you also want to surround your base areas with additional iterations of b0ne123's trigger example, otherwise, an air unit entering from the back/side will fly completely through the base (if entering from the back) or along the entire side of the region on their way to the destination.
0
I'll be honest, I look at the Host/Hosting tab for a unit, and I pretty much completely disregard it. I've seen Hosted Attachments used in a tutorial about attaching turrets to a unit, but when attempting to create my own such creations, I got the effect I wanted before I needed to bother with it. As with everything in the editor, trial and error and nothing and error seems to be the only way to get anything done... but I don't even know where to start with Hosted Attachments since there's no documentation I'm aware of explaining the function.
0
Unless Blizzard gives us a GUI point-and-click attachment editor, (fingers crossed :D) using Site Operations and Actor/ModelAddition seems to be the only good way to do it. The map I'm working on will end up using hundreds of model additions... after you create a few, it just seems pretty normal. You can pull off some pretty sweet effects using model additions and events without a bunch of messy and performance hogging triggers.
0
I think I understand what you're talking about, and if I do, you'll want to look for the turret actor and model in the data editor (it should actually be separate and created using actor events, if it's anything like normal turrets) and uncheck any scale flags in Accepted Property Transfers, then set the minimum/maximum scale value on the model data tab to the same scale that you want the tank at. That should allow it to scale independently of the unit it becomes attached to.
0
There are some basic-sounding things that would greatly improve usability for entry-level mappers, but more importantly, speed up the process for vets:
0
Has anyone figured out a way to either remove or hide datum added by a dependency?
I've noticed that nearly a third of the time I'm working in the data editor (or in the trigger editor selecting values) is spent scrolling through the millions of data entries added by the campaign dependency. For that matter, about half of my editor crashes occur when opening a dialog to pick a button or some such due to the quantity of useless additions. The only problem with simply not using the campaign dependency is the inconvenience of the editor denying you the selection of assets outside a dependency despite the game still loading assets correctly.* That'd be fine if you could select any model asset in the browser, but you'd have to manually type in/paste the value from somewhere else... additionally, in a map with dozens of custom units, seeing each one in the editor as the placeholder gets a bit confusing.
Unfortunately, Removing Object in the data editor doesn't seem to work for blue/grey data... changing any value on a blue object turns it green and adds it to the map assets; however, removing that item is pointless since they seem to be recreated whenever a data filter changes.
Anyone have any ideas? "Hopefully Blizzard will change X" isn't quite what I'm looking for... but it's the best I've been able to come up with. I'd love it if I could just specify assets from a complete browser without needing the dependency simply because the whole editor seems to run much faster without that massive pack loaded.