I think it would require using one of the currently unused unit collision types, changing every not-burrowed not-a-worker mobile ground unit in the game to collide with that type, and setting the egg to use only that collision type. However, in SC1, workers failed to collide with any ground units, but only while attempting to gather resources. You could accomplish that by giving the workers a behavior, with a validator that makes sure it is using the Gather ability at any stage, with the Suppress Collision flag set.
I don't know who originally made the billboards, but I took the in-game billboard model and the images from the first page of this topic and assembled two variations of a SC2Mapster billboard just now, because billboards are the coolest way to advertise. :P
Use the camera editor to make sure your camera angle is exact, then hold the mouse button while hitting an arrow key on the keyboard to scroll the map. Zoom in if it jumps too far.
Unless someone knows something I don't about brush constraints. :P
Okay, to do this, we need to know how the Xel'Naga Tower controlling works...which is an ability called Tower Capture. The ability automatically casts itself whenever a non-buried, non-dead, non-hidden, non-missile, non-structure, non-uncommandable...*whew*...and non-under-construction ground unit is nearby. Set an event to trigger when the ability Tower Capture is used, and use the Triggering Ability Unit Target to get the player in control of the tower.
If you don't want to use an event for it, you'll need to use Unit Ability Command State (returns a boolean) to determine if the Tower Capture ability is being used, then Target Unit for Order to get the unit. Here's an example for this:
(Xel'Naga Tower [7.00, 16.00] ability command ((Tower Capture, 0)) is in state Executing) == True
(Target unit for (Xel'Naga Tower [7.00, 16.00] order at index 0)) == Value 2
To determine if the tower is being controlled at all:
Value 1: Unit Ability Command State
Unit: Xel'Naga Tower [7.00, 16.00]
Ability Command: Ability Command
Ability: Tower Capture
Command: 0
State: Executing
Operator: ==
Value 2: True
And to get the player in control of the tower:
Value 1: Target Unit For Order
Order: Unit Order
Unit: Xel'Naga Tower [7.00, 16.00]
Index: 0
The camera in my current map decided to start being jumpy one day out of the blue, as far as I can recall. I've verified that the camera is being told to pan just as smoothly as ever, the target is moving properly and rapidly, etc. I've tried changing the panning duration and deceleration and so forth. I've tried enabling and disabling height smoothing and height displacement. I've also tried messing with a few of the Default Camera data-only options, such as minimum smoothing time. I cannot figure out the cause for the behavior of this camera, although it does seem to be linked to what's in the foreground. Does anyone have a clue how to put an end to it?
Some specifics for the sake of satisfaction and not having to answer certain questions later:
I verified that this line is occurring with high but constant frequency even during the jittering, and regardless of how I tweak the parameters: Camera - Pan the camera for player (Picked player) to CameraPoint over 0.1 seconds with Existing Velocity% initial velocity, 10% deceleration, and Do Not use smart panning
I verified that CameraPoint is being moved in the correct direction, both smoothly and consistently, as well.
I also tried disabling height smoothing and height displacement immediately after that line, which only resulted in my camera being lower. (The camera is above a cliff but not right at the edge.)
I have no idea what you mean, but there is a "Pathing Cost" function too, so you can try that instead. A really high value would mean trouble. :p
And your target problem is that you're trying to use a function that only does something when it's caused by a target acquisition event, so use Target Unit For Order (Unit Order (whatever your unit is, index 0)) and check if it's No Unit. You can check pretty much whatever property of the target unit that you want to check that way, too.
There's a "Point Is Passable" condition. You could have a periodic trigger to check once per second or so to determine if at least one of a few points (say, 3) in the direction the unit is trying to move (Point With Polar Offset, at the position of the unit, offset magnitude 2 or so, -45 + facing of the unit, facing of the unit, and 45 degrees + facing of the unit) is passable. If any one is passable, you can Skip Remaining Actions, and the last action in the trigger would be to issue the attack order.
Yeah, that crash is a bother. You can still safely use the "Create Formula" button to assist you in figuring out the reference path, as long as you hit Cancel rather than OK.
@Jksnubben:
In the actor's events, you can try modifying the action for the "WeaponStart.*.AttackStart" event, which plays the attack animation. Change "Time Type" to Time Scale or Duration, and change Time Variant to your desired scale/duration.
Yesterday, I set up a Terran Tarmac doodad (which is a decal) to turn the terrain under it black, and a couple days ago, I made sidewalks using Hard Tiles (also called "roads" in the editor). So yes, you can do that--and the easiest way would probably be to swap out the textures for the Terran Tarmac models (or make additional variations like I did), and scale them as necessary. But keep in mind that the textures *will* squish when you scale them (whereas you can simply make smaller areas with normal terraining tools) and it would take additional variations to blend edges.
Edit: I originally attached my Terran Tarmac variation 10, along with its (blank) textures, but I forgot that I edited several aspects of it to make sure it was completely black. All you've got to do is load up the TerranTarmac_08 model in 3DS Max or a hex editor and change all instances of 08.dds to 09.dds and duplicate the textures, and you'll be in business.
Fixed a bug where the program loaded the wrong number of vertices. (As long as you didn't modify the vertices that shouldn't have been there in the previous version, it wouldn't have any effect on the model file.)
Fixed sorting by Z value.
I researched a bit more and figured out how faces are drawn, so if I don't get entirely bored with the project, I'll probably enable a polygonal draw mode and adding/removing vertices. (One cannot simply delete vertices without modifying the face data and possibly animation data.) I will also set up editing of material references, so you can put a different skin on a model while still using the original model with its original skin. I'd also like to deal with attach points (which requires implementing bones), but that's pushing it. :P
Not with the current version of my model editor, but you can pop open 010 Hex Editor and load up NiNtoxicated's M3 template like I did... struct MODL mdata -> struct Ref mVert -> struct HeadRef HRef -> ulong indData is the number of vertices. Just reduce that number and it should cut off the last vertices. I don't know what kind of effect it has on texturing or continuity of the model, but I speculate that it doesn't affect texturing.
Well, I tried cutting off 400 vertices and I ended up with just a sphere. :P
The program is C#, and I only tested it with about 6 models.
Once in a while, I want to accomplish a pretty simple task, and I don't have the tools to do it. I didn't want to download a 3DS Max trial since it's huge...and a trial. But Blender has a M3 importer, but no exporter. There have been a few times I wanted to move a couple polygons in a model, and then there have been a few times I found animations labeled "None" in a model so there was no way to access them. And since I'm a programmer, I solved my problem the hard way. I wrote a quite simple M3 model editor, which can reposition vertices and rename animation sequences. At first, I had just made a program to scale the height of every model in a directory, because that's the only way to change the height of cliff faces.
And I didn't really want to stop so soon, since I spent 3 hours researching the M3 format. :P
I will probably implement the ability to remove vertices and possibly implement the ability to add them, depending on how difficult it ends up being. I'd like to support at least partial modifying of animations, but that's not looking very likely. I realize that effort would be better spent on a Blender exporter, but I haven't used Python before, and I'm not in a position where I'm comfortable starting that type of project right now since I'm entering the Air Force in March.
Well, I wasn't planning on the ability to add or remove vertices because I'd have to change just about all the offsets in the file, but it looks like I'll have to do that anyway (which is less hard than I thought, it looks like) in order to rename animations. In the current iteration, you can just move vertices.
I didn't want to start too big a project since I'm good at not finishing big ones. :P
If I stay off my IM clients, I may be able to have animation renaming implemented in a few hours, but there will probably be no animation viewing, so you'd have to use it in tandem with the Galaxy Editor model previewer or something.
Edit: Voilà!
Back up the models for which you want to change the animations and give it a shot if you want.
0
I think it would require using one of the currently unused unit collision types, changing every not-burrowed not-a-worker mobile ground unit in the game to collide with that type, and setting the egg to use only that collision type. However, in SC1, workers failed to collide with any ground units, but only while attempting to gather resources. You could accomplish that by giving the workers a behavior, with a validator that makes sure it is using the Gather ability at any stage, with the Suppress Collision flag set.
0
Can one truly necro a pinned topic? :P Just because, I'm going to reply to a 1.3-year-old post!
@ZarafFaraz: Go
I don't know who originally made the billboards, but I took the in-game billboard model and the images from the first page of this topic and assembled two variations of a SC2Mapster billboard just now, because billboards are the coolest way to advertise. :P
0
@sonnert:
Use the camera editor to make sure your camera angle is exact, then hold the mouse button while hitting an arrow key on the keyboard to scroll the map. Zoom in if it jumps too far.
Unless someone knows something I don't about brush constraints. :P
0
Okay, to do this, we need to know how the Xel'Naga Tower controlling works...which is an ability called Tower Capture. The ability automatically casts itself whenever a non-buried, non-dead, non-hidden, non-missile, non-structure, non-uncommandable...*whew*...and non-under-construction ground unit is nearby. Set an event to trigger when the ability Tower Capture is used, and use the Triggering Ability Unit Target to get the player in control of the tower.
If you don't want to use an event for it, you'll need to use Unit Ability Command State (returns a boolean) to determine if the Tower Capture ability is being used, then Target Unit for Order to get the unit. Here's an example for this:
(Xel'Naga Tower [7.00, 16.00] ability command ((Tower Capture, 0)) is in state Executing) == True
(Target unit for (Xel'Naga Tower [7.00, 16.00] order at index 0)) == Value 2
To determine if the tower is being controlled at all:
Value 1: Unit Ability Command State
Unit: Xel'Naga Tower [7.00, 16.00]
Ability Command: Ability Command
Ability: Tower Capture
Command: 0
State: Executing
Operator: ==
Value 2: True
And to get the player in control of the tower:
Value 1: Target Unit For Order
Order: Unit Order
Unit: Xel'Naga Tower [7.00, 16.00]
Index: 0
0
The camera in my current map decided to start being jumpy one day out of the blue, as far as I can recall. I've verified that the camera is being told to pan just as smoothly as ever, the target is moving properly and rapidly, etc. I've tried changing the panning duration and deceleration and so forth. I've tried enabling and disabling height smoothing and height displacement. I've also tried messing with a few of the Default Camera data-only options, such as minimum smoothing time. I cannot figure out the cause for the behavior of this camera, although it does seem to be linked to what's in the foreground. Does anyone have a clue how to put an end to it?
Some specifics for the sake of satisfaction and not having to answer certain questions later:
I verified that this line is occurring with high but constant frequency even during the jittering, and regardless of how I tweak the parameters: Camera - Pan the camera for player (Picked player) to CameraPoint over 0.1 seconds with Existing Velocity% initial velocity, 10% deceleration, and Do Not use smart panning
I verified that CameraPoint is being moved in the correct direction, both smoothly and consistently, as well.
I also tried disabling height smoothing and height displacement immediately after that line, which only resulted in my camera being lower. (The camera is above a cliff but not right at the edge.)
0
0
0
0
0
0
Fixed a bug where the program loaded the wrong number of vertices. (As long as you didn't modify the vertices that shouldn't have been there in the previous version, it wouldn't have any effect on the model file.)
Fixed sorting by Z value.
I researched a bit more and figured out how faces are drawn, so if I don't get entirely bored with the project, I'll probably enable a polygonal draw mode and adding/removing vertices. (One cannot simply delete vertices without modifying the face data and possibly animation data.) I will also set up editing of material references, so you can put a different skin on a model while still using the original model with its original skin. I'd also like to deal with attach points (which requires implementing bones), but that's pushing it. :P
0
Not with the current version of my model editor, but you can pop open 010 Hex Editor and load up NiNtoxicated's M3 template like I did... struct MODL mdata -> struct Ref mVert -> struct HeadRef HRef -> ulong indData is the number of vertices. Just reduce that number and it should cut off the last vertices. I don't know what kind of effect it has on texturing or continuity of the model, but I speculate that it doesn't affect texturing.
Well, I tried cutting off 400 vertices and I ended up with just a sphere. :P
The program is C#, and I only tested it with about 6 models.
0
I guess my file host is being dumb. Redirect your attention to the attachment here! http://www.sc2mapster.com/forums/development/artist-tavern/31310-simple-m3-model-editor/#p1
0
I posted this program in http://www.sc2mapster.com/forums/development/artist-tavern/31243-fast-way-to-rename-animations-in-m3/ already, but I guess it should have its own topic.
Once in a while, I want to accomplish a pretty simple task, and I don't have the tools to do it. I didn't want to download a 3DS Max trial since it's huge...and a trial. But Blender has a M3 importer, but no exporter. There have been a few times I wanted to move a couple polygons in a model, and then there have been a few times I found animations labeled "None" in a model so there was no way to access them. And since I'm a programmer, I solved my problem the hard way. I wrote a quite simple M3 model editor, which can reposition vertices and rename animation sequences. At first, I had just made a program to scale the height of every model in a directory, because that's the only way to change the height of cliff faces.
And I didn't really want to stop so soon, since I spent 3 hours researching the M3 format. :P
I will probably implement the ability to remove vertices and possibly implement the ability to add them, depending on how difficult it ends up being. I'd like to support at least partial modifying of animations, but that's not looking very likely. I realize that effort would be better spent on a Blender exporter, but I haven't used Python before, and I'm not in a position where I'm comfortable starting that type of project right now since I'm entering the Air Force in March.
I hope someone gets some use out of it.
Edit: I've created an Assets page for this.
0
Well, I wasn't planning on the ability to add or remove vertices because I'd have to change just about all the offsets in the file, but it looks like I'll have to do that anyway (which is less hard than I thought, it looks like) in order to rename animations. In the current iteration, you can just move vertices.
I didn't want to start too big a project since I'm good at not finishing big ones. :P
If I stay off my IM clients, I may be able to have animation renaming implemented in a few hours, but there will probably be no animation viewing, so you'd have to use it in tandem with the Galaxy Editor model previewer or something.
Edit: Voilà!
Back up the models for which you want to change the animations and give it a shot if you want.