[Micky C]

Helixhorned removed them for some reason... not sure why... it would be nice to know.

[Paul B]

Suspect I found a problem with SE 12 and wall palettes...

My Mapster version is 3241
Please see the attached file which is a demo map of a single room with the bug.

In the map notice the wall has a palette of 15. (Brown walls). Flip the light switch.... the room is illuminated with (Brown Walls).So far so good
But flip the light switch again to turn off the lights and notice that the wall palette isn't restored to palette 15 it is gone and now there is no palette when the lights are off.

Any suggestions?

I haven't seen Helix around in the last week or so I hope he's still around.

Attached File(s)

•  lightbug.zip (1.98K)
  Number of downloads: 310

[Helixhorned]

This is really a game effect limitation and has no relation to Mapster32. Right now, you have to live with it, but it might be addressed in the future.

[Paul B]

 Helixhorned, on 27 November 2012 - 12:09 PM, said:

This is really a game effect limitation and has no relation to Mapster32. Right now, you have to live with it, but it might be addressed in the future.

I wasn't aware of that.. Thank you for your time Helix! I'm glad to see you're still around =)

[Micky C]

So what's the deal with the auto texture alligning feature not alligning textures over windows and things? It works in all cases except over window-like holes in the wall where both the ceiling and floor height are different from the adjacent sectors. It aligns the bottom but not the top.

I know it's a fairly complicated thing because I remember reading textures work differently in those situations over the 3 renderers but I can't get it to work in any of them. It's a fairly annoying problem because it means loads of work doing tedious repetitive allignment. And sometimes you have to do everything all over again if you want the walls alligned differently.

[Paul B]

 Micky C, on 11 December 2012 - 04:18 PM, said:

So what's the deal with the auto texture alligning feature not alligning textures over windows and things? It works in all cases except over window-like holes in the wall where both the ceiling and floor height are different from the adjacent sectors. It aligns the bottom but not the top.

I know it's a fairly complicated thing because I remember reading textures work differently in those situations over the 3 renderers but I can't get it to work in any of them. It's a fairly annoying problem because it means loads of work doing tedious repetitive allignment. And sometimes you have to do everything all over again if you want the walls alligned differently.

I've noticed that too.. Say Micky, since you map quite a bit have you noticed any thing funny going on with copying and pasting textures using TAB + Enter or Shift Enter to copy the shading information to other walls? Or is it just my PC that's fuxored? What i've noticed is on smaller new maps I don't experience any problems until my maps get fairly detailed with lots of walls then i run into issues and need a tissue.

Or lets say I'm aligning a wall texture and I am holding the shift key down while pressing down. If I continue to hold the shift key down and lock to a different wall and press down it stretches the tile instead of moving the tile. Sorta like it forgets that i'm holding shift. So I have to let go of shift and press shift again before it takes effect. Just an annoyance I am having. I suspect its all related.

 Micky C, on 11 December 2012 - 04:29 PM, said:

Nope I haven't noticed that. Then again you can't get mapster working on windows 7 (which is what I use it on) so you're probably doing something wrong

Ah you bugger! LOL! =)

[Micky C]

Nope I haven't noticed that. Then again you can't get mapster working on windows 7 (which is what I use it on) so you're probably doing something wrong

[Mike Norvak]

 Micky C, on 11 December 2012 - 04:18 PM, said:

So what's the deal with the auto texture alligning feature not alligning textures over windows and things? It works in all cases except over window-like holes in the wall where both the ceiling and floor height are different from the adjacent sectors. It aligns the bottom but not the top.

I know it's a fairly complicated thing because I remember reading textures work differently in those situations over the 3 renderers but I can't get it to work in any of them. It's a fairly annoying problem because it means loads of work doing tedious repetitive allignment. And sometimes you have to do everything all over again if you want the walls alligned differently.

Yeah it was like that over a year or so, it is really annoying indeed.

[Mike Norvak]

Visibility 240 doesn't work anymore. Visibility values were changed. Now maps with that value looks black-pitched while it should look just dark but still visible at long distance.

I´m using r3266

The change was introduced in r1943

Quote

* New shade/visibility calculation code, which is activated with 'r_usenewshading' (on by default), and is closer to the classic look. Also tweak the FOGSCALE macro to have approximately the same fog distance with all renderers.

This is how it looks with r1942 and Polymer (just before the change was introduced):



This is how it looks with r1943 and Polymer (after the change was introduced):



For Polymost is the same.

This is how it looks with both r1942 and r1943 with Classic 8-Bit mode:



As it should look like in both Polymer and Polymost.

It is possible to revert it to the correct behavior?

It is important to note that visibility should become darker and darker from 1 to 239, so 239 = vis 0% and then 240 to 255 ≈ 100% visibility just like always have been.

Thanks in advance

EDIT: So reading the quote, I noticed turning off "r_usenewshading" is the solution, but should it be on by default in the first place?

[Mike Norvak]

Sorry for triple post. :S

 Micky C, on 11 December 2012 - 04:18 PM, said:

So what's the deal with the auto texture alligning feature not alligning textures over windows and things? It works in all cases except over window-like holes in the wall where both the ceiling and floor height are different from the adjacent sectors. It aligns the bottom but not the top.

I know it's a fairly complicated thing because I remember reading textures work differently in those situations over the 3 renderers but I can't get it to work in any of them. It's a fairly annoying problem because it means loads of work doing tedious repetitive allignment. And sometimes you have to do everything all over again if you want the walls alligned differently.

Maybe you can find where the change was introduced and post screenshots of how it was before, and even an example map. I can't reproduce the bug right now.

Someone remember which was the last synthesis to work correctly? maybe before TROR was introduced?

[Hank]

 Norvak, on 11 December 2012 - 06:53 PM, said:

Visibility 240 doesn't work anymore. Visibility values were changed. Now maps with that value looks black-pitched while it should look just dark but still visible at long distance.

Here is my lighting test map - in the back ground is a 240 visibility sector.
Done just right now with last weeks EDuke/Mapster set.

[Mike Norvak]

 Hank, on 11 December 2012 - 08:04 PM, said:

240HRP.jpg
Here is my lighting test map - in the back ground is a 240 visibility sector.
Done just right now with last weeks EDuke/Mapster set.

Well, my problem is in most part for large sectors, besides decrease the shading of the sector and look the result.
I'm not discovering nothing, the trouble is there.

Just make a large sector set shading to 15 or so, set visibility 240... with "r_usenewshading" as it is in default mode.

Example:

vis=240, sector shading = 9, r_usenewshading = 1



vis=240, sector shading = 9, r_usenewshading = 0



I´m using r3266

Shadescale is default, but it is the same with shadescale = 1.0

[Hank]

 Norvak, on 11 December 2012 - 08:24 PM, said:

Just make a large sector set shading to 15 or so, set visibility 240... with "r_usenewshading" as it is in default mode.

Example:

vis=240, sector shading = 9, r_usenewshading = 1

capt0002.png

vis=240, sector shading = 9, r_usenewshading = 0

capt0003.png

I´m using r3227

Shadescale is default, but it is the same with shadescale = 1.0

Where do I edit the default r_usenewshading? b.t.w. I am using version 3266

[Mike Norvak]

 Hank, on 11 December 2012 - 08:51 PM, said:

Where do I edit the default r_usenewshading?

just write "r_usenewshading 1" or "r_usenewshading 0" on the console on mapster and watch the difference.

Ohh sorry typo, I'm also using r3266

[Hank]

 Norvak, on 11 December 2012 - 08:56 PM, said:

just write "r_usenewshading 1" or "r_usenewshading 0" on the console on mapster and watch the difference.

Ohh sorry typo, I'm also using r3266

