SC2Mapster

Since it sounds like you're wanting to determine when the camera is zoomed in or out, why not try the "Camera Moves" event? It has a Zoom preset for its "reason" parameter.

Blah blah blah, necro, etc.

So anyway, I've been working on identifying additional structures and fields for NiNtoxicated's 010 Hex Editor template. Additionally, I added the particle info he already had in his 3DS Max importer script into said template. And I'm posting this here in case someone else looks for this sort of thing any time soon.

Additions: identified most of the noteworthy LITE (lights), PHRB (physics body), and PHSH (physics shape) fields, added the SDCC and COL (color) structs, implemented PAR_ and PARC (particles) from the importer script, put in structs for the PATU, TRGD, and PROJ blocks, and identified and implemented the FOR_ (local forces) block.

It's a bit of a complicated process, but I'll try to explain it all for you.

First of all, you need to track the upgrades each player has. There's no way to just iterate through each upgrade, so you'll have to use a Unit Research Progress event to store the upgrades. You also need a place to store the upgrades, so create the following global variables:
StoredUpgrades: Type = "- Game Link", Link Type = "Upgrade", check Array, set the first size to 16 and the second size to a number big enough to hold all your upgrades (perhaps 100).
StoredUpgradeCount: Type = Integer, check Array, set the size to 16.

StoredUpgrades will be the variable that holds the actual upgrades, while StoredUpgradeCount will be used to tell the trigger which slot to should put the next upgrade in.

So in your trigger with the Unit Research Progress event (which, by the way, should be "Any Unit research progress is Completed"), make a Set Variable action. Set StoredUpgrades[Triggering Player][StoredUpgradeCount[Triggering Player]] = (Triggering Progress Upgrade). This will store the upgrade as the player completes it. Then add another Set Variable action, and Set StoredUpgradeCount[Triggering Player] = Arithmetic(StoredUpgradeCount[Triggering Player] + 1). This ensures you won't overwrite previous upgrades when a new upgrade is stored.

Now go to your Unit Entered Region trigger. Create a local Integer variable for a loop; let's call it "x" here, but you can use a more descriptive name. Add a For Each Integer loop, using that variable, from 0 to Arithmetic(StoredUpgradeCount[Triggering Player] - 1). This upper bound is because our first upgrade is in slot 0, but StoredUpgradeCount is 1 at that time. Leave the increment set to 1. In this loop, you need an Add Upgrade Level for Player action. Set the upgrade to StoredUpgrade[Triggering Player][x], and set the player to whatever player you give the units to. After the loop, set StoredUpgradeCount[Triggring Player] to 0 so that these upgrades won't be added again the next time a unit from that player enters the region.

Multiple upgrade levels: I don't think it'll cause any errors if you exceed the maximum level for an upgrade, but if it does, you might have to use Set Upgrade Level instead, so if that's the case and you have an upgrade with multiple levels, you would have to modify this trigger to get more than 1 level to transfer. Also, if one player has 3 levels of an upgrade and another player has 5 of the same upgrade and its maximum is 10, you'll end up with the target player having 8 levels.

Only giving upgrades that apply to the current unit: In order to determine if an upgrade applies to a specific unit type, make an If Then statement with a Unit Type Is Affected By Upgrade == True condition. Set the unit type to Unit Type Of Unit (Triggering Unit) and Upgrade Type to StoredUpgrade[Triggering Player][x]. Instead of setting StoredUpgradeCount to 0 after the loop, you need to remove that action and subtract 1 from StoredUpgradeCount inside the If Then statement, and immediately before that, you would also Set Variable: StoredUpgrade[Triggering Player][x] = StoredUpgrade[Triggering Player][StoredUpgradeCount[Triggering Player]]. This results in the last upgrade in the array being moved backwards so that it isn't forgotten due to the reduced StoredUpgradeCount.

