A long while back helixhorned added in the .movflag member for actors - I could also use this to make new custom moves for actors but this doesn't work in newer snapshots. Is this an intentional act, or a side-effect of something else? If it's the latter, I'll try and track down the snapshot where it starts to occur but it was an intentional move, I'll have to change my code accordingly.
Page 1 of 1
.movflag issues "intentional or accidental?"
#1 Posted 28 January 2019 - 02:57 AM
#2 Posted 28 January 2019 - 09:22 AM
Does htmovflag still get set correctly if a sprite is bumping into something? It sounds like just the custom move thing is broken, but I want to make sure.
#3 Posted 12 March 2019 - 04:32 AM
I'm bumping this since I'm trying to figure when the break happens - I isolated it down to snapshot 7238 - 7187 works as intended. In 7187 if I set .movflag it'll remain to what I set it, but in 7238 and up if I set it to anything new it'll reset to -1 causing the enemy to just wander in a straight line. There's a lot of revisions there talking about CON clean ups so it looks like this is a sideeffect.
#4 Posted 12 March 2019 - 05:35 PM
That member is set by the game purely so you can see what an actor collided with from CON--it's not read back anywhere except for in CON_IFNOTMOVING. It's kind of a poor name for it but it is what it is.
What you're describing sounds more like what the source code also sometimes calls "movflags"--the flags you define "moves" in CON with. Those are stored in the actor's hitag.
What you're describing sounds more like what the source code also sometimes calls "movflags"--the flags you define "moves" in CON with. Those are stored in the actor's hitag.
#5 Posted 12 March 2019 - 10:24 PM
Yeah that's what I mean - I had no idea they were stored in the actor's hitag; That explains why whenever I dump a map with debug the enemies always have different values.
#6 Posted 13 March 2019 - 12:09 AM
This isn't worth making a new topic over, but findnearspritez is broken after snapshot 7352; I can replace this easily enough but it might be worth mentioning anyways since maybe it has a knock-on effect elsewhere.
here's some example code that demonstrates it:
108 picks up 109 fine on 7352, but on 7358 up to the latest snapshot it doesn't find it.
here's some example code that demonstrates it:
gamevar TEMP 0 2 useractor notenemy 108 ifaction 0 { ifcount 13 { findnearspritez 109 1024 1024 TEMP ifn TEMP 0 spritepal 6 else spritepal 0 addlogvar TEMP resetcount } } enda useractor notenemy 109 enda
108 picks up 109 fine on 7352, but on 7358 up to the latest snapshot it doesn't find it.
Share this topic:
Page 1 of 1