[Hank]

High Treason, on 08 February 2012 - 12:20 AM, said:

It's not really causing problems anyway, because all I did was swap the first wall and slope the floor up instead. I am using the Polymost renderer. It behaves the same in-game as well.

Just thought I'd point it out on the off-chance that it actually is a problem that nobody noticed.

This is normal. I noticed that since 1998 and use it to make lasers invisible to the player and other diabolic traps.

[Micky C]

I tried adding some sectors to the ground floor of that SS sloped platform map, and I've run into the problem where sloped sectors can't be split, which is a fairly biggish problem if I want to add any detail to that map. In this particular case, I'm splitting the sector with a line parallel to the slope (perpendicular to the firstwall) so that the original TROR slope should be able to remain intact. However, I foresee problems with splitting sectors in other others, in which case will it ultimately be possible for this problem to be overcome by automatically splitting the sloped TROR sector as well (possibly after asking the mapper if that's what they want to do)? And while I'm requesting features, it's not a high priority but hopefully it's still on the to-do list to be able to create an island sector with ctrl-u from any set of sectors not just those which have been sector punched.

[Hank]

^ Are you referring to a sloped sector adapting the last drawn line as first wall? Every time you alter a sloped sector, the last drawn wall becomes the first wall of the sector. It would be nice if the 'first wall' of a given sloped sector stays as its first wall and only the newly drawn sector gets its 'new' asigned first wall.

[Micky C]

No I was talking about something TROR specific, but yes it would be very nice if a sector kept its first wall instead of always making the newest wall the firstwall.

[Danukem]

High Treason, on 08 February 2012 - 12:20 AM, said:

I'm not sure as to wether this is a bug or not - it probably isn't and is just a side-effect of the engine's inner workings, basically, I have a floor which slopes down, when I tried to place a switch and a few other sprites at one end of the sector, it disappeared (the cursor could still find it though) - took me a while to figure out that it was something to do with the floor height, as soon as a sprite (unless it is floor aligned) goes below that (the height of the highest point of the floor), it starts to disappear.

If this were a general problem, then enemies would be invisible on about half of sloped floors (the slopes where floorz is the top of the slope). But enemies are not affected, right?

[High Treason]

Enemies are unaffected. I deffinitely think it's normal behavior as opposed to a bug given that Hank has seen this happen as far back as '98.

I just figured I'd post about it to be sure though, as things I've ignored in the past (circle insertion problems for example) turned out to actually be bugs. But now I know it isn't, I can carry on knowing I'm not ignoring something that'll bite people in the ass later.

[Danukem]

High Treason, on 08 February 2012 - 11:05 PM, said:

Enemies are unaffected. I deffinitely think it's normal behavior as opposed to a bug given that Hank has seen this happen as far back as '98.

I just figured I'd post about it to be sure though, as things I've ignored in the past (circle insertion problems for example) turned out to actually be bugs. But now I know it isn't, I can carry on knowing I'm not ignoring something that'll bite people in the ass later.

There have been cases before where people (maybe even myself) claimed to have seen something back in the early days of Duke, but it turned out to be a recently introduced bug. So I would not rely on one person's memory. Moreover, it sure sounds like a bug that results from an over-simplified rendering criterion. There's no legitimate reason why sprites should be disappearing in this kind of situation, even if it has been that way forever. So I think you were correct to report it.

[Hank]

^ This is not a recent bug. Flat sprites simply do not get rendered below the bottom point. However, are High Treason and I the only one's in the community to have noticed that?

[The Commander]

I have seen this before and made use of the bug in MP for the trip mines.

[Hank]

 Cody, on 09 February 2012 - 05:42 AM, said:

I have seen this before and made use of the bug in MP for the trip mines.

Still, to get to Deeper Thought's point ...
The disappearance of flat sprites in a sloped sector below the bottom of the first wall happened(s) in the original Build, Mapster 0.4 and Mapster32 version around version 1870. Perhaps it was fixed once and reappeared.

