[Forge]

as for ceilings lowered all the way to the floor; this method works for me every time:

get into squished sector, aim at "ceiling" and lock onto it with mouse, hit pgn dwn and the floor lowers

this leaves a gap where you can actually see instead of being in a kind of hom squished state. then you can lock onto the "ceiling" and raise it.

worse case you may have to lower the adjoining sector to give yourself some room if the target sector is too thin

[Paul B]

Helixhorned, on 12 November 2011 - 04:19 AM, said:

Just aim at a ceiling/floor door's wall, and holding LAlt (to affect the sector on the other side of the wall) and SPACE (to lock the aim), move the ceiling or floor as usual with (Ctrl+)PGUP/PGDN.

The functionality I am trying to achieve works when I mouse cursor at a squished sector wall and press and hold the LEFT "ALT" while i tap the "PGUP"/ "PGDN" to adjust walls vertically. I am actually starting to prefer this method a lot more! I was just so accustom to "PGUP"/ "PGDN" within a squished sector, like in build. Helix, once again... you've solved all my problems and I have been mapping all day in Mapster today! Thanks Man!!! =)

I appreciate it!
Paul

[Micky C]

A few of us have noticed that sprites cannot be dragged into other sectors if the floor of the sector is higher than the sprite's position. It's possible to get around this by highlighting the sprite with right shift, but is this a bug?

[Danukem]

Micky C, on 14 November 2011 - 04:45 PM, said:

A few of us have noticed that sprites cannot be dragged into other sectors if the floor of the sector is higher than the sprite's position. It's possible to get around this by highlighting the sprite with right shift, but is this a bug?

It has been that way for years now, I think. If the sprite didn't stop it would either have to go inside the floor of the next sector, or have its height changed to be on the floor of that sector. Either one of those could be desirable, or could be bad, depending on the mapper's intentions. No matter what the behavior is, someone is not going to like it.

[The Commander]

Yes, I am quite sure BUILD did this as well.

[Micky C]

Wow, in my entire experience with mapping, I've never seen that before. It always seemed like the sprite adjusted its height to the height of the floor.

[Mark]

That is my recollection also Mickey. Its a more recent thing.

ADDED: I went back to old project folders that have earlier versions from late 2010 and the glitch was not present. So it happened somewhere between 1743 and whichever newer version I installed a few weeks ago. Later today I will load a few random versions to try and narrow it down a bit. But it seems it's something I have noticed within the last month.

[Kyanos]

Between 1957 & 1973

It was set that sprite height would be equal from one sector to another, unless the sector being moved to was higher than original sprite height. Then it put the sprite on the floor.

[Paul B]

Drek, on 15 November 2011 - 08:39 AM, said:

Between 1957 & 1973

It was set that sprite height would be equal from one sector to another, unless the sector being moved to was higher than original sprite height. Then it put the sprite on the floor.

According to my previous experience this has always been like this, ever since the days of build. I have been mapping in build for a while and any time I ever wanted to drag a sprite which is lower than the sector I am moving it into I have to raise the sprite to the same level before it will allow me to drag it into the adjacent sector. I believe this bug you are referring to is actually a feature. That way your sprites are not embedded in some floor or ceiling so that you can't even locate the sprite.

[Mark]

I guess it depends on what you are used to. I started mapping almost 3 years ago and I'm used to not having to manually change sprite height before moving it between sectors of different heights. It would automatically detect the higher floor height and put the sprite there. I would like to see it go back to that.

[Stabs]

Yeh the sprite movement seems to be a bit odd

btw helix can the extended part not give a shit about ceiling height/floor height, just find the most common height and just extend around that, i really dont mind a bit of manually adjustment, finding one sector that accidently got raised is a bit painful sometimes.

[Helixhorned]

"Accidentally raised"? That all ceilings and floors of a particular bunch are at the same height is quite a central consistency requirement.

[Micky C]

I think he's saying that there are times when he wants to extend a group of sectors, but he can't because one or more of them are at a different height to the rest (and as you said they need to be at the same height to be extended), and that sometimes it's extremely difficult if not seemingly impossible to actually find which one is at a different height.

[Stabs]

Basically what micky said, when i work with ror i never touch the ceiling or floor i intend to extend from, sometimes by accident using rightmouse + mwheel i may end up raising/lowering one of these sectors, if there are 10 sectors with 9 at a height of 100 and one with a height of 98 it should just have the power to raise that one sector to whatever is the common height in the selection you wish to extend.

