Duke4.net Forums: End of level button SUCKS ! - Duke4.net Forums

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

End of level button SUCKS !  "Grrrrr"

#1

OK, I give in, how do you make the end-of-level nuke button work ?

As you can see in attached map, I've tried all sorts of things and the only nuke button that works reliably is the one sided one on the far right when hit from behind i.e. not visible ! Sometimes, other switches may work if you randomly jump/crouch/push/move-sideways whilst swearing profusely but it is damn difficult.

TTFN,
Jon

Attached File(s)


0

User is offline   Mark 

#2

I pulled my hair out a few times with those keycard readers in Decay acting the same finicky way. Just another small thing I learn to live with.

This post has been edited by Mark.: 31 December 2015 - 01:18 PM

0

#3

View PostMark., on 31 December 2015 - 01:16 PM, said:

I pulled my hair out a few times with those keycard readers in Decay acting the same finicky way. Just another small thing I learn to live with.


Yes, I've had trouble with those too. Anyhow, test map is just as bad in ye olde original Duke so I want to assume it's something I've done wrong.

Assuming it is a bug I wonder if it can be fixed in Eduke without affecting existing maps ?

TTFN,
Jon
0

User is offline   Danukem 

  • Duke Plus Developer

#4

That is messed up. I tried changing their size and raising them off the ground like the E1L1 button, and it made no difference. I also tried making them two-sided and shootable. Again, no difference.
0

User is offline   Paul B 

#5

View PostTrooper Dan, on 31 December 2015 - 02:22 PM, said:

That is messed up. I tried changing their size and raising them off the ground like the E1L1 button, and it made no difference. I also tried making them two-sided and shootable. Again, no difference.



Okay, I found the problem with your Nuke button. After running the map through my extensive home made Mapster troubleshooter program =D i've come to the conclusion the problem is from a blockable attribute on the Nuke button. Toggle the blockable bit and it will fix your problem. The proper low tag to use to end the level is 65535 for the button. (Sprite button can't be made blockable)

The real problem lies with the damn color scheme. Impossible to tell if the sprite is blockable or not. I wish they'd just restore the color scheme, its such a step backwards for Mapster.

This post has been edited by Paul B: 31 December 2015 - 03:53 PM

3

#6

View PostPaul B, on 31 December 2015 - 03:45 PM, said:

Okay, I found the problem with your Nuke button. After running the map through my extensive home made Mapster troubleshooter program =D i've come to the conclusion the problem is from a blockable attribute on the Nuke button. Toggle the blockable bit and it will fix your problem.


Well done that man ! I never thought to check the effect of the blocking flag as switches in general have that immensly annoying feature of automatically being made blocking during the game - but not so the nuke switch.

I wondered if by blocking it stopped the player getting close enough to operate the switch but no, it operates from quite some distance.

So, excitedly I looked to see if the same thing was happening with keycard switch which can also be infuriating at times - but no, that is always blocking. Oh well ... at least I can now end the damn level !

View PostPaul B, on 31 December 2015 - 03:45 PM, said:

The proper low tag to use to end the level is 65535 for the button. (Sprite button can't be made blockable)


The info suite mentions a number of values - 32767, 65534 and 65535. Guess I'd better check the standard levels to see what the real answr is.

View PostPaul B, on 31 December 2015 - 03:45 PM, said:

The real problem lies with the damn color scheme. Impossible to tell if the sprite is blockable or not. I wish they'd just restore the color scheme, its such a step backwards for Mapster.


In this instance it isn't to blame - I simply never thought that the blocking state was of any consequence.

rant()
{
But I totally agree that the colour scheme should be reverted back to the original. I've tried the mod posted a while back to try and restore the colours - damn, where is that post ? Anyhow, that mod at best gives you a dark purple so old gits like me cant read the text. I tweaked it to give bright purple (with a yellow border? nice ...) but it flashes red when the mouse goes anywhere near it.

return old_system;
}

TTFN,
Jon
0

User is offline   Helixhorned 

  • EDuke32 Developer

#7

View PostThe Mechanic, on 01 January 2016 - 01:54 AM, said:

I never thought to check the effect of the blocking flag as switches in general have that immensly annoying feature of automatically being made blocking during the game - but not so the nuke switch.

Yes, it is a bit unusual and I didn't know it either until now. The reason is that after having found the NUKEBUTTON using neartag(), the code goes on to do a hitscan(), and only if it arrives at a wall without overpicnum, proceeds with the level exit. Having the NUKEBUTTON be blocking prevents that :thumbsup:. (P_CheckSectors() in sector.c, "case NUKEBUTTON_STATIC", code is AFAICS unchanged from Duke3D, where the same behavior is observed.)

Quote

So, excitedly I looked to see if the same thing was happening with keycard switch which can also be infuriating at times - but no, that is always blocking.

This is more likely another issue that was at one time discussed from here on.

Quote

The info suite mentions a number of values - 32767, 65534 and 65535. Guess I'd better check the standard levels to see what the real answr is.

I think that any non-zero lotag would do, but these values are used as a convention so as not to conflict with the other tags in the map.

Quote

I've tried the mod posted a while back to try and restore the colours - damn, where is that post ?

Here.

Quote

Anyhow, that mod at best gives you a dark purple so old gits like me cant read the text. I tweaked it to give bright purple (with a yellow border? nice ...) but it flashes red when the mouse goes anywhere near it.

Check "set showpal 1" using a.m32. You need a headroom of four color indexes above the one you specify since the range for the periodic fading is [0 .. 4].
1

#8

View PostHelixhorned, on 01 January 2016 - 04:29 AM, said:

The reason is that after having found the NUKEBUTTON using neartag(), the code goes on to do a hitscan(), and only if it arrives at a wall without overpicnum, proceeds with the level exit. Having the NUKEBUTTON be blocking prevents that :thumbsup:.


Not sure I quite understand. In my example map it is literally NUKEBUTTONs - no mask walls or tagged sectors , just NUKEBUTTONs.

View PostHelixhorned, on 01 January 2016 - 04:29 AM, said:

This is more likely another issue that was at one time discussed from here on.


Now that may well explain the keycard switches responsible for a good portion of my main swear box's contents - they were planted on a complex rotate-rise sector(s). Shall investigate further but it makes sense - the test map in that disussion really helped.

View PostHelixhorned, on 01 January 2016 - 04:29 AM, said:

I think that any non-zero lotag would do, but these values are used as a convention so as not to conflict with the other tags in the map.


I checked up to e2l4 (at which point I got bored) and they use 65535 except secret levels of course, also they are all non-blocking (I used an earlier version of mapster :) )

View PostHelixhorned, on 01 January 2016 - 04:29 AM, said:

Check "set showpal 1" using a.m32. You need a headroom of four color indexes above the one you specify since the range for the periodic fading is [0 .. 4].


Indeed, I used "do set showpal 1". Trouble is, purple-that-can-cycle-to-bright only exists in the last 16 full-bright colours which don't have any headroom - as you said "... you can't really use the last 16 (fullbright) colors, only the gradual "ramps" of the Duke3D palette." So in tiles.cfg I used:

colors 139 244


So it is old fashioned purple for blocking and if I move mouse over the sprite sure it gets a bit phsychadelic but at includes bright colours which, being a blind old fart, help me read the text.

TTFN,
Jon

PS: For anyone using "showpal", you may find it easier if you remove the following code from a.32 (circa line 1449 last time I looked):

ifge tmp 240
{
  drawline16 xx
100 xx 200 -tmp
  add xx
1
  drawline16 xx
100 xx 200 -tmp
  add xx
1
}


This doubles the scaling above colour 240 which threw me for a while and it only clicked what was happening after tickmarks were added in r5428.
0

User is offline   Mark 

#9

I have been having trouble with activating switches in every single project I have worked on in the last couple of years.

I did more testing today in my DukePlus map. I tested in version 4575 which was in the folder and the latest version 5501. Same thing. It is very hard to impossible to find the sweet spot for clicking to activate the switches. Testing reveals that in this case switch height was the culprit. If you look at the closeup pic, that switch does not activate from any angle. If I raise it up 1 pgup unit in Mapster it works as it should. Same thing with the keycard reader switch and other door switches in the map. Height wise they have to be set so they are right at the middle of your screen when you walk right up against it to make it work.

Second issue is that you can activate switches from too far away using the "open" key. See the other pic.

Attached thumbnail(s)

  • Attached Image: duke1.jpg
  • Attached Image: duke2.jpg


This post has been edited by Mark.: 02 January 2016 - 05:54 AM

0

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC