[JASS] Hidden ATTACK_TYPE in the World Editor?

[looking_for_help]

Hello all,

I wounder if there is some "hidden" functionality in the World Editor which isn't specified at all in the libraries, but still accessable.

According to the common.j , there are seven different AttackTypes, namely:

ATTACK_TYPE_NORMAL    = ConvertAttackType(0)
ATTACK_TYPE_MELEE     = ConvertAttackType(1)
ATTACK_TYPE_PIERCE    = ConvertAttackType(2)
ATTACK_TYPE_SIEGE     = ConvertAttackType(3)
ATTACK_TYPE_MAGIC     = ConvertAttackType(4)
ATTACK_TYPE_CHAOS     = ConvertAttackType(5)
ATTACK_TYPE_HERO      = ConvertAttackType(6)

This is also what you get in GUI when using the UnitDamageTargetBJ function to deal damage to a target.

BUT if you use ConvertAttackType(7) as an AttackType-Parameter for this function, you will get a "hidden" AttackType. Just like this:

call UnitDamageTargetBJ( unitAttacker, unitAttacked , 1.0, ConvertAttackType(7), DAMAGE_TYPE_UNIVERSAL )

This "hidden" AttackType has some interesting behaviour: If you want to deal 1 damage on a unit with it, it deals in reality:

• 1 Damage to units with armortype MEDIUM
• 1 Damage to units with armortype FORTIFIED
• 25 Damage to units with armortype UNARMORED
• 150 Damage to units with armortype HERO
• 400 Damage to units with armortype DIVINE
• 522 Damage to units with armortype HEAVY
• 522 Damage to units with armortype NORMAL
• 2048 Damage to units with armortype LIGHT

With this, its quite easy to identify a units armortype. But even more interesting is: Are there more hidden functionalities in the World Editor? A ConvertAttackType(8) doesn't do anything, so after checking all integers up to 10000, this is the only hidden AttackType. There is also a huge amount of DamageTypes (over 1000), but they don't differ in any kind, so they might be uninteressting. But you can convert many other things, like unitevents. So it would be interessting to know if there are more hidden and usefull functions in the WE.

Does anybody know something about this? I googled for several days now and didn't find anything about this...

Greetings,
lfh

 

[Starquizer]

I was looking for a system that can do the following:

Adds new types of damage which are: fire, cold, electric, acid poison and magic fire and magic cold plus piercing, slashing, crushing damages but I don't know how that could be done. But I wonder what attack type do if you changed to the in-game different types.

 

[rulerofiron99]

I was looking for a system that can do the following:

Adds new types of damage which are: fire, cold, electric, acid poison and magic fire and magic cold plus piercing, slashing, crushing damages but I don't know how that could be done. But I wonder what attack type do if you changed to the in-game different types.

Can be done easily with damage detection.

Before dealing damage, specify attack type based on unit/item/abilities of the damage source, and calculate how much should be done based on attack type/defense type.

Save attack/defense ratios using a hashtable or an array.

 

[Starquizer]

Can be done easily with damage detection.

Before dealing damage, specify attack type based on unit/item/abilities of the damage source, and calculate how much should be done based on attack type/defense type.

Save attack/defense ratios using a hashtable or an array.

That's exactly what I have in mind but I never used that system before. Is this system GUI or JASS ?

 

[Arhowk]

That's exactly what I have in mind but I never used that system before. Is this system GUI or JASS ?

damage detection? gui... just go in spell section and author search "Bribe". its fairly straight forward.

as for getting a units armor to scale the damage,

function GetUnitArmor takes unit u returns real
    local real hp = GetUnitState(u, UNIT_STATE_LIFE)
    local real damage
    call UnitDamageTarget( u, u, 10.0, true, false, ATTACK_TYPE_CHAOS, DAMAGE_TYPE_NORMAL, null)
    set damage = hp - GetUnitState(u, UNIT_STATE_LIFE)
    call SetUnitState(u, UNIT_STATE_LIFE, hp)
    if damage > 10.0 then
        set damage = 20.0 - damage
        return (damage-10.0)/(damage*0.06)
    endif
    return (10.0-damage)/(damage*0.06)
endfunction

(from Pharoah)

 

[looking_for_help]

Hm, I would better do it this way:

function Trig_DamageEvent_Actions takes nothing returns nothing
    set udg_damageDealt = GetEventDamage()
