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

What Is This Called and How Do I Get Rid of It?

Recommended Posts

These little lines occur quite frequently in my maps, usually (always?) in "random" geometry areas. Usually I can drag a vertex or two and they're gone, but some are more stubborn than others, and in some situations, the vertex is exactly where it needs to be. Different node builders seem to have an effect too.

 

Recently, it seems that I open a map without any of these, edit it some, and boom - they pop up in places that have been fine for months. 

 

Is there an easy way to correct this or prevent it? Is there a foolproof way to correct this or prevent it?

Grr.jpg.8d4d300487a334000083df7e923389e9.jpg

Share this post


Link to post
Posted (edited)

Please search the Doom Wiki for "slime trails". It's a renderer math calculation problem that occurs occasionally with diagonal lines. There's nothing wrong with your map, so there's no way to fix it. There's some hacky things you could do to the most offending lines, but not really worth it. Any true fix must happen engine-side. It changes each time you edit and compile the map, because the nodebuilder makes different choices as the map is changed. You cannot really control those choices deliberately.

 

The most effective "fix" is to slightly move the vertices where the effect is noticed most.

 

EDIT: Beaten to it :)

Share this post


Link to post

Thanks.

 

I've heard of slime trail but thought it was something different.

Share this post


Link to post

As has been stated, move vertices around to fix current slime trails. This will change the nodebuilding process. Do note that just as moving other vertices or adding new ones in can create distant slime trails elsewhere, moving other vertices may also clean them up, even if they do not border the trail itself or impact anything necessarily nearby. However, that stated, the closer they are the better, but as we make things that sometimes are so detail-dependent that the vertices can't be moved without texturing problems, it is very helpful to know that you can sometimes move more than just the 2 vertices bordering the line to fix a slime trail, especially if those 2 vertices are among those that cannot be proportionally moved from one-another.

 

Much of it also seems to come down to shapes of sectors, so a slime trail in, say, the bottom corner of a diamond-shape can sometimes be fixed by moving the top-most vertex, etc, even though doing so doesn't change the position or angle of the lines or "corner" that have caused the slime trail. By the same token, if some sector furniture is causing a slime trail, don't expect to shift over the entire thing by 1-pixel and fix it; the shape of the sector needs to be changed. I'm not entirely sure, but in the cases of 2-sided lines, you may even be able to fix a slime trail through either neighboring sector.

 

It is also worth noting that a slime trail will not always appear on a structure if you replicate it in another map, so it may come down to more than just interactions between the neighboring sectors, lines, and vertices. I guess it just comes down to how the nodebuilder tackles the map as a whole and as it enters the area with the slime trail. All of the things I mentioned will change the nodebuilders path, though, and can help, or fail, depending on the situation ;D

Share this post


Link to post
Posted (edited)

I get these all the time and usually sort them out during the final testing phase. If they aren't obvious I let it slide but if they're really ugly I remove them.

 

How to fix:

Test the level without monsters so you can walk around unharassed.

Find the 'slime trail' - I call it a bleed.

Note where it's coming from and in what direction it leads (this is usually a range of angles).

In the editor find the linedef that the slime trail comes from and note where you were standing when you saw it.

Draw a thin sector between the problem linedef and the player position. You can make this 1 unit thin so as not to interfere with the architecture. I call this a blocking sector.

Sometimes you need to select a different texture for the floor or ceiling (depending on where the slime trail leads). Sometimes you need to raise the blocking sector by 1 unit to work. Sometimes the blocking sector needs to be disconnected (i.e. not adjacent) to the problem linedef.

Test in game.

Sometimes you have to try several solutions until it works. Note, this is not the same problem as mid textures not being cut off at the floor or ceiling. That's a port parameter you can set to on or off.

 

There are other ways to remove the slime trail without adding a sector but it depends on your luck. Sometimes placing a vector on the problem linedef lets you move the slime trail to a direction the player won't stand in, effectively hiding it.

 

Here's a diagram:

Slime_trail.png

 

This can also be caused if you copy and paste a sector intersecting another sector and the resulting linedef indexes don't match the sectors they're supposed to. This can be fixed by correcting these linedef indexes.

 

Another solution is to place an architectural object (i.e. not a thing) in front to block it. Like a crate.

 

Oh, and another cause that's similar is when you have a hidden pit with no texture for the walls projecting downwards and intersecting two sectors (imagining the player could look through the floor). This does something to the game renderer that confuses it and can cause a large slime trail. Method to fix is same as above.

 

4 hours ago, Fonze said:

As has been stated, move vertices around to fix current slime trails. This will change the nodebuilding process. Do note that just as moving other vertices or adding new ones in can create distant slime trails elsewhere, moving other vertices may also clean them up, even if they do not border the trail itself or impact anything necessarily nearby.

The problem with this method is that any later edit that changes the nodebuilding process can recreate the slimetrail. The sector blocking method (although more effort) is more reliable.

Edited by alowe

Share this post


Link to post
4 hours ago, alowe said:

The problem with this method is that any later edit that changes the nodebuilding process can recreate the slimetrail. The sector blocking method (although more effort) is more reliable.

 

This is a problem with any method of crushing slime trails, however sector blocking (not sure if you mean:

 

4 hours ago, alowe said:

Draw a thin sector between the problem linedef and the player position. You can make this 1 unit thin so as not to interfere with the architecture. I call this a blocking sector.

Sometimes you need to select a different texture for the floor or ceiling (depending on where the slime trail leads). Sometimes you need to raise the blocking sector by 1 unit to work. Sometimes the blocking sector needs to be disconnected (i.e. not adjacent) to the problem linedef.

Test in game.

Sometimes you have to try several solutions until it works. Note, this is not the same problem as mid textures not being cut off at the floor or ceiling.

 

or:

 

4 hours ago, alowe said:

Another solution is to place an architectural object (i.e. not a thing) in front to block it. Like a crate.

 

) isn't always a viable way to fix them as the first method is dependent on even being able to fit a new sector in, which as slime trails are much worse in finer-detailed line-work, is not always even possible, let alone smart to do, and the second method is kinda like throwing your hands up and letting the slime trail win. Also, both of these methods can still very likely result in the slime trail reappearing later, same as any other method. The one thing you had right was waiting til the end to fix them.

 

4 hours ago, alowe said:

Note, this is not the same problem as mid textures not being cut off at the floor or ceiling. That's a port parameter you can set to on or off.

 

This sentence makes me really question a lot... This shouldn't be fixed by setting a parameter in a port. Midtexture bleeding is either a mapping error or a purposefully built effect and should always be solved on the mapper's end, not the player's end. Don't pass off the extra work laziness brings onto others.

Share this post


Link to post
Posted (edited)
29 minutes ago, Fonze said:

This sentence makes me really question a lot... This shouldn't be fixed by setting a parameter in a port. Midtexture bleeding is either a mapping error or a purposefully built effect and should always be solved on the mapper's end, not the player's end. Don't pass off the extra work laziness brings onto others.

So far when I've fixed a slime trail with a blocking sector it has always worked and the point is, even if the slime trail reappeares the problem is still fixed. Changing a vertex is not guaranteed to work since any other edit in the same map can undo that fix.

You're right about it letting the slime trail win, because you haven't really got rid of it, but my focus is on the player's experience. As long as the player isn't bothered by them, I can live with that slime trail being hidden :o)

PS A crate is the same as a blocking sector if that is why it was placed there. They're not mutually exclusive. The only reason I allow slime trails is if they are small (i.e. not top to bottom) and I've already got a complex area where adding a blocking sector might cause other issues.

Personally, fixing (or hiding) slime trails is a professional necessity. The last thing you want when someone reviews your wad is for someone to say it was good and all, but the design could have been better (because of the slime trails).

 

There's a parameter in MAPINFO to choose to automatically stop rendering mid textures where they intersect with a floor or ceiling. This might be ZDoom specific - I dunno. It's called ClipMidTextures. The default behaviour is to allow the mid texture to overwrite the flats. I've never come across a situation where you'd want a mid texture to overlap your flats but I still choose to manually cover my mid textures with blocking sectors because I cannot be sure the wad will be run in ZDoom (or a port that implements ClipMidTextures).

 

Sometimes people test my wads in other ports, so the closer to vanilla I can make it, the less likely there'll be any compatibility issues.

 

For example, here's a slime trail I've so far decided not to bother fixing:

 

Spoiler

Slime_Trail.png

 

Edited by alowe

Share this post


Link to post

