[DavoX]

I don't know if this is normal behaviour or not but when I have num lock activated whenever I move the player with the arrow keys it's like the shift key is always pressed (Sprites show the sprites they are connected to, whenever I move a group of sprites after being duplicated the sprite rotation tool will be active by default, etc)

[DavoX]

Mapster keeps crashing when I zoom all the way in 2d mode with textures activated.

[Helixhorned]

DavoX, on 05 June 2013 - 08:52 AM, said:

I don't know if this is normal behaviour or not but when I have num lock activated whenever I move the player with the arrow keys it's like the shift key is always pressed (Sprites show the sprites they are connected to, whenever I move a group of sprites after being duplicated the sprite rotation tool will be active by default, etc)

Not for me, looks like something system-specific :-/.

DavoX, on 07 June 2013 - 11:19 AM, said:

Mapster keeps crashing when I zoom all the way in 2d mode with textures activated.

Well, you didn't provide the information I asked of you. On my setup (Linux/x64), I cannot reproduce this either. Did you miss this post?

Helixhorned, on 30 May 2013 - 01:18 AM, said:

Could you post the test map? Also, an eduke32_or_mapster.crashlog can be useful to compare with similar open bugs (one by LeoD). Are you running the x86 or x86_64 build, i.e. using the ASM rendering routines or their C replacements?

[DavoX]

Oops i missed it, I'm on windows xp pro 32 bits. I'm using DNF's mod eduke32. I haven't tried with the latest builds, I'm guilty of that.

[Paul B]

New bugs have emerged in the current releases of the synthesis builds.

1) Making a flat sprite (Floor aligned) 1 sided object only applies to top side only. The top sprite surface is visible & bottom surface is not. If you show both sides of the sprite and select the bottom surface to be the visible side and press 1 the bottom surface still disappears. 1 sided sprite function worked in 20130515-3773 and was broken in 20130516-3780.

2) I've also noticed when working with TROR not always will the focus be set on an extended sector. I am unable to select a lower extended sector as it remains grey no matter how much I adjust the Z -axis of the extended sector.

3) Sector Shading only applies to the floor and the ceiling and not the walls within a sector. This function worked in 20130506-3736 and was broken in 20130507-3737

Hopefully this helps in correcting the problems. As for the TROR issues, I didn't spend a lot of time on it. I just got annoyed back dated to an older version that I knew worked manipulated the extended sector that I couldn't edit before and then noticed the other two glitches forcing me to finally settle on version 20130506-3736.

[Helixhorned]

Paul B, on 09 June 2013 - 10:26 PM, said:

1) Making a flat sprite (Floor aligned) 1 sided object only applies to top side only. The top sprite surface is visible & bottom surface is not.

Thanks for reporting the regression and narrowing down the relevant range of revisions! Fixed in r3869.

Quote

2) I've also noticed when working with TROR not always will the focus be set on an extended sector. I am unable to select a lower extended sector as it remains grey no matter how much I adjust the Z -axis of the extended sector.

Is this a regression, too? I think either you or Micky PM'd me about something similar recently but I haven't yet looked in depth at it. You can try selecting it from various angles in side-view mode (toggle Ctrl-TAB to see what the currently "aimed at" sector is). Then, restrict z editing range with Ctrl-R.

Quote

3) Sector Shading only applies to the floor and the ceiling and not the walls within a sector. This function worked in 20130506-3736 and was broken in 20130507-3737

Wall shading works fine for me in Polymer/ART-mapping. How is sector shading supposed to automatically apply to walls?

[Daedolon]

Paul B, on 09 June 2013 - 10:26 PM, said:

1) Making a flat sprite (Floor aligned) 1 sided object only applies to top side only. The top sprite surface is visible & bottom surface is not.

Oh I just saw this too, wasn't sure what was going on. I totally didn't think to report it for some reason. Glad it's getting fixed!

I also had issues with the second thing. For some reason I was unable to work with my upper extended TROR stack no matter how I pageupped or moved myself into it in 3D mode. A random fluke allowed me to finally do it somehow, though.

[DavoX]

I don't know if this has been brought up before but selecting wide screen for mapster32 makes the cursor innacurate on 3d mode (you select something and another thing gets modified instead)

[Micky C]

Helixhorned, on 11 June 2013 - 12:09 PM, said:

Micky PM'd me about something similar recently but I haven't yet looked in depth at it.

