Because this code:
if @flag == 0x10
$game_character.opacity = 90
else
end
is part of the class itself and not a defined method, it gets executed immediately at compile time. Compile time starts when you hit the 'Test Play' button or run the game executable before anything is actually executed and the game starts.
At this point, the instance variables '@flag' and '@priority' are both nil. They have no value in them. So when the compiler reads the line:
if @priority == 3
It is really saying
if nil == 3
Which is false, because nil does not equate to 3. So the code within the if statement is never executed, and the program continues on.
Having code run at compile time can be a very important thing to make use of, but in this case it basically does nothing at all.
This code might be good* as part of the 'initialize' method after everything else has been initialized. This would be achieved by aliasing initialize:
*The point here is to demonstrate aliasing, rather than what you actually want to do. Going from what you are trying to achieve, this isn't actually a good place at all.
class Game_Event < Game_Character
alias :alias_initialize_method :initialize
def initialize
#call the original initialize method by its alias
alias_initialize_method
#do my extra things here
if @priority == 3
$game_character.opacity = 90
end
end
end
Now, there's also a couple of other things that should be noted.
Firstly, $game_character doesn't actually exist in the first place, so you will get a NoMethodError as soon as the code hits "$game_character.opacity". If you want this opacity change to occur on the event itself, you can just use "@opacity = 90" instead. If you want, for whatever reason, the player character to have it's opacity changed you want to use "$game_player". You really don't want to do that, though; every time an event is created (which normally happens at the time of reading the map data and setting the current map up), the opacity of the player will be set to whatever event triggers that bit of code last. It would be unpredictable and, therefore, a difficult thing to manage.
Having the opacity of the player change when you go 'under' the event is easily achieve without a script in the first place. There's options in the 'Set Move Route...' command where you can change opacity of the player. Just set the event to trigger on "Player Touch".
Secondly, you don't need a floating 'else' if there's nothing 'else' to do. When the if fails, the code in else is executed. But when there's no code in else, it does nothing. So it might as well not actually be there.
If you really did want to use a script, as means of learning how to script, I'd actually say don't bother anyway with regards to this idea. There's far more simpler and easier things to learn scripting with than by basically repeating what the system can already do for you.
The way that I started (and I'm certain many other scripters did this too) is to take a script that already exists, copy it to a slot in materials and make changes to the script paying close attention to what you did and how it affected the game. An example can be changing the Window_Item class to have a different layout to the default, or changing Window_Menu to a new layout. By familiarising yourself with existing code, you can start to understand how it comes together to give the effect it does when you run the game. Then you can try to do some new and interesting things.
I don't want to sound like an ass, but I believe the right direction is what I've given you. You know why your code isn't working the way you was hoping it did, but I really can't justify to myself why it would be worth taking the time to demonstrate using a script to do what essentially can be done in less than 30 seconds already. It'll take a good 30 minutes for me to get started; it really just isn't worth the hassle.
I hope that's understandable, and I hope you still got something useful out of this post. I apologise for not being that little more helpful.