[Gambini]

You guys are talking of a bug but actually that´s just one peculiarity of the engine. All mappers should be aware by now that if you plan to put a flat sprite on a sloped floor you have to slope it from the bottom line to avoid this thing to happen. In fact it is always recommended that sloped floors have their first wall at the bottom and sloped ceilings have their first wall at the top. The same peculiarity that produces this is also responsible of view alligned sprites being drawn even if they cut beyond the floor/ceiling plane (when sloped of course). It has been always like that and some maps make use of it. So another case where "fixing" would be more like "breaking".

There are a few differences facing what engine specifically you use.

[Gambini]

 Gambini, on 14 October 2011 - 06:46 PM, said:

Today Steam broke the Source tools so I felt like replaying my last map for Duke. It would have been funny to take a picture of my expression when I saw my beloved map and its best friend -the software renderer- broken. There are several clipping issues with sprites, more specifically: it occurs when sprites are very close to walls, they tend to overpass the wall and clip out in very strange shapes, even through the floor. I wonder whether this has something to do with Polymer or TROR but whatever reason it calls for a fix.

Here are some images attached, gay circles indicate the visual error. Just after taking these screenshots went to downloaded the snapshot from the time i released this map (1854 from 3-23-11) and tried to reproduce the same scenarios, same player position and all the other variables but the errors don´t occur.

http://i289.photobuc...1/soft_bug6.jpg

http://i289.photobuc...1/soft_bug5.jpg

http://i289.photobuc...1/soft_bug4.jpg

http://i289.photobuc...1/Soft_bug1.jpg

http://i289.photobuc...1/soft_bug2.jpg

http://i289.photobuc...1/soft_bug3.jpg

I post this here and not in "eduke32 and polymer" thread because i´m confident the only one who still plays around with the software renderer is Helixhorned.

This hasn´t got a solution yet, four months later. Remember it affects polymost and polymer too.

I wonder if there are other demotivated people like me that don´t want to map again because of this.

[Gambini]

script_expertmode no longer works, even when the console seems to accept the command. WTH

Ok, it seems to work but now sprites are updated once you move them.

[Helixhorned]

 Gambini, on 10 February 2012 - 07:06 PM, said:

This hasn´t got a solution yet, four months later. Remember it affects polymost and polymer too.

I wonder if there are other demotivated people like me that don´t want to map again because of this.

It's a classic-only issue happening only with r_usenewaspect set to 1. What DT considered the same bug in Polymost is actually an unrelated problem.

 Gambini, on 10 February 2012 - 09:17 PM, said:

script_expertmode no longer works, even when the console seems to accept the command. WTH

Ok, it seems to work but now sprites are updated once you move them.

You mean assigning "wrong" sectnums to sprites? This is probably r2110's fault, but since you say that it's still possible I don't consider this a bug. Doing "weird" things shouldn't be easy.

[Gambini]

 Helixhorned, on 11 February 2012 - 04:03 AM, said:

You mean assigning "wrong" sectnums to sprites? This is probably r2110's fault, but since you say that it's still possible I don't consider this a bug. Doing "weird" things shouldn't be easy.

Yeah it is not a problem TBH, it´s just that i had to get used to the new way. In fact it is safer now because i have to do that "weird thing" concientiously and also can run the script at mapster startup without having to worry of unforeseen consecuences .

Quote

It's a classic-only issue happening only with r_usenewaspect set to 1. What DT considered the same bug in Polymost is actually an unrelated problem.

Ok then why not making the r_usenewaspect thing be 0 by default? Why someone releasing a map meant to be played in sofware has to write pages warning their players to change that thing? thing that most players will ignore or not know how to do BTW. Legacy support/compatibility should be always the 1st priority.

Come to think of it, whoever takes advantage of the new "usenewaspect" feature is most likely doing a mod, in which case it is very easy for them to merely include an autoexec.cfg or whatever con code line that fixes it in their mod. the old "usenewaspect 0" is how Duke always looked like. Tons (and i mean Tons) of maps were designed when things looked the old way. And you are aware that what makes user maps the most played stuff in Duke is how simple to "install" they are. having to rely in more files, ergo a cfg file or a specifical eduke32 snapshot, simply spoils the fun.

