[Corvin]

Yes the Lift works in WH2. But I'm toying with it. I'm not sure if Its set to only go a certain height or what. Having a bit trouble keeping the Lift together completely, especially the top. I might have to duplicate WH1's Lift exactly which I don't want to do, which the lift is 32z tall. Mine is only 17z, just enough to accommodate the player.(16.75z).
So I have to keep playing with the Tags and the construction of it.

BTW, the base/bottom of the expanded WH2 BUILD Manual contains our notes on various aspects that we been passing back and forth, please check them out. I updated some with what I think helps.


EDIT: Well I made the Lift same height as WH1's Lift, but the Lift stops short of it's start position when going back up. If I knew exactly what the tags are doing I might be-able to correct the problem. I don't think there 4 pixel groups, like you said they might be just related to how long the sound plays. Very frustrating. Next I'll compute the travel distance and try to set the tags as 4 groups of pixels each z.

This might be why Capstone created a red sector underneath the Lift to rest it on. Cause it doesn't have a problem going any distance down, it keeps going until it rest on the floor. Up is the problem.

[Corvin]

Taking a break from the Sprite Lift, can't figure it out. Sent you an updated EXAMPLE MAP with the sorta functioning Lift.

Like I said in the e-mail about Visibility, I don't think Capstone even used it in their maps. It wasn't documented anyhow and the maps I looked at these used shading to darken rooms. WH2 seems to have a set visibility once the game is loaded. It gets darker in the distance, I think too much too quick....I forget what this is called, some sorta of lighting that diminishes, some games have 32 shades others 64.

[Corvin]

@EG

Any luck on finding why the EXAMPLE map traps don't work?
I think it has something to do with the Pull Chain or the Arrow trap Only, since in the WH2 regular maps, they activate the traps with breaking glass or floor plates. and they use Javelins or fire for the traps.

When I get time I'll change out the pull chain with a floor plate and see if the arrows spawn or not.

EDIT: Well I used a floor plate and it worked. So its just down to the Pull Chain being the problem in the source.

[Corvin]

Found this in the WH1 source, TAGS.TXT

1800-1899 MANUAL ELEVATOR STAYS 16 UNITS FROM CEILING CAN HAVE
UP AND OR DOWN SWITCH

The units are the key presses, I'll have to see if that fixes my elevator....
EDIT: Lowered the ceiling so its 16 key presses from top of elevator, with no luck on correcting the problem.

However I found why WH1 style sprite doors where not working, the sector needs to be tagged 0,3000, All the information is added to the expanded manual now.

[ETTiNGRiNDER]

For the elevator, have you perhaps tried tagging both the sprites and the sector?

Here are some relevant parts of the code:

From WHTAG.C

     if ((sprite[s].lotag == 1800 || sprite[s].lotag == 1810 || sprite[s].lotag == 1820)
         && sprite[s].sectnum == plr->sector) {
          for (j = 0; j < MAXSPRITES; j++) {
               if (sprite[s].sectnum == sprite[j].sectnum
                   && (sprite[j].lotag >= 1800 && sprite[j].lotag <= 1899)) {
                    newstatus(j, LIFTDN);
               }
          }
     }
     if ((sprite[s].lotag == 1801 || sprite[s].lotag == 1811 || sprite[s].lotag == 1821)
         && sprite[s].sectnum == plr->sector) {
          for (j = 0; j < MAXSPRITES; j++) {
               if (sprite[s].sectnum == sprite[j].sectnum
                   && (sprite[j].lotag >= 1800 && sprite[j].lotag <= 1899)) {
                    newstatus(j, LIFTUP);
               }
          }
     }

