Fall in hole teleport to map // Arch Vile attack scare? [ZDoom]

[BlueEagle]

Hi!

I have two questions for a project for ZDoom:

1) What is the best method to make the effect of a player falling in a hole and when he has reached a certain height, he will get teleported to a new map. I've tried the "actor hits ground" object, but I don't want the player to actually hit the ground (and this leads to problems when you hit multiple sectors at once)...

2) How do I create an Arch-Vile scare? I just want the player to go inside a big hall and suddenly the Arch Vile flame appears on the player, but he doesn't get hurt.

Thanks in advance :D

[Gez]

1. You might use a portal (aka stacked sector) to give the impression the actual bottom of the pit sector is not the bottom of the pit. You might also monitor the player's Z-position.

2. To spawn that, you'll need to give a TID to the player (possible in an open script) and then you can SpawnSpot the flame actor at the player's position.

[Enjay]

Gez said:

(possible in an open script)

an enter script?

[BlueEagle]

Thanks so far, Gez!
I'll try that when I come home tonight.

Just two more things:

1) I don't know the proper way to monitor the z-height of the player. Do I have to use a "while" in a script and getactorZ somehow? How would such a script look like? I can't run a script when the player gets to a certain height, can I? Running the script when player crosses a line doesn't make sense, because he is falling in a well. And hitting the ground doesn't make sense either, because the well has multiple sectors and when I change level and return back to the well level (it's a hub), the "oof" sound is played again and the player exits the level AGAIN as if he was still in the well (even when player is at complete other sector). Maybe you could be a little more precise? That would help a lot :)

2) Alright, I get the part with the tid and spawnspot, but does this trick include that the flame follows the player around like the actual effect?

[DuckReconMajor]

I think you should have the outside edges of the hole trigger a script that has a few second delay (long enough so you won't hit the ground) and then ends the level.

[Gez]

Enjay said:

an enter script?

Yeah, that's what I meant, sorry.

BlueEagle said:

2) Alright, I get the part with the tid and spawnspot, but does this trick include that the flame follows the player around like the actual effect?

No. You'd have to use Thing_Move to do that yourself.

[gggmork]

zing:

http://www.speedyshare.com/182132953.html
(only tested w/ zdoom 2.3.1 = exit while falling half way down a hole)

Only pay attention to script 2 (the other is from some unrelated thing). Also try to run over the corner edge of the hole WITHOUT falling in (to trigger the walk-over edge which triggers the script). Then it will print your height continually (try walking up the stairs to see your height etc). I made the sides of the hole trigger this to save computational power (I guess) so that loop wouldn't be running for the entire level; just the exit. Also if it always ran, any equally low spot on the level could trigger your exit. You probably want to delete the print of course.
The >> 16 stuff is weird and I don't really get. I just read you have to do that to convert numbers or they'll be meaninglessly huge instead of reflecting true height.

Actually you might have to turn off the script whenever you leave the well room or it could have a possible bug, like you could trigger the line but not fall in. Then walk around the normal level some more and if there are any equally low places as the well exit, you could exit there instead.

[Gez]

gggmork said:

The >> 16 stuff is weird and I don't really get. I just read you have to do that to convert numbers or they'll be meaninglessly huge instead of reflecting true height.

Back in 1993, many computers were quite lousy when performing floating point arithmetics. They were doing just fine with integer computations, but floating point was slow. Still, using integers is not always something you want, since you'll often need to have units that are less than 1. A Doom teleport pad is 64x64, imagine how shaky the game would be if all movements were cut into steps of one mapunit.

The solution is to use "fixed point" arithmetic. You take your 32-bit "word", and cut it into an integral part and a decimal part, usually using 16 bits for each (but you could cut it anywhere you want, really). In effect, this is just like using a very tiny base unit.

Now, fixed point arithmetic has the advantage of being as fast as integer arithmetic, since it's just integer arithmetic disguised. But it has a few problems. The first is that it's less precise. In effect, with a 16.16 fixed point system like that used by Doom, the decimal part is a fractional number (with 65536 as the denominator). Many numbers can't be expressed properly as such fractions, so you get roundoff errors.

The other is that you need to constantly multiply or divide by this denominator. For example, if you decide to use 10 to represent 1, then when you compute 2x2, you actually compute 20x20, and the result is 400, which becomes 40. Obviously, 2x2=40 is not something you want. So you need a fixed_multiplication function. Same thing, just with larger numbers, when you use 65536 to represent 1.

And when mixing true integers and fixed point units, you have to divide or multiply to convert them. When mixing integers and floating point, the conversion is handled directly by the compiler, so you don't have to worry about it.

Nowadays, computers are performing floating point arithmetics fast enough that games don't need to rely on fixed point numbers instead. (There was a project to convert ZDoom to floating point arithmetic, but it has been dropped for some reason.)

[gggmork]

Thanks for taking the time for that interesting explanation. Hopefully I can cram that in my brain before the next cryptic thing pops it back out again; it often amazes me how much programmers seem to know.