[Helixhorned]

No, r_usenewaspect is a core feature, see the attachment for why there is need for it. It's not a legacy issue either because all there was back in the day is 4:3 fullscreen, while EDuke32 can be run with every imaginable aspect ratio.

I agree that the glitches suck, but don't worry, I'm already on my way to understanding the respective code.

Attached File(s)

•  asptest2.zip (282bytes)
  Number of downloads: 243

[Gambini]

Ok. Thanks for taking the time of explaining this to me. I still don´t understand why this can´t be disabled by default and/or why something so easily operable can´t be linked to the moment where the user switchs engines. Like making r_usenewaspect dependent of hardware accelerated renderers.

In fact, after checking your map i noticed this is even worse than I thought. It not only produces those glitches but also reduces the field of view considerably. Remember that, in software mode there are no aspect ratio options (with the exception of the hud, which somehow makes a difference).

I know you did a lot of great stuff for Eduke, so i´m sure you will address this problem soon.

[Helixhorned]

Well, fixed in r2341. I recall you mentioning something about making a new map?...

I can't imagine how r_usenewaspect would narrow the FOV with ratios greater than 4/3 (for that exact ratio, I checked, and it stretches the scene horizontally a bit), since it's supposed to always keep squares in the world squares on the screen (thus, larger w/h ratio --> greater FOV).

Also, it's supposed to be the aspect ratio option for classic and Polymost.

[Gambini]

Thats great to hear!

I just checked and everything is back to normal Thank you!

One last thing regarding your last line: I´ve been enabling and disabling the r_usenewaspect before and after this new submission for testing purposes. Does Eduke32 store the values i enter through the console in the cfg? I mean now I don´t know which one is the default and considering that now the problem is fixed in both instances usenewaspect disabled/enabled I´d suggest to make it enabled by default as it keeps the viewscreens FOV original.

Seeing your effectivity at the moment of solving this kind of issues I think i´m gonna dust off a few reports i made months (or even years) ago and nobody fixed.

Quote

I recall you mentioning something about making a new map?.

Yes of course, there´s something on the way. It is nowhere a map of such magnitude as It Lives was, but better than nothing

[Hank]

 Helixhorned, on 14 February 2012 - 03:42 PM, said:

Well, fixed in r2341. I recall you mentioning something about making a new map?...

Cheers; and thanks also.

[Paul B]

It's interesting how people can comment on the smallest of things and consider them to be show stoppers and yet they seem very immaterial compared to some of the more critical engine flaws where things actually just don't work. Such as mentioned below:


1) Breakable glass isn't breakable on a TROR ceiling or floor surface.

2) Very frequently when loading a .map from within mapster or changing the transparency of a TROR surface or deleting & creating sectors or copying and pasting using shift enter all these actions seem to introduce a random problem where all TROR tile surfaces will loose their assigned texture where a SE 13 has been placed in that same sector. To work around this problem i've had to quit mapster not save the changes, load mapster and check to see if the TROR surfaces have kept their tile. If not, I exit mapster and try loading the map again. If the texture is retained by checking the textured sector after the load I keep working on the map while periodically checking to make sure the sectors don't loose their tile texture associated with them by passing the mouse cursor over top of the TROR tile to make sure it shows the proper tile associated to it and not the default ugly brick tile. The palette information on the TROR sector surface seems to be retained though.

This has been a very frustrating bug while editing the parkade.map because i've had to make over 1000 copies of the map to make progress with editing while trying to avoid having to manually go back and retexture these sectors which is very time consuming. There is no easy way to pin point the exact cause of what brings this on as it appears randomly while editing the map or just loading the map and it appears to be something that is internal to the mapster code.