From WHANI.C

     // LIFT UP
     i = headspritestat[LIFTUP];

     while (i != -1) {
          nexti = nextspritestat[i];
          spr = &sprite[i];
          switch (spr->lotag) {
          case 1821:
               spr->z -= (synctics << 6);
               setsprite((short) i, spr->x, spr->y, spr->z);
               if (spr->z <= sector[spr->sectnum].ceilingz + 32768) {

                    SND_StopLoop(cartsnd);
                    cartsnd = -1;
                    playsound_loc(S_CLUNK, spr->x, spr->y);

                    changespritestat(i, INACTIVE);  // EG Note: RAF.H gives this a nice name, so use it
                    spr->lotag = 1820;
                    spr->z = sector[spr->sectnum].ceilingz + 32768;
               }
               break;
          case 1811:
               spr->z -= (synctics << 6);
               setsprite((short) i, spr->x, spr->y, spr->z);
               if (spr->z <= sector[spr->sectnum].ceilingz + 65536) {
                    changespritestat(i, INACTIVE);  // EG Note: RAF.H gives this a nice name, so use it
                    spr->lotag = 1810;
                    spr->z = sector[spr->sectnum].ceilingz + 65536;
               }
               break;
          case 1801:
               spr->z -= (synctics << 6);
               setsprite((short) i, spr->x, spr->y, spr->z);
               if (spr->z <= sector[spr->sectnum].ceilingz + 65536) {
                    changespritestat(i, INACTIVE);  // EG Note: RAF.H gives this a nice name, so use it
                    spr->lotag = 1800;
                    spr->z = sector[spr->sectnum].ceilingz + 65536;
               }
               break;
          }
          i = nexti;
     }

     // LIFT DN
     i = headspritestat[LIFTDN];

     while (i != -1) {
          nexti = nextspritestat[i];
          spr = &sprite[i];

          ironbarmove = 0;
          switch (spr->lotag) {
          case 1820:
               spr->z += ironbarmove = synctics << 6;
               setsprite((short) i, spr->x, spr->y, spr->z);
               if (spr->z >= (sector[spr->sectnum].floorz - 32768)) {
                    SND_StopLoop(cartsnd);
                    cartsnd = -1;
                    playsound_loc(S_CLUNK, spr->x, spr->y);
                    changespritestat(i, INACTIVE);  // EG Note: RAF.H gives this a nice name, so use it
                    spr->lotag = 1821;
                    spr->z = sector[spr->sectnum].floorz - 32768;
               }
               break;
          case 1810:
               spr->z += ironbarmove = synctics << 6;
               setsprite((short) i, spr->x, spr->y, spr->z);
               if (spr->z >= sector[spr->sectnum].floorz) {
                    changespritestat(i, INACTIVE);  // EG Note: RAF.H gives this a nice name, so use it
                    spr->lotag = 1811;
                    spr->z = sector[spr->sectnum].floorz;
               }
               break;
          case 1800:
               spr->z += ironbarmove = synctics << 6;
               setsprite((short) i, spr->x, spr->y, spr->z);
               if (spr->z >= sector[spr->sectnum].floorz) {
                    changespritestat(i, INACTIVE);  // EG Note: RAF.H gives this a nice name, so use it
                    spr->lotag = 1801;
                    spr->z = sector[spr->sectnum].floorz;
               }
               break;
          }
          i = nexti;
     }

     if (datag >= 1800 && datag <= 1899) {
          i = getanimationgoal(&sector[s].floorz);
          if (i >= 0) {
               daz = sector[s].ceilingz + (1024 * 16);

               if (animategoal[i] == daz)
                    animategoal[i] = sector[nextsectorneighborz(s, sector[s].ceilingz - (1024 * 16), -1, -1)].floorz;
               else
                    animategoal[i] = daz;
          }
          else {
               if (sector[s].floorz == sector[s].ceilingz + (1024 * 16))
                    daz = sector[nextsectorneighborz(s, sector[s].ceilingz - (1024 * 16), -1, -1)].floorz;
               else {
                    daz = sector[s].ceilingz + (1024 * 16);
               }
               if ((j = setanimation(&sector[s].floorz, daz, 32L)) >= 0) {
                    SND_PlaySound(S_STONELOOP1, 0, 0, 0, (sector[s].lotag - 1800) / 10);
               }
          }
     }

