[The Mechanic]

OK, I give up, how do you use ifceilingdistl in a con file ?

For example, creating a user actor and placing them in a door (ST20) that repeatedly opens and closes :-

ifceilingdistl 10
{
    soundonce STEPNIT
 }

Well, I expect a sound when the door closes, or is closed (or multiple times, whatever). Only ... the sound never plays.

Acording to the Eduke wiki,

Quote

Checks if the current actor is less than 256*<number> z units away from the actor's sector's ceiling. That is, one <number> unit corresponds to 16 x/y BUILD units

x/y units !? Eh ? Uh ?

Anyhow, if I modify the value 10 in my code, either the sound repeats indefinately, or else it never plays. Either way, it is completely independant of whether the door's ceiling is up or down. Is ifceilingdistl only calculated based on state at map initialisation ? Just how do I code to detect a ceiling height less than a certain value (in real-time) and in sensible units (e.g. 1 unit = 1 PGUP) ?

TTFN,
Jon

[Mark]

If I understand correctly, the sound won't play because the door never closes all the way. The door goes down 99 percent of the way, encounters your actor and moves back up. Its hard coded behavior. Just a guess. About the con code, others with more knowledge than I will have an answer.

[brownfarted]

The Mechanic, on 03 August 2015 - 02:13 PM, said:

    soundonce STEPNIT

[Danukem]

Keep in mind that using the command soundonce does not mean that the sound plays only once. It means that the command will not start an instance of the sound if there is an instance of it already playing. Thus, as long as the the condition before soundonce is met, then the sound will play over and over again.

Before you go any farther, you should try using some debugging code. Problems like this will waste a lot of time if you don't know what is going on. Maybe something unexpected is happening -- for example, maybe your actor is failing to move along with the floor of the door sector.

Somewhere outside the actor code (in defs.con for example) declare a variable for testing:

gamevar Z 0 0

Now, in the code of your actor, insert the following lines:

ifhitspace
{
  getactor[THISACTOR].z Z
  addlogvar Z
}

When the game is running, hold down the spacebar (or whatever is assigned to open). During that time, the actor's Z coordinate will be put into eduke32.log every game tic. Check the results to confirm the value of the Z coordinate at different times.

[The Mechanic]

Mark., on 03 August 2015 - 02:25 PM, said:

If I understand correctly, the sound won't play because the door never closes all the way. The door goes down 99 percent of the way, encounters your actor and moves back up.

Good point I hadn't considered. But in this case the door is totally closing and opening.

This does appear to be a bug - "ifceilingdistl" seems to be the ceiling distance when map is initialised, not what it is currently. See attached test map and associated con file; the actor placed in an initially closed door behaves differently from the actor placed in an initially open door. I think it is a bug as the related "iffloordistl" DOES update in realtime - see test map, pal 23.

Trooper Dan, on 03 August 2015 - 11:00 PM, said:

Keep in mind that using the command soundonce does not mean that the sound plays only once.

Indeed. I just hacked my actual code back to a minimal version to illustrate the issue. I've attached a fuller version.

Trooper Dan, on 03 August 2015 - 11:00 PM, said:

Before you go any farther, you should try using some debugging code. Problems like this will waste a lot of time if you don't know what is going on .... (useful code snipped) ....

Cheers Trooper Dan I was trying to work out how to debug the code, this is exactly what I'm looking for, thanks !

Empirically, it seems that the mythical "x/y BUILD unit" referenced in the wiki is actually 4 times number of PGUP's, e.g. a door that opens by 16 PGUP's is equivalent to a ceiling distance of 64. Is this always true?

[Edit]

OK, I cant seem to access the actual value used by ifceilingdistl, however using Trroper Dan's method I've a woorkaround where I can manually calculate a sector height:

gamevar debuggy 0 0
gamevar debuggy2 0 0
gamevar sectorid 0 0

(... start of actor code and then ...)

ifhitspace
{
  getactor[THISACTOR].sectnum sectorid
  getsector[sectorid].ceilingz debuggy
  getsector[sectorid].floorz debuggy2
  subvarvar debuggy debuggy2 // ceiling minus floor
  addlogvar debuggy
}

This gives a value of -1024 * PGUP's which makes more sense (though I'd forgot that UP is -ve Z, D'Oh!)

TTFN,
Jon

Attached File(s)

•  smokegen.zip (3.84K)
  Number of downloads: 88

[Danukem]

I forgot to mention you can also use the cheat DNDEBUG to create a dump of the map in its current state. This is useful if you want to see the positions of all the actors etc.

Personally I would not use a regular actor to achieve your effect. It is possible to code the equivalent of a sector effector, which would be more reliable. One of the problems with actors is that they can fall asleep (like enemies which are frozen until you walk up to them).

[The Mechanic]

Trooper Dan, on 04 August 2015 - 09:20 PM, said:

I forgot to mention you can also use the cheat DNDEBUG to create a dump of the map in its current state. This is useful if you want to see the positions of all the actors etc.

Personally I would not use a regular actor to achieve your effect. It is possible to code the equivalent of a sector effector, which would be more reliable. One of the problems with actors is that they can fall asleep (like enemies which are frozen until you walk up to them).

DNDEBUG does sound useful, cheers.

