New features (last update 8.8.2005)

Moderator: GZDoom Developers

User avatar
DoomRater
Posts: 8265
Joined: Wed Jul 28, 2004 8:21 am
Location: WATR HQ

Post by DoomRater »

TheDarkArchon wrote:It doesn't use ammo since the UseAmmo argument (Which is the argument after PuffType) is blank and hence is assumed zero, which means the weapon uses no ammo.

[NOT A BUG]
Then why did it work before? I thought 1 meant usenoammo. In fact that's what happened before this patch was made. In fact the REST of my weapons left out the 1 and they still use ammo.

That should say that something changed in the code.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48377
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Post by Graf Zahl »

1 means useammo and was the default. The thing is that Grubber screwed up when implementing the variable feature. He accidentally inverted the default for this parameter.

But before we can deal with this we have to decide what we are about to do with the expression evaluator. Randy has already said that he'd like to do it differently so my suggestion would be to revert to the last version before this was added and then only add the rest of the stuff to it.

Due to Randy's recent comments I can not recommend to use the latest unofficial versions that contain the expression evaluator. If you still got an old version use that. Sorry.
User avatar
DoomRater
Posts: 8265
Joined: Wed Jul 28, 2004 8:21 am
Location: WATR HQ

Post by DoomRater »

(tiwtch) I hope Grubber can upload a new version soon, seeing as I don't have an old version and I don't think anyone else does either....
Costja
Posts: 188
Joined: Mon Oct 18, 2004 3:58 pm
Location: Russia, Moscow

Post by Costja »

I have last 5-7 versions, link to what version do you need?
User avatar
DoomRater
Posts: 8265
Joined: Wed Jul 28, 2004 8:21 am
Location: WATR HQ

Post by DoomRater »

July 25 I think.
User avatar
Killo Zapit
Posts: 292
Joined: Wed Jul 16, 2003 9:26 pm
Location: Most likely sleeping.

Post by Killo Zapit »

Grubber wrote:He was asking about SPECIAL flag, which can be changed via A_ChangeFlag, NOBLOCKMAP can't.
Really? When I try it it gives an unknown flag error. I assumed the SPECIAL flag wasn't on any of decorate's parser lists so it couldn't be set/unset.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48377
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Post by Graf Zahl »

It isn't. Setting SPECIAL in DECORATE is useless so it can't be set by A_ChangeFlag which just uses the DECORATE flag table.
User avatar
Grubber
Posts: 1031
Joined: Wed Oct 15, 2003 12:19 am
Location: Czech Republic

Post by Grubber »

Graf Zahl wrote:1 means useammo and was the default. The thing is that Grubber screwed up when implementing the variable feature. He accidentally inverted the default for this parameter.
Yeah, lack of documentation + confusing variable names = these errors :x (and don't forget about a little bit of my strange behavior ;)). Sorry, but I can't remember all actions & their argument lists...
Graf Zahl wrote:But before we can deal with this we have to decide what we are about to do with the expression evaluator. Randy has already said that he'd like to do it differently so my suggestion would be to revert to the last version before this was added and then only add the rest of the stuff to it.
This is not a problem really, implement-wise it will be totally different, but for user it will be still "1 + 1". Main problem are user variables - fixed count, only integers.
Graf Zahl wrote:It isn't. Setting SPECIAL in DECORATE is useless so it can't be set by A_ChangeFlag which just uses the DECORATE flag table.
Dunno, I haven't checked it. Sorry everyone...
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48377
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Post by Graf Zahl »

Grubber wrote:
Graf Zahl wrote:1 means useammo and was the default. The thing is that Grubber screwed up when implementing the variable feature. He accidentally inverted the default for this parameter.
Yeah, lack of documentation + confusing variable names = these errors :x (and don't forget about a little bit of my strange behavior ;)). Sorry, but I can't remember all actions & their argument lists...
'!' in the old parameter lists meant 'boolean, default==1'. Just do a comparison with an old version and you will find them. ;)
User avatar
Grubber
Posts: 1031
Joined: Wed Oct 15, 2003 12:19 am
Location: Czech Republic

Post by Grubber »

I did, dunno why the errors are there... (me = messy one)
User avatar
DoomRater
Posts: 8265
Joined: Wed Jul 28, 2004 8:21 am
Location: WATR HQ

Post by DoomRater »

average programming ability > no programming ability, even though experienced programming ability > average programming ability...
User avatar
Grubber
Posts: 1031
Joined: Wed Oct 15, 2003 12:19 am
Location: Czech Republic

Post by Grubber »

Are you insulting me? I was 21st in programming competition in whole Czech Republic, might be higher, but missed final part :(. Obviously I have a little bit more than average programming ability. But, enough about me :x.
Last edited by Grubber on Mon Aug 01, 2005 9:16 am, edited 1 time in total.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48377
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Post by Graf Zahl »

The errors are there because with a parameter type 'x' they default to 0, not 1. I think it is best to leave them as constants as it was previously. Just look what the parser does when it encounters a '!' parameter.
User avatar
Grubber
Posts: 1031
Joined: Wed Oct 15, 2003 12:19 am
Location: Czech Republic

Post by Grubber »

I'm negating them when evaluating = same effect (I suppose - when evaluating default - always 0 - it turns to 1).
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48377
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Post by Graf Zahl »

No, it's not the same. For '!' the default is like passing 1 to the function call in DECORATE, not 0. What you do gives the correct values when the parameter is there but not when it isn't. I made these a separate type for a reason.

Return to “Closed Feature Suggestions [GZDoom]”