The thing I PM'd you about was a visual glitch in classic with a rectangular TROR sector. Originally, there was HOM along the lower sector boundary, but in newer versions of the map, that was mysteriously fixed, however sprites aren't appearing in the lower sector. In both cases if you're standing in the TROR sector itself, the glitches go away.

[Paul B]

Helixhorned, on 11 June 2013 - 12:09 PM, said:

Thanks for reporting the regression and narrowing down the relevant range of revisions! Fixed in r3869.

Helix, if there is anyway I can make your job easier I am all for helping as much as I can. You do so much for us! It is appreciated to say the least. So thank you!

Helixhorned, on 11 June 2013 - 12:09 PM, said:

Is this a regression, too? I think either you or Micky PM'd me about something similar recently but I haven't yet looked in depth at it. You can try selecting it from various angles in side-view mode (toggle Ctrl-TAB to see what the currently "aimed at" sector is). Then, restrict z editing range with Ctrl-R.

I think that was me that PM'd you about that. I just forgot, but it would be nice if switching between extended TROR was made easier somehow. As per our conversation previously setting the focus of the TROR layer that Duke is in depending on the position of the 3D Player view may help resolve this problem or reduce the complaints.

Helixhorned, on 11 June 2013 - 12:09 PM, said:

Wall shading works fine for me in Polymer/ART-mapping. How is sector shading supposed to automatically apply to walls?

Okay you'll have to bear with me on this one because I'm terrible at describing visual oddities because I lack the terminology. When an entire sector is shaded using (Sector Visibility) in the past the walls would get darker the further away you got as well as the ceiling and the floor. Now only the floor and the ceilings darken while the walls remain bright and unshaded. This would be using the "ALT" + "-" keys on a sector. Hopefully that makes more sense.

[Helixhorned]

Paul B, on 11 June 2013 - 09:01 PM, said:

Okay you'll have to bear with me on this one because I'm terrible at describing visual oddities because I lack the terminology. When an entire sector is shaded using (Sector Visibility) in the past the walls would get darker the further away you got as well as the ceiling and the floor. Now only the floor and the ceilings darken while the walls remain bright and unshaded. This would be using the "ALT" + "-" keys on a sector. Hopefully that makes more sense.

It does; visibility is the right term here. Note how it looks right after you switch to 2D mode and back again, so it's one of those Polymer update issues. In-game, that probably wouldn't be noticed unless a sector's visibility is changed dynamically.

[Micky C]

Helixhorned, on 12 June 2013 - 12:42 AM, said:

It does; visibility is the right term here. Note how it looks right after you switch to 2D mode and back again, so it's one of those Polymer update issues. In-game, that probably wouldn't be noticed unless a sector's visibility is changed dynamically.

I think some mods might do that. I believe WGR2's shotgun changes visibility when it's in it's sniper mode. The AMC TC also makes things brighter when nightvision googles are used (not sure how that's done though).

[Plagman]

Oops, you're right; sector visibility is probably not on the list of things that force the wall updating logic to trigger.

[Helixhorned]

DavoX, on 08 June 2013 - 03:54 AM, said:

Oops i missed it, I'm on windows xp pro 32 bits. I'm using DNF's mod eduke32. I haven't tried with the latest builds, I'm guilty of that.

OK, I was able to reproduce it on 64-bit Linux too. It was just a matter of finding a right point, since it doesn't happen everywhere. Shouldn't be crashing with r3878 any more. Broadly speaking, the "blame" is on the ever-recurring issue of BUILD using fixed-point numeric types for geometrical calculations.

DavoX, on 11 June 2013 - 03:42 PM, said:

I don't know if this has been brought up before but selecting wide screen for mapster32 makes the cursor innacurate on 3d mode (you select something and another thing gets modified instead)

Known issue. Mouse picking is broken in Polymost, better use a different renderer.

[DavoX]

Copying a sector with spritework inside with RIGHT ALT sometimes scrambles the location of a few wall alligned sprites, this is very time consuming as I have to find the sprites and delete/relocate them manually both on the original and new copied sector.

[Helixhorned]

DavoX, on 19 June 2013 - 02:53 PM, said:

Copying a sector with spritework inside with RIGHT ALT sometimes scrambles the location of a few wall alligned sprites, this is very time consuming as I have to find the sprites and delete/relocate them manually both on the original and new copied sector.

This sounds like a genuine bug, but without a test case, I likely won't have luck in reproducing it. First, I have to ask though: is the map you're editing free of corruptions of level 4 or greater? (Level 3-cleanness would be nice, too.)