No luck - neither on Mapster nor EDuke do I see a difference, I wonder if my AMD card suppresses it?
Still, thanks for the command.

[Mike Norvak]

Okay here's a more graphic example (using the latest revision and a fresh folder):

Using newshading, Visibility = 240, Sector shade = 9



Without newshading, Visibility = 240, Sector shade = 9



It makes no sense for a day-time map to be that dark.

Here's the map of the pick:

 newboard.zip (410bytes)
Number of downloads: 251

I can't just use a .cfg file to turn off the newshading because it would affect other maps in the mod we are working atm.

@Helixhorned: Could this problem be addressed? Thank you

[Paul B]

 Norvak, on 12 December 2012 - 10:00 PM, said:

Okay here's a more graphic example (using the latest revision and a fresh folder):

Using newshading, Visibility = 240, Sector shade = 9


It makes no sense for a day-time map to be that dark.

Here's the map of the pick:

I can't just use a .cfg file to turn off the newshading because it would affect other maps in the mod we are working atm.

@Helixhorned: Could this problem be addressed? Thank you

I was just in another thread and noticed this conversation was mentioned by Helix just the other day. I'll repost it here:

 Helixhorned, on 11 December 2012 - 01:33 PM, said:

In PM, zykov eddy called my attention to discrepancies in the way visibility fog is handled in classic vs. OpenGL renderers. In particular, the fact that dark areas are too dark when viewed from a distance. This is all my fault, particularly due to revisions around r1943:

I really tweaked the fog factor to look closer to classic (a permanent goal, if you ask me) for a simple test scene, but overshot it for large distances. So if your open maps became darker in a way that looks wrong, the solution is to use the old GL fog factor calculation method by setting r_usenewshading to 0. With usenewshade on, I'll probably have to throw in another round of tweaking (or better, finding out the actual equation used by classic and rewriting to fit the GL fog), but hopefully the change won't be that drastic.

edit: oops, it's r_usenewshading.

I believe it was in the forum Eduke32 2.0 and Polymer Under Duke Modifications. I hope this helps.

[Helixhorned]

 Micky C, on 11 December 2012 - 04:18 PM, said:

So what's the deal with the auto texture alligning feature not alligning textures over windows and things? It works in all cases except over window-like holes in the wall where both the ceiling and floor height are different from the adjacent sectors. It aligns the bottom but not the top.

The base wall has to be bottom-aligned [O] if these "window" walls are to be aligned. It won't work otherwise, just check it out by hand. OTOH this feature is really somewhat broken at the moment, for example you might need pressing <Modifiers>+[.] twice for proper alignment.

Quote

I know it's a fairly complicated thing because I remember reading textures work differently in those situations over the 3 renderers

That's only for textures with non-power-of-two y dimensions.

[Micky C]

 Helixhorned, on 13 December 2012 - 04:48 AM, said:

The base wall has to be bottom-aligned [O] if these "window" walls are to be aligned. It won't work otherwise, just check it out by hand. OTOH this feature is really somewhat broken at the moment, for example you might need pressing <Modifiers>+[.] twice for proper alignment.

Edit: Ah I see so you have to bottom align the texture to the left then auto-allign the textures.

Btw, is there any way to align textures in the opposite direction to the default? To the left instead of to the right?

[Helixhorned]

 Micky C, on 13 December 2012 - 05:32 AM, said:

Btw, is there any way to align textures in the opposite direction to the default? To the left instead of to the right?

I was about to go on a rant describing why it's difficult to implement when I noticed that it's actually straightforward. The result is r3281.

[Arwu]

hi . Hendricks266 a few posts earlier answered to my question about quickly set height of all highlightened sectors, this helped me but today I tried to do the same and it is not working.. a.m32 file is in the main folder and scripts subfolder, I not have any idea why this is not workong for me anymore.. maybe someone have a point, thanks in advance when I enter in console: for i selsectors , set sector [i]. ceilingz 50000 , then mapster says: 'for' is not a valid command or cvar