You can modify the emissive texture to darken the non-blades portions, then use my model editor ( http://www.sc2mapster.com/assets/deps-m3-model-editor/ ) to increase its emissive multiplier, assuming you can figure out which material is used by the blades. It won't break the dreads, and the material editor is marked as "not implemented" but it can edit specular and emissive multipliers. :P

@bravojuliet: If you want a number without any fractional part (ie. -7, 3, or 2398), you'd declare it like this: int nameOfYourIntegerGoesHere; For larger numbers, use "long" (8 bytes) instead of "int" (4 bytes), and for smaller numbers, use "short" (2 bytes) or "char" (1 byte). You can also declare a variable that is strictly nonnegative with the "unsigned" keyword: unsigned int NameOfYourIntegerGoesHere; If you want a number with a fractional part (ie. 0.5, 12.4, or -0.003) you'd use a "float" or "double" (which allows both larger and more precise numbers than a float) instead: float nameOfYourFloatGoesHere; So in general, it's <font color="#0099FF">variabletype</font> <font color="#99FF00">variablename</font> <font color="#FF0099">semicolon ( ; )</font>

There are multiple variations.

So this problem is caused by the Fog Grey doodads I placed in the lab. If I remove those, the jitter is gone, and if I hit undo and test again, it's back. However, it's clearly not a frame rate issue--the fog is actually interfering with the camera's movement. I failed to find any particular flags in the actor or model that had an effect on the interference, though. When it's not 3 AM, I'll try creating the fog during runtime as actors rather than doodads and see if that changes anything.

@Deeweext: Go

1. Reduce the separation radius and inner radius in the unit's Movement tab.

2. I'd say that using a "Unit Uses Ability" event would probably trigger for setting a rally point, and then you could use a Issue Order (Order Targeting Point) to fix the rally point.

3. Check out the Command Center Rally ability in the data editor. Remove the command that has its "Set on ground" box checked.

The way my program is designed, it's not possible for information to be lost. I believe you need to update the terrain object's size in the data editor. It could be something else, though. :p

Edit: Well, I tried changing the size in the data editor and it just made the terrain object cease to exist. But I used the previewer to verify the material data hasn't changed despite the ugly stretched edges. It might have to do with the UV mapping needing updated, which my editor is also currently not capable of dealing with. Additionally, the terrain object's edges aren't screwed up everywhere; depending on where you place the object, its edges may look just fine.

You could add a 0.0625-second dummy behavior to them and set a condition in the Unit Enters Region trigger to ensure the triggering unit does not have said behavior.

Create a Buff behavior (let's call it PreserveUnit), then go to the Stats tab and set Duration to 0.0625, which is one frame of game time.

In your unit creation event, add a Pick Each Unit in Unit Group action, using the Last Created Units (assuming you made them all with one command), and in the loop, use an Add Behavior To Unit action with the PreserveUnit behavior and Picked Unit.

In your Unit Enters Region trigger, add a "Not" condition, and inside it, add a "Unit Has Behavior" condition using Triggering Unit and the PreserveUnit behavior.

@Enexy: Go

Check out the Camera properties in the Data Editor. There are several pertaining to following. I believe, in particular, reducing the maximum smoothing time for following should accomplish your goal.

Yeah, there's a "Hide Lowest Level" option in the Terrain Texture Sets data.

@zorbotron: Go

You can't do that at this time, but that was actually something I was considering the last time I was working on it. I can have that done in no time, just for you. :P

Edit: Done, uploaded. Enjoy. :3

3/10 because it's blurry; I can't even tell what it is. Wait, is that a beany octopus? :P

To he who rates my avatar... it's me!

(The drawing, done by fly_boy42, came before the photo.) :P

@Zolstice: Go

"Advertising

This category includes content which advertise:

Any non-beneficial businesses, organizations, or websites"

It sounds like advertising a mapmaking community does not fall under this clause, so it ought to be fine.

http://us.battle.net/support/en/article/starcraft-ii-inappropriate-content-policy-overview