[Loke]

Recently finished this map and after some testing I've decided to release it as it is. Started off as some sort of TROR experiment and eventually grew into a small, 5 minute'ish SP map.

http://msdn.duke4.ne...retaliation.php
http://www.scent-88....etaliation.html

HRP is completely untested. 8-bit runs best and it is what I built it in however TROR looks like garbage when viewed at certain angles so if you're annoyed by this run it in Polymer but expect poor performance if so.

[Mikko]

Nice little map! Took me 3,5 minutes. I'll play it again tomorrow properly in the 8-bit mode as Polymost had quite a number of visual glitches.

[zykov eddy]

Great map with a bunch of new ideas. Love the details and new TROR tricks. Although it's a small map, it feels like a step forward for a Duke mapping.
It would be nice if the player could access some of the buildings on the street.

[VinsaneOne]

zykov eddy, on 09 December 2011 - 06:19 AM, said:

Great map with a bunch of new ideas. Love the details and new TROR tricks. Although it's a small map, it feels like a step forward for a Duke mapping.
It would be nice if the player could access some of the buildings on the street.

All that plus it was way too short! More please.......

[Mike Norvak]

Played this map, it took me about 7 minutes without counting the time spent on looking at mind blowing parts, the map's length gives it a special touch, like a little gem. I voted great!

[Jblade]

I forgot to post feedback about this! Like the others said, it was a nice short enjoyable romp. I encountered some glitches in classic mode like you said but I didn't let it bother me. I can't really say too much about the gameplay since again it's a short map, but it was fun in anycase

If you do make another map with TROR, making the sections a bit wider would help since it did feel a bit cramped (although I had no real problems moving around)

[Helixhorned]

Nice map, only got to playing it now because I didn't know it's the same you posted screenshots of earlier. The big room is very well crafted but the other ones are a bit cramped.

There's a TROR issue fixable in the editor: here's an album and a link to an older post for why (well, it follows from the explanation, too lazy now to go into details).

I really hope this map gets proper hosting, since that link crashes my Firefox and it's not gonna stay there forever.

[Mikko]

Helixhorned, on 15 January 2012 - 03:13 PM, said:

I really hope this map gets proper hosting, since that link crashes my Firefox and it's not gonna stay there forever.

There already is a link for that: http://msdn.duke4.ne...taliation.shtml

[Mia Max]

The megaupload-link won't work anymore.



I'll test the map soon.
Need some inspirations, hehe.

[Loke]

Mia Max, on 22 January 2012 - 07:41 AM, said:

The megaupload-link won't work anymore.



I'll test the map soon.
Need some inspirations, hehe.

Either check Mikko's page or here.

[Mikko]

The link I posted is about to go obsolete in a few days so here's a new one (don't try to click any of the non-download links yet as they won't work they way they're supposed to): http://msdn.duke4.ne...retaliation.php

[Danukem]

I finally got around to playing this. Like everyone says, it's a nice little map. In fact, it has some of the best eye-candy of any map to date. I did encounter one little problem: I could not get the nuke button to work until I tried it about 50 times from a lot of different angles. Anyone else have that problem?

[Helixhorned]

Curious... neartag() picks up the MUSICANDSOUNDFX nearby instead of the NUKEBUTTON. I'm wondering if it's the same reason as for the other "hard-to-push-switches" glitches that you reported a while ago.

[Danukem]

Helixhorned, on 15 February 2012 - 02:53 PM, said:

Curious... neartag() picks up the MUSICANDSOUNDFX nearby instead of the NUKEBUTTON. I'm wondering if it's the same reason as for the other "hard-to-push-switches" glitches that you reported a while ago.

I don't know about other examples, but I can confirm that it was the cause in this case. I tested several times, and you cannot activate the nuke button facing it straight on. But after I deleted that nearby music sprite, it worked fine.

[Mikko]

Interesting to know, always wondered what causes some Nukebuttons to be hard to hit.

[rasmus thorup]

I just played this map, it was a little short, but that doesn't make the map itself worse at all. The map is simply perfect when it comes to looking good. The gameplay was great, but you a great amount of monsters in the map, so it wasn't too hard or too easy.
The only thing that annoyed me a bit, is that you made some of the areas too small to fit this game. Duke runs very fast, so it feels like the areas should have been bigger, even though they shouldn't. But that was mostly in the rooms without monsters, so great too

I also had the problem with the nuke button. I've had it a few times before, but never really thought about it. It's good to know what to look out for now

[Danukem]

The rule is: when the player is in position to use the nuke button, the button should be the closest thing to him that has a tag. So keep other tagged sprites away from the nuke button! And the same goes for other buttons and switches as well.

[Gambini]

That would had been handy for the "pushable from the outside nukebuttom" some people reported in my last map. In fact, it can be a good trick to put whatever tagged sprite between a glass and a switch so there´s no need to make that ridiculous safe distance for unaccessible switches.

[Danukem]

Gambini, on 15 February 2012 - 05:08 PM, said:

That would had been handy for the "pushable from the outside nukebuttom" some people reported in my last map. In fact, it can be a good trick to put whatever tagged sprite between a glass and a switch so there´s no need to make that ridiculous safe distance for unaccessible switches.

You might be tempted to use that, but it really is a bug and should be fixed.

[Helixhorned]

svn commit 2373 said:

engine: make neartag accept a sprite-blacklist function and use it in sector.c.

Internally, the last argument to neartag is now a pointer to a function
int32_t (*blacklist_sprite_func)(int32_t i),
which is supposed to return 1 if sprite[i] should NOT be considered for hitting.