[Hendricks266]

Prepend the command "do".

[Kyanos]

do for i

I think I may get this tattooed somewhere.

edit: Sorry Helixhorned, I didn't releasing I was shooting the shit in your bug report thread. I owe you one good and proper bug report.

[Paul B]

I don't know if it's too early to comment or not... But so far so good. Helix I just wanted to clear the air and I don't mean by "farting". The problem I have been having with the shift button, copying textures and shading seems to have all been corrected after I disconnected my USB Microsoft Sidewinder Joystick. I'm not sure how they are related but so far i've managed to do some editing without this glitch surfacing since I've disconnected it.


*Modified
Yes i've been editing maps long enough now to say it works great! Thank goodness because that was a nasty random and annoying problem.

[Paul B]

I would just like to mention since the recent changes to the shading and visibility it has rendered both my previous and new maps useless using Polymer. They no longer look good in either Eduke or Mapster. The current map I'm working on there is way too much difference in shading between mapster and Eduke and it has become really imposible to do any texture or shading work. I realize this is a work in progress but I am forced to use a previous build before the shading & fog changes occured. The build I was currently using was 3306 and now I'm back dating until such a time the shading and visibility are restored / improved.

Going back to previous synthesis build versions 3300 or 3298 do NOT work any more. The last lines of the debug Mapster.log are:
Definitions file loaded.
Setting video mode 1024x768 (8-bit fullscreen)
polymost_glreset()
Uninitializing DirectDraw...

So i'll try another older build.

The last working Synthesis Build for me is 3295 which I am now using.

To be more specific with the 3300 or 3298 it attempts to load mapster then just dumps me back to my desktop. I suspect this may be caused from a new file that was introduced from a newer synthesis build that causes an error when it is left behind and not removed? Anyway just thought i'd share my experience.

[Micky C]

You can always type "r_usenewshading 1" to go back to the older shading system. If I miswrote the console command, look it up on the wiki.

[Paul B]

 Micky C, on 22 December 2012 - 11:34 PM, said:

You can always type "r_usenewshading 1" to go back to the older shading system. If I miswrote the console command, look it up on the wiki.

Hmm so does that also apply for Eduke as well as mapster? If so in my previously released maps do I need a exec file to execute that command before people play my map? Thanks for the prompt reply Micky.

[Micky C]

Hmm maybe. Perhaps wait to see if anything else happens with the shading.

[Helixhorned]

 Paul B, on 22 December 2012 - 11:27 PM, said:

The current map I'm working on there is way too much difference in shading between mapster and Eduke

r3313 now saves r_usenewshading in Mapster32's configuration file.

[Micky C]

The lack of being able to use the circle function and the requirement that there cannot already be TROR connections when joining or something like is giving me a real headache at the moment. I'm trying to create some floating rings, which normally you'd expect to be a really simple thing, however since both of those things I mentioned aren't working (and really only one of them is all I need, preferably the first one) it's impossible to do. I've just wasted an hour+ of my time trying to get it to work. Is there any way these can be added in?

While I'm talking away about adding TROR functionality, I'll restate the other two things which would IMO make TROR editing pretty much complete:
1. The ability to break the TROR connection between any two identially shaped sectors in seperate layers, or at least make them seperate bunches so the connection can be broken manually (This is useful if the sector is connected to the edge of the bunch).
2. The ability to paste island sectors. Hopefully both the top and bottom, kind of a very advanced form of sector punching. Obviously the sectors the islands are being pasted into would have to one sector (and flat?).

If the 4 things are addressed then that would make TROR a lot easier and faster to deal with, and easier to make corrections and add things after you've made the TROR, which is an important thing too, and one of the put-offs for some mappers to not get involved with TROR (since right now you need quite a bit of experience to make reasonable changes post-TROR without messing stuff up.)