It looks like you should end the sprite tags in 0 for a down lift, 1 for an up lift; only 1800, 1801, 1810, 1811, 1820 and 1821 appear to be valid for the sprites, despite the sector tag being a range.

[Corvin]

Well I checked the sector on the WH1 map and there where no tags. I increased the size/height of the lift to 32 and that helped with it coming down.
But going up it still stops short. Whoever figured out the math on this was a genius when mapping the lift.

I also constructed the room and the room leading up to it the same height dimensions as the WH1 map, but it still comes short to returning to the same spot when going up.
According to what I understand this is a combo lift, goes up and down, not one or the other.

Is there another Lift used in WH1 or WH2 that you remember?
That might help to have another example...

[Corvin]

Alright, I believe I got all WH1 effects and tricks in the updated example map. Except for the three that where only demo based, and of course the Sprite Lift is incomplete. All the information is in the Expanded WH2 Build Editor Manual. The end of the manual indicates stuff I'm/where working on figuring out and testing. Here's the link again:

http://dukertcm.com/...en2-manual.html

[ETTiNGRiNDER]

Corvin, on 03 January 2015 - 10:17 AM, said:

Well I checked the sector on the WH1 map and there where no tags. I increased the size/height of the lift to 32 and that helped with it coming down.
But going up it still stops short. Whoever figured out the math on this was a genius when mapping the lift.

I also constructed the room and the room leading up to it the same height dimensions as the WH1 map, but it still comes short to returning to the same spot when going up.
According to what I understand this is a combo lift, goes up and down, not one or the other.

Is there another Lift used in WH1 or WH2 that you remember?
That might help to have another example...

Setting up or down tag should determine what direction it goes in first, then it will be reverse on the next use. TBH I never realized the one in the original level could go back up until this was pointed out.

As far as I can recall, WH1 LEVEL1 is the only one that has this construct, so it's entirely possible they half-assed it in some way that only works in that situation (then the matter would be figuring out in what way). Did you try all three versions of the tags? It seems by the code that they might affect what level the lift moves to. Also, I think the up movement is relative to ceiling height of the sector, not starting position of the lift, could that be the problem?

Edit: After experimentation, yes, it is reliant on ceiling height.

[Corvin]

Yes they built it just for that situation, to solve it from the top coming apart it has to be 32z tall. Then I raised the ceiling in the red sector to 21z more than the ceiling around it. You helped me on that, I was going the other way (down) with it. So thanks, cause I would still be trying to figure it out.
I don't know how I'm going to explain all this in the manual, but I'll try. It would be a shame never to see it used again.

I might experiment with the other tags now that its working.

EDIT: I updated the manual. The Lift is broken down into a four part instruction set. Hope its clear enough. If you have any ideas or information I should add to it please let me know. http://dukertcm.com/...html#spritelift

[Corvin]

Okay just finished reviewing the WH1DEMO Level3 map.

There's a split sliding door made out of walls, looks complicated to make. I also loaded up wh1 full version level13(probably other places too), it has a splinting door too. Looks like this might be heavy on the directions to make it. Anyhow I'll get to it.

EDIT: The sector, which ever one that is is tagged 0,16 and there is one or two 0,6 sectors. The walls seem to come back onto each other, and there's vertices on top of each other, very complicated. Not sure where to start.

BTW do you know what the SPAWN tile#675 is suppose to do?
Its at the very beginning of WH1 Level3. Its the same tile and number in WH2.

[ETTiNGRiNDER]

Corvin, on 03 January 2015 - 07:49 PM, said:

BTW do you know what the SPAWN tile#675 is suppose to do?
Its at the very beginning of WH1 Level3. Its the same tile and number in WH2.

Seemingly nothing. From the setupboard function in WHAVEN.C:

            if(sprite[i].picnum == SPAWN ) {
                deletesprite((short)i);
            }

So the sprite appears to get removed without having any effect when the map loads.

