[Gambini]

Quote

There are good, released user maps which are adversely affected by the neartag() bug right now.

No, they are affected by the sprites placement. Hell, maps are tested for something. And it is supposed that if there´s a switch that can´t be used in the way it should, the mapper will try to fix it. The only example that comes to my mind is when you put a switch on a spritework structure, usually the player has to kick the switch to make it work. Hence I assume it is because this neartag thing? Otherwise i have never had to deal with such a problem in my maps, so it is all about the mapper. And for the upcoming maps: Beware guys, do not put a tagged sprite between a switch and the point where the player is likely going to stand at the moment of using it.

That´s it. Maps where a switch can be used in the wrong way have a design flaw. Maps where a switch could be used in the wrong way because this fix do not.

[Danukem]

I agree that mappers are at fault for releasing maps with switches that are hard to use because of the bug. Yes, they should have tested more and realized that there was a problem. However, to say that "Retaliation" for example, suffers from a design flaw, which is what you just implied, is pretty ridiculous. The nuke button is in a place that should be perfectly useable, right in front of the player with no obstructions. The fact that it can't be used that way is due to a bug in the game (which I agree should have been noticed during testing), not a design flaw in the map.

Of course, even if mappers did discover the problem during testing, they would have had no idea how to fix it because it wasn't until a few days ago that it was discovered to be a bug in neartag(). And that's significant: in the other examples of mappers using bugs to their advantage, they actually knew about the bug and how it works. In this case, no one knew about it. So the likelihood of there being maps that depended upon the bug is pretty small. But if the change does turn out break maps, it can be reversed.

[Mike Norvak]

DeeperThought, on 20 February 2012 - 09:59 PM, said:

But if the change does turn out break maps, it can be reversed.

I wouldn't want to be negative about that specific point but there's a great difference beetween it can be and it will be we have learned that with previous EDuke tweaks.

[Danukem]

Norvak, on 20 February 2012 - 10:23 PM, said:

I wouldn't want to be negative about that specific point but there's a great difference beetween it can be and it will be we have learned that with previous EDuke tweaks.

Can we at least find one single map where the change causes a problem before changing it back? Just one map?

EDIT: And of course I mean an already released map that has not been updated recently, because I know Gambini wants to use the bug to fix something in "It Lives", and I'm sure he could whip up another map where it would be a problem.

[Gambini]

Quote

Can we at least find one single map where the change causes a problem before changing it back? Just one map?

I don´t have time to check the maps I think could be affected with two eduke32 versions. Also, there are a lot of maps I have not played, or simply don´t remember. Where switches are placed in tricky locations that relied on the game mechanics (which as been now changed). In the other hand. How many maps get benefit with this fix? Retaliation and ...?

Quote

Of course, even if mappers did discover the problem during testing, they would have had no idea how to fix it because it wasn't until a few days ago that it was discovered to be a bug in neartag().

A rule of thumb for when an effect doesn´t work: Isolate it. If it works the problem is with the surrounding stuff.

Quote

because I know Gambini wants to use the bug to fix something in "It Lives"

No, it´s not because of that. In fact it seems easier now to prevent the player to use the nukebuttom from the outside.

[Danukem]

Gambini, on 21 February 2012 - 05:46 AM, said:

How many maps get benefit with this fix? Retaliation and ...?

I have to leave for work, so I don't have time to do an investigation right now, but as I mentioned Operation Get Back Bike should benefit from it. Also I remember a map by Forge (not his latest map) which had a difficult to push button in an outdoor area near a boat, and there are various other maps whose names I can't remember at the moment. Also there are many maps where you have to kick or shoot buttons, and I wonder if those work with the open key now. We won't know until we test them.

[Helixhorned]

Gambini, on 20 February 2012 - 05:26 PM, said:

But these are very old bugs people have learned to live with, and therefore they took advantages too. There are at least 20 top quality maps that make the player start with no weapons because mappers discovered that if they put a hurting floor under a blockable sprite and the playerstart above them he will lose all weapons. Fixing that will break those maps (and what will it improve?).

That you start weaponless when on hurting floors is actually explicitly coded.

Quote

Lezing once realized that if you stretch a wall long enough the floor of the sector this wall belongs will have an unusual texture scale, he takes advantage of that.

This one's ugly because it presumably "relies" on integer overflow in the classic renderer's texture mapping functions. Overlong walls (blue in Mapster32) are really map corruptions. In the unfinished "kickass" map I posted, I had to remove them in the outline of the main area which you don't even see, because they were preventing some masked walls from being drawn.

Gambini, on 20 February 2012 - 08:03 PM, said:

Beware guys, do not put a tagged sprite between a switch and the point where the player is likely going to stand at the moment of using it.

Yes, that's intended neartag behavior and won't change.

Also, I don't consider the issue at hand a "neartag bug" because neartag itself is perfectly fine; it does what you ask it, namely get the nearest tagged wall/nextsector/sprite. It's more an oversight in its use (a special case), which is why the "fix" isn't inlined into neartag itself.

So, just to clear up things a little -- the change will only hit other objects when previously an effector would have been hit. Covering switches by lotagged sprites will work as before. Because I consider the probability of a mapper knowingly placing effector sprites to cover a switch (which moreover unlikely is robust) to be low in comparison to the benefits of the fix (effector sprites occur very frequently after all), I think it's an acceptable tradeoff.

[Forge]

Will this effect switches covered by either raising/lowering sectors requiring an activator or locked ceiling/floor doors? Usually the activator/lock sprite prevents the switch from being pushed while the sector is closed, and in most cases requires the player to shoot the switch once it's been exposed.

Just want to be sure I understand that a player will not be able to activate a switch through one of the said sectors before opening it.

[Helixhorned]

Hm, good concern. Do you have a map or ripped-out part handy that demostrates this?

edit: is there a raising/lowering effect that does not require the sector to be tagged? For example, in Scent.map, the ST28 of the lowering sector prevents pushing the button.

[Inspector Lagomorf]

Forge, on 21 February 2012 - 10:00 AM, said:

Just want to be sure I understand that a player will not be able to activate a switch through one of the said sectors before opening it.

This very glitch actually allows you to trigger the building detonation in E1L2 without using the access card by moving to the other side of the demolition box and pushing Spacebar against the bottom of the wall. I believe that you can also launch the rockets in E4L11 by pushing at the "LAUNCH CODE REQUIRED" panel at a certain angle too.

[Helixhorned]

Only two downloads of my test map ? It's pretty instructive about what neartag actually does, namely get the nearest sprite/nearsector/wall, which is why stuff like "hiding" switches in ST28 sectors works.

[Mike Norvak]

DeeperThought, on 20 February 2012 - 10:36 PM, said:

Can we at least find one single map where the change causes a problem before changing it back? Just one map?

I'm not talking about the neartag thing, I'm talking about eduke updates that in one or another way have changed the way maps looks/works, two examples that comes to my mind are the change of the shading system, both on polymost and 8-bit that affects dark maps/zones, the glitchy ornament on wall sprites on 8-bit mode for example, and other mapster tweaks, and I'm sure we could list more "meaningless" like those atm I don't remember, but c'mon this isn't some kind of random paranoia, if we have "scared" about those changes as mappers is because they have given us problems in the past.

[Forge]

Helixhorned, on 21 February 2012 - 10:27 AM, said:

Hm, good concern. Do you have a map or ripped-out part handy that demostrates this?

Not off the top of my head, but there are dozens of user made maps that make use of this effect in one form or another. Some use locked floor/ceiling doors others use raising/lowering sectors with activators. If you're going to be changing the properties of things I'd suggest just making yourself a couple small demo maps using these effects to see if they stop blocking access to concealed switches.

Helixhorned, on 21 February 2012 - 10:27 AM, said:

edit: is there a raising/lowering effect that does not require the sector to be tagged? For example, in Scent.map, the ST28 of the lowering sector prevents pushing the button.

you mean like raising/lowering sector that only require tagged SE sprites 31 & 32 ?

The Mighty Bison, on 21 February 2012 - 10:32 AM, said:

This very glitch actually allows you to trigger the building detonation in E1L2 without using the access card by moving to the other side of the demolition box and pushing Spacebar against the bottom of the wall. I believe that you can also launch the rockets in E4L11 by pushing at the "LAUNCH CODE REQUIRED" panel at a certain angle too.

pushing a button through an untagged sector is not the problem (that's a design error). being able to activate a switch through a floor/ceiling door or raising/lowering sector that's using an SE sprite, Activator sprite, Activatorlocked sprite, or Masterswitch sprite would be a problem if the sprite's characteristics of blocking a players use/push action is altered

[Helixhorned]

Norvak, on 21 February 2012 - 12:15 PM, said:

(...) the change of the shading system, both on polymost and 8-bit that affects dark maps/zones,

r_usenewshading affects only GL renders to make visibility look more like in 8-bit.

Quote

the glitchy ornament on wall sprites on 8-bit mode for example, and other mapster tweaks

You mean, [O] is buggy? Why wasn't this reported then? Also, the ornamentation should be renderer-indepentent.

[Danukem]

Norvak, on 21 February 2012 - 12:15 PM, said:

I'm not talking about the neartag thing, I'm talking about eduke updates that in one or another way have changed the way maps looks/works, two examples that comes to my mind are the change of the shading system, both on polymost and 8-bit that affects dark maps/zones, the glitchy ornament on wall sprites on 8-bit mode for example, and other mapster tweaks, and I'm sure we could list more "meaningless" like those atm I don't remember, but c'mon this isn't some kind of random paranoia, if we have "scared" about those changes as mappers is because they have given us problems in the past.

I understand that, and I have been bothered by stuff like that as much as anyone. I have actually spent a lot of my time in the past trying to identify problems caused by source changes and campaigning for them to be corrected. But Heilixhorned has been very good about listening to people and making the necessary adjustments to get things working correctly, so I don't think it's fair to bring up those past examples in the present context.

[Gambini]

@Helixhorned: What does actually this fix do?

I have tested your map with 2375 and 2344 side by side and performed the same operations in both and there was no difference at all.

[Helixhorned]

Norvak, on 21 February 2012 - 12:15 PM, said:

(...) and other mapster tweaks (...)

If you're hinting at how you couldn't drag sprites uphill in 2D mode, that's possible again, I just didn't post it here.

Forge, on 21 February 2012 - 12:50 PM, said:

If you're going to be changing the properties of things I'd suggest just making yourself a couple small demo maps using these effects to see if they stop blocking access to concealed switches.

There would be no point in me constructing a test map -- I know exactly what the change does. The question is whether there are existing maps that used the previous behavior knowingly to achieve a certain effect. If that is found to be the case, I could adjust things further (for example by providing an exception to the exception).

Gambini, on 21 February 2012 - 05:24 PM, said:

@Helixhorned: What does actually this fix do?

I have tested your map with 2375 and 2344 side by side and performed the same operations in both and there was no difference at all.

I thought I described it in great detail. The test map only serves to show that neartag finds the nearest object, and throws away any other potential candidates.

[Mark]

[quote name='Helixhorned' timestamp='1329935203' post='121285']
If you're hinting at how you couldn't drag sprites uphill in 2D mode, that's possible again, I just didn't post it here.

WOO HOO

[Hank]

butting in, to Loke's map, with all those details, wow. Times have changed for the good

[MetHy]

Nice little map. Great detailing. A bit cramped in some areas but enjoyed it all nonetheless.

[Helixhorned]

Norvak, on 21 February 2012 - 12:15 PM, said:

... the change of the shading system, both on polymost and 8-bit that affects dark maps/zones, ...

About this, I did in fact make a change that wasn't documented well and that could have broken things for some people. Basically, I discovered that visibility in the GL renderers wasn't independent of aspect (and maybe other similar parameters) and went on to patch that up. The result is somewhat messy -- constants were found out by experimentation -- but it does its job. I thought about bringing the old behavior back when playing with r_usenewaspect=0, but then one couldn't sensibly say "set r_usenewaspect to 0 and r_ambientlight to XXX" e.g. in a map readme, because it would look differently for different users.