SC2Mapster

I'm assuming you set this to a button, and it acts as a backdrop for an empty item slot, correct? Has anybody gotten this working? I currently have bags / equipment set up for my hero, and custom buttons I want to use as backdrops for equipment slots, but despite applying them as the "Empty Face" for slots inside the container editor they are not showing up in-game.

@ashgad: Go Doesn't the fixed real variable prevent you from having an exact value of 90 or 270? If you set a real to 90 or 270 and then get the tangent of that, would it still divide by zero?

@Alex134: Go

I really liked the map. I died after completing the first objective, about 20 minutes in, and didn't play after that because I was a bit annoyed and didn't want to do everything over, but it was very well-made.

Quote from PSGMud: Go

I thought this doesn't work with bnet latency?

It doesn't work any less than any other method. The lag just makes FPS games in general unplayable.

Hello sc2mapster, I didn't get you guys with the first showcase, so you can see it on youtube here:

Today I'm posting a second showcase, this time featuring the physics engine I've been working on. It's by no means perfect, but I've currently got a headache from being so frustrated with it so I decided to take a break and share my progress. :)

Here's the newest video:

And the description: This video is an update on the "Reaper Madness" UMS game for SC2 that is currently in development. I haven't posted an update in a while because I've been very busy creating a new physics engine from scratch. Since the last video, I have:

1. Made significant improvements to the UI
2. Removed all previous movement functions and begun coding a vector-based physics engine to replace them
3. Implemented a prototype grenade, the baneling grenade, that showcases the current state of my physics engine
4. Implemented multiple hitboxes per unit. I showcase a couple headshots in this video
5. Made some progress on seamless cliff-jumping. The unit moves smoothly over the cliff, however I'm not sure there's a solution to the jolting camera
6. Implemented a "bnet mode" that is designed to allow leniency on aiming due to BNet's minimum of 125ms latency

About 90% of the time since my last video has been spent on this physics engine. So far it's been a huge headache, as I've never used let alone created a physics engine before.

I am contemplating abandoning the project for a few reasons:

1. The minimum latency on BNet is posing a huge problem. As the only player in the game, the latency makes the game feel unplayable (To me, as a former FPS enthusiast). It definitely doesn't feel like 125ms (which is already high for an FPS game)
2. The unfixable camera jolts when crossing cliffs; Another thing out of my control that ultimately makes the game less fun to play
3. The camera renders all textures and models at 100% even at great distances, meaning the player gets considerable video lag. Currently when I look toward the center of my map, my mouse is inconsistent in its response, making precise aiming virtually impossible

@Slistak: Go

Do you have a link to the guide you're talking about? The easy way to do it is:

1. Open your map
2. File -> "Save As..."
3. "Editor Components List" from the dropdown
4. Open the MapScript.galaxy file in your favorite text editor and start coding away

You won't be able to use triggers through the trigger editor this way, it all has to be hand-coded.

@Ardnived: Go

You need a traceline function to detect which units/buildings/terrain the player is aiming at using mouselook. Take the player's camera vaules: Yaw and Pitch. Use those angles to draw a line from the camera's height and position, along the direction the player is facing. Take small steps down the line in increments until it intersects a unit, building or terrain.

To detect collision with a unit, attach a region to the point in the traceline and get all units inside the region. If the unit count is >1, create a region with the radius of the unit (or your own custom value, which can be more accurate) and attach it to the unit. If the traceline intersects the region, you know that you hit the unit on the XY plane. To check the Z plane (height) you'll need to either specify a custom height for each unit (The most precise) or take the easy approach and just use the unit's radius as a baseline. Using the radius won't work very well on odd-shaped units like colossi or tanks. For flying units, you'll have to specify a Z offset as well. For instance, a muta flies 3.75 units above the c_heightMapAir heightmap.

Detecting collision with terrain is much easier. At each step, simply check if that point in the traceline is below the WorldHeight() at that point. If it is, then the shot collided with terrain and you can spawn the appropriate effects at that point.

This doesn't apply only to shooting. Any form of aiming will require a traceline. For instance, in Reaper Madness an enemy bar pops up when your crosshair is over another unit. This requires a traceline.

From my experience, the cliff levels alternate. If the corner tile at (x,y) = (5,5) is round then (4,5), (6,5), (5,4) and (5,6) are all square.

I have only been paying attention on one specific tileset so this behavior may be unique to those cliffs.