[Helixhorned]

With r2146, Mapster prints the sectnums of two non-matching sectors. Anything more automatic would be more trouble than it's worth.

[Stabs]

Can the texture alignment tool be enhanced to work vertically with tror layers?

[Helixhorned]

Something on my mind.

P.S. Now that +rep point was really undeserved for such a trivial change. I did in fact think about making smaller deviations ask for confirmation (like, a 2/3 majority is needed, at most 3 different heights are allowed, and the z difference is at most 512*16 units), but it seems like the current informational message is enough?

[Stabs]

anything has to be better than nothing, esp aligning rock textures up 7 layers

[Stabs]

Here is an odd request helix, is there some kind script you could make, a press and hold one that makes the player sprite tile appear where the cursor is at his proper in-game scaling when i release the key it will disappear , to help get the scale right within maps?

[Helixhorned]

I don't really have time to play with such stuff right now... kinda...
Nevertheless, an update to r2172 is highly recommended because there were some pretty bad bugs lurking which have been squashed there.

[Micky C]

Is there some kind of mapster feature which checks vertices to see if the walls they're connected to are parallel (i.e the wall is a continuous straight line), and not connected to any other walls, and then deletes those vertices? The TROR CBP really needs all the walls it can get at this stage, and if this feature only frees up a hundred, that would be a help. In addition, this function would probably be able to help a lot of larger maps in the future.

[Helixhorned]

 DanM, on 06 December 2011 - 05:31 AM, said:

Can the texture alignment tool be enhanced to work vertically with tror layers?

A prototype is now in r2178.

 Micky C, on 12 December 2011 - 12:41 AM, said:

Is there some kind of mapster feature which checks vertices to see if the walls they're connected to are parallel (i.e the wall is a continuous straight line), and not connected to any other walls, and then deletes those vertices? The TROR CBP really needs all the walls it can get at this stage, and if this feature only frees up a hundred, that would be a help. In addition, this function would probably be able to help a lot of larger maps in the future.

r2179's a.m32 state 'print_parallel_midpts' prints out the wall indices of the midpoint walls between two parallel segments. The interesting part is filtering out those you want to keep; right now you'll probably encounter many false positives due to TROR. Also, deletion would have to be done manually.

[Plagman]

Note that parallel walls can have a lot of value, so some of them you might want to keep. One is for Polymer lighting performance reasons, the other is that the core engine functions turn to become buggy once a wall is too long.

[Stabs]

Cheers that texture thing is a treat

a+++

[Micky C]

You're making me scared to use that script

But yeah props on the vertical automatic texture alignment, can't wait to try it out. 4 layers is a nightmare to allign by hand
Thanks again. Eduke is lucky to have such great developers

[Helixhorned]

 Plagman, on 12 December 2011 - 05:11 PM, said:

Note that parallel walls can have a lot of value, so some of them you might want to keep. One is for Polymer lighting performance reasons, (...)

Oh, why is that?

Micky, there's nothing dangerous about the script, all it does is some printing to the console -- you then [']+[j], [w] to the desired wall and drag that if you find that it's redundant. What I meant by "false positives" is the following: consider a sector that has (among others) 3 parallel line segments. Extend that sector, and in the original one, add a passageway connected to the middle sector. Then, the script would print out the two middle points of the extended sector's parallel segments, but you certainly want to keep them!

[Plagman]

If you have a huge plane lit by 10 lights, right now it gets drawn 10 times, so it's good to have some amount of subdivision.

[Stabs]

Flipping selected sectors with x is doing naughty things again

[Helixhorned]

Yeah, it was broken before, but the easy selection of all sectors of a bunch with RAlt+RShift made it pop up. I hope to fix that in the not-too-distant future.

[Micky C]

There are several instances in the CBP where enemies are in a sector, but part of them is sticking up into an above TROR layer. The parts of them that show in the above layer cannot be hit by weapons, and this seems to be the case for Duke as well, because he's 'invincible' against enforcers in a place where the TROR layer is a bit below waist height. This also happens with the final boss, which is so big that's impossible not to make him stick through into the next layer. I really hope that this can be fixed somehow, this is a very serious bug that can have dire consequences for the map.