endfunction

function GetUnitArmor takes unit u returns real
    local real differenceHP
    local real damage

    call UnitDamageTarget( u, u, 0.00000000000001, true, false, ATTACK_TYPE_CHAOS, DAMAGE_TYPE_UNKNOWN, null)

    set damage = udg_damageDealt*100000000000000
    set differenceHP = damage*0.00000000000001

    call SetUnitLifeBJ( u, GetUnitState(u, UNIT_STATE_LIFE) + differenceHP )

    if damage == 0 then
        return -1000000
    elseif damage > 10.0 then
        set damage = 20.0 - damage
        return (damage-10.0)/(damage*0.06)
    else
        return (10.0-damage)/(damage*0.06)
    endif
    
endfunction

As the unit could die if you deal 10 damage. Also it might crash if the unit is invu (division by zero).


But this has quite nothing to do with the topic of this thread, so I would really like to discuss the hidden functionality of the WE in this thread.

Greetings,
lfh

 

[Starquizer]

Perhaps, they can be used as custom types or perhaps Blizzard simply left them empty without giving them any value, who knows.

 

[Arhowk]

Hm, I would better do it this way:

function Trig_DDS_DamageEvent_Actions takes nothing returns nothing
    set udg_damageDealt = GetEventDamage()
endfunction

function GetUnitArmor takes unit u returns real
    local real differenceHP
    local real damage

    call UnitDamageTarget( u, u, 0.00000000000001, true, false, ATTACK_TYPE_CHAOS, DAMAGE_TYPE_UNKNOWN, null)

    set damage = udg_damageDealt*100000000000000
    set differenceHP = damage*0.00000000000001

    call SetUnitLifeBJ( u, GetUnitState(u, UNIT_STATE_LIFE) + differenceHP )

    return damage
endfunction

As the unit could die if you deal 10 damage. Also it might crash if the unit is invu (division by zero).


But this has quite nothing to do with the topic of this thread, so I would really like to discuss the hidden functionality of the WE in this thread.

Greetings,
lfh

reals can only go to 1/32 so your gonna be returning like millions every time

 

[looking_for_help]

reals can only go to 1/32 so your gonna be returning like millions every time

I don't understand?

I made an ArmorType detection system with exactly this code and it works perfect. It also returns the correct value of the damage, so I don't see the problem?

Try:

function testReals takes nothing returns nothing
    local real test = 0.00000000000001

    if (0 == test) then
        call BJDebugMsg("test is not zero")
    else
        call BJDebugMsg("test is zero")
    endif

endfunction

It will notice the difference between the both values.

 

[Maker]

Before dealing damage, you increase the current and max hp by the damage amount, then reset them.

 

[looking_for_help]

Perhaps, they can be used as custom types or perhaps Blizzard simply left them empty without giving them any value, who knows.

Well, actually ConvertAttackType(7) is not empty, thats what makes this so interessting.

Maybe there are more invisible functions which one could use and we only have to find out its IDs?

 

[Starquizer]

Well, actually ConvertAttackType(7) is not empty, thats what makes this so interessting.

Maybe there are more invisible functions which one could use and we only have to find out its IDs?

Indeed, they didn't return null when I tested them but what could be there use if you have no way to detect the attack type, I for myself don't know of a function that can do that.

 

[looking_for_help]

Indeed, they didn't return null when I tested them but what could be there use if you have no way to detect the attack type, I for myself don't know of a function that can do that.

Huh?

With ConvertAttackType you can set an AttackType, so you allready know the AttackType. An application could be a very simple ArmorType Detection, as mentioned.

And maybe there is a hidden function for AttackType Detection, would be awesome.

 

[Starquizer]

Huh?

With ConvertAttackType you can set an AttackType, so you allready know the AttackType. An application could be a very simple ArmorType Detection, as mentioned.

And maybe there is a hidden function for AttackType Detection, would be awesome.

you set the attack type ok, no problem with that, but when a unit takes the attack it will be hard to detect, if it was easy then you could make a resistance system as well.

 

[looking_for_help]

Not really, as UnitDamageTarget deals triggered damage you can also easy store the AttackType. So if it takes the attack you can also apply some resistance stuff.

But detecting the AttackType of untriggered damage would be very interesting, I suppose this is what you meant.

 

[Magtheridon96]