Alright, guys, this is something I've been having a ton of trouble with for over a week, and I've gone extremely far out of my way to try to solve it, with no luck. Basically, my camera follows my hero, and my hero can fly steadily over cliffs. My hero can ignore all cliff height and fly at a constant height no matter what terrain he's on, which is great. However, cameras do not have the same options available as units do. My camera can remain steady over bumpy terrain using calculations involving WorldHeight(), however when moving over the edge of a cliff my camera ALWAYS jolts.

On all heightmaps (Ground, air and glide) there are invisible ramps leading up the edge of the cliff. The ramp heights are not linear, making calculating the offset impossible. I have looked through the available camera functions too many times to count and I can't find any setting that will either ignore these ramps, ignore terrain or otherwise rid me of this issue. I'm pulling my hair out over this one.

I know it's a long shot that anybody else is even working on this, as getting my unit to be able to fly smoothly across cliff levels was a task in itself, but does anybody know something I don't? I'd love to be able to get past this hitch and move on.

@Zeke50100: Go

A first person shooter might not be the easiest way to get used to the editor.

You can make a crosshair for all players by drawing a screen image, or you can make individual crosshairs by creating a dialog, hiding its background and adding an image to it as a dialog item. You can change the facing of the unit by calling UnitSetFacing on the unit every 0.0 seconds and updating it to the Yaw of the player's camera which you can get with CameraGetYaw. To get the camera into first person, you want to set the camera object bounds to a small region you have attached to the unit, and set the camera's values however you desire them.

Here's an example from my game. It's over-the-shoulder third-person but you can push it up to first-person by adjusting the numerical values of HeightOffset and Distance:

CameraSetValue(gv_players[i].playerID, c_cameraValueHeightOffset, -0.5, 0, 0, 0);
CameraSetValue(gv_players[i].playerID, c_cameraValueDistance, 3.0, 0, 0, 0);
CameraSetValue(gv_players[i].playerID, c_cameraValueNearClip, 0.3, 0, 0, 0);
CameraSetValue(gv_players[i].playerID, c_cameraValueFarClip, 20000.0, 0, 0, 0);
CameraSetValue(gv_players[i].playerID, c_cameraValueFieldOfView, 75.0, 0, 0, 0);

There's a full list of functions here: http://paste.sc2mapster.com/1979/

All of the functions I've mentioned are also available in the trigger editor, as are most of the functions at the link I supplied. Their location in the editor is usually pretty self-explanatory.

@WontonST: Go

Yes, you simply save unit001 as a variable. Create a variable (We'll call it SavedUnit) with type unit. In trigger001 after creating the unit, set variable SavedUnit to LastCreatedUnit(). You can use "Unit Dies" events from there.

@Docablo: Go

You can change the size of your actor by sending it a message after making it. You can set the number of max iterations by passing an iterator to the recursive function. Here's an example of both changes:

void recursiveFunction(int iteration)
{
    if(iteration < 15) {
        //All of your function stuff. Create your actor (new missile).
        ActorSend(libNtve_gf_LastCreatedActor(), "SetScale 0.200000");
        recursiveFunction(iteration+1);
    }
}

@Centreri: Go

Use the KeyUP and KeyDOWN events to set a bool value to true or false, representing the state of the key. Write a trigger that occurs every 0.0 game seconds that turns the unit a slight angle if that boolean value is true.

Quote from Ttn114: Go

@rrowland: Go

Oh wow you can change that? The constant flickering from auto-adjustments was driving me nuts

I don't know if you're doing all the movement from instant positioning or some combination of issue ordering, but if the former try reading from stored vectors/points at all times and only writing to the unit, like this:

gameloop(){ newposition = oldPosition + movement; Turn ignore Height State On Move unit instantly to newposition Set unit height to Z-value of newposition oldPosition = newposition }

I'm moving by issuing commands, it seems smoother to me. Have you had success making WASD movement + mouselook aiming using instant moves? If so, I will test it out and see how it compares to issuing move commands. I've tested my map on BNet 2.0 and the 125ms minimum lag is looking to be an issue, so if there's any way to make movement more efficient in laggy situations I'm all for it.

For anybody interested, I developed a cheesy little work-around that I'd rather avoid, but will be using until there's a fix or solution for this issue. Basically, I'm just moving my unit to his current position instantly every time I change my unit's height, so it always acts correctly as if I'm constantly moving, even when I'm not. It's redundant, wastes processing and creates lag I'm sure, but for now it seems to be the only fix.

Now if there were a way to apply this flag to the player's camera, my cliff ignore functionality would be completely seamless.