Any fix is good, and your method can work in select scenarios (it can even cut off a slime trail from extending forever vertically, as you said, though the slime trail will extend through the sector(s) directly adjacent to it), but you also said yourself you're only blocking its view and haven't actually fixed anything. No method is a 100% fix without a chance of recurrence. The 2 biggest problems I see with this are: 1) as you said complex areas don't handle this method best and 2) adding in such a sector as a crate to more physically block LoS to the slime trail is going to change the flow of the area. Even something that small can drastically change the gameplay by giving a new spot for cover or making a cramped area more difficult to maneuver in, and to potentially alter the gameplay over something purely visual is just not smart at all in my opinion. Moving a single vertex 1-pixel right before the final map save is a much safer and complete way to do things, even in the event that they do come back, which from my experience the small majority do not after they've been solved.

 

This also comes from somebody who builds tiny boom sector worms and super-frankensteined sector furniture/geometry, so I too have a lot of experience fighting hordes of slime trails, and not always in places that can be easily altered or hidden away. But we've just a differing opinion on how much they need to be squashed it seems, and ultimately as long as they are not totally glaring, obvious things most people won't see them anyway, so any effort to reduce that is a good thing :)

Share this post


Link to post
Posted (edited)
9 hours ago, Fonze said:

(regarding using a port setting to prevent midtex bleeding:)

This sentence makes me really question a lot... This shouldn't be fixed by setting a parameter in a port. Midtexture bleeding is either a mapping error or a purposefully built effect and should always be solved on the mapper's end, not the player's end. Don't pass off the extra work laziness brings onto others.

 

9 hours ago, alowe said:

There's a parameter in MAPINFO to choose to automatically stop rendering mid textures where they intersect with a floor or ceiling. This might be ZDoom specific - I dunno. It's called ClipMidTextures. The default behavior is to allow the mid texture to overwrite the flats. I've never come across a situation where you'd want a mid texture to overlap your flats but I still choose to manually cover my mid textures with blocking sectors because I cannot be sure the wad will be run in ZDoom (or a port that implements ClipMidTextures).

 

Sometimes people test my wads in other ports, so the closer to vanilla I can make it, the less likely there'll be any compatibility issues.

MAPINFO, and its setting, "ClipMidTextures" is ZDoom-specific. Because you want multiple-port compatibility, you'll need to use a compatible method to get proper clipping.

 

If I'm not mistaken, the fix is to find the sector where the bleeding occurs, and change its properties slightly, do it differs from nearby sectors. For example, you can change that sector's brightness by 1 unit, and that is enough.

 

Technical reason (as much as I understand it): The problem occurs during visplane merging. When Doom prepares to draw flats, it examines all the sectors in the scene. If it finds multiple sectors with the same brightness, height, flats, etc., it merges the separate rendering steps into a single step, which usually helps renderer performance. But, the id guys never bothered to differentiate between different mid-textures. So, sometimes, the scene is rendered properly clipped, and sometimes not, depending on which sector, in a given view, happens to become the model for the merge process. Changing a property that the merge function will be actually checking on, is enough to ensure that it draws that sector by itself, with its own properties.

Share this post


Link to post
1 hour ago, Fonze said:

Any fix is good, and your method can work in select scenarios (it can even cut off a slime trail from extending forever vertically, as you said, though the slime trail will extend through the sector(s) directly adjacent to it), but you also said yourself you're only blocking its view and haven't actually fixed anything. No method is a 100% fix without a chance of recurrence. The 2 biggest problems I see with this are: 1) as you said complex areas don't handle this method best and 2) adding in such a sector as a crate to more physically block LoS to the slime trail is going to change the flow of the area. Even something that small can drastically change the gameplay by giving a new spot for cover or making a cramped area more difficult to maneuver in, and to potentially alter the gameplay over something purely visual is just not smart at all in my opinion. Moving a single vertex 1-pixel right before the final map save is a much safer and complete way to do things, even in the event that they do come back, which from my experience the small majority do not after they've been solved.

 

This also comes from somebody who builds tiny boom sector worms and super-frankensteined sector furniture/geometry, so I too have a lot of experience fighting hordes of slime trails, and not always in places that can be easily altered or hidden away. But we've just a differing opinion on how much they need to be squashed it seems, and ultimately as long as they are not totally glaring, obvious things most people won't see them anyway, so any effort to reduce that is a good thing :)

You're right that if I was modifying an existing mod, my options would be more limited, but since I am designing the level I can account for the consequences of the fix without introducing negative effects on the flow or design.

 

I stand by my claim that I can fix 100% of slime trails (from the player's perspective). I define a fix as not being able to see it in-game. The only reason I don't fix 100% of slime trails is because of laziness. There are times that it doesn't make a lot of difference so is hardly worth the effort fixing.

 

Anyone can send me a wad with coords and I'll prove it.

Share this post


Link to post
1 hour ago, kb1 said:

 

MAPINFO, and its setting, "ClipMidTextures" is ZDoom-specific. Because you want multiple-port compatibility, you'll need to use a compatible method to get proper clipping.

 

If I'm not mistaken, the fix is to find the sector where the bleeding occurs, and change its properties slightly, do it differs from nearby sectors. For example, you can change that sector's brightness by 1 unit, and that is enough.

 

Technical reason (as much as I understand it): The problem occurs during visplane merging. When Doom prepares to draw flats, it examines all the sectors in the scene. If it finds multiple sectors with the same brightness, height, flats, etc., it merges the separate rendering steps into a single step, which usually helps renderer performance. But, the id guys never bothered to differentiate between different mid-textures. So, sometimes, the scene is rendered properly clipped, and sometimes not, depending on which sector, in a given view, happens to become the model for the merge process. Changing a property that the merge function will be actually checking on, is enough to ensure that it draws that sector by itself, with its own properties.

MAPINFO is not ZDoom specific. The ZDoom specific mapinfo file is called ZMAPINFO. MAPINFO is generic. As for ClipMidTextures, that might not be ZDoom specific either. I got that from a non-ZDoom specific webpage but I'm being cautious. Just because ZDoom implements it doesn't mean other ports do, even if it is generic. My assumption is that if a wad is close to vanilla compatible then it should be stable with most ports. That's what I aim for, without any compromises on design.

 

There is no official fix because there is no office. So, the phrase "the fix" is misleading. Any fix will do as long as it achieves the goal of removing the slime trail from the game. I like the idea of changing the light by 1 unit though. Never thought of that. And it's an elegant solution because that wouldn't effect the design. But it won't work in every situation and any further edit of the map could randomly make it ineffective. This is why I use a sector blocking method.

 

As for changing the properties of an adjacent sector, that isn't always a good solution, because the slime trail will still be visible between the problem linedef and that sector. Sometimes this sector can be a long way off or there just isn't one in the right place. If you add a sector so that there is one in the right place then you've created a blocking sector.

 

Sector blocking isn't an elegant solution and it takes effort but it is more reliable than other methods since it isn't prone to being effected by map edits, meaning that, if you fix the slime trail and go away to work on the map elsewhere, you won't come back to find it has reappeared. It doesn't really matter what method you use as long as it works. So, if changing lighting works and the slime trail is not in the final version of the wad, then it's as good a fix as any for that one occurence.

 

Notice that none of ID's maps have any slime trails...

Share this post


Link to post
39 minutes ago, alowe said:

Notice that none of ID's maps have any slime trails...

E1m1_slime_trail.png

 

... y'quite sure about that?

Share this post


Link to post
Posted (edited)
23 minutes ago, Arctangent said:

... y'quite sure about that?

Weird, I can't get a slime trail there. What port are you using?

 

Edit:

Ha, you're right. I was able to recreate it. Never noticed it before.

 

Spoiler

Itbeslime.png

 

But notice that the slime trail ends as it meets the sector with the lower lighting. This nicely demonstrates what kb1 was saying but also demonstrates my response that the slime trail is still visible from the problem linedef to the blocking sector. When I fix these I place the blocking sector 1 unit from the problem linedef so that this doesn't happen.

 

In this example the player's attention is in the distance, either to the zombies or the imps on the ledge. Personally once I'd have noticed it, it would have bugged me until I fixed it. This for me would be a medium sized slime trail.

Edited by alowe

Share this post


Link to post
36 minutes ago, Fonze said:

 

I don't think you've understood at all what I was saying.

Every established mapper has battled with slime trails more times than they can count; there is nothing to prove but how big ur e-peen iz.

Then explain again or quote the relevant part. Otherwise you just have to accept that we're talking about different things.

 

e-peen. Is that the screen grab? Ya, I like to see as much as possible to maximise the player experience. Given that my laptop is just 15 inches I can get away with a full width display without having to move my head. If the screen was one of those uber wide ones, I might defer to the aspect ratio of the screeny Arctangent posted. It might look big to you but that depends on your physical screen size.

Share this post


Link to post

Assuming you're mapping for Doom-in-Doom format, you might find that BSP does a better job than other node builders in avoiding slime trails. Lee Killough added some heuristics years ago to try to avoid them and it helps. Nothing is perfect but maybe give it a try.

Share this post


Link to post

What port/s are you targeting? If you use ZDBSP's extended nodes, this should take care of a lot of them, though it will restrict the pool of compatible ports somewhat (Eternity, GZDoom, prb+ are still covered, though). 

Share this post


Link to post

@durian

@fraggle

 

Yes, BSP has worked best. I've never seen any such issues testing in GZDoom, but I'm referring to maps to be playable in limit-removing ports.

Share this post


Link to post
22 hours ago, alowe said:

MAPINFO is not ZDoom specific. The ZDoom specific mapinfo file is called ZMAPINFO. MAPINFO is generic. As for ClipMidTextures, that might not be ZDoom specific either. I got that from a non-ZDoom specific webpage but I'm being cautious. Just because ZDoom implements it doesn't mean other ports do, even if it is generic. My assumption is that if a wad is close to vanilla compatible then it should be stable with most ports. That's what I aim for, without any compromises on design.

There are efforts underway to create a generic, universal MAPINFO for interested ports, but, currently, MAPINFO is *very* port specific, as is the ClipMidTextures property. However, the "change the light by 1" method does, in fact, work in all ports, including vanilla. I suggested it, because you indicated your desire to create amps that work everywhere.

 

22 hours ago, alowe said:

There is no official fix because there is no office. So, the phrase "the fix" is misleading. Any fix will do as long as it achieves the goal of removing the slime trail from the game.

Office? You lost me there.

The phrase "the fix" is exactly what I meant. A "fix" would eliminate slime trails in all maps. What you describe is a "workaround" (nothing wrong with that, just saying.)

 

22 hours ago, alowe said:

 

I like the idea of changing the light by 1 unit though. Never thought of that. And it's an elegant solution because that wouldn't effect the design. But it won't work in every situation and any further edit of the map could randomly make it ineffective. This is why I use a sector blocking method.

I think you are confusing 2 issues and 2 solutions. The "change light by 1" method is to fix bleeding midtextures (where it looks like a midtexture dips into and below the floor). This has nothing to do with slime trails, which cause the ends of lines to bleed. The "change light by 1" method will do nothing to correct slime trails.

Share this post


Link to post
53 minutes ago, kb1 said:

The "change light by 1" method will do nothing to correct slime trails.

 

It actually might to some degree; in THT MAP19: BFG, one all of the worms were plagued with slime trails during development. However, as part of the way they work, they are surrounded by 4 (trigger) lines forming an insignificant sector. IIrc, I believe that one slime trail was so persistent that I did eventually change the light level by 1 in the insignificant sector surrounding each worm and find that it did "stop" or cut off the trail at the border between the insignificant sector and the larger sector/area surrounding them. I still fixed the trail before the final submission, but given that it was being compiled in a set, I left in the way to cut off the trails just in case.

 

I may be misremembering some details, but I want to say slime trails don't cross sectors with different properties well, so a small sector with different properties around a slime trail should at least make it vertically smaller? I haven't been able to spend much time in the builder lately so I'm starting to forget little things like that, especially being without the ability to look them up in-editor right now.

Share this post


Link to post

I have tried all of the methods described in this thread 100s of times. The only reliable method I've found is using a blocking sector. Other methods seem to work but then later the slime trails can come back. They often do. So even though creating a blocking sector is more work it's less effort in the longrun.

 

I know that bleeding midtextures and exposed hidden pits are not the same thing. I am not confused. But the method to fix these other things is also a blocking sector. Sure, you can use ClipMidTextures in MAPINFO but I don't like that solution because it is port specific.

 

I've not seen anything fundamentally new in this thread. People can use whatever method they like if it works for them. I'll continue using the method that works for me, That way everybody is happy.

 

Simplz :D

Share this post


Link to post
2 hours ago, Fonze said:

 

It actually might to some degree; in THT MAP19: BFG, one all of the worms were plagued with slime trails during development. However, as part of the way they work, they are surrounded by 4 (trigger) lines forming an insignificant sector. IIrc, I believe that one slime trail was so persistent that I did eventually change the light level by 1 in the insignificant sector surrounding each worm and find that it did "stop" or cut off the trail at the border between the insignificant sector and the larger sector/area surrounding them. I still fixed the trail before the final submission, but given that it was being compiled in a set, I left in the way to cut off the trails just in case.

Interesting. That makes me want to investigate them further right now (but I can't :)

 

42 minutes ago, alowe said:

I know that bleeding midtextures and exposed hidden pits are not the same thing. I am not confused.

I am. I was comparing bleeding midtextures to slime trails...What's an exposed hidden pit?

 

42 minutes ago, alowe said:

But the method to fix these other things is also a blocking sector.

It's a good workaround. Unless it causes another slime trail! Or, unless you're running up too close to a map limit.

 

42 minutes ago, alowe said:

I've not seen anything fundamentally new in this thread. People can use whatever method they like if it works for them. I'll continue using the method that works for me, That way everybody is happy.

I wasn't dogging your method, nor am I unhappy - again, nothing wrong with it. I was just providing clarification, in case you or someone else cared to know.

 

 

Share this post


Link to post
2 hours ago, kb1 said:

I am. I was comparing bleeding midtextures to slime trails...What's an exposed hidden pit?

 

It's a good workaround. Unless it causes another slime trail! Or, unless you're running up too close to a map limit.

I've never seen a situation where a blocking sector caused another slime trail. Sometimes they need to be tweeked to work but they always work. Other methods don't always work and any further edit can cause them to stop working.

 

I referred to exposed hidden pits earlier in this thread. Figured nobody read that bit. It's the post with the diagram.

Share this post


Link to post
11 hours ago, kb1 said:

I am. I was comparing bleeding midtextures to slime trails...What's an exposed hidden pit?

 

A sector lowered into the ground with no textures on its sides. These are most commonly used for monster pop-up traps, though the reflective water trick also works off of this same function. Much of the point of using this was made obsolete by boom's action 242, create fake ceiling/floor. When a lowered sector has no textures on its walls the game renders (software mode) its flat and light level across the whole space. The majority of this water sector in this screenie is a "hidden pit:"

 

8jpsm9s.png

 

I thought I showed you this befkre

 

12 hours ago, alowe said:

I have tried all of the methods described in this thread 100s of times. The only reliable method I've found is using a blocking sector. Other methods seem to work but then later the slime trails can come back. They often do. So even though creating a blocking sector is more work it's less effort in the longrun.

 

100s of times? Where are the maps you've made after these hundreds of slime trails? This has me insanely curious on how many you average per map, as well as how small of detailing you do to make so many appear.

 

On another note, if you map for zDoom (as evident by the clipmidtex flag) and are still plagued by slime trails maybe you should be looking into other node builders. ZDoom's node builders are much better at severely reducing the occurrence of slime trails. Not much need to worry about vanilla compat if you are already mapping for a format that vanilla does not support anyway.

Share this post


Link to post
Posted (edited)
1 hour ago, Fonze said:

 

A sector lowered into the ground with no textures on its sides. These are most commonly used for monster pop-up traps, though the reflective water trick also works off of this same function. Much of the point of using this was made obsolete by boom's action 242, create fake ceiling/floor. When a lowered sector has no textures on its walls the game renders (software mode) its flat and light level across the whole space. The majority of this water sector in this screenie is a "hidden pit:"

 

I thought I showed you this befkre

 

100s of times? Where are the maps you've made after these hundreds of slime trails? This has me insanely curious on how many you average per map, as well as how small of detailing you do to make so many appear.

 

On another note, if you map for zDoom (as evident by the clipmidtex flag) and are still plagued by slime trails maybe you should be looking into other node builders. ZDoom's node builders are much better at severely reducing the occurrence of slime trails. Not much need to worry about vanilla compat if you are already mapping for a format that vanilla does not support anyway.

I don't use the ClipMidTex flag. I just read about it on a non-ZDoom webpage. That's how I know it's not ZDoom specific.

You never showed me before. Must be thinking of someone else.

My maps are not yet released. I do a lot of fine work in some of them and this does increase the occurrences of slime trails.

I choose to aim towards vanilla compatibility in order to reduce the chance of port incompatibility (for all ports known and all possible future ports yet unknown).

I am not plagued by slime trails because I have a simple fix that always works. I've never felt the need to use any other port because ZDoom is exactly what I want. I try to avoid using Boom actions because 1), I don't use Boom, and 2) for other reasons given.

 

Let me see if I can find a screengrab (not an e-peen) of a hidden pit...

 

Here is the hidden pit in the editor, just so we can see exactly what is being talked about.

Spoiler

Hidden_Pit.jpg

 

And here it is in-game. This for me is not an acceptable slime trail (or whatever you wish to call it, exposed hidden pit etc). It will get fixed with a blocking sector when I do the final testing on the level and that blocking sector will not be visible to the player or negatively effect their experience in any way.

Spoiler

Ingame.png

 

Edit:

This is now the third day of follow-up posts after I posted about blocking sectors. I'm beginning to wonder if people have some issue with blocking sectors and I'm curious what that issue could be. Surely the only thing that is important is what works.

Edited by alowe

Share this post


Link to post
Posted (edited)
Quote

Edit:

This is now the third day of follow-up posts after I posted about blocking sectors. I'm beginning to wonder if people have some issue with blocking sectors and I'm curious what that issue could be. Surely the only thing that is important is what works.

When you claim that a potential engine-side fix for slime trails is not "an official fix", and simultaneously claim that the only viable fix is to Bondo your levels, and you present this claim to a forum full of expert mappers that have been successfully dealing with this issue for many years, maybe consider the possibility of expecting a differing opinion or two.

 

And, for three days: "Nothing wrong with your method."

Share this post


Link to post
Posted (edited)
8 hours ago, alowe said:

You never showed me before. Must be thinking of someone else.

You are failing to follow that my message was split into two parts for two different people; you and kb1. IIrc, I showed kb1 the reflecting water trick that was dropped from that map during development around the time I first met him, which iirc was when didy and I were still working on that map. That's what my comment was referring to.

 

8 hours ago, alowe said:

I choose to aim towards vanilla compatibility in order to reduce the chance of port incompatibility (for all ports known and all possible future ports yet unknown).

 

Saying vanilla compatibility is just misleading. While looking to see if you had uploaded any maps after my last post, I came across the titlepic thread you made. You said "vanilla compatibility" in that thread too, then said "well not really... hey it's not my fault if ppl cant read even though they are questioning the exact words i said" when somebody pointed out that zdoom, even if it's zdoom in doom format, doesn't equal vanilla compatibility and stating so will only confuse people.

 

I was gonna reply this there, but instead I'll just post it here because I don't really feel like having 2 discussions with you. I shouldn't even be perpetuating this with this post.

 

 

In addition to what Capellan said, which you blithely blazed over by quoting yourself from the very quote he replied to with the part of the quote he was addressing, it should also be noted, since you don't know, that chocolate Doom's main purpose is 100% vanilla emulation within modern windows, since modern windows cannot run vanilla Doom on its own. We can see how close chocolate is to the original .exe from the fact that it can both: play demos correctly and crashes under the same circumstances/limits. It is 100% safe to assume that if it runs correctly in chocolate, it will run correctly in vanilla as well. 

Combined with the usefulness of chocorenderlimits, I don't know of many modern mappers that do not test their genuine vanilla-compatible maps in chocolate in favor of only using the .exe through Dosbox, or an old machine running a vintage OS. This is choco's entire reason for existence.

 

8 hours ago, alowe said:

Edit:

This is now the third day of follow-up posts after I posted about blocking sectors. I'm beginning to wonder if people have some issue with blocking sectors and I'm curious what that issue could be. Surely the only thing that is important is what works.

 

Ummmm..... ok before I requote stuff to show that you do not read, let me ftfy: "the only thing that is important is that it works"

 

On 3/21/2018 at 7:30 PM, Fonze said:

Any fix is good,

 

On 3/21/2018 at 7:30 PM, Fonze said:

any effort to reduce that is a good thing :)

 

