Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
LanHikariDS

Manual sector hieght changes?

Recommended Posts

I was wondering, in ZDoom, is it possible to have it so the player could change the floor/ceiling height of the sector they're currently standing on at will during the game? I don't care if it has to be done as a weapon or as a separate control function, but I would like to take advantage of this, if possible.

Share this post


Link to post

As far as I know, it is not possible to get a "reference" to sector which the player (script activator) is standing on. Even if there was, action specials can only identify sectors by their tags, and what if the player's sector has tag 0, or another tag shared by multiple sectors around the map? There would be no way to separate the one sector that the player is standing on, and perform an action for that one sector only. And finally, even if the feature was possible to implement somehow, manual sector manipulation would easily reveal HOMs everywhere and behave strangely in areas consisting of multiple sectors, especially if multiple sectors were forming the same floor (or ceiling) for the sake of light variation or structural detail on the ceiling above the given floor (or floor below the given ceiling).

EDIT: My reply assumed that you wanted to manually control ANY sector that the player was standing on, anywhere and anytime during the game. If you merely want him to manually operate certain sectors on pre-determined places (for example lifts), the possibilities extend, but classic linedef-based activation is still the cleanest method of doing so.

Share this post


Link to post

That's an informational function, and only returns floor height as a number in fixed point map units. It doesn't let you identify a sector, nor manipulate it.

Share this post


Link to post
scifista42 said:

My reply assumed that you wanted to manually control ANY sector that the player was standing on, anywhere and anytime during the game.

scifista42 said:

even if the feature was possible to implement somehow, manual sector manipulation would easily reveal HOMs everywhere and behave strangely in areas consisting of multiple sectors, especially if multiple sectors were forming the same floor (or ceiling) for the sake of light variation or structural detail on the ceiling above the given floor (or floor below the given ceiling).

Yes I did.
I could figure that, but I built a map to be based around this (potential) principle of being able to adjust the sector heights. I wasn't going to use that as a 'cheat' for other WADs.

Share this post


Link to post

There are two components you have to work out to build something like this:

The first is you need to be able to get a reference to the specific sector to change like scifista42 said. Each sector you want to change will have to have a unique tag. That part is straight forward. However, you then need to trigger a script that knows the tag of the sector it's in. The only way I can see to do this is to activate a script with one of the sector action things. (You'll have to scroll that a bit). Each one can pass an argument with the correct tag for the script to activate. The very newest versions of UDMF claim to support multiple tags per sector, making the tagging part easier if you also want to have changeable sectors do some other thing. (If only SLADE supported that field...)

The second, more complex, part of this is you need to determine what the player is trying to do. Even if he can only raise/lower a floor or ceiling by fixed increments then there are four states he has to be able to invoke. The easiest way to play would probably be to give the player a weapon that shoots a different projectile depending on whether he wants to lower or raise a floor or ceiling. When one of those hits the floor it activates a script that checks its class and decides whether to raise or lower it. Same idea for ceilings.

Something like this feels straight forward to build as an example with a few sectors, but would be a nightmare with a complex map. My take on it would also mean running a script every time a projectile hits a floor or ceiling. It would also mean you don't have to stand in the sector being changed.

If you really want to build something like this, the map will have to be very clever for it to be any fun at all.

Share this post


Link to post
Aliotroph? said:

The easiest way to play would probably be to give the player a weapon...


No, it would be to use fucking switches.

In fact, I can't imagine any scenario entailing "sector height manipulation" that isn't modelable as either a lift/raising platform/dropping floor/crusher, switch-activated and even moving in tiny steps, if that somehow is required to create a special gameplay effect.

Share this post


Link to post

The map design (in terms of the parts you can see and click on) would be clunkier if you restrict it to switches. Being able to use a magic wand to crush monsters or create pitfalls in a running fight might be fun.

Moving floors around for some kind of puzzle area might be ok too, but more than the simplest interactions will slow down the game immensely. I agree that kind of thing is usually best done with switches.

Share this post


Link to post

If you really want to add a "dynamic", dramatic effect to a fight, you can use shootable switches to activate while you run, if you imagine the pistol as a "magic wand" ;-)