From your description is sounds like only the positions of these sprites are somehow displaced, all else being kept in place, right? So when this happens, there is no structural curruption taking place. Is it possible to undo this change then and have a map in a state just before this bug would happen reproducibly? It may be the cause for the stray sprites I've occasionally been seeing in maps, definitely interesting to have this fixed.

[DavoX]

I will send you a specific case but it has to be private for now I'll go prepare it now.

I've checked and it seems that when you press the insert button, the whole sector appears a little bit on the right, as usual, to diferentiate between the old and new sector. But when you move the new sector (still highlighted) some sprites from the new sector that were wall alligned to a white wall are left behind in the old sector. Could this be somehow related to wall alligned sprites not being able to be right on top of a white wall? (they are not pasted to the wall with the "O" in 3d mode but pasted with Insert in 2d mode right on top of the white wall)


EDIT: Checked and even if the sprite isn't on top of the wall, it will still be moved.

Screw the PM , here is the "map"

Select everything with right alt , press insert, then move the new sector to another location. The "shadows" made with sprites will move a bit. (the ones wall alligned on top of white walls)

Attached File(s)

•  bug.rar (1.09K)
  Number of downloads: 197

[Micky C]

Is there some kind of limit for TROR in software mode? It seems like if you try to look through more than 8 layers, it draws a masked floor/ceiling at the 8th one.

[Helixhorned]

DavoX, on 20 June 2013 - 05:52 AM, said:

Screw the PM , here is the "map"

Select everything with right alt , press insert, then move the new sector to another location. The "shadows" made with sprites will move a bit. (the ones wall alligned on top of white walls)

Thanks for the test case! It definitely cleared up some stuff that previously was obscure. The problem turned out to be much more interesting than I had anticipated, having its roots in the engine's inside() function, which tests whether a given (x, y) pair is inside a certain sector. Prior to r3839, it did not consider a point inside a sector in certain border cases (i.e. literally on the border). For example, here's what you would get if you attempted to drag eight sprites to each edge and corner of a rectangular sector:

So, if they happened to be on the wrong borders from the beginning, they could easily get transported to an overlapping sector.

[Helixhorned]

Micky C, on 21 June 2013 - 01:55 AM, said:

Is there some kind of limit for TROR in software mode? It seems like if you try to look through more than 8 layers, it draws a masked floor/ceiling at the 8th one.

Yes, that's the limit. It's arbitrary, but it increasing it implies greater usage of resources (mostly memory).

[Micky C]

Cool, no worries I'll work around it, just nice to know the reason.

I'll add this little nugget of info to the wiki page when I get home.

[LeoD]

As of r3911 Mapster32 doesn't load any map files.

Invalid map format, nothing loaded (code -1).

[Helixhorned]

Oops, my bad. Everyone affected can now throw a half-rotten tomato from 20 meters at me. Should be in working order again with r3911.

[Mark]

20 meters? Its not worth it if I have to bother to convert to yards first.

[Hank]

Mark., on 29 June 2013 - 04:35 AM, said:

20 meters? Its not worth it if I have to bother to convert to yards first.

http://www.yumsugar....a-Spain-4392370
throwing tomatoes at 20 metres, it's an annual event in Spain, and what is a yard?

@ Helixhorned
I noticed the latest version, 3913, no longer tries to link to the internet, is this on purpose, or is my setting off?

[Helixhorned]

Hank, on 29 June 2013 - 06:07 AM, said:

@ Helixhorned
I noticed the latest version, 3913, no longer tries to link to the internet, is this on purpose, or is my setting off?

I have nothing to do with that since I usually use "bare" builds -- without the startup window and any of that chrome. Maybe it's r3884 that changed this for you? Reading the code, it's supposed to take you to http://store.steampo....com/app/225140 .

[Mark]

Hank, on 29 June 2013 - 06:07 AM, said:

http://www.yumsugar....a-Spain-4392370
throwing tomatoes at 20 metres, it's an annual event in Spain, and what is a yard?

@ Helixhorned
I noticed the latest version, 3913, no longer tries to link to the internet, is this on purpose, or is my setting off?

In the U.S. 3 feet equals 1 yard. IIRC 1yard equals about .91 meters.

[DavoX]

Sometimes when I quit mapster32 from 3D mode, the program crashes. It sometimes saves or not your map when this happens.

[Micky C]

Always quit from 2D mode.

[Helixhorned]

DavoX, on 07 July 2013 - 04:57 PM, said:

Sometimes when I quit mapster32 from 3D mode, the program crashes. It sometimes saves or not your map when this happens.

Does an eduke32_or_mapster32.crash.log get generated?