Not sure even where to start with coding a sector effector equivalent - kinda assumed game.con was all actor-related code, ergo I'd need to create a (user)actor to do anything ? In this smoke generator example, what should I replace the useractor with ? Hmmm ... wouldn't it be nice to be able to extend the existing sector effector via con code eg SE10000 == smoke generator, that'd be neat.

In this example, I'm assuming the sprite will always come into line-of-sight of the player so won't sleep (at least when player is about) but can quite understand that trying to code another effect where the sprite might not be visible could run into trouble. Indeed, I've been wondering what would happen in the example four sequenced smoke generators if they didn't all see the player at the same time => wouldn't sequence correctly. [Goes away and tests it] that's lucky they all seem to still be synchronised, phew!

TTFN,
Jon

[Danukem]

One thing you will want to do is use the eventloadactor command. In your case, the resulting code for that will look something like this:

eventloadactor SMALLSMOKEMAKER
getactor[THISACTOR].hitag hitag_count
ifvare hitag_count 0 setvar hitag_count 30
cstat 32768
getactor[THISACTOR].ang hitag_thingy
enda

It is separate from the actor code and the block is executed before the map loads. This allows you to make the sprite invisible before it can be seen by the player and load up the tags into vars before gameplay actually starts. This is necessary for some things. Aside: The wiki says it is "deprecated", but I think it's still useful because you can keep the initialization code for a sprite right next to its actor code, which improves readability.

[The Mechanic]

Trooper Dan, on 05 August 2015 - 06:06 AM, said:

One thing you will want to do is use the eventloadactor command. In your case, the resulting code for that will look something like this:

eventloadactor SMALLSMOKEMAKER
getactor[THISACTOR].hitag hitag_count
ifvare hitag_count 0 setvar hitag_count 30
cstat 32768
getactor[THISACTOR].ang hitag_thingy
enda

It is separate from the actor code and the block is executed before the map loads. This allows you to make the sprite invisible before it can be seen by the player and load up the tags into vars before gameplay actually starts. This is necessary for some things.

Cheers ! Yes, I like the idea of seperating init code into a seperate function from main runtime code.

Indeed, this might well have saved me some time; if you are wondering why I used .ang to initialise hitag_thingy instead of the more usual lotag, it's because I was initialising based on ifactioncount being zero. I was puzzled for quite a while why adding initialising the hitag_thingy based on lotag completely stopped the smoke generation - so I then tried 'extra' - then tried angle only out of desperation ! It was quite a while until I figured actioncount was always zero so it was always initialising, D'Oh ! Event based init would have avoided that one.

Trooper Dan, on 05 August 2015 - 06:06 AM, said:

Aside: The wiki says it is "deprecated", but I think it's still useful because you can keep the initialization code for a sprite right next to its actor code, which improves readability.

Hmm, thats a concern, usually deprecated really does mean the developer(s) are hacked off with trying to maintain something and it WILL dissapear. I do hope not in this case.

On the subject of readability, is there the equivalent of the c/c++ "#define" in a con file ? OK, there is "define" but that is just for setting up constants. The reason I ask is that lets say I made a dozen actors, each needing their own variables; either I create every variable - which would then appear on every actor (sprite?) and be inefficient, else I simply add, say, variables jonz1, jonz2, whatever, which have different meanings for different actors - which will make nightmare code. Being able to #define a name for gamevar "jonz2" etc would bring back the readability.

TTFN,
Jon

[Danukem]

The Mechanic, on 05 August 2015 - 01:18 PM, said:

Hmm, thats a concern, usually deprecated really does mean the developer(s) are hacked off with trying to maintain something and it WILL dissapear. I do hope not in this case.

You shouldn't be concerned about that. The developers do try to maintain compatibility with the various mods and TCs which have been released over the years. In fact, they DO break things from time to time, but they generally don't get rid of commands that were widely used (and eventloadactor is one of those).

The Mechanic, on 05 August 2015 - 01:18 PM, said:

On the subject of readability, is there the equivalent of the c/c++ "#define" in a con file ? K, there is "define" but that is just for setting up constants. The reason I ask is that lets say I made a dozen actors, each needing their own variables; either I create every variable - which would then appear on every actor (sprite?) and be inefficient, else I simply add, say, variables jonz1, jonz2, whatever, which have different meanings for different actors - which will make nightmare code. Being able to #define a name for gamevar "jonz2" etc would bring back the readability.

Nope, so usually I choose the nightmare code option. However, you can code in Lunatic, which has local variables. It is an implementation of Lua developed by Helixhorned: http://forums.duke4....w-introduction/

[The Mechanic]

Trooper Dan, on 05 August 2015 - 10:29 PM, said:

You shouldn't be concerned about that. The developers do try to maintain compatibility with the various mods and TCs which have been released over the years. In fact, they DO break things from time to time, but they generally don't get rid of commands that were widely used (and eventloadactor is one of those).

OK, I'll use it then, it is definitely useful.

Trooper Dan, on 05 August 2015 - 10:29 PM, said:

Nope, so usually I choose the nightmare code option. However, you can code in Lunatic, which has local variables. It is an implementation of Lua developed by Helixhorned: http://forums.duke4....w-introduction/

Ah-ha ! You know, I stumbled across:

#ifdef LUNATIC

in the code and, after finishing laughing, wondered what on earth was going on! Anyhow, looks interesting so added to the list of things to play with. Looks like it requires a specific build of mapster ?

TTFN,
Jon