[Hendricks266]

Don't all sectors with floorpals > 0 cause sprites to lose their own pal if you don't use that one spriteflag/htflag?

[Mike Norvak]

The previous behaviour was: 1 - 25 floorpals change the pal of sprites. > 25 floorpals just change fogpal without changing sprite's pal.

Rightnow it is 1 - 25 floorpals change the pal of sprites. 26 -29 floorpals just change fogpal without changing sprite's pal. > 29 change fogpal whilst still changes sprite pal, obviously > 25 pals on sprites don't make any change to color hence they seem to look like being on pal 0.

[Micky C]

Hendricks266, on 04 July 2014 - 09:55 AM, said:

SDL2 makes that possible with multiple windows, but it would take much internal reconfiguring to actually have both open at the same time.

By much do you mean too much? IMO it'd be a noteworthy step towards making the interface more modern.

[Hendricks266]

No, "much" = "a lot of". It's a good idea.

[Micky C]

Is there some mapster script to paste the clipboard (tile with all its tags) to say, the centre of all highlighted sectors? Such a thing would be extremely handy for building complex effects.

[Micky C]

Can anything done be about the inability to auto-align masked walls?

[pmw]

Any updates related to faulty autoalign for textures? Since it still breaks orientations.
I mean, when I have all walls top-aligned and hit . <-button to auto-align, it doesn't align correctly example walls with windows.

An example video:


Wall textures at up and bottom of the window doesn't align correctly with autoalign when I'm using top orientation. This used to work since first Build..but in some 6 months or something, there was one update which made it to act this way. Why? What's the point?

[MetHy]

I had no idea it was even possible to make a working auto-alignement in such cases, I always make both textures seperate (bottom and top) and manually align both (which takes time).

[pmw]

I've used this method always. I still have old versions of mapster where autoalign works perfectly. But now it doesn't. I'm not sure is this a bug or feature? I haven't got any clear answer. But since it's like this, I don't really have interest to continue mapping, since it's painful like this(i'm not blaiming anyone).

[Helixhorned]

 pmw, on 08 September 2014 - 10:38 AM, said:

Any updates related to faulty autoalign for textures? Since it still breaks orientations.
I mean, when I have all walls top-aligned and hit . <-button to auto-align, it doesn't align correctly example walls with windows.

The auto-align feature will take over the bottom-wall alignment bit of the pointed-at wall to all affected ones. Hence, proper alignment of "window" walls can be had if it's made bottom-aligned before pressing [.].

Edit: Maybe I'll write a longer post another time. The auto-alignment feature is relatively complex.

[pmw]

Helix, ok. But if I make window walls bottom-aligned _before_ pressing [.] to top-aligned wall, it changes window walls from bottom-aligned to top-aligned and texturealign is faulty. The only way to fix this, is to change _all_ textures to bottom-aligned and then hit [.]. I can't use top-align, because it doesn't fit properly there, even I try to align it manually. And changing all walls to bottom-aligned, is not usually a good solution.

[Helixhorned]

 pmw, on 08 September 2014 - 11:33 AM, said:

And changing all walls to bottom-aligned, is not usually a good solution.

You only need to change the initially pointed-at wall to bottom alignment. The main issue is this: if you have a white wall adjacent to a "window" wall (one with visible top and bottom parts), they can in general only be aligned if the latter is bottom-alignment. So, the alternative -- to keep the alignment bit unchanged in all visited walls -- is not a solution either; it will fail if the window wall is top-aligned for the same reason.

Maybe I'm not seeing some aspect of your problem though. Can you provide a more complete example where you think that some wall of the visited ones has to be top-aligned?

[Paul B]

Well, I made the mistake of booting into Windows 7 32Bit to use Mapster. Once again after about 4 hours of mapping bouncing back between Eduke and Mapster it finally cut out and stopped working with a black screen when toggling the video mode to load Mapster. The end result is a frozen pc with random hard-drive activity. From this point it required me to hard boot my PC. I thought i'd take the time to publish my log files incase any developers would care to fix this problem while the product is still in beta. I realize I am not running the most recent release of the game but I have my reasons. This was the last release that I was able to successfully use TROR so i've just stuck with it. Generally speaking, if I want Mapster to run without freezing when loading or switching from 2D/3D Video modes I just boot into XP and run mapster from XP on the same PC. This works just fine on the same hardware. So it must be specific to Windows 7 32Bit and Mapster. However, I haven't tried another 32 Bit windows 7 PC to know if I can reproduce the same results. Typically this problem surfaces when I start bouncing back and forth between Eduke and Mapster while play testing my maps. It's at this point where I significantly increase the risk of freezing the computer up when either launching Mapster or switching video modes from 2d to 3d. It is not a smooth transition 100 percent of the time. I suspect that something might lock the video memory and not release its resources fast enough.

Attached File(s)

•  mapster32.log (1.89K)
  Number of downloads: 219