3) Having a button switch or a door border a TROR sector wall... Neither the door or switch will function if its too close to the TROR sector wall. The door and the switch will behave like it has no lowtag associated to it from the direction closest to the TROR wall. Making these doors only open and function from the side furthest from the TROR wall. This is another problem and while creating the parkade.map these were obstacles we've had to work around.

4) Also i've noticed that some TROR surfaces while they are invisible and pass through able Duke can still get caught on these invisible TROR sectors and its not a smooth transition from one TROR sector to another. NOTE: This occurs when using slopped TROR sectors ceilings and floor walls..

5) Also as mentioned previously, enemies which might extend into a different TROR sector area because of their physical size are not hitable in the TROR sector they aren't initially located in.

6) Also any sprites that are laying or touching a TROR sector even though they are blockable Duke will still pass through the sprite as the sprite seems to lose their blockable attribute when they are touching a TROR ceiling or floor sector wall.


Anyway, i'm sure there's more frustrations that can come to mind, but at the moment i can't think of any.

[Micky C]

Is there some autoalligning function for walls/ceilings that automatically lines up textures in different sectors which have their relativity bit set and have parallel first walls? I tried doing it by hand, but it's taking an excruciatingly long time, and I can never get it to look quite right.

[Lord Misfit]

This bug actually applies to both EDuke32.exe and Mapster32.exe, [at least that's what TX tells me about the input layer being shared], but some long time back, the ability to use the Caps Lock button in the consoles disappeared. TX said something about it using raw input since a certain long-ago revision, and saying something would have to be programmed in there for support of the Caps Lock function again.

I'd have brought this up much much sooner had I not been having so many other things keeping my attention, but the reason I ask for this to be "fixed" is because I generally use the "setvar" family of commands in eduke32.exe for testing stuff for my mods and vars are a case sensitive thing. Holding down shift and trying to enter the vars with one hand for the most part isn't nearly as efficient as being able to simply toggle caps lock like I used to be able to.

And yeah, I was told by TX to write about this in here, in case anyone else thinks to complain. o.o Sorry all, but I think it's time I remembered to put knowledge of this little issue out there so it can be dealt with as soon as possible. x.x

[Helixhorned]

 Paul B, on 14 February 2012 - 11:16 PM, said:

2), 3), 6)

Fixed . Points 3 and 6 were new to me.

Quote

4) Also i've noticed that some TROR surfaces while they are invisible and pass through able Duke can still get caught on these invisible TROR sectors and its not a smooth transition from one TROR sector to another. NOTE: This occurs when using slopped TROR sectors ceilings and floor walls..

Can you post a map that demonstrates this? I assume you don't mean the same glitch as when ascending a "ladder" in Retaliation? (which still exists)

[Paul B]

 Helixhorned, on 16 February 2012 - 01:49 PM, said:

Fixed . Points 3 and 6 were new to me.


Can you post a map that demonstrates this? I assume you don't mean the same glitch as when ascending a "ladder" in Retaliation? (which still exists)

I have been venting my frustrations through Micky, God bless his soul for putting up with me and when he got tired of hearing me complain I decided to publicly post my findings. Thank you very much for addressing most set backs. I am looking forward to testing it out tonight.

As far as the 4th point goes, this will be impossible for me to capture with a screenshot because the problem only occurs when Duke is in motion, while jumping or jet packing through a TROR extended sector. I don't believe this has anything to do with the Retailiation.map and it definitely has nothing to do with ascending any ladders.

This problem is most noticable when flying around the TROR skywalk in parkade.map passing through extended sectors. Or jumping over to the skywalk from the vent. There is a hitch or invisible wall that duke hits and eventually it allows him to pass through by backing off and going forward several times. I am pretty certain it has to do with entering an extended sector that has both a floor and celing slope to it. Duke seems to hit the sector and stop dead. It acts very much like an invisible blockable wall but after a few times of going backwards and forwards it lets Duke pass through.