22 hours ago, kb1 said:

I wasn't dogging your method, nor am I unhappy - again, nothing wrong with it. I was just providing clarification, in case you or someone else cared to know.

 

So, good job on finding a way around those pesky things :)

 

That said, my hangup is your attitude. It is conceited, uninformed, and it just makes me want to avoid you. You phrase things like your method is the best, and in fact you got this started by claiming (repeatedly) that your method is the end-all definitive fix for all slime trails:

 

On 3/21/2018 at 5:31 AM, alowe said:

The problem with this method is that any later edit that changes the nodebuilding process can recreate the slimetrail. The sector blocking method (although more effort) is more reliable.

 

On 3/21/2018 at 9:04 PM, alowe said:

I stand by my claim that I can fix 100% of slime trails (from the player's perspective). I define a fix as not being able to see it in-game. The only reason I don't fix 100% of slime trails is because of laziness. There are times that it doesn't make a lot of difference so is hardly worth the effort fixing.

 

Anyone can send me a wad with coords and I'll prove it.

 

Nobody asked for you to prove anything, but you got one thing right!:

23 hours ago, alowe said:

I've not seen anything fundamentally new in this thread. People can use whatever method they like if it works for them. I'll continue using the method that works for me, That way everybody is happy.

 

Simplz :D

 

Unfortunately you also took the path of being a messiah claiming to have the only reliable path to nirvana in this same thread. I'm all for an open discussion on different ways to accomplish particular tasks/problems, but that's not gonna happen with your attitude. I'm done here.

Edited by Fonze

Share this post


Link to post

@alowe This isn't your thread. HAK3180 asked a question, and people provided answers and possible solutions, which are pretty much the standard solutions used by people for years. You replied with your own solution, touting it as superior, while calling foul on the standard methods.

 

You then seem to take a defensive stance, as if you were being personally attacked. I say this because you then make a lot of statements that either seem combative, or are out-of-context, or simply don't seem to make a lot of sense: Examples:

  • The MAPINFO, "ClipMidTextures" thing, which really doesn't apply to the OP's questions. You seem to oscillate between the position that it's either ZDoom-specific, or it's not. Because may people (including you, apparently) are concerned with highly-compatible maps, I felt it important to point out the fact that both MAPINFO (and its variants) and the "ClipMidTextures" flag are NOT compatible with the majority of ports.
  • I suggest that an engine-side fix for slime trails would solve the issue for all maps. You reply: "There is no official fix because there is no office. So, the phrase 'the fix' is misleading." Is the "office" thing a joke? What does that even mean? And, what is misleading about solving the issue for all maps? This seems combative...
  • In that same paragraph about slime trails, you elaborate about the midtex-bleed bug - a completely separate bug, as if it was a valid fix for slime trails. You appeared to be mismatching the two issues. Later, you do the same thing with hidden pits. These are three separate issues, which must serve to confuse the OP. It confused me. Yet, you said them with the utmost confidence, and proceeded to defend that stance.

My guess is that we have not been jiving on the terminology used. It's as if you went back and checked out some of these terms in the wiki, and started to agree with things you were originally disagreeing with, without admitting it.

 

Finally, you complain that it's taken 3 days to hash it all out. It would go quicker without the drama.

 

@HAK3180 The non-drama version:

  • Those vertical strips are slime-trails, caused by math precision errors during the node-build process.
  • There are some workarounds to reduce and/or eliminate them, including:
  1. Trying different node builders. Node builders are free to do their job in lots of different ways. Often, one node builder will work better on a particular map than others.
  2. Jiggling around vertices slightly usually reduces or eliminates the slime trails. It's best to do this at the end of the map-making process, because changing map geometry changes how the node builders work. Drawbacks: It's not an exact science, and may require a few tries, and may not completely remove all of them.
  3. Often, slime trails can be obscured by adding a similarly-textured sector in front of the slime trail. Drawbacks: This requires more map geometry, and may cause more (or less) slime trails to appear.

Share this post


Link to post
6 hours ago, kb1 said:

When you claim that a potential engine-side fix for slime trails is not "an official fix", and simultaneously claim that the only viable fix is to Bondo your levels, and you present this claim to a forum full of expert mappers that have been successfully dealing with this issue for many years, maybe consider the possibility of expecting a differing opinion or two.

 

And, for three days: "Nothing wrong with your method."

Ok lol, so it's not just my imagination that people are triggered. That explains a lot. Who knew that blocking sectors could be such a scandal lol

Share this post


Link to post

Not sure what you mean. I make observations. For example, *you* seem triggered. Which is strange, because #4: "Nothing wrong with your method". Again, less drama is an option.

 

I've done what I can to help answer OP's question, so I'm also done here.

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
×