I wonder HOW much faster it is than floating point (like python games are relatively slow, so perhaps they could benefit somehow, not that I'd likely get skilled enough to do that type of thing). There was an interesting term I remember that referred to how computers somehow use addition to do.. subtraction.., forgot what it was called.

[Graf Zahl]

gggmork said:

I wonder HOW much faster it is than floating point.

Back in 1993: Several magnitudes because back then most CPUs didn't even have a floating point unit.
Today: Irrelevant. Since floating point math is actually easier to code it's often faster except for very basic stuff.

[andrewj]

Gez said:

The other is that you need to constantly multiply or divide by this denominator.

But these are just bit-shifts (<< and >> in C) which are much faster than true multiplication and division.

gggmork said:

There was an interesting term I remember that referred to how computers somehow use addition to do.. subtraction.., forgot what it was called.

You're probably thinking of Two's Complement.

[Gez]

andrewj said:

But these are just bit-shifts (<< and >> in C) which are much faster than true multiplication and division.

Only if the denominator chosen is a power of two. (Of course, it wouldn't make much sense to choose a denominator that isn't a power of two.)

[BlueEagle]

sorry doublepost :(

[BlueEagle]

Alright, thanks for the big help so far!
Still one problem: it's not changing the map :/

This is the modified script

script 10(void){
 while(1){
  print(d: getactorz(0)>>16);
  if(getactorz(0)>>16 <= -384){
   teleport_newmap(02,2);
   terminate;
  }
  delay(1);
 }
}

It's writing the height just fine and the script terminates itself, but the teleport is not happening...

[gggmork]

This worked for me:
Teleport_NewMap (2,0,1);
(has another parameter)
http://zdoom.org/wiki/Teleport_NewMap

If it doesn't work maybe you have to update files:

"Get ACC r1822 from here for the exe, and the acc.acs package with the highest revision number"
http://svn.drdteam.org/ACC/

Two's complement: bingo :)

[BlueEagle]

Doesn't work. If I put the same teleport_newmap line in a different script, it works. So I guess the script doesn't know who the actor is? How can I define that?

[gggmork]

Maybe your player TID is not 0 or something. Maybe try this test:

script 2(void){
 while(1){
  //print(d: getactorz(0)>>16);
  print(d: activatortid()>>16);
  if(getactorz(0)>>16 <= -512){
   Teleport_NewMap (2,0,1);
   terminate;
  }
  delay(1);
 }
}

(then just walk over the corner of the hole without falling in. Does it print '0' or some other number as the player TID?

Also remember to click 'compile' for each change..

[BlueEagle]

Yes, it's always printing 0 now.

[gggmork]

What map# is your well map and which map do you want to warp to (and does that map you'll warp to have a player 1 start?)?

It might have something weird to do with hub levels, like level-to-level global variables or something, but that's a guess. Or maybe you didn't install the acs/etc update correctly.

If you want just pm me a speedyshare link to the map or something, though I might not figure it out.

[BlueEagle]

When I put the teleport_newmap on a regular switch, everything works fine.

[gggmork]

I probably just don't know, but its hard to guess without seeing all the code or preferably the whole map (to see what causes which script to trigger etc).
Maybe kill the first print and put a print in the if to see if that if even triggers. Maybe some code somewhere is influencing other code somehow or some small error.

[BlueEagle]

Posting the map is not so easy, because the resources take up a lot of space and there is nothing else to see in the map that would make uploading it worth it.

I have two lines. One line is at the edge of the well that triggers the posted script when player walks over (repeated use).

script 10(void){
 while(1){
  print(d: activatortid()>>16);
  if(getactorz(0)>>16 <= -384){
    teleport_newmap(02,2,1);
   terminate;
  }
  delay(1);
 }
}

The other triggers a second script when player leaves the room with the well that deactivates the posted script with a "acs_terminate" when player walks over (repeated use).

script 11(void)
{
   acs_terminate(10)
}

[gggmork]

move the line:

teleport_newmap(02,2,1);

back one space (if that matters)

--

also I think acs_terminate takes 2 parameters.

--

This works for me (altering my previous linked map above) so I dunno:

script 2(void){
 while(1){
  print(d: getactorz(0)>>16);
  if(getactorz(0)>>16 <= -512){
    Teleport_NewMap (02,0,1);
   terminate;
  }
  delay(1);
 }
}

script 3(void){
 acs_terminate(2,1);
}

well outer lines trigger script 2 (walk over repeatable). exit room line (i added a new room) triggers script 3 (walk over repeatable).

And uh... your well's sector goes far enough down right? Is -380 or whatever you put ever even reached by the player. Try making that number higher or something.

[BlueEagle]

Now it works!

I had to flip the lines (they were showing to the inside)! I think I will never get why lines that show inside activate some things when you walk over and some things they ignore...

Thanks for the great help gggmork :)

[gggmork]

It's often a minor detail like that that causes stuff not to work.