I'm going to necrobump this thread with some possibly useful information that will seem obvious to a lot of you:

constant fogstate       FOG_OF_WAR_MASKED               = ConvertFogState(1)
constant fogstate       FOG_OF_WAR_FOGGED               = ConvertFogState(2)
constant fogstate       FOG_OF_WAR_VISIBLE              = ConvertFogState(4)

These are flags.

I'm pretty sure ConvertFogState(5) will give you FOG_OF_WAR_MASKED and FOG_OF_WAR_VISIBLE at the same time.

Care to try experimenting with this?

Try ConvertFogState(7)
It should give you a combination of all of these!

If they're not actually flags, try ConvertFogState(3) to see what happens.

I came to this realization ~8 months ago and I never got to test it, and I can't test it at the moment :V

 

[Xonok]

I'm going to necrobump this thread with some possibly useful information that will seem obvious to a lot of you:

constant fogstate       FOG_OF_WAR_MASKED               = ConvertFogState(1)
constant fogstate       FOG_OF_WAR_FOGGED               = ConvertFogState(2)
constant fogstate       FOG_OF_WAR_VISIBLE              = ConvertFogState(4)

These are flags.

I'm pretty sure ConvertFogState(5) will give you FOG_OF_WAR_MASKED and FOG_OF_WAR_VISIBLE at the same time.

Care to try experimenting with this?

Try ConvertFogState(7)
It should give you a combination of all of these!

So basically they use integers to create 32-bit boolean arrays?

 

[Magtheridon96]

Yeah, that's what flags are.

You use the bits in an integer to represent booleans.

 

[Almia]

I'm going to necrobump this thread with some possibly useful information that will seem obvious to a lot of you:

constant fogstate       FOG_OF_WAR_MASKED               = ConvertFogState(1)
constant fogstate       FOG_OF_WAR_FOGGED               = ConvertFogState(2)
constant fogstate       FOG_OF_WAR_VISIBLE              = ConvertFogState(4)

These are flags.

I'm pretty sure ConvertFogState(5) will give you FOG_OF_WAR_MASKED and FOG_OF_WAR_VISIBLE at the same time.

Care to try experimenting with this?

Try ConvertFogState(7)
It should give you a combination of all of these!

If they're not actually flags, try ConvertFogState(3) to see what happens.

I came to this realization ~8 months ago and I never got to test it, and I can't test it at the moment :V

Papa Meg discovered something, YAY!

Somewhat, It is just like the ids of the flags summed up. like NewFogState = ConvertFogState(GetHandleId(FOG_OF_WAR_MASKED) + GetHandleId(FOG_OF_WAR_VISIBLE))
Hence, a fogstate that shows both visibility and masked states

So, if my statement above is true,hence:
FogState[3] = FOG_OF_WAR_MASKED + FOG_OF_WAR_FOGGED
FogState[5] = FOG_OF_WAR_MASKED + FOG_OF_WAR_VISIBLE
FogState[6] = FOG_OF_WAR_FOGGED + FOG_OF_WAR_VISIBLE
FogState[7] = FOG_OF_WAR_MASKED + FOG_OF_WAR_FOGGED + FOG_OF_WAR_MASKED

You can also try the following perhaps : 0, 8, 9, 10, 11, 12+

 

[Magtheridon96]

Summing would work, but for the sake of symmetry, we use bitwise operations for all flag adding/removing/checking.

// add flag
flags = flags | flag; // bitwise OR the flag in

// remove flag
flags = flags & ~flag; // bitwise AND with NOT flag

// check if flag is set
bool b = flags & flag; // bitwise AND

// check if flag is not set
bool b = flags ^ flag; // bitwise XOR

You can also try the following perhaps : 0, 8, 9, 10, 11, 12+

0 and 8 might bring something new to the table.
If 8 fails, anything higher shouldn't really work. (If you're skeptical, try 16, 32 and the rest of the powers of 2)

Also, I didn't discover anything. Pipedream, Pitzermike, Daeod, Vexorian or some other wc3c.net relics probably tried this many years ago.
A lot of the things we're "discovering" today are usually already known somewhere

 

[Almia]

That BitWise ops..... Archange1 XD

So, those old men discovered those?

Btw, it is Deaod.

 

[Magtheridon96]

I don't know. This kind of thing should be common knowledge.
Not sure why nobody talks about it.

