Time for Blizzard to release another patch, I say.

Troll-Brain

You can change this now in User CP.
Reaction score
85
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.
 

Troll-Brain

You can change this now in User CP.
Reaction score
85
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.
 

Azlier

Old World Ghost
Reaction score
461
Does it just validate the value? Can you fire from an array? I need some solid answers here.
 

Jesus4Lyf

Good Idea™
Reaction score
397
>I need some solid answers here.
Of course, Blizzard doesn't need to fix this. They already protected code variables.
Read. :p

>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

Level 1 Crypt Lord
Reaction score
48
Do you guys think a native code array would be useful? I'm thinking it is.
 

Azlier

Old World Ghost
Reaction score
461
>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!
 

chobibo

Level 1 Crypt Lord
Reaction score
48
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

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

Lyerae

I keep popping up on this site from time to time.
Reaction score
105
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

Good Idea™
Reaction score
397
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

You can change this now in User CP.
Reaction score
144
5 minutes ago, I thought I'd try something new.

Azlier. <3
Typecasting from nothing still works. Our research was not in vain.
JASS:
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

I keep popping up on this site from time to time.
Reaction score
105
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

New Member
Reaction score
12
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

Visitor (Welcome to the Jungle, Baby!)
Reaction score
216
Code:
--------------------------------------------------------------------------
  WARCRAFT III: THE FROZEN THRONE VERSION HISTORY
--------------------------------------------------------------------------

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

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

Nice. :p
I hope Blizzard will add multi-core processor support for Wc3.
 
General chit-chat
Help Users
  • No one is chatting at the moment.

      The Helper Discord

      Staff online

      Members online

      Affiliates

      Hive Workshop NUON Dome World Editor Tutorials

      Network Sponsors

      Apex Steel Pipe - Buys and sells Steel Pipe.
      Top