This is now used in the hard-coded neartag() calls in sector.c, but not in any
way in CON (there's neither a C blacklist function provided, nor is there a
possibility to define one in CON). There, all sprites with picnums >=1 and <=10
(i.e. the effectors) will be blacklisted. This remedies problems where such
sprites would get in the way of switches.

Note that a whitelist approach (only consider a predefined set, namely those
picnums which will be checked afterwards) has back-compatibility implications
since people may have used e.g. lotagged window sprites to cover a switch.

Also, the >=1 to <=10 range is [sic] (the static, not dynamic values are used),
since anyone redefining effector picnums is clearly out of their mind.

Explanatory map attached.

Attached File(s)

•  neartagtest.zip (703bytes)
  Number of downloads: 264

[LeoD]

r2370 is a cool little goodie...

[Plagman]

Hmm, shouldn't neartag stay the same and a new flag / entrypoint be added that uses the blacklist function that adds non-BC behavior?

[Helixhorned]

My reasoning was that some mod might have wanted to hit effectors for some weird effect, but for maps it's almost certain to be unwanted.
edit: there's also no externally visible change introduced, i.e. CON neartag stays the same.

[Gambini]

Man that´s a very good fix but I´m 100% sure it will break quite a lot of old maps. You know, for 16 years mappers have been putting switches behind doors and other "tagged" stuff carelessly because it didn´t give any problem. Now those mappers´ maps won´t be passable because people will get stuck trying to press those, now unaccesible, switches.

In other words, I think it is too late to fix some stuff in Duke, people learned to live with these peculiarities and designers did their work in consequence. If it would be possible to start adding a new tag value like xvel yvel etc. So, new mappers/modders can acquit themselves well without the need of dealing with these ancient bugs. But fixing things right away, and for everybody, will only break other things.

[Danukem]

Gambini, on 20 February 2012 - 04:33 PM, said:

Man that´s a very good fix but I´m 100% sure it will break quite a lot of old maps. You know, for 16 years mappers have been putting switches behind doors and other "tagged" stuff carelessly because it didn´t give any problem. Now those mappers´ maps won´t be passable because people will get stuck trying to press those, now unaccesible, switches.

I don't follow your reasoning. Helixhorned's fix will make some switches easier to use which were difficult to operate before. It's not going to break any switches that were previously working. The only potential downside I see is the opposite problem. It may be that some switches were placed such that you had to be in a certain location to use them, and now they will work from all directions. I would like to actually verify that there is a map like that, though, before deciding that the fix is problematic.

[Gambini]

Yeah go ahead and check the one hundred thousand of user maps out there to see if now something works not in the way it was supposed to.

There are lots of "bugs" like this one:
respawn sprites not pasting their palette value in the respawned monsters.
Blockable sprites that make the player float even if they´re behind a blockable wall.
Sectoreffectors going outside their sector, damaging floors hurting the player even if he doesn´t stand on them.
Underwater sprites that make the player feel he´s outside of water.
Ceiling doors that if activated a lot of times will not update their respective SE8 sprites and a huge, massive etc.

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?).

There was a case when sprites outside the valid area would be deleted, and because of that, one of the best maps of all time (a map by roch) would have a glitchy carrousel because its mapper realized that it was possible to put a SE outside a sector, back then.

There are also quite a lot of maps (tens? hundreds?) that use that blockable sprite glitch to create ladders, if you fix that glitch, those ladders won´t work anymore.

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.

The list is countless. What is worse is that there are things like those of which most of us are unaware but still make one or other map unique. Fixing this dark stuff is bound to break some other old stuff. It does. Maybe you don´t care enough about regular usermaps being broken. But there are people that does, me included. And it is terribly disturbing to see such radical changes being performed without the enough care and backtracking investigation. No mapper worth their salt will leave a switch unoperable.

Helixhorned does great stuff but sometimes he requires advice and opinions. We, he ones left, base all these changes in our criteria, which isn´t perfect but it gets closer to be, when we look at the past and see the hows and whys.

[Paul B]

I agree with Gambini on this one

[Danukem]

Most of the stuff on that list is well known and not even considered a bug by anyone. No one is going to change that stuff. Take the ladder one, for example: everyone knows that flat sprites pop the player up and are used as ladders in many maps. On the other hand, you gave a good example of the "fix" that deleted sprites in null space, breaking some maps. I caught that one myself and it was reversed. That's something you should keep in mind: code is easily reversible.

And as for "no mapper worth his salt would have inoperable switches", that's simply not true, I have actually encountered very difficult to operate nuke buttons in several otherwise good maps. For example, the nuke button in OGGB. Sometimes a bug is just a bug.

So let's keep the discussion about the specific issue at hand.

[Gambini]

The implication is that this, as any other bug, is part of the game and should remain as it because the potential damage it can produce on old user content. This bug is as bad as the one that makes the ladders work, and as good as the one that lets the player take a breath underwater if he stands above a flat sprite. We should not draw the line between "well known" and "hardly known" issues. But more how they affect game´s functionality.

[Danukem]

Bugs get fixed all the time, and it is a necessary part of the development process. I think what you are trying to say is that we should not fix OLD bugs. I understand why you think that, but I believe that old bugs should be considered on a case-by-case basis. There are good, released user maps which are adversely affected by the neartag() bug right now. There are also people still making maps which could be adversely affected by it in the future. On the other side, there is the potential of there being some user maps where fixing the bug might allow a switch to be used in a position where it could not be used previously. Switches being used when they aren't supposed to be is a common problem in many maps, anyway, as you know. So on balance, it's not clear at all why we should forego fixing this particular bug.