•  eduke32.log (2.11K)
  Number of downloads: 217

[Mark]

I remember a couple of years ago myself and others had problems when running Mapster in fullscreen mode. Switching it to windowed mode solved the hangups back then. Try it now and see if anything good happens.

[Paul B]

 Mark., on 26 September 2014 - 03:03 PM, said:

I remember a couple of years ago myself and others had problems when running Mapster in fullscreen mode. Switching it to windowed mode solved the hangups back then. Try it now and see if anything good happens.

Thanks Mark! Yea I always run it in Full Screen Mode. If the logs don't contain anything useful I may not have been using debug. But I always try to run debug as a best practice however I may have forgotten this time. Anyway, if any Dev wants to work with me on this I will do whatever they want with any kind of monitoring software to nail this problem.

[Paul B]

I have a separate question.

I tried to run Mapster in the background on my computer in Windowed Mode. While I fired up Eduke32 to test the map. The first time Eduke runs just fine. But if I try to open Eduke a second time it freezes. How difficult would it be to allow Mapster to run in conjunction with Eduke simultaneously on the same PC? Perhaps allowing this to happen would maybe fix other problems when switching between video modes too.

[LeoD]

 Paul B, on 01 November 2014 - 11:11 PM, said:

How difficult would it be to allow Mapster to run in conjunction with Eduke simultaneously on the same PC?

Follow my signature and try the nonSDL executable offered in the Public Backup section. Run both EDuke and Mapster in windowed mode. Do not click into their windows when in background to change application, only use ALT-TAB to switch. I once had three Mapsters and three EDukes running ...

[Razzy]

I just returned to Duke 3D mapping after a while, excited once I found how good TROR is right now. Still, I seem to have ran into a problem. Mainly, panning wall textures vertically doesn't seem to work. I can pan then horizontally just fine, I can pan floor textures in any direction, but when I hit right alt and 8 or 2 on the keypad while looking at a wall, Mapster32 displays the current panning and that it changes, but the texture remains unchanged, no actual panning takes place.

I'm running the version compiled on 18th December 2014, 10:27:53.

cya
Razzeh

[Mark]

I went and checked it out. I have the same problem present in version 4777 from Nov 28th. No error message in the log.

[Micky C]

I still have the problem where I can't even pan wall textures with the keyboard. I've been dragging them with the mouse for a while now.

[Mark]

Further testing shows that the verticle panning that didn't seem to move actually does kick in right at the beginning of a horizontal pan if you do it immediately after trying the verticle pan.

[Helixhorned]

Can't reproduce the issues: vertical wall panning is fine here with r4824 on Linux. There's the well known KP5 problem, but that's not what was reported, right?

[Mark]

Correct. It is not that issue. I'll update to the latest version shortly and see what happens.

EDIT: The problem still exists in 4828 running windows Vista. You can see the verticle panning number on the screen changing but the texture you are pointed at does not change. So it seems as though the keypress is being recognized. It might not be a keyboard issue.

[Helixhorned]

I just tested on Windows, and I can report Shift having no effect together with KP8/KP2. Seems like it's capitally broken, so one has to evade to using Alt. Other than that, everything works fine. In particular, there's no mismatch between what's displayed as info and what's shown, i.e. a rendering issue as your report seems to suggest. Testing was done with the latest 64-bit synthesis build on Windows 7.

[Mark]

I made the switch from SHIFT to ALT when that issue first popped up. I'm running the 32bit version in Windows Vista. I guess we will have to see if anyone else chimes in with a confirmation or not of the panning issue.

EDIT: The panning issue starts with version 4696.

[Razzy]

Micky C, on 19 December 2014 - 07:15 PM, said:

I still have the problem where I can't even pan wall textures with the keyboard. I've been dragging them with the mouse for a while now.

... You can pan textures by dragging them with the mouse? How? .-.

cya
Raziel-chan

[Mark]

I tried Mickey's way. You hold down the RShift key, then point at your wall while pressing the left mouse button and move the mouse. You learn something new every day.

[Daedolon]

I only use that to do rough positioning and finish it off with the numpad.

[Razzy]

Yeah, dragging works, but it has the same problem - if you move the mouse up or down, nothing happens, but the panning gets applied as soon as you drag it diagonally or to the side. And yeah, panning to the side applies former vertical panning via numpad too.

Also, found another error. A small one, but, still. Parallax textures/skyboxes don't get updated until you exit and re-enter 3D mode. The side-display will display the correct, current texture/skybox, but the ceiling itself will show the previous texture.

cya
Raziel-chan

[Hendricks266]

Razzy, on 20 December 2014 - 05:10 PM, said:

Also, found another error. A small one, but, still. Parallax textures/skyboxes don't get updated until you exit and re-enter 3D mode. The side-display will display the correct, current texture/skybox, but the ceiling itself will show the previous texture.

Are you using Polymer? That's a Polymer problem, not an editor problem.