Time for Blizzard to release another patch, I say.

[Troll-Brain]

hehe contacted blizzard about it and about something else I found in another place.

This means I'll have a new chance to demmand them to fix the silly boolexpr bug...

The leak when you use a null boolexpr in a GroupEnum... is rather silly also.

 

[Narks]

The leak when you use a null boolexpr in a GroupEnum... is rather silly also.

what leak is this?

 

[Lyerae]

what leak is this?

The leak when you use a null boolexpr in a GroupEnum...

?

 

[Jesus4Lyf]

Lol, and the other leak.

>So, you CAN attach a viruses with this, which was supposed to be fixed in the latest patch?
I don't see how. I don't see any way to do it in any patch since 1.23b...

 

[Troll-Brain]

Lol, and the other leak.

Yes, but this one is quite irrelevant, and i don't know if blizzard can fix it without adding a garbage collector (which would be awesome, but we all know it won't never happen, in this spacetime at least, dunno for the others)

I don't see how. I don't see any way to do it in any patch since 1.23b...

So we can't typecast integer <-> code anymore ?
If not, Blizzard didn't totally fail finally.

 

[Jesus4Lyf]

So we can't typecast integer <-> code anymore ?

You can't manipulate the integer and then typecast it back.

 

[Azlier]

Does it just validate the value? Can you fire from an array? I need some solid answers here.

 

[Jesus4Lyf]

>I need some solid answers here.

Of course, Blizzard doesn't need to fix this. They already protected code variables.

Read.

>Does it just validate the value?

You can't manipulate the integer and then typecast it back.

