[Zaxtor]

Fox, on 15 January 2016 - 01:07 PM, said:

Cstat is available for both floor/ceiling and walls, but they use different values.

How we identify the wall's number since a sector has 3 walls and up.
So we don't "block all 3 walls at once"

cstat I wanna use is block and is 1 according to the site.
1 just like everything else.

When I use "setwall[THISACTOR].cstat 1"
nothing happens at all.

[Fox]

That's because THISACTOR has no use in setwall. It equals the ID of the current actor or player running the code. You have to find the ID of a specific wall.

[Zaxtor]

Fox, on 15 January 2016 - 03:54 PM, said:

That's because THISACTOR has no use in setwall. It equals the ID of the current actor or player running the code. You have to find the ID of a specific wall.

Ok

btw
I know the wall's ID but I am sure is not setwall[14299].cstat 1

(14299 is the wall's ID / number)

[Mblackwell]

It would be exactly that actually.

[Zaxtor]

I'll pass
I'm way too confused

[Fox]

Mblackwell, on 15 January 2016 - 05:33 PM, said:

It would be exactly that actually.

If I recall it correctly, [] only accepts variables. For a good reason...

[The Mechanic]

When Duke's path is blocked he often grunts or spurts out "Where is it?". Now, I have an object - a custom switch - which of course could block Duke. So, you press my custom switch and it operates fine but duke still grunts. What is the correct way to stop this happening ?

Initially what I tried was setting a flag when switch was pressed and in EVENT_SOUND checking if flag was set and grunt sound was being attempted and blocking it. Unfortunately, the code that decides Duke's path is blocked and plays the relevant sound occurs BEFORE event game and hence before I can set my flag. D'oh!

So, as a workaround, in the undocumented EVENT_WORLD I set a count to zero, then in EVENT_GAME if any of my blocking objects is within 1024 units of player then I increment the count. Then in EVENT_SOUND only allow grunts if count is zero. Hack ! (If I *want* to make the duke grunt sound, I set the counter to -30000 ... hack-squared!)

Now, if in mapster I set my switch as non-blocking then Duke never grunted. Strangely, if I set it to blocking but switched off blocking during initiaisation then Duke _did_ grunt. Suggests there is some statusy thing somewhere I need to set on my objects (it 'aint statnum, I checked).

Any ideas ?

TTFN,
Jon

[The Mechanic]

Zaxtor, on 15 January 2016 - 10:40 AM, said:

You know we have setsector[THISACTOR].floorstat xxx and setsector[THISACTOR].ceilingstat xxx
That makes floor and ceiling blockable, unblockable etc (good for tror etc)
But is there a version for walls , especially redlines wall.
Like making a redline wall blockable, unblockable etc.
Example we put the number of the line so it doesn't change all redlines in the sector.
Only let say wall 9510 that I wanna block or unblock?

If you want to target a particular wall - I'm assuming it is in THISACTOR's sector - try making the wall the first wall of a sector. Then do something like the following (assumes you have a global gamevars "temp1" and "temp2"

getsector[THISACTOR].wallptr temp1   // = firstwall
getwall[temp1].cstat temp2
orvar temp2 1
setwall[temp1].cstat temp2

TTFN,
Jon

[Zaxtor]

It works but how we reverse it.
So the thing "undo" the blocking first wall?

I have a global tempb1,2,3 or so (works the same) as temp

[Fox]

The Mechanic, on 19 January 2016 - 05:09 AM, said:

Any ideas ?

It's tricky, the wall pushing sound is checker internally only for hard-coded operators. I suppose stopactorsound <actor> <sound> with the player actor id should work, but I haven't tested it. It's also not a 100% solution since theoretically it would cut the sound after it has been playing for 1 tic.

[Danukem]

The Mechanic, on 19 January 2016 - 05:09 AM, said:

the undocumented EVENT_WORLD

What is that?

[Fox]

It's like EVENT_GAME but it doesn't run from any actor.

[Danukem]

Fox, on 20 January 2016 - 01:37 AM, said:

It's like EVENT_GAME but it doesn't run from any actor.

And it happens once per game tic?

So, in singleplayer, what would be the advantage of using EVENT_WORLD over executing code from the player actor?

[The Mechanic]

Zaxtor, on 19 January 2016 - 06:26 PM, said:

It works but how we reverse it.
So the thing "undo" the blocking first wall?

I have a global tempb1,2,3 or so (works the same) as temp

Replace the

orvar temp2 1

with either

andvar temp2 32766

(32767 minus the-value-you-are-trying-to-remove)

or, if you _know_ the wall is already blocking,

xorvar temp2 1

The latter method is more useful when dealing higher bits as the maths is easier

Fox, on 19 January 2016 - 10:09 PM, said:

It's tricky, the wall pushing sound is checker internally only for hard-coded operators. I suppose stopactorsound <actor> <sound> with the player actor id should work, but I haven't tested it. It's also not a 100% solution since theoretically it would cut the sound after it has been playing for 1 tic.

I tried that way first but as you said you still get a short burst of the sound. Sounded longer than 1/30th of a second too, wonder if there is a delay between stoping a sound and it actually stopping, such as letting a audio buffer finish emptying or something (not that that would normally be an issue, just curious).

Trooper Dan, on 19 January 2016 - 11:43 PM, said:

(EVENT_WORLD) What is that?

I empirically found out that it runs once per game tic. Because my sound hack worked I think the sequence really is:

(Eduke does hardcoded wall detection, plays sounds)
EVENT_WORLD
EVENT_GAME * lots

and not

(Eduke does hardcoded wall detection, plays sounds)
EVENT_GAME * lots
EVENT_WORLD

Basically I intercepted every game event and logged a different number when each ran so I could see the order in which things ran and discovered EVENT_WORLD which until then I wrongly assumed was related to initialisation. Don't like resorting to undocumented events but EVENT_WORLD can be useful.

TTFN,
Jon

[Fox]

Trooper Dan, on 20 January 2016 - 01:48 AM, said:

And it happens once per game tic?

So, in singleplayer, what would be the advantage of using EVENT_WORLD over executing code from the player actor?

If you are using the player, theoretically the same code would be compiled several times in multiplayer.

There are three events, PRELEVEL, PREWORLD and WORLD. They are equivalents to LOADACTOR, PREGAME and GAME except they doesn't originate from any sprite. To use commands that depends on the ID of an sprite such as spawn or ifp you can set the userdef structures vm_sprite, vm_player and vm_distance (ID of the current sprite, ID of the closest player and distance to the player).

There are several advantages with this. You don't need to find a sprite or player to run a global code, which is an ugly hack. If there are no actors in the map, it's impossible to do something during EVENT_LOADACTOR. If you run a code that affects all actors in the map, you don't have to worry about which actor will have the code compiled first of last during the same tic (the player for example probably won't be the first or last actor).

[Hendricks266]

The idea behind EVENT_WORLD is that EVENT_GAME is terribly inefficient. It is a lot of overhead to run an event for every actor, only to conditionally branch X number of times, where X is the number of actors you want to control with EVENT_GAME. EVENT_WORLD lets you loop through actors only in the ways you need, such as with the spritesect and spritestat linked lists.

[Danukem]

Thanks, guys. So it works the way that one would expect it to work.

I will say this in defense of EVENT_GAME: It's convenient to be able to reference actors with THISACTOR or simply [], and if used properly, a great deal of the overhead can be avoided. What I do is run a switch statement on the picnums of interest, then I use the htflag which prevents sprites from being processed in that event for the default case. That way, only sprites of interest will be processed in the event after the first game tic.

From the sound of it, EVENT_WORLD is a better choice when I want to process entire statnums (e.g. doing something to all of the projectiles).

[The Mechanic]

Trooper Dan, on 20 January 2016 - 12:01 PM, said:

What I do is run a switch statement on the picnums of interest, then I use the htflag which prevents sprites from being processed in that event for the default case. That way, only sprites of interest will be processed in the event after the first game tic.

Cool. I hadn't realised SFLAG_NOEVENTS existed and like you I use EVENT_GAME plus a switch statement for my stuff.

TTFN,
Jon

[The Mechanic]

Ah .. I ran Holywood Holocaust with and without using SFLAG_NOEVENTS in EVENT_GAME and can see no difference in frame rate. Are direct writes to htflags actually ignored ? The reason I ask is that I previously scrapped an idea because writing to htflags didn't work. For example, the new feature to make items slimer-edible, I did:

        // Temp1 = what to make edible eg 4670 (NEWBEASTHANG)

	getactor[THISACTOR].sectnum temp5

	headspritesect temp5 temp5
	whilevarn temp5 -1
	{
		getactor[temp5].picnum temp6
		ifvarvare temp6 temp1
		{			
			addlogvar temp6	

			getactor[temp5].htflags temp6
			orvar temp6 8388608 // SFLAG_GREENSLIMEFOOD
			setactor[temp5].htflags temp6
			
			// Just so I know it did something :thumbsup:
			addlogvar temp5
			addlogvar temp6
		}
		nextspritesect temp5 temp5
	}

Like SFLAG_NOEVENTS this too had absolutely no effect (using r5501).

TTFN,
Jon

[Danukem]

I know that it used to work, and that in some of my mods it did make a significant difference to framerate. To test whether it is working now, you could set the flag on a sprite and then have it log its ID in the event; if it keeps logging, then it's not working.

[Fox]

The Mechanic, on 20 January 2016 - 02:01 PM, said:

Ah .. I ran Holywood Holocaust with and without using SFLAG_NOEVENTS in EVENT_GAME and can see no difference in frame rate. Are direct writes to htflags actually ignored ?

I wouldn't expected it to increase the performance to an extend you can actually notice the difference, except for a mod that uses EVENT_GAME a gazillion of times.

The Mechanic, on 20 January 2016 - 02:01 PM, said:

The reason I ask is that I previously scrapped an idea because writing to htflags didn't work. For example, the new feature to make items slimer-edible, I did:

The slimer code check the tilenum of the sprite. So you have to set the flag to the tile, not the actor.

Use it outside of any actor or event:

spriteflags NEWBEASTHANG 8388608

[The Mechanic]

Trooper Dan, on 20 January 2016 - 02:20 PM, said:

I know that it used to work, and that in some of my mods it did make a significant difference to framerate. To test whether it is working now, you could set the flag on a sprite and then have it log its ID in the event; if it keeps logging, then it's not working.

OK, tried that and SFLAG_NOEVENTS does seem to work, phew ! Perhaps it'll really pay when there is a lot going on (projectiles, snow effects, that kinda thing). Anyhow, does no harm so shall use it.

Which just leaves the issue of why SFLAG_GREENSLIMEFOOD isn't working - ah, wait a mo ....

Fox, on 20 January 2016 - 02:42 PM, said:

The slimer code check the tilenum of the sprite. So you have to set the flag to the tile, not the actor.

Use it outside of any actor or event:

spriteflags NEWBEASTHANG 8388608

D'Oh. As htflags is a per-sprite variable I assumed you could set it on an individual sprite. Drats. And double drats So, is there a way of modifying the flag from _inside_ EVENT_GAME (even if it means affecting all sprites of the same picnum) ?

TTFN,
Jon

[Fox]

Like I said, the slimer is hard-coded to check the tilenum, so it's not supposed to be set in-game. This way it should also be possible to define flags for sector or wall textures, such as breakable monitors.

[The Mechanic]

That's a shame. Being able to "do something" to an enemy in-game to make it edible did open up a few possibilities.

TTFN,
Jon

[Danukem]

The Mechanic, on 20 January 2016 - 03:44 PM, said:

That's a shame. Being able to "do something" to an enemy in-game to make it edible did open up a few possibilities.

Most of those flags do work in-game. The slimer flag just isn't one of them.

[The Mechanic]

Trooper Dan, on 20 January 2016 - 10:21 PM, said:

Most of those flags do work in-game. The slimer flag just isn't one of them.

OK. Which ones ? Hang on, I've just looked at the wiki page again and notice some flags have a "Provided CON Label" and some don't, is it the ones that don't that can't be modified in-game ?

TTFN,
Jon

PS: Who do I have to ask about being given the ability to edit the wiki ? There's a fair bit of missing detail I could add.

[Hendricks266]

The Mechanic, on 21 January 2016 - 02:17 AM, said:

PS: Who do I have to ask about being given the ability to edit the wiki ? There's a fair bit of missing detail I could add.

All you have to do is create an account. The prompt to give us a certain amount of text about yourself is an anti-spam feature that has reduced our wiki vandalism to zero, so figure something out that will let us know that you're human and we'll approve it.

[Fox]

Trooper Dan, on 03 January 2016 - 04:47 PM, said:

I know this was covered a long time ago, but could someone explain why it would be prohibitively difficult to enhance CON language so that we can do things like this:

addvar sprite[THISACTOR].z 1024

A great deal of writing CON code involves getting struct members into variables and then manipulating those variables before putting them back into the structs. It makes for a lot of typing and it reduces readability.

I just wanted to add that this is mostly impossible to work out. It would be limited to the number of bits available to each structure members, unlike gamevars which all use 16 bit.

For example, if I wanted to make a sprite with a consistent size regardless of the height in pixels of the tile:

setactor[].xrepeat 64
shiftl sprite[].xrepeat 6
div sprite[].xrepeat tilesizy[MYTILE]

This would not work because xrepeat is limited to 8 bit (0-255), and the value would overflow in the second line.

[Danukem]

Fox, on 24 January 2016 - 07:58 AM, said:

This would not work because xrepeat is limited to 8 bit (0-255), and the value would overflow in the second line.

That would be user error, though. How is that worse than setting xrepeat to an invalid value using setactor?

[Fox]

It's different. The final value is within the limit of the .xrepeat, however it temporary sets to an invalid value during calculation.