| 02-27-2007, 02:46 PM | #1 |
Not those BJs, mind you, but BJ functions in Wc3.... PolarProjectionBJ is defined as: function PolarProjectionBJ takes location source,real dist,real angle returns location local real x = GetLocationX(source) + dist * Cos(angle * bj_DEGTORAD) local real y = GetLocationY(source) + dist * Sin(angle * bj_DEGTORAD) return Location(x, y) endfunction I'm trying to write my own code to use instead of the polarprojectionbj function, but I don't understand at the end what that bj_DEGTORAD is...nor can I find an explanation in JSP. Any help? ---------------------------- Quick edit: Whoever came up with IssuePointOrderLocBJ should be shot: function IssuePointOrderLocBJ takes unit whichUnit,string order,location whichLocation returns boolean return IssuePointOrderLoc( whichUnit, order, whichLocation ) endfunction Does anyone actually USE or NEED a boolean return? I know it MIGHT be useful in theory, but I've never seen it used. |
| 02-27-2007, 02:55 PM | #2 |
bj_DEGTORAD converts Degrees to Radians. Wc3 trig functions calculate things in Radians, so you need to convert to radians when putting something into one of those functions. For example, the CosBJ function, this is used in GUI, which uses degrees, but if you look at the function, they convert it to radians for it to work. JASS:function CosBJ takes real degrees returns real return Cos(degrees * bj_DEGTORAD) endfunction And when you want radians to degrees, you use bj_RADTODEG. Oh, and IssuePointOrderLoc returns a boolean to tell you if the order is possible, if the unit cannot to the order, it will return false. |
| 02-27-2007, 03:09 PM | #3 |
Ah..thanks, hadn't though about working with either degrees or radians...gah its been long since trig. Yea, I knew about the return issues for issuePointOrderLoc and its BJ, just seemed really silly to me. Oh, and tide..one last quick question: I know certain people (like you) are totally anti-BJ because they're leaky and just not a good coding practice, but does EVERY BJ leak? Or is that just a generality that usually is true? ---------------- Ok I was working on reworking some of my code to remove BJs, and this is what I started with: JASS:local unit u = GetTriggerUnit() local integer i = GetUnitAbilityLevelSwapped('A01E', u ) call SetUnitLifeBJ( u, ( GetUnitStateSwap(UNIT_STATE_LIFE, u) - ((i * 50) + 50 ) ) ) call SetUnitManaPercentBJ( u, ( GetUnitManaPercent(u) + (i * 20) ) ) And this is what I ended with: JASS:local unit u = GetTriggerUnit() local integer i = GetUnitAbilityLevelSwapped('A01E', u ) local real life = GetUnitState( u, UNIT_STATE_LIFE) local real mana = GetUnitManaPercent( u ) call SetUnitState( u, UNIT_STATE_LIFE, ( life - ((i * 50) + 50 ) )) call SetUnitState( u, UNIT_STATE_MANA, (mana + (i * 20) )) set u = null Do they do the same? |
| 02-27-2007, 03:25 PM | #4 |
GetUnitAbilityLevelSwapped('A01E', u ) To: GetUnitAbilityLevel(u, 'A01E') Also, you can use GetWidgetLife(u), instead of GetUnitState, which is faster (?) and shorter. |
| 02-27-2007, 03:32 PM | #5 |
Alright, I've changed out to GetUnitAbilityLevel instead of GetUnitAbilityLevelSwapped My main concern now that I'm looking back over it is the new: JASS:call SetUnitState( u, UNIT_STATE_MANA, (mana + (i * 20) )) vs. JASS:call SetUnitManaPercentBJ( u, ( GetUnitManaPercent(u) + (i * 20) ) ) I think I goofed..I don't see that working the way I need it. ------------------ On a separate issue, so I don't have to create another thread, are x and y values (and the functions that use them) faster than locations (and the functions that use them)? |
| 02-27-2007, 03:35 PM | #6 |
20 BJ functions in one thread cause your map to explode and corrupts mpq files, so you need to format the hard drive =/ |
| 02-27-2007, 04:02 PM | #7 | |
Quote:
Lies. No, not every BJ function leaks, but they are just custom made functions that could be better. They are seperate functions blizzard has made to make theyre lives easier. But alot of them do not do much, alot of them are just wrapper functions that call another function, like: JASS:function SetUnitBlendTimeBJ takes unit whichUnit, real blendTime returns nothing call SetUnitBlendTime(whichUnit, blendTime) endfunction That function just calls SetUnitBlendTime Theyre is no point in that when you can call it directly, saving processing time. Thats what im against, but some functions do leak pointers, and sometimes groups if you dont set a variable. Oh, and for your 'vs', the SetUnitState is better. If you take a look in the SetUnitManaPercentBJ, you will find it just calls SetUnitState. JASS:function SetUnitManaPercentBJ takes unit whichUnit, real percent returns nothing call SetUnitState(whichUnit, UNIT_STATE_MANA, GetUnitState(whichUnit, UNIT_STATE_MAX_MANA) * RMaxBJ(0,percent) * 0.01) endfunction So it is kind of a wrapper function. |
| 02-27-2007, 04:07 PM | #8 |
I just wasn't certain if I reorganized the call correctly. I completely rewrote the SetUnitState call, and subsequently left out the * .01 which I may desperately need for it to calculate it correctly. The point is to restore 20% * level (so at level 1, 20%, level 3, 60%). Is that what my SetUniteState call does? (I can't test it) |
| 02-27-2007, 04:56 PM | #9 |
BJs aren't inherently bad, there are actually some incredibly useful BJs. TriggerRegisterAnyUnitEventBJ(..) is an example of one of the coolest BJs ever made. The Multiboard Bjs are also pretty awesome. The real problem with most BJs is that they really don't make anything easier to handle or figure out, and function calls to non-natives in jass are really freakin' slow compared to other coding languages. So yeah, things like "Swapped" BJs or "Percent" BJs are pretty tacky and should be replaced. JASS:local integer lvl = GetUnitAbilityLevel(u, 'A01E') local real curmana = GetUnitState(u, UNIT_STATE_MANA) local real maxmana = GetUnitState(u, UNIT_STATE_MAX_MANA) local real manaper = curmana / maxmana //I really have no idea what you want to achieve, but for example to add 20% to their current mana by level... call SetUnitState(u, UNIT_STATE_MANA, maxmana * (manaper + ((lvl)*.2))) //See how that worked? You multiplied their max mana by a decimal to get a new value. //This can give more than max mana, but you could add conditions if you feel that's unsafe. //Now in the case you just wanted to add X mana to their current by level... call SetUnitState(u, UNIT_STATE_MANA, curmana + (lvl * 20)) //That adds 20 mana to the unit's current mana for each level of the spell it has. |
| 02-27-2007, 06:10 PM | #10 |
Alrighty, thanks for that assistance, I now have that issue fixed. I do have another problem with another snippet: JASS:call CreateUnit(GetOwningPlayer(u), 'E00C', x1, y1 - 50, GetUnitFacing(u)) set dup = GetLastCreatedUnit() if dup != null then call BJDebugMsg( "DUP != NULL" ) else call BJDebugMsg( "DUP == NULL" ) endif Outputs "DUP == NULL" every time. I'm confused as to why this is happening. |
| 02-27-2007, 06:11 PM | #11 |
The CreateUnit native does not set GetLastCreatedUnit() to anything. It is a native. JASS:set dup = CreateUnit(GetOwningPlayer(u), 'E00C', x1, y1 - 50, GetUnitFacing(u)) |
| 02-27-2007, 06:20 PM | #12 | |
Quote:
If it was that, Warcraft 3 would be already died. And also, no one complained that BJs were too slow (especially non-map makers, and also they never noticed it). |
| 02-27-2007, 06:24 PM | #13 | |
Quote:
|
| 02-27-2007, 06:33 PM | #14 |
Noone's telling you not to use BJs in your code, we're simply offering help to someone who wants to remove them from his code. They *are* slower, though they will not slow a map a noticeable amount. It may not be necessary to remove them, but it is good practice to do so. Also, he did post this topic to get help to remove them, suggesting he wants to for his own reasons. So shoosh. :P |
| 02-27-2007, 07:00 PM | #15 |
lol... Anyways, is there a way to test to see if a particular x/y coordinate has a tree or other doodad on it? I have a spell that encircles the caster with dummy units to "trap" whoever is inside in (or whoever is ouside, out) but if a tree is within a point where one of the dummy units should be created, it is pushed off path and thus, doesn't make a perfect circle. |