The integer always displays as 0 (this wasn't the case in 1.23 - it was an unprotected memory location).

>Can you fire from an array?
No, because you can't manipulate the integer (or take an integer) and then typecast it to code.

 

[chobibo]

Do you guys think a native code array would be useful? I'm thinking it is.

 

[Azlier]

>Read.
I see. I was in confusion this whole time, especially after I saw (apparently I read it wrong) that you managed to fire from arrays in chat.

>Do you guys think a native code array would be useful?
I don't think so. Trigger arrays are really all you need. After all, how are you going to fire the code? With a trigger? Inconceivable!

 

[Jesus4Lyf]

I don't think code arrays are useful at all.
At very least, store Filter(function MyFunction).

 

[chobibo]

I see, I thought it would be, since a lot of people are trying to use the I2C bug, I thought that adding a code array would make life easier for them lol, looks like I was wrong.

 

[Azlier]

No, we want I2C so we can put viruses in maps. It hasn't been done since before patch 1.23b though.

 

[chobibo]

Okay, now I truly understand.

 

[Lyerae]

No, we want I2C so we can put viruses in maps. It hasn't been done since before patch 1.23b though.

Well, if you could store code in an array, or whatever, using I2C, couldn't you store functions?
It was awhile ago, and my memory isn't the best, but didn't Jesus4Lyf make something that would allow you to add new things (locals, calls, w/e) to a function, while the map was being played?
Like I said, my memory isn't the best, so I may be wrong... But that would be a "blessing"?. I'm sure there are a lot of possibilities to having something like that.

 

[Jesus4Lyf]

Well, if you could store code in an array, or whatever, using I2C, couldn't you store functions?
It was awhile ago, and my memory isn't the best, but didn't Jesus4Lyf make something that would allow you to add new things (locals, calls, w/e) to a function, while the map was being played?
Like I said, my memory isn't the best, so I may be wrong... But that would be a "blessing"?. I'm sure there are a lot of possibilities to having something like that.

Time to clarify terminology.

1. In 1.23 and earlier, C2I and I2C could be used to store code variables in an array (recall CodeVar). This is pretty useless. We can store boolexprs in an array instead anyway.
2. In 1.23 and earlier, we could store bytecode in an integer array. The memory location of this array could be typecast into a code variable using I2C to execute code out of an array, which allowed the dynamic JASS hardcoding thing I demonstrated. We could also typecast a function back to itself without bounds checking on arrays, using [LJASS]I2C(C2I(function MyFunction)+1)[/LJASS]. This allows writing to various memory locations, including native modification to run machine code.

All of these are no longer possible, even with C2I and I2C for the reasons already mentioned.

The only thing that is possible is typecasting [LJASS]I2C(C2I(function MyFunction))[/LJASS] which is useless (as in, doing so without modifying the integer result in between at all).

So Blizzard allowing the first option would be useless, and Blizzard allowing the second option would be fatal.

If you look at my demo map of old from 1.23, you shall see that I store hex codes (not code variables) in an integer array.

 

[Tru_Power22]

5 minutes ago, I thought I'd try something new.

Azlier. <3
Typecasting from nothing still works. Our research was not in vain.

function ReturnI takes integer i returns integer
    return i
endfunction
function ReturnB takes boolean b returns boolean
    return b
endfunction
function I2B takes integer i returns boolean
    call ReturnI(i)
    if i==0 then
        return false
    endif
endfunction
function B2I takes boolean b returns integer
    call ReturnB(b)
    if b==false then
        return 0
    endif
endfunction
function Trig_Untitled_Trigger_001_Actions takes nothing returns nothing
    call BJDebugMsg(I2S(B2I(I2B(50))))
endfunction

At the end of 1.23, we found that typecasting from nothing returns the last item returned. We joked about optimising TimerUtils with it (by typecasting from TimerStart(CreateTimer... returning the timer in H2I).

So um. There's a nice typecast integer to boolean. I thought this may work and it does.

When all else fails believe in Jesus. I could go back to fixing age of myths, but it seem like a lot more work now.

 

[Lyerae]

Time to clarify terminology.

1. In 1.23 and earlier, C2I and I2C could be used to store code variables in an array (recall CodeVar). This is pretty useless. We can store boolexprs in an array instead anyway.
2. In 1.23 and earlier, we could store bytecode in an integer array. The memory location of this array could be typecast into a code variable using I2C to execute code out of an array, which allowed the dynamic JASS hardcoding thing I demonstrated. We could also typecast a function back to itself without bounds checking on arrays, using [LJASS]I2C(C2I(function MyFunction)+1)[/LJASS]. This allows writing to various memory locations, including native modification to run machine code.

All of these are no longer possible, even with C2I and I2C for the reasons already mentioned.

The only thing that is possible is typecasting [LJASS]I2C(C2I(function MyFunction))[/LJASS] which is useless (as in, doing so without modifying the integer result in between at all).

So Blizzard allowing the first option would be useless, and Blizzard allowing the second option would be fatal.

If you look at my demo map of old from 1.23, you shall see that I store hex codes (not code variables) in an integer array.

Okay, that kinda makes sense now... Thanks.
I've still got a lot to learn about JASS...

 

[R 3 T R O]

Warcraft III v1.24c Patch Notes

Latest Patch LOG 1.24c

- Custom maps have now been disabled.
- Removed the World Editor (PAWNED BY BLIZZARD)

PC WORLD EDITOR CHANGES

- Increased max map file size from 4 MB to 8 MB.
- Added the ability to store hashtable handles in a hashtable.
- Added GetSpellTargetX and GetSpellTargetY natives.
- Added a new base handle type "Agent" of which many types now extend from.
- Added a SaveAgentHandle native which can be used for saving most handle types.
- Added a JASS optimization dealing with global variable change events.

FIXES (1.24)

- Fixed a few false positives caused by the "return bug" fix.
- Fixed a crash related to hashtable reference counting.
- "Shadowing" global variables with local variables no longer is possible.
- Fixed a type conversion dealing with operators (i.e. adding a handle with an integer).

lol

 

[kingkingyyk3]

--------------------------------------------------------------------------
  WARCRAFT III: THE FROZEN THRONE VERSION HISTORY
--------------------------------------------------------------------------

--------------------------------------------------------------------------
Patch 1.25
--------------------------------------------------------------------------
FEATURES

- Removed Jass.
- Add new language, *unknown*

Nice.
I hope Blizzard will add multi-core processor support for Wc3.