When a programmer looks at such numbers, the first thing that should come to his mind is flags :V

 

[LeP]

I don't know. This kind of thing should be common knowledge.
Not sure why nobody talks about it.

When a programmer looks at such numbers, the first thing that should come to his mind is flags :V

Because it isn't of any significance (is there?). Everyone who sees those numbers gets it.
Same things applies to ConvertMapFlag, ConvertGameType and some more.

What could be of interest are different damagetypes.
common.j jumps over some numbers.
http://jass.sf.net/doc/api/common_j-source.shtml#217

e: or not, op says he tested over 1000 damagetypes…

 

[Magtheridon96]

Because it isn't of any significance (is there?)

No idea at all if anything significant could be done with these
Fogstate might allow someone to pull off some crazy visual shit, but this is just a hypothesis and it will require some testing

What could be of interest are different damagetype s.
common.j jumps over some numbers.

Yeah, I noticed those. Never got a chance to see what they might be

 

[Xonok]

What could be especially interesting is the hundred or so missing events...

 

[Magtheridon96]

Good luck testing those

edit
Actually, there is one way to test those. Register the ~200 events to 1 trigger.
Whenever it fires, output the return value of GetTriggerEventId() and see if you can find anything interesting

 

[gorillabull]

interesting stuff, but you cant make an armor detection system of any kind with this because the damage amount for each armor type is not unique

 

[Spartipilo]

I was looking for a system that can do the following:

Adds new types of damage which are: fire, cold, electric, acid poison and magic fire and magic cold plus piercing, slashing, crushing damages but I don't know how that could be done. But I wonder what attack type do if you changed to the in-game different types.

http://www.hiveworkshop.com/forums/triggers-scripts-269/custom-damage-resist-system-222959/

 

[Imp Midna]

To Come back to the op (though i'm aware of it being quite old and that he wont read this):
I took a quick look into the UnitDamageTarget native:
- every AttackType > 7 is discarded. No hidden attack types there.
- every WeaponType > 0x18 (#24) is discarded. i think common.j's WeaponTypes go till 23, but i dont remember that weaponTypes do anything at all anyways
- I dont get what they do to the DamageType, its doesnt seem to have such a clear border

 

[Dr Super Good]

The damage type seems to have an "off by one" error in it. Thus the hidden entry is all garbage as it is probably reading values from memory directly after where the damage tables are stored.

Have you tried negative values? It might go backwards and start to read memory before the start of the table.

 

[looking_for_help]

interesting stuff, but you cant make an armor detection system of any kind with this because the damage amount for each armor type is not unique

Yes, unfortunatly they are not unique... which is really annoying
At least we can use the attacktype to deal armor table independent damage.

To Come back to the op (though i'm aware of it being quite old and that he wont read this):

Hi, I'm still active and reading all this stuff here

The damage type seems to have an "off by one" error in it. Thus the hidden entry is all garbage as it is probably reading values from memory directly after where the damage tables are stored.

Hm I doubt this somehow, as you can use the damagetypes with bigger values without any problems. If they would be just random garbage memory they shouldn't work I think.

I also remember when I tested this that there is some periodicity in the damagetypes: After some values they started again with the first damagetype, so it might just look like there would be thausands of different damagetypes, while in reality some safty mechanism might reduce the user parameter to a valid value.

Good luck testing those

edit
Actually, there is one way to test those. Register the ~200 events to 1 trigger.
Whenever it fires, output the return value of GetTriggerEventId() and see if you can find anything interesting

Yes, new events would be really awesome^^
But until now I found nothing.

 

[Eleandor]

Yes, unfortunatly they are not unique... which is really annoying

Can't you make them unique via gameplay constants?

Regarding the attack types: attack type 7 is reading memory that it isn't supposed to read.
In fact, I just confirmed that:
- the value in UNARMORED is the minimum movement speed for buildings
- the value in HERO and DIVINE is the minimum movement speed for units (maybe it's here twice because there's a different movement speed for units & heroes)
- the value in HEAVY and NORMAL seems to be the hardcoded maximum movement speed (522)
- the value in LIGHT, if I'd take a guess, is the hardcoded maximum sight range?

I also remember when I tested this that there is some periodicity in the damagetypes

I don't know how you tested this, but I just looped through 1 million damage types, and none of them return the same damagetype value

 

[Xonok]

Can't you make them unique via gameplay constants?

Regarding the attack types: attack type 7 is reading memory that it isn't supposed to read.
In fact, I just confirmed that:
- the value in UNARMORED is the minimum movement speed for buildings
- the value in HERO and DIVINE is the minimum movement speed for units (maybe it's here twice because there's a different movement speed for units & heroes)
- the value in HEAVY and NORMAL seems to be the hardcoded maximum movement speed (522)
- the value in LIGHT, if I'd take a guess, is the hardcoded maximum sight range?


I don't know how you tested this, but I just looped through 1 million damage types, and none of them return the same damagetype value

150 is the default minimum for units, 400 is default maximum(speed).

 

[looking_for_help]

Can't you make them unique via gameplay constants?

1.) No of course not. There is no field in the gameplay constants for this attacktype, thats why its "hidden".

2.) Even if one could it would be completly senseless because you could do that with every other attacktype too.

Regarding the attack types: attack type 7 is reading memory that it isn't supposed to read.
In fact, I just confirmed that:
- the value in UNARMORED is the minimum movement speed for buildings
- the value in HERO and DIVINE is the minimum movement speed for units (maybe it's here twice because there's a different movement speed for units & heroes)
- the value in HEAVY and NORMAL seems to be the hardcoded maximum movement speed (522)
- the value in LIGHT, if I'd take a guess, is the hardcoded maximum sight range?

Hm, interesting.

I don't know how you tested this, but I just looped through 1 million damage types, and none of them return the same damagetype value

Some damagetypes are affected by the armor value (depending on the attacktype too). When you loop through all damagetypes and use them to deal damage you will notice that the offset between those armor value affected damagetypes is constantly repeated. The handle id is of course unique.

 

[Eleandor]

150 is the default minimum for units, 400 is default maximum(speed).

Yes, I made a mistake by setting max movement speed below min movement speed, which is why I got the same value for HERO and DIVINE.

UNARMORED = Minimum Building Movement Speed
HERO = Minimum Unit Movement Speed
DIVINE = Maximum Unit Movement Speed
HEAVY / NORMAL = Absolute maximum unit/building movement speed (522)
LIGHT = unknown, possibly maximum sight range.

1.) No of course not. There is no field in the gameplay constants for this attacktype, thats why its "hidden".