[Corvin]

Okay Thanks for the info on the SPAWN.

I'm going to try to make a swinging door before I tackle the pocket door. But...

Now does the instructions made by Capstone for a swinging door make sense to you?
http://dukertcm.com/....html#swingdoor

The diagram just looks wrong, especially image 2.

EDIT: I managed to create it the way they said, it just doesn't seem to work. Also the diagram needs one or two more images to be a decent example...I'll add to it if I can get the door to work...

EDIT2: LOL, WTH. The low tag is suppose to be a 4 not 5, geez. It works now.

EDIT3: Okay, I broke the instructions down a bit and expanded the image examples from 4 images to 6. This should work till I or somebody creates an image from BUILD directly.

[Corvin]

POCKET DOORS GUIDE

I just completed the guide on pocket doors and uploaded it. I'll probably add to the description and image latter on but It's all there now.

[Corvin]

BOBBING LAVA

WH1 Tags implies that a low tag of 1000 needs to apply to the lava sector. I tried it and nothing happened, same thing with 1050.
Maybe It needs to be activated, but that seems foolish.

Any thoughts?

PS, I tried the FLICKER and GLOW sprites and textures with no results. They either don't work in WH2 or I'm doing something wrong.

[ETTiNGRiNDER]

Corvin, on 07 January 2015 - 06:38 PM, said:

BOBBING LAVA

WH1 Tags implies that a low tag of 1000 needs to apply to the lava sector. I tried it and nothing happened, same thing with 1050.
Maybe It needs to be activated, but that seems foolish.

Any thoughts?

It probably refers to the 10000 tag that I found in the code earlier.

[Corvin]

You seem correct good sir. I also found the 1000 value in that new BSTUB.C but it refers to the following:

1000:PLATFORM ELEVATOR: Must be activated, it rises to floor height once.
1003:BOX ELEVATOR: Must be activated, it rises to floor height once.
So maybe the Bobbing Lava is suppose to be ten thousand rather than one thousand, basically like you said.

But getting back to these ELEVATORS, I think I seen one of WH2 maps start off like this, I'm not sure if there is any sound associated with them yet. I'll have to find that map again and see what it's low tagged at.

EDIT: Found the map, but Its in WH1. It doesn't use the ELEVATORS to raise the player. It uses the 1100 low tag and a pull chain. I think why is because the elevators are fast. I'll have to find an excuse to build one in the new example map. No idea at the moment tho. Also I don't know what the difference is between a PLATFORM and BOX Elevator is. I assume the the platform is just the moving floor, no idea what a "BOX" is.

[Corvin]

Added considerable amount of information, corrections and clarity to the Expanded WH2 BUILD Manual. I'm trying to get all the functions of that editor into the Xmanual.
http://dukertcm.com/...en2-manual.html
Anyone Building maps for WH2? If so please speak up, or is it I'm only doing this for EG and myself?

@EG, could you please compile me the WH2 Build Editor from the source code?
I want to see if there's any improvements, since part of that code is nearly three months newer than the editor they included on the CD.
Thanks again in advanced.

EDIT: BUG on HUD when you have the Long Bow, the arrow counter is overlapping the word ARROWS, the ammo counter needs to be moved to the right a bit more. Unless the ammo count could go in three digits, then I guess it would be unwise. I only tested this with 50 arrows, and on WH2 v2.0g and EGwhaven.

[Corvin]

I guess you don't know how to compile the Editor or what not or too busy, so I'll move along. But I'd appreciate a word or two. I know your self taught and getting better.

Just so you know there's Makemap Editor available from RR game (which is very similar to dukes editor, I may test this one out with a WH2 map) and the Duke3D map editor source available, and TerminX's DOS Mapster source code is available too. To run DOS Mapster I have to copy the WH2 map file to the duke directory to modify the WH2 map for my BUILD Scale document, thats all I use of it, it has weird colors too for lines and points etc. I haven't tested Mapster32 with a WH2 map, I'm afraid it might have too many duke3d and or EDuke32 assumptions.

