You can fix camera lag. I've seen camera render distances being modified in the following maps. Peredition, Mars Sara. You can look into the triggers for more info.
make the target box larger to compensate for high lat.
Cameara Jolting? Someone's going to come up with a solution in no time. It's probably in the animation.
if you must give up, can you release your stuff so that others can make progress? It looks pretty damm impressive. Without jass eh?
I have no problems with camera lag and my camera jolting issue is exclusive to a unit moving over the edge of a cliff, and is caused by the invisible ramp. I also already have larger hitboxes when connected to bnet to compensate for lag, however that does not address the delay when moving and jumping.
A bug in GE makes UnitInventoryLastCreated() unusable. The library definition specifies that it takes a unit parameter, but it doesn't. If you try to save your map with "Last Inventory Item Created" you will get an invalid parameter type error. The workaround I'm using for this is instead of selecting "Last Inventory Item Created" from the Function menu, I'm adding the Custom Script "UnitInventoryLastCreated()" in its place.
I did a periodic event every 0 secs and input Traceline(position of main unit, camera height: 1, 1); And the traceline_targetPoint is always at the main unit... My camera works just like urs its not pointing at the unit.
That's because 1.0 is under the world height, which is 8.0 by default. Pass camera height as WorldHeight + 1.0 instead of 1.0.
This will double your maximum loops per second to 46. If you remove the Wait statement you will exceed 128 which will cause a stack overflow, so it's necessary.
Rrowland thats not correct basically the fastest time you can implement is .0001 of a second well if you input 0.0 is actually refreshing as fast as possible which is even faster. I noticed with the traceline function there is no need to do it faster than .2 seconds because you will eat alot of ram the other method just redoing the same feature. This will cause latency problems later on with multi-player maps and for slower machines.
Well just to make sure, I just ran a test:
A variable to count how many times our fastest timer has elapsed:
So every 0.00 seconds it will increase the integer by 1. After 1 second, it displays the number of iterations and then sets the integer back to 0.
Here are the results (plugging in different times for the fast timer):
0.00 seconds = 23 loops
0.0001 seconds = 23 loops
0.001 seconds = 23 loops
0.01 seconds = 23 loops
0.1 seconds = 8 loops
Those results show that really 0.045 is actually the fastest time you can implement using real time. If we switch our fastest loop to game time and switch our game speed to 'fastest', we get the results:
0.00 seconds = 23 loops
0.0001 seconds = 23 loops
0.001 seconds = 23 loops
0.01 seconds = 23 loops
0.1 seconds = 11 loops
So yes, I was wrong that the shortest loop interval is 1/32 of a second, it is in fact worse at 1/23 of a second. Using game time does not affect this limit, only the rate at which you reach the limit.
Make a global variable (in the trigger list on the left) named "mainUnit" of type "unit" and make it an array of size 2. After you spawn each unit, set the mainUnit of that player to Last Created Unit.
mainUnit[0] = Unit that was created for player 1.
mainUnit[1] = Unit that was created for player 2.
If mainUnit[0] dies, player 2 wins
If mainUnit[1] dies, player 1 wins
I think the whole traceline idea is great. But the problem with it is that we need to create a vector system in order to create a very realistic shooting system.
Right now, what I've been doing is simply using the point that the center of the camera is looking at and create a sniper damage from the main unit to any unit within that point. Now this is the problem, because what happens if you are targeting the head of a unit, but that is actually pointing to a point far far away from the unit's head? Aha see, that is a problem! Hence we need to create a vector system, instead of using the dumb environment effect that blizzard creates, we need to create an actual missile that goes to that point. If the missile hits something, kill it and it will do damage.
This map so far uses a line system, so it is much more accurate than sherardt's way of using circle region at the point clicked. It will create circle regions from main unit to target point and figure out which unit is the closest at that "line". But it doesn't make sense because you can pretty much target at a point beyond an enemy unit and still kill it if u get the angle right... So it does not replace the missile system I'm talking about.
PRESS ESC for the 3rd person view
You're talking about two different things. You're saying you want to treat bullets like missiles, in which case yes you'd use vectors. The minimum amount of time spent between steps is "0.0" which actually means 1/32 of a second (I believe) due to the fixed point (reals) system. Assuming that a bullet should span an entire map in less than 0.1 seconds, that means each step would be approximately 1/3 of the map. You can't simply check for a hit every step this way, or you would only ever hit a unit if the bullet happened to land on him at one of the wide steps. You would need to generate a heightmap of the entire map to get the planes of the terrain, and you'd have to create a box of planes around every unit that is shootable. Then you'd need to run some vector calculations to determine whether or not the bullet's directional vector intersects any of those planes. In the case of multiple, you'd have to figure out which one it hit first.
The most obvious downside is you won't be able to see which unit the player is looking at without a traceline. You could implement both, but that's a much bigger load you're throwing on the processor.
I also haven't been able to get the camera to work the way I think it's supposed to. The map linked here that has it working doesn't really work because targeting is based off of mouse XYZ and doesn't seem to use the traceline. This of course means it won't be possible to get headshots or shoot at the sky for example.
Here are my camera functions, straight from my code:
Rrowland I have a question for you? How did your trace line to affect a Mutalisk in that first video? I put some air units in the map and I have to aim low still to view their information?
Yeah, you need to set a Z value for flying units. I went over this briefly in the tutorial, you will have to replace the 0.0 in
with c_heightMapAir. The way I handled this is by creating structs (basically a variable with multiple variables inside) that describe each type of unit I will have in my game. Then at the beginning of the game I iterated through every unit and set their custom values to some of my custom values such as radius, heightmap, hitboxes etc.
I store some enumerated values in constants to make my code more readable, here are the relative constants:
//--------------------------------------------------------------------------------------------------// General//--------------------------------------------------------------------------------------------------constintc_EnemyTypes=4;constintc_MaxPlayers=4;constfixedc_MaxRange=30.0;//--------------------------------------------------------------------------------------------------// Custom Unit Values//--------------------------------------------------------------------------------------------------constintc_CustomValues_UnitType=0;constintc_CustomValues_OffsetZ=1;constintc_CustomValues_Height=2;constintc_CustomValues_HeightMap=3;constintc_CustomValues_Radius=4;constintc_CustomValues_PhysicsIndex=5;
Then I apply the properties to all existing units by placing them into custom unit values:
// Initialize Enemies (Existing on map creation) \\//--------------------------------------------------------------------------------------------------//voidcf_InitEnemies(){unitgrouplv_tempUnitGroup;unitlv_tempUnit;inti=0;intj=0;while(i<c_EnemyTypes){lv_tempUnitGroup=UnitGroup(gv_enemyTypes[i].name,c_playerAny,RegionEntireMap(),UnitFilter(0,0,(1<<c_targetFilterMissile),(1<<(c_targetFilterDead-32))|(1<<(c_targetFilterHidden-32))),0);while(j<=UnitGroupCount(lv_tempUnitGroup,c_unitCountAll)){lv_tempUnit=UnitGroupUnit(lv_tempUnitGroup,j);UnitSetCustomValue(lv_tempUnit,c_CustomValues_UnitType,i);UnitSetCustomValue(lv_tempUnit,c_CustomValues_OffsetZ,gv_enemyTypes[i].hitboxes[0].offsetZ);UnitSetCustomValue(lv_tempUnit,c_CustomValues_Height,gv_enemyTypes[i].hitboxes[0].height);UnitSetCustomValue(lv_tempUnit,c_CustomValues_HeightMap,gv_enemyTypes[i].heightMap);UnitSetCustomValue(lv_tempUnit,c_CustomValues_Radius,gv_enemyTypes[i].hitboxes[0].radius);j+=1;}j=0;i+=1;}}
I also have a trigger to add these values to newly created units:
//--------------------------------------------------------------------------------------------------// Trigger: Unit Is Created//--------------------------------------------------------------------------------------------------boolgt_UnitCreated_Func(booltestConds,boolrunActions){inti=0;while(i<c_EnemyTypes){if(UnitGetType(EventUnit())==gv_enemyTypes[i].name){UnitSetCustomValue(EventUnit(),0,i);UnitSetCustomValue(EventUnit(),1,gv_enemyTypes[i].hitboxes[0].offsetZ);UnitSetCustomValue(EventUnit(),2,gv_enemyTypes[i].hitboxes[0].height);UnitSetCustomValue(EventUnit(),3,gv_enemyTypes[i].heightMap);UnitSetCustomValue(EventUnit(),4,gv_enemyTypes[i].hitboxes[0].radius);}i+=1;}returntrue;}//--------------------------------------------------------------------------------------------------voidgt_UnitCreated_Init(){gt_UnitCreated=TriggerCreate("gt_UnitCreated_Func");TriggerAddEventUnitCreated(gt_UnitCreated,null,null,null);}
And now finally I am able to use these values in my traceline by using the custom values of the target I'm looking at:
Well, running fewer times and running less calculations are both equally efficient ways of optimizing code and should both be practiced. Whether one or the other is more efficient is entirely dependent on the function(s) in question. Your code should run as lightly as possible during any amount of load, and it should also avoid overloading itself at all.
I agree but I was also thinking of using it to draw a line for a projectile to follow, I was going to factor in gravity, and I have done some research already and Gravity isn't the same due to scaling of the game. I figure If the average person is about 2 m high it means that a ghost is about .6 of the map scale. this to me means that that is approximately equivalent to 2 meters. That means gravity is closer to a -1 unit per second. As far as wind this might be good in a golf game or if you were sniping at a long distance, but for something fairly close this wont matter. I was also thinking of using this to display information about units and am having no luck with that aspect.
By wind resistance I'm referring to the friction caused by any object attempting to move through open air. This affects objects of all sizes moving in any direction, regardless of whether there is wind or not. The scale of its effect is dictated usually by mass and surface area of the object in the direction it's traveling, but for emulation purposes you can give it an absolute value on an object-by-object basis.
0
I have no problems with camera lag and my camera jolting issue is exclusive to a unit moving over the edge of a cliff, and is caused by the invisible ramp. I also already have larger hitboxes when connected to bnet to compensate for lag, however that does not address the delay when moving and jumping.
0
A bug in GE makes UnitInventoryLastCreated() unusable. The library definition specifies that it takes a unit parameter, but it doesn't. If you try to save your map with "Last Inventory Item Created" you will get an invalid parameter type error. The workaround I'm using for this is instead of selecting "Last Inventory Item Created" from the Function menu, I'm adding the Custom Script "UnitInventoryLastCreated()" in its place.
0
That's because 1.0 is under the world height, which is 8.0 by default. Pass camera height as WorldHeight + 1.0 instead of 1.0.
0
@Layola: Go
Oops, I forgot to re-add the if statement.
0
As a follow-up to my previous post, here's a way to double the maximum. Change your fast trigger to this:
This will double your maximum loops per second to 46. If you remove the Wait statement you will exceed 128 which will cause a stack overflow, so it's necessary.
0
The loop was unnecessary. This works:
0
Well just to make sure, I just ran a test:
A variable to count how many times our fastest timer has elapsed:
Our fast timer:
Every 1 second of real time display how many times the fast timer has run and reset the count:
So every 0.00 seconds it will increase the integer by 1. After 1 second, it displays the number of iterations and then sets the integer back to 0.
Here are the results (plugging in different times for the fast timer):
0.00 seconds = 23 loops
0.0001 seconds = 23 loops
0.001 seconds = 23 loops
0.01 seconds = 23 loops
0.1 seconds = 8 loops
Those results show that really 0.045 is actually the fastest time you can implement using real time. If we switch our fastest loop to game time and switch our game speed to 'fastest', we get the results:
0.00 seconds = 23 loops
0.0001 seconds = 23 loops
0.001 seconds = 23 loops
0.01 seconds = 23 loops
0.1 seconds = 11 loops
So yes, I was wrong that the shortest loop interval is 1/32 of a second, it is in fact worse at 1/23 of a second. Using game time does not affect this limit, only the rate at which you reach the limit.
0
@WraithChaser: Go
Make a global variable (in the trigger list on the left) named "mainUnit" of type "unit" and make it an array of size 2. After you spawn each unit, set the mainUnit of that player to Last Created Unit.
mainUnit[0] = Unit that was created for player 1.
mainUnit[1] = Unit that was created for player 2.
If mainUnit[0] dies, player 2 wins
If mainUnit[1] dies, player 1 wins
0
@Layola: Go
The units also have to have the ability you're trying to make them cast.
If you upload the map I'll take a look.
0
You're talking about two different things. You're saying you want to treat bullets like missiles, in which case yes you'd use vectors. The minimum amount of time spent between steps is "0.0" which actually means 1/32 of a second (I believe) due to the fixed point (reals) system. Assuming that a bullet should span an entire map in less than 0.1 seconds, that means each step would be approximately 1/3 of the map. You can't simply check for a hit every step this way, or you would only ever hit a unit if the bullet happened to land on him at one of the wide steps. You would need to generate a heightmap of the entire map to get the planes of the terrain, and you'd have to create a box of planes around every unit that is shootable. Then you'd need to run some vector calculations to determine whether or not the bullet's directional vector intersects any of those planes. In the case of multiple, you'd have to figure out which one it hit first.
The most obvious downside is you won't be able to see which unit the player is looking at without a traceline. You could implement both, but that's a much bigger load you're throwing on the processor.
0
Here are my camera functions, straight from my code:
0
Yeah, you need to set a Z value for flying units. I went over this briefly in the tutorial, you will have to replace the 0.0 in
with the height of the unit. You will also need to replace the c_heightMapGround in
with c_heightMapAir. The way I handled this is by creating structs (basically a variable with multiple variables inside) that describe each type of unit I will have in my game. Then at the beginning of the game I iterated through every unit and set their custom values to some of my custom values such as radius, heightmap, hitboxes etc.
I store some enumerated values in constants to make my code more readable, here are the relative constants:
Here are my two struct definitions:
I initialize a variable as an array of structs. c_EnemyTypes represents how many unit hitboxes I have customized:
Next I initialize all of my custom unit info. This is run only once at the very beginning of the game:
Then I apply the properties to all existing units by placing them into custom unit values:
I also have a trigger to add these values to newly created units:
And now finally I am able to use these values in my traceline by using the custom values of the target I'm looking at:
0
@ezbeats: Go
Well, running fewer times and running less calculations are both equally efficient ways of optimizing code and should both be practiced. Whether one or the other is more efficient is entirely dependent on the function(s) in question. Your code should run as lightly as possible during any amount of load, and it should also avoid overloading itself at all.
0
@Layola: Go
Yeah, you're using arrays wrong. Also take out the status = unused just because it's pointless.
Revision:
0
By wind resistance I'm referring to the friction caused by any object attempting to move through open air. This affects objects of all sizes moving in any direction, regardless of whether there is wind or not. The scale of its effect is dictated usually by mass and surface area of the object in the direction it's traveling, but for emulation purposes you can give it an absolute value on an object-by-object basis.