I was talking about the non-hidden attack types. If you change those gameplay constants, you can detect the defense type of a unit by calling UnitDamageTarget() and seeing how much damage you actually did.

Also, small nitpick, but it's not really a handle id, it's just the number you passed. ConvertAttackType(3) == ConvertDamageType(3)

 

[looking_for_help]

Yes, I made a mistake by setting max movement speed below min movement speed, which is why I got the same value for HERO and DIVINE.

UNARMORED = Minimum Building Movement Speed
HERO = Minimum Unit Movement Speed
DIVINE = Maximum Unit Movement Speed
HEAVY / NORMAL = Absolute maximum unit/building movement speed (522)
LIGHT = unknown, possibly maximum sight range.

I could just verify this. If you change the corresponding values in the gamplay constants, the dealt damage from the hidden attacktype is also changed.

The hidden attacktype deals for example 400 damage on divine armor (which is the default value for maximum unit movement speed as you said). If I change this value to 200, the attacktype deals 200 damage. So it is really reading from those memory fields.

Good job spotting this!

I was talking about the non-hidden attack types. If you change those gameplay constants, you can detect the defense type of a unit by calling UnitDamageTarget() and seeing how much damage you actually did.

Yes, but then it would not be armor table independent. But this doesn't work anyway with the new discoveries.

Also, small nitpick, but it's not really a handle id, it's just the number you passed. ConvertAttackType(3) == ConvertDamageType(3)

How should an attacktype be equal to a damagetype?

 

[Eleandor]

I could just verify this. If you change the corresponding values in the gamplay constants, the dealt damage from the hidden attacktype is also changed.

That's basically how I verified it.

How should an attacktype be equal to a damagetype?

It IS equal. ConvertAttackType(0) is also equal to "null". I assume Convert<anything> just returns the int parameter.

 

[Xonok]

