Bug in switch()?
Displaying 1-12 of 12 total.
1
Eldritch05
|
I don't know if this has been brought up before, but I looked around and didn't see it, so I'll mention it myself. switch() commands appear to crash and burn if any of their cases includes a return or Map() statment. The "switch breaking on return" I'm used to, since it was an issue in V2 as well, but this Map() thing is a little annoying.
More specifically, when a switch() statment encounters a return or Map(), V3 exits and returns the error "VCCore::HandleSwitch() - internal error, bad switch opcode (x)" where "x" is the opcode of the next command the program encounters for which it then lists the file name, function, and line number. If the return/Map() is the last command encountered in the switch() statement, the file/line can be in different functions or even different files altogether.
Can these issues be worked around? Yes, I just have to convert all my switch()'s to else if()'s. I just thought I should point out a recurring bug that I've noticed and that Map() doesn't end execution quite as adeptly as it claims to.
Posted on 2004-09-02 18:42:16
|
Zip
|
Indeed.
Either if() else if() or put the value in a variable and return it at the end.
Zip
Posted on 2004-09-02 19:59:49
|
Overkill
|
And if you have map switch you want to do, just have a local string to pass a map filename:
void BigSwitch(int switchvar)
{
string newmap;
switch(switchvar)
{
case 3: newmap="island.map";
}
//Make sure this is at the function's end, so to execute last.
if(len(newmap)) Map(newmap);
}
Posted on 2004-09-02 20:55:27 (last edited on 2004-09-02 20:55:59)
|
Eldritch05
|
So that's where known issues are kept. Good to know. Thank you.
While passing ints and strings back works perfectly and is what I normally do, the problem lies in the way my code is structured, so I'm going to have to convert everything to else if()'s. (Or wait for a fix.) What's happening is an item is trying to warp the party back to its bind point. So the actual Map() is in the MapSwitch() function which is called inside the switch() to run the item's effect which is inside the switch() to use an item of its specific type which is inside the switch() to use an item from the menu which is inside the switch() to open the item menu from the main menu. Rather than try and pass a value back through four switches and three functions, I'll just convert my switches. Or work on something else until it either becomes an issue or gets fixed.
Posted on 2004-09-02 22:06:52
|
Zip
|
I'd convert. This bug's been here a while. And though I dare not take vec's name in vain, there MIGHT not be a fix for a while.
Zip
Posted on 2004-09-02 22:13:57
|
Omni
|
It's a minor problem to convert it though. Switch() is for gurlie-men (Zip please don't hurt me).
Since the Switch statements can't handle returns, and the Map() function does a super-return out of all functions, it makes good sense that Map also crashes Switch.
Posted on 2004-09-03 00:02:05
|
Overkill
|
Why not, instead of switches, make item functions, and then go callfunction("") to them?
int use_onwho;
void UseItem(int index, int who)
{
use_onwho=who;
callfunction(item[index].usefunc);
}
// Callfunction("UsePotion");
void UsePotion()
{
int who=GetInt(use_onwho); //Fake giving arguments
Heal(who,300); //Heals 300 hp.
}
// Callfunction("UseTeleporter");
void UseTeleporter()
{
int who=GetInt(use_onwho); //Fake giving arguments
MapSwitch("magicalhappyplace.map"); //Teleport!
}
Posted on 2004-09-03 02:15:26 (last edited on 2004-09-03 02:23:15)
|
Eldritch05
|
I already do something like that; each ability has an effect variable that my switch() statement reads, and then proceeds to call generalized functions like RestoreHP() or IncreaseDefense() so multiple effect references can have the same effect without having to write it over and over. And something in my idea of code style sees writing functions for every ability as needlessly complex. Especially since there are like 400 unique abilities.
Besides which, it'd still require reconstruction into else if()'s. Since V3 is very smart, it remembers that the calling function was in the middle of a switch() statement when some function down the line tries to do a Map(). So I can get away with calling a Map() outside the switch() in my AbilityEffect() function so long as ItemMenu() and Menu() are both recoded with else if()'s.
But really, now that you all have me thinking about this, it makes more sense from a game design outlook to have the menu close itself if you're teleporting around rather than having it open itself as soon as you land. So while it strikes me as somewhat clunky to have a Map() in the hooked Menu() function, I suppose most work-arounds have that feel to them.
Posted on 2004-09-03 03:50:46
|
blues_zodiakos
|
It's a minor problem to convert it though. Switch() is for gurlie-men (Zip please don't hurt me).
Let's terminate tarkussism!
Posted on 2004-09-03 13:21:59
|
vecna
|
The switch bug is a priority.
It wasn't really, before.
Still, no promises. :D
Posted on 2004-09-03 17:57:58
|
loretian
|
Don't listen to vecna, he really doesn't know anything about verge.
Posted on 2004-09-03 19:08:40
|
Eldritch05
|
Quote:Originally posted by vecna
The switch bug is a priority.
It wasn't really, before.
Still, no promises. :D
That's cool. It's really not even going to be an issue for a month or so yet, and even then it can be worked around. For now, I just have to take the offending item out of the shop. And maybe add a guy complaining about how his friends were annihilated by faulty warp stones.
Posted on 2004-09-03 20:19:01
|
