New features (last update 8.8.2005)

DoomRater · Post by **DoomRater** » Sun Jul 31, 2005 1:24 pm

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.

Post by **Graf Zahl** » Sun Jul 31, 2005 1:38 pm

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.

DoomRater · Post by **DoomRater** » Sun Jul 31, 2005 3:03 pm

(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 · Post by **Costja** » Sun Jul 31, 2005 3:33 pm

I have last 5-7 versions, link to what version do you need?

DoomRater · Post by **DoomRater** » Sun Jul 31, 2005 5:30 pm

July 25 I think.

Killo Zapit · Post by **Killo Zapit** » Sun Jul 31, 2005 8:08 pm

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.

Post by **Graf Zahl** » Mon Aug 01, 2005 1:28 am

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.

Grubber · Post by **Grubber** » Mon Aug 01, 2005 7:50 am

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

(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...

Post by **Graf Zahl** » Mon Aug 01, 2005 8:06 am

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 (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.

Grubber · Post by **Grubber** » Mon Aug 01, 2005 8:38 am

I did, dunno why the errors are there... (me = messy one)

DoomRater · Post by **DoomRater** » Mon Aug 01, 2005 9:05 am

average programming ability > no programming ability, even though experienced programming ability > average programming ability...

Grubber · Post by **Grubber** » Mon Aug 01, 2005 9:12 am

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

.

Post by **Graf Zahl** » Mon Aug 01, 2005 9:12 am

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.

Grubber · Post by **Grubber** » Mon Aug 01, 2005 9:17 am

I'm negating them when evaluating = same effect (I suppose - when evaluating default - always 0 - it turns to 1).

Post by **Graf Zahl** » Mon Aug 01, 2005 9:51 am

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.

New features (last update 8.8.2005)

Login • Register