So, basically we now have a way to retrieve game constants ingame
The next step would probably be expanding this idea and finding more such exploits(since we've found some now)

 

[Magtheridon96]

You know, a mouse can be represented by a singleton class or any static set of data. If Blizzard software engineers actually used a static singleton to represent the mouse internally (they could be avoiding this completely by just using the data Win32 API provides o.o), we might be able to use these ConvertXXX functions to navigate to the memory addresses of these coordinates

ConvertPlayerColor(16+) take you into the textures in the MPQ. It's undefined behavior really, but one of the possible scenarios is getting MPQ textures as my testing in the past showed

 

[Eleandor]

Don't get your hopes up. ConvertAttackType only works on values from 0 to 7. Anything else just seems to return 0 floats. The usefulness of retrieving game constants is also dubious.

 

[Xonok]

Don't get your hopes up. ConvertAttackType only works on values from 0 to 7. Anything else just seems to return 0 floats.

Might be that it references something that isn't usually used. Not constants then, though.

Has anyone tried negative attack types?

 

[Dr Super Good]

Hm I doubt this somehow, as you can use the damagetypes with bigger values without any problems. If they would be just random garbage memory they shouldn't work I think.

That is what bound checking is for. It also is why I say it is an "off by one" error as instead of using <7 for maximum bound check they used <=7 which is, well, off by one.

 

[Eleandor]

Might be that it references something that isn't usually used. Not constants then, though.

Has anyone tried negative attack types?

I tried negative attack types, I also tried positive attack types up to 10000. With each attack type having at least 8 floats, that's 80Kb of memory that would all be zero? No, like DSG said, it's just a bounds checking mistake.

 

[Dr Super Good]

It could also be a bounds checking error caused by the removal of an attack type. During early development of WC3 there may have been an extra attack type. This attack type was removed before release and the data entry for it eradicated. Thus the native still thinks that the game has this attack type (why the value is valid) but in reality it is pointing to garbage (as mentioned above, they are other constants that are stored directly after the damage type tables in memory).

 

[D.O.G.]

You know, a mouse can be represented by a singleton class or any static set of data. If Blizzard software engineers actually used a static singleton to represent the mouse internally (they could be avoiding this completely by just using the data Win32 API provides o.o), we might be able to use these ConvertXXX functions to navigate to the memory addresses of these coordinates

ConvertPlayerColor(16+) take you into the textures in the MPQ. It's undefined behavior really, but one of the possible scenarios is getting MPQ textures as my testing in the past showed

I had similar idea in the past - change texture by changing player color to 16+ and importing that textures with appropriate name. But this did't worked, game crashed when I was setting 16+ color to unit(

Interesting, what result you had?

 

[Magtheridon96]

It leads to undefined behavior. Sometimes, I get some icons popping up on a wisp, other times I got special effects. Most of the time however, Wc3 crashed, which is why this is labeled as undefined behavior ;p

 

[D.O.G.]

It leads to undefined behavior. Sometimes, I get some icons popping up on a wisp, other times I got special effects. Most of the time however, Wc3 crashed, which is why this is labeled as undefined behavior ;p

Have any example code/settings which gave that special effects?

 

[Magtheridon96]

struct Test extends array

    private static method onInit takes nothing returns nothing
        // Choose any number you want here.
        // If you continue to retry this code, at one point, you'll get nice textures <:
        local playercolor undefinedBehaviorFactory = ConvertPlayerColor(22)
        local unit u = CreateUnit(Player(0), 'hpea', 0, 0, 0)

        call SetUnitColor(u, undefinedBehaviorFactory)

        set u = null
    endmethod
endstruct

Run that a few times. When it doesn't crash, it'll give you weird effects or no effects at all.

 

[D.O.G.]

struct Test extends array

    private static method onInit takes nothing returns nothing
        // Choose any number you want here.
        // If you continue to retry this code, at one point, you'll get nice textures <:
        local playercolor undefinedBehaviorFactory = ConvertPlayerColor(22)
        local unit u = CreateUnit(Player(0), 'hpea', 0, 0, 0)

        call SetUnitColor(u, undefinedBehaviorFactory)

        set u = null
    endmethod
endstruct

Run that a few times. When it doesn't crash, it'll give you weird effects or no effects at all.

Haha, this is pretty much the same as I did, only the difference was that I have tried only 17th color - game crashed and I thought that the same will be for other values))

This is a lesson for me now - never give up!)

Thanks for pointing out that there is some effects for greater values)

 

[Magtheridon96]

This is why it's called undefined behavior - It's undefined!