Also, another problem which comes to mind is when playing the Parkade.map I have noticed that there's the odd time when Duke actually passes through the floor and is unable to jump or walk up any small steps or move around properly. It is very much like the sector inherits a lowtag of 1 as if Duke were in water but he's not or it's like Duke is stuck in miniature mode and it happens really randomly and its a rare occurrence. Duke is also unable to jump when this happens and it forces the player to stop playing the map and reload from the start because nothing the player can do can correct the problem.

I'll pay more attention to this glitch tonight and i'll see if I can't reproduce it consistently so I can have a better description of what brings on the problem.

Thanks!!!! Paul

[Micky C]

 Paul B, on 16 February 2012 - 03:26 PM, said:

As far as the 4th point goes, this will be impossible for me to capture with a screenshot because the problem only occurs when Duke is in motion, while jumping or jet packing through a TROR extended sector. I don't believe this has anything to do with the Retailiation.map and it definitely has nothing to do with ascending any ladders.

This problem is most noticable when flying around the TROR skywalk in parkade.map passing through extended sectors. Or jumping over to the skywalk from the vent. There is a hitch or invisible wall that duke hits and eventually it allows him to pass through by backing off and going forward several times. I am pretty certain it has to do with entering an extended sector that has both a floor and celing slope to it. Duke seems to hit the sector and stop dead. It acts very much like an invisible blockable wall but after a few times of going backwards and forwards it lets Duke pass through.

That's because I used some small scale TROR scissoring in order to have a gap between the catwalks. Having TROR boundaries that close together is never a good idea and is bound to cause clipping issues.

[Paul B]

There are two things that make me happy in life. 1) Oreo cookies with vanilla icecream and 2) Helixhorned's Eduke Fixes! Thanks a lot man!

[Helixhorned]

 Gambini, on 14 February 2012 - 07:56 PM, said:

One last thing regarding your last line: I´ve been enabling and disabling the r_usenewaspect before and after this new submission for testing purposes. Does Eduke32 store the values i enter through the console in the cfg? I mean now I don´t know which one is the default and considering that now the problem is fixed in both instances usenewaspect disabled/enabled I´d suggest to make it enabled by default as it keeps the viewscreens FOV original.

Yeah, a non-default r_usenewaspect is stored in settings.cfg. The default is on.

BTW, I think I understand why you were/are getting a wrong ratio with this feature. In fullscreen mode, you're supposed to set the r_screenaspect to your physical screen width/height ratio (in the form WWHH), since you might be playing with a resolution where pixels aren't square (in windowed mode, the assumption is that your desktop has native resolution). You probably have the default of 0403, which is why you're seeing a narrow FOV. I know I need to make this stuff visible from the menu since it's probably not easy to find this way...

 Micky C, on 15 February 2012 - 05:47 AM, said:

Is there some autoalligning function for walls/ceilings that automatically lines up textures in different sectors which have their relativity bit set and have parallel first walls? I tried doing it by hand, but it's taking an excruciatingly long time, and I can never get it to look quite right.

There is none at the moment, but it should be doable for sectors with parallel or orthogonal firstwalls.

[Gambini]

No problem with that Helix. I have a 1920x1080 screen and play Eduke32/use Mapster32 in 1280x1024 in windowed mode, all in software of course. The aspect ratio is correct and i have plenty of screen space to watch porn while playing. For those days i use Polymer/ost i go fullscreen and put the aspect in wide or 1.666.

BTW i have no choice since software mode crashes in fullscreen since a couple of years, and that´s a widely known problem all players i talked to suffer.

[Helixhorned]

 Gambini, on 18 February 2012 - 06:14 AM, said:

BTW i have no choice since software mode crashes in fullscreen since a couple of years, and that´s a widely known problem all players i talked to suffer.

Is this the known Alt-TAB problem or something else? I'm routinely playing Duke in 1680x1050 software mode with no problems. (I'm doing this in windowed mode without window borders though). Also, classic's non-slope ceiling/floor texturing functions go wild with very wide aspects and large up/down looking angles, but for me it's only manifested in "noise" textures.