old BUG: That death bug when you get in tight spots seems to activate the teleport code, well at least I see the teleport graphics before it goes away. Don't know if it's just using sector to sector or what.

Something else I was suppose to tell you, I'll post it when I remember....

[ETTiNGRiNDER]

I haven't had time to look into compiling the editor, last stuff I did was poke at the WH1 stuff a bit more, still to no avail. I'm going to try to figure out getting a proper debugging tool on it at some point. Right now my biggest priority is getting v0.3 of EGWhaven for WH2 done and released. Have to make sure the mouse fix stuff is really fixed this time, and hopefully make GAME parameter able to load custom .ART sets too (probably will wait on JOESND/SONGS for now since no one seems to know how to edit them anyway).

I've noticed the thing with the teleport sprite coming up when the wall death bug happens, never thought too hard on it but it might be worth my looking into the code that spawns that sprite at some point.

In your experimenting with map editing, did you look into the "patrol point" sprites at all? They appear in LEVEL12 of WH2 apparently to guide some imps along a tunnel. Not sure if WH1 used it at all.

[Corvin]

Thanks for the update.

I'll look into the patrol points next and see what I can figure out.

EDIT: didn't see these special sprites or even imps in L12 of WH2. I'll keep loading maps to see if I can find what your are talking about.

EDIT: Okay found them....They are right at the beginning. I think there just to get the enemy to leave there chambers without seeing the player first. So they don't just stand in them and do nothing. That's my take on them.

I'll go back to it later and examine that example again. Unless you know another example I could look at?

EDIT: Speculating, that when the player is not seen, the enemy will return to the closes patrol point, so maybe you can place these sprites(since there not tagged) one closer than the previous and they should follow each point. You probably make a long patrol path until you can't place any patrol points(sprites).
I haven't tested putting any tags to them, I need more information if available.

[ETTiNGRiNDER]

I'm giving the code a look now to see what it's doing with patrol points internally. AFAIK they were only used in LEVEL12, which could either mean their usefulness is limited, or that it was just an overlooked feature (sort of like how water animation was never used in the WH2 levels even though the specials for it still work).

In WHAVEN.C setupboard patrol points are given sprite status APATROLPOINT. A good hook to search further from.

Now, states like this are handled in WHANI.C. I couldn't find a handler for this particular state, but there is code in the SKIRMISH state that looks for other sprites that are in the APATROLPOINT state.

          if (movestat != 0) {
               // spr->ang=(getangle(plr->x-spr->x,plr->y-spr->y)&2047);
               // newstatus((short)i,FACE);

               j = headspritestat[APATROLPOINT];
               while (j != -1) {
                    nextj = nextspritestat[j];
                    tspr = &sprite[j];
                    dist = klabs(tspr->x - spr->x) + klabs(tspr->y - spr->y);
                    if (dist < mindist) {
                         mindist = dist;
                         target = j;
                    }
                    j = nextj;
               }
               tspr = &sprite[target];
               if (cansee(tspr->x,
                          tspr->y,
                          tspr->z,
                          tspr->sectnum,
                          spr->x,
                          spr->y,
                          spr->z - (tilesizy[spr->picnum] << 7),
                          spr->sectnum) == 1) {
                    spr->ang = (getangle(tspr->x - spr->x, tspr->y - spr->y) & 2047);
                    // newstatus((short)i,PATROL);
               }

          }

This isn't the complete SKIRMISH block, only the part that cares about APATROLPOINT sprites.

The other state that can look for an APATROLPOINT sprite is CHASE. This is a big complicated block of code so I'm not going to paste from it here, but of note, sprites GONZOGHM and GONZOGSH have one set of behavior, while KOBOLD, IMP, MINOTAUR, SKELETON, GRONSW, NEWGUY, GONZOCSW and GONZOGSW have another. Both these groups can potentially switch to SKIRMISH state under the right conditions.

There are also two other groups in the CHASE code, one for DEMON, GUARDIAN, and WILLOW, another for GRONHAL, GRONMU, KATIE and DEVIL. Neither of these groups look for patrol points or switch to SKIRMISH state from their CHASE code. I would therefore surmise that these enemies ignore patrol points. Something to check up on.
(I checked and DEMON does not appear to be a valid monster, but the last frame of the jumpscare head that pops up sometimes. Not sure if it actually uses this code at all, I haven't looked.)

We can also find a function in WHANI.C called findapatrolpoint that looks for these objects, but the code doesn't seem to call this function from anywhere. Odd. Dead code maybe. In any case I'd consider it a red herring in our search, and go by the other code mentioned.

I checked the WH1 code and it appears there's no mention of patrol points, so it would seem to be a WH2-only feature. Possibly something they added late and didn't have time to make more use of (given it's only used in LEVEL12 AFAIK, perhaps it was put in solely to fill a need in that map.)

[Corvin]

Okay, In the game the PATROLPOINT sprite/tile says Chase Point and they use GONZOSW , NEWGUYBOW and KURTSTAND to go after the chase point.

Just to clarify which ones will use the chase point/PATROLPOINT?
I know the three I mentioned...

EDIT so these? KOBOLD, IMP, MINOTAUR, SKELETON, GRONSW, NEWGUY, GONZOCSW and GONZOGSW
I was in a rush earlier, so these mentioned are using it.

[ETTiNGRiNDER]

Yeah, those plus GONZOGHM and GONZOGSH (Giryon Knights IIRC).

[Corvin]

Well I tested it out.

I made an E shaped hallway, and placed the NEWGUYBOW in there and put a couple of chasepoints then used the cheats showmap and showobjects to observe his behavior.
The result was he didn't wake up till he seen me. He followed me tho as I was approaching, he faced me where ever I was on the map during the times he couldn't see me, through the walls.

Then after I woke him up by being in his line of sight he didn't follow the chasepoints, he just kept going back forth and in slight different directions.

I changed the position and direction of the stick on the chasepoint but to no results. I also moved the chasepoints close to him.

They may have had hitscan turned on on the sprite, but I don't think that wouldn't effect it....

I'm not sure what else to try.

[TheDragonLiner]

Do you think making bigger hallways would change the thing up a bit ?

I noticed the AI tends to get away from you when you hit them or when they run into a wall no matter what direction the wall faced, I'm not a specialist but my guess is that if the AI collides with a wall or gets hit by the player then this might brake something in the chasepoints.

[Corvin]

A.I. nutz to figure out, I'm not expert either, but did a little A.I. testing in the past.

I made the hallways wide in the test map, so I don't know. The chase/patrol points I don't think where intended for long paths. I lean more for they where to keep them in chase mode more often. Which I think just means to progress towards the player. OR to keep them from returning into there little coves they came out of.

When I did use the showobjects cheat the enemy and the chasepoints where the say color, probably indicating they are working to some extent. Later when I removed the chasepoints from the map the enemy object turned white.

[ETTiNGRiNDER]

Try an IMP since IIRC that's what uses them in the map where they were used. It's entirely possible that the game considers a NEWGUYBOW as different from a NEWGUY in some way.

[Corvin]

Just tried the IMP, sorta the same behavior. Maybe it just keeps them active, rather than turning off, keeps them in chase mode...

[ETTiNGRiNDER]

Well, shoot. I'll try to get a better understanding of the AI code at some point but for now I guess we file this as an unfinished/broken feature. Could be why they're not present in more places.

[Corvin]

Actually the IMPS are not even used in the area the chase points are located. Its just a room with little coves that open up to reveal the enemy. The points sit right in front of those coves.

Not sure where you got the "IMP's Using patrol points in a long hallway" I guess just bad info.

Anyhow I'm moving on to splitting doors, HORZ and VERT since the HORZ is mentioned in the manual, just no creation or description information.