However from the entire thread, it seems surprising that ZDoom scripting cannot use the underlying engine functions that determine the player's position and apply a random effect to a specific sector directly.

Share this post


Link to post

It's a strange omission. There's no function to determine what sector an actor is occupying - not even one to determine the tag of the sector. There are functions for returning the light level or checking the flat name against a string.

Share this post


Link to post
Maes said:

If you really want to add a "dynamic", dramatic effect to a fight, you can use shootable switches to activate while you run, if you imagine the pistol as a "magic wand" ;-)

However from the entire thread, it seems surprising that ZDoom scripting cannot use the underlying engine functions that determine the player's position and apply a random effect to a specific sector directly.

I didn't plan it for a fight. I was going to use it as more of a puzzle-solving tool, and not have it move to a predetermined height.

Yeah, sadly.

EDIT: What if, instead of the game checking what sector the player is on, if I scripted the sector to detect whether or not the player is atop it, like a pressure plate? The pressure plate could raise up a flag, which would determine which sector(s) to move, then clear the flag when the player is no longer present on the sector.

Share this post


Link to post
Aliotroph? said:

It's a strange omission. There's no function to determine what sector an actor is occupying - not even one to determine the tag of the sector. There are functions for returning the light level or checking the flat name against a string.

Because actors actually have more than one sector, and exist in order of collision. It's pretty much nonsense in terms of static single references.
It's also even more nonsense as the map would have to be designed specifically for the effect, which means you already have ways to do it from the map design itself.
It's also possible for an actor to have no sector at all.

Light level is ridiculously easy because only one point of reference is needed: The same one rendering uses. Flat retrieval seems to use the same logic behind sector damage specials, and likely exists in relation to it.

Share this post


Link to post
Edward850 said:

It's also even more nonsense as the map would have to be designed specifically for the effect, which means you already have ways to do it from the map design itself.

Again, my map IS designed for it, but I don't have external triggers for the sectors to move without it.

Edward850 said:

Because actors actually have more than one sector, and exist in order of collision.
It's also possible for an actor to have no sector at all.

Well again, instead of the actor stating what sector(s) it's on, what if the sectors check whether or not the actor is on them?

Share this post


Link to post
LanHikariDS said:

Well again, instead of the actor stating what sector(s) it's on, what if the sectors check whether or not the actor is on them?

That is possible. Use ThingCountSector or ThingCountNameSector. However, this will still force you to give each sector an unique tag and then somehow determine which sectors to check for player's presence, or in the worst case check all sectors in the whole map one by one (which might hurt the game's performance).

Share this post


Link to post

Simply put, the potential for brokenness is far too great.

Okay so I raise the floor of my current sector a bit. It is now higher than the surrounding sectors (before it was level) and guess who never thought to put lower side textures around it? The map designer, yes! Okay, so now I have HOMs everywhere, cool. Now I'm lowering the ceiling, and look now this door doesn't work anymore. And now I'm fiddling with this one sector but wait this isn't what I wanted to happen, ah dammit this area is made of ten billion little sectors because the mapper detailed each grain of sand on the beach holy hell I'm never going to get this done.


Generally people who want to change sector properties "on the fly" make assumptions about the nature of sectors in Doom, assumptions that are completely false. First assumption is that all sectors correspond logically to a room, or one discrete area in a large room, second assumption is that all sectors have about the same size.

Share this post


Link to post
Gez said:

Simply put, the potential for brokenness is far too great.

Okay so I raise the floor of my current sector a bit. It is now higher than the surrounding sectors (before it was level) and guess who never thought to put lower side textures around it? The map designer, yes! Okay, so now I have HOMs everywhere, cool. Now I'm lowering the ceiling, and look now this door doesn't work anymore. And now I'm fiddling with this one sector but wait this isn't what I wanted to happen, ah dammit this area is made of ten billion little sectors because the mapper detailed each grain of sand on the beach holy hell I'm never going to get this done.


Generally people who want to change sector properties "on the fly" make assumptions about the nature of sectors in Doom, assumptions that are completely false. First assumption is that all sectors correspond logically to a room, or one discrete area in a large room, second assumption is that all sectors have about the same size.

Again, my map I made for this is being built around this principle of modifying the sector height. I don't expect to use it outside of my map.

Share this post


Link to post

Well then, you can try something like this:

1. Write an ACS library with 4 scripts: One will serve to lower floor below the player, one to raise floor below him, one to lower ceiling and one to raise ceiling. I will elaborate how to write them in point 5.
2. Use LOADACS to make the library accessible from multiple maps.
3. Now you have 2 choices how to let the player use the scripts:
3a) Use defaultbind in KEYCONF to bind executing the scripts to particular keys on the keyboard, for example IJKL. Writing this: defaultbind i "puke 101" - will execute script 101 when the player presses I, and so on.
3b) Define 4 new weapons (or 2 weapons with both normal and alt attacks) and let the player have them. Let the weapon's fire state actually not fire anything, but call ACS_ExecuteAlways instead, to call one of your scripts.
4. Give each sector in your map(s) a unique tag.
5. Now, let's actually write the effective scripts. What should they do:
5a) Temporarily change the activator's (=player's) TID to an arbitrary one, for example 999.
5b) Call ThingCountNameSector on multiple sectors to determine the tag of the sector on which the player is actually standing, use his TID 999 to identify him.
5c) Once it knows the tag, call a certain floor/ceiling moving action on the sector, depending on which one of the scripts it is.
5d) In the end, change player's TID back to 0. This is mainly to make the script usable in multiplayer when multiple players call the script at the same time.
6. Test and debug.

Share this post


Link to post
scifista42 said:

4. Give each sector in your map(s) a unique tag.

Is there any editor that can do this automatically? I have a little over 12,000 sectors ;-;

scifista42 said:

5d) In the end, change player's TID back to 0. This is mainly to make the script usable in multiplayer when multiple players call the script at the same time.

Thanks. I wanted to do multiplayer with this.

Share this post


Link to post
LanHikariDS said:

Is there any editor that can do this automatically?

I don't think so. (EDIT: Although the functionality - giving unique tags to each of selected sectors - sounds possible, I didn't succeed to do it in GZDoomBuilder)

Also, if you have so many sectors, you might need to implement some supportive algorithm to reduce the amount of sectors that need to be checked for player's presence at a time. If you used a naive algorithm - check ALL sectors in the whole map one by one - the game will probably freeze or at least lag heavily.

Share this post


Link to post
scifista42 said:

I don't think so. (EDIT: Although the functionality - giving unique tags to each of selected sectors - sounds possible, I didn't succeed to do it in GZDoomBuilder)

Also, if you have so many sectors, you might need to implement some supportive algorithm to reduce the amount of sectors that need to be checked for player's presence at a time. If you used a naive algorithm - check ALL sectors in the whole map one by one - the game will probably freeze or at least lag heavily.

Damn it

Share this post


Link to post

By the way, you said that you made your map while assuming that the player will be able to move any sector on his will, but the extreme sector count suggests that the design is either very specific (like a mega-grid), or inappropriate for the concept to work well. Out of curiosity, can you share a top-down view of the whole map in an editor?

Share this post


Link to post
scifista42 said:

Out of curiosity, can you share a top-down view of the whole map in an editor?

https://scontent-lax3-1.xx.fbcdn.net/hphotos-xpt1/t31.0-8/11234858_851062074992228_7683759710445739761_o.png?
The concept of the wad is that it's to be a map that can be edited during gameplay, with concept taken from terrain editing in the Far Cry 4 map editor. There are only 4 sectors the player isn't meant to modify, the edges, and those are blocked by lines flagged as impassible.

Share this post


Link to post

If the map is a pure and perfect square grid, and if you tagged all sectors in a predictable manner (ascendingly from left to right, top to bottom), you could relatively easily write an ACS function to determine player's sector tag based on his X/Y position discovered via GetActorX and GetActorY. This function would be fast, no sector actor checking would be needed, the coordinates could be directly calculated into a single number (=sector tag) using only addition, division and truncation in a special way. It still requires you to tag all the sectors to be able to move them, though.

Share this post


Link to post

What was the name of that editor that let you script editing functions? That always seemed like a neat idea, but not very useful for most kinds of mapping. This map is the one obvious exception I've seen.

Share this post


Link to post
LanHikariDS said:

https://scontent-lax3-1.xx.fbcdn.net/hphotos-xpt1/t31.0-8/11234858_851062074992228_7683759710445739761_o.png?
The concept of the wad is that it's to be a map that can be edited during gameplay, with concept taken from terrain editing in the Far Cry 4 map editor. There are only 4 sectors the player isn't meant to modify, the edges, and those are blocked by lines flagged as impassible.

Something to make the manual adding of unique tags less tedious (but still a bit tedious anyway):
First, select all sectors by columns, and give them tags 1, 2, 3, 4, etc. to the whole column.
Then select all sectors by rows (starting from the second), and give them tags in ++x, where x is the number of columns times the number of rows already processed this way. So if you have 128 columns in total, do ++128 on the second row, ++256 on the third, ++384 on the fourth, and so on.

This way you only get to edit properties X+Y-1 times instead of X*Y times.

Aliotroph? said:

What was the name of that editor that let you script editing functions? That always seemed like a neat idea, but not very useful for most kinds of mapping. This map is the one obvious exception I've seen.

SLADE 3 should let you do that, eventually, since sirjuddington integrated Lua into it for this purpose. I don't think it's fully working at the moment though.

Share this post


Link to post
scifista42 said:

If the map is a pure and perfect square grid, and if you tagged all sectors in a predictable manner (ascendingly from left to right, top to bottom), you could relatively easily write an ACS function to determine player's sector tag based on his X/Y position discovered via GetActorX and GetActorY. This function would be fast, no sector actor checking would be needed, the coordinates could be directly calculated into a single number (=sector tag) using only addition, division and truncation in a special way. It still requires you to tag all the sectors to be able to move them, though.

That may not be the best way, as I planned the player (In 'edit mode', achived by a separate playerclass) to be able to change their size, so instead of grabbing one 'tile' at a time, they could grab a square of 4 tiles, or 9, or so on.

Share this post


Link to post

I actually think it is the best way. It's a quick function to convert any world coordinates to a tag of the sector located on these coordinates. You can use the function in various ways, easily as a base for more complex functions and actions, such as "selecting" multiple sectors, in combination with plain mathematical / geometrical functions + some kind of "memory" in script variables. It will be fast and clean.

Share this post


Link to post
scifista42 said:

I actually think it is the best way. It's a quick function to convert any world coordinates to a tag of the sector located on these coordinates. You can use the function in various ways, easily as a base for more complex functions and actions, such as "selecting" multiple sectors, in combination with plain mathematical / geometrical functions + some kind of "memory" in script variables. It will be fast and clean.

Yes, but could I move adjacent sectors with separate tags with that? Each sector is 32x32, so actually creating something would be rather annoying, only being able to move one at a time

Share this post


Link to post

It sounds like you're not much skilled/experienced in programming and algorithmization.

Once you know a sector tag, and if all sectors are tagged in a predictable pattern, and you want to select for example a group of 3 sectors leading to the west from your sector, it's a matter of using mathematics. In this particular example, the algorithm would be something along these lines:

tag1 = myCustomFunctionToGetSectorTagFromCoordinates(x,y);
tag2 = tag1 + 1;
if(tag2 % numberOfSectorsInARow == 0) { tag2 = 0; tag3 = 0; }
else {
    tag3 = tag2 + 1;
    if(tag3 % numberOfSectorsInARow == 0) tag3 = 0;
}
And so on. As an ACS programmer, you can do anything with your scripts and functions and variables. Solving your given problems is a matter of using functions and variables in a way that leads to the desired effect. Sometimes you need to combine multiple functions to achieve the desired effect, for sure. A good programmer should try to find the fastest and cleanest ways. In your case, you can have an ideal environment for using geometrical functions: A grid of indexed cells (sectors). So why not take an advantage of the fact? It would be a shame not to.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×