[Zaxtor]

It is funny.


In testmap
In polymer mode those hom and slime trail errors on zigzag and floating ROR are gone.


Did a very complex ROR that looks like a ham (turns a lot).

In non polymer mode it does bugs (hom, slime trail etc)
In polymer is all gone and works perfectly fine.

Strange.

[EARTH DEFENCE FORCES]

Is there any mod/option that exists, or that could be created in eduke,
that would enable full 180 degree vertical look up/down, to compliment TROR?

I always found the limit on the angle you could look up and down to be limiting in duke3D.

It would be great to have a mod like this as an option within eduke32.

Or would this involve too much effort by having to fully redesign the source in order to overcome these limitations?

[Zaxtor]

Is easy to turn on/off polymer.
In cfg of Eduke32 you put 1 (on), put 0 (off) for polymers.

[Master Fibbles]

I'm fairly certain such an option already exists and has existed for some time. Looking up too high has previously caused hall of mirror or something, however, but I'm not sure that is any longer a problem.

[Zaxtor]

In standard I get hall of mirrors in complex ROR, zigzag ROR and floating platform (ROR)

But in polymer is all fixed.

Did many tests.

[Nukemprime]

TROR looks awesome.
I have tried to do the things in the Tutorial, but nothing seem to work right now. So when will this feature be available?
Or is it a MOD?

[Hank]

Nukemprime, on 26 July 2011 - 06:33 AM, said:

TROR looks awesome.
I have tried to do the things in the Tutorial, but nothing seem to work right now. So when will this feature be available?
Or is it a MOD?

did you download the latest version of Mapster32?
http://dukeworld.duk...ke32/synthesis/

[Nukemprime]

Hank, on 26 July 2011 - 06:47 AM, said:

did you download the latest version of Mapster32?
http://dukeworld.duk...ke32/synthesis/

Thanks for the link, i would never find it otherwise.
I downloaded the ZIP pack trough the main (eduke32) page, thought it was the latest version.

[Micky C]

I've been meaning to post about this for a while, but when ctrl-a is not activated (when walls aren't meant to be blocked out), walls are still getting grayed out which aren't around the height of the player, I still have to adjust the height to edit them. This leads to stuff like inserting a point on a TROR wall, where it should be inserting 2 points, it inserts a point on either the upper or lower wall (but not both), so if you drag the point out, it messes everything up. When I press ctrl-a, a lot more walls get grayed out, so that's not a problem, but when the feature is not enabled, all walls should be editable.

One side effect of the bug is opening up a hole into void space, the other side effect can be this:


Where as soon as I insert a point, it automatically gets connected to some far off sector. You can see in the pic that some walls are grey, when they shouldn't be (I'm not sure whether this last one is directly related or not, but it's a bummer.)

[Mark]

I'm not sure if my answer relates to anything since you are using TROR which I have not tried yet. But I had a problem like yours and I discovered that somehow sectors got copied and pasted over themselves. When I finally figured out how to remove the second layer my weird line adding problem went away.

[Helixhorned]

Micky C, on 31 July 2011 - 03:06 AM, said:

I've been meaning to post about this for a while, but when ctrl-a is not activated (when walls aren't meant to be blocked out), walls are still getting grayed out which aren't around the height of the player, I still have to adjust the height to edit them. This leads to stuff like inserting a point on a TROR wall, where it should be inserting 2 points, it inserts a point on either the upper or lower wall (but not both), so if you drag the point out, it messes everything up. When I press ctrl-a, a lot more walls get grayed out, so that's not a problem, but when the feature is not enabled, all walls should be editable.

One side effect of the bug is opening up a hole into void space, the other side effect can be this:


Where as soon as I insert a point, it automatically gets connected to some far off sector. You can see in the pic that some walls are grey, when they shouldn't be (I'm not sure whether this last one is directly related or not, but it's a bummer.)

Wow, it turned out that your map had TROR-nextwall corruptions but they weren't shown because of a typo in the code. All you need to do now is 'corruptcheck tryfix', and they will go away. It had nothing to do with walls being grayed out since inserting a point considers all walls found on its upward and downward search.

[Jimmy]

Generally any time something like that happens, it's a pointer corruption. In 2D mode, pressing Enter on a highlighted sector will find and try to fix corrupted pointers. CTRL + Shift + Enter will try to find and fix all corrupted pointers in a map. Don't know if that's what Helix was getting at, or if it'd fix this specific issue, but it's still good information to know.

[Helixhorned]

These are TROR links though ('upwall' or 'downwall'), and what's called 'pointers' in BUILD/Mapster32 are wall-to-nextwall links. Pressing Ctrl-Shift-ENTER will only attempt to fix up the latter, while 'corruptcheck' knows about the TROR ones.

[Jimmy]

Ah. Is corruptcheck a console command?

[Micky C]

"corruptcheck tryfix" is a very useful console command for mapster32 that attempts to find and automatically fix all the corruptions in the current map, and it works 90+% of the time.
I'm actually surprised there isn't a dedicated keyboard shortcut for it.

[Helixhorned]

Actually, 'corruptcheck tryfix' should be used as last resort, and the first thing to do when encountering a map corruption doing legal stuff is to give me a call so I can fix up the root cause. I know I'm contradicting some of my own statements at the beginning of this thread, but I didn't want to be flooded with issues back then...

[DavoX]

I tried making some really heavy stuff with this but to no avail It's really hard with all the lines visible, etc. To make complicated structures. I believe that is one of the reasons the old ROR worked the way it did, probably to keep things simpler.

Don't misunderstand me, I love the new effect and I applaud Helixhorned's effort. But the way it is now is really complicated to make things with really fine detail.

[Micky C]

Helixhorned, on 02 August 2011 - 09:10 AM, said:

Actually, 'corruptcheck tryfix' should be used as last resort, and the first thing to do when encountering a map corruption doing legal stuff is to give me a call so I can fix up the root cause. I know I'm contradicting some of my own statements at the beginning of this thread, but I didn't want to be flooded with issues back then...

Oh so if we do something that seems harmless, but causes a corruption, we should tell you about it because it's an error? Is there a list or explanation of what causes corruptions? I probably have a pretty good idea by now but it'd be nice to have a more solid understanding.

[Danukem]

I'm guessing that if Helixhorned knew which legal mapping moves caused corruption, then he would have fixed them already.

[Micky C]

I was thinking more along the lines of illegal operations, but I doubt such a list exists

[Helixhorned]

DavoX, on 02 August 2011 - 09:34 AM, said:

I tried making some really heavy stuff with this but to no avail It's really hard with all the lines visible, etc. To make complicated structures. I believe that is one of the reasons the old ROR worked the way it did, probably to keep things simpler.

Don't misunderstand me, I love the new effect and I applaud Helixhorned's effort. But the way it is now is really complicated to make things with really fine detail.

If it's your stadium map that is at risk then I better come up with something fast!

Micky C, on 02 August 2011 - 02:27 PM, said:

Oh so if we do something that seems harmless, but causes a corruption, we should tell you about it because it's an error? Is there a list or explanation of what causes corruptions? I probably have a pretty good idea by now but it'd be nice to have a more solid understanding.

Since the task of the editor is to transform one uncorrupted map state into another, any failure to do so is a bug, yes. So, anything that corrupts a map by using the documented controls should be reported (unless you happen to like a particular bug for some reason). What I implied by "illegal" are certain operations that modify certain sector/wall/sprite fields directly. Here's a partial list:

• running m32scripts with script_expertmode on
  
• modifying wall[].x/wall[].y directly instead of using dragpoint

There are probably a couple of others, but when in doubt, just report it. I won't bite.

[Micky C]

Editing sector tags in 2D mode is a pain

Even when every layer except one has been grayed out, when I press 't' to enter a lotag, I have to go through every single sector which the mouse pointer is inside of. This can be up to 6 or more sectors, and I couldn't see any way to distinguish between them, so it becomes a matter of trial and error until you finally hit the right sector. Is there any way to fix this so entering sector tags is restricted to the current layer?

[Helixhorned]

DavoX: Check out Ctrl-Alt-A in 2D mode again (r1957).

MickyC: Good reminder. It should be better now.

[Micky C]

Copying and dragging sprites is incredibly difficult, because more often than not, they leave the z-range or something (I don't think that's the reason but something's causing it) and 'teleport' to a different layer. In effect, the sprites I'm currently dragging with the mouse disappear. Can you make it so that in 2D mode with ctrl A enabled, sprites are locked to their current layer?

[Jblade]

For some reason if the player drops down from the upper part of a TROR bit to the bottom part he can't exit the bottom sector, it's as if they're blocking walls. Is this a bug or something, or how do I fix it?

EDIT: And visa-versa. If I move up into the upper section I can't move past the upper TROR sector either.

EDIT: Ok, just did some testing in the trueror1 map. If you fly above the water sector, when you drop down the floor turns solid. If you move into those side tunnel bits, the wall down to the subway then starts blocking the player.

[Micky C]

I'm also experiencing the same problem as James with my TROR map. Makes the level unplayable in some parts due to all the blocking.

Edit: apparently it's been fixed in 1966, I'll check it out later today.

[Micky C]

Sector Effector 13 doesn't work in polymer in the context of making a hole in the ground with TROR, at least not on a sloped surface. It more or less works in classic and polymost, and it clips as though it's working in polymer, but visually it's still a hole like it is in mapster. Upon demolition it also stops the floor and ceiling sectors from the lower bunch being rendered resulting in the pic below. While I'm mentioning it, hopefully Plagman hasn't forgotten to hook up masked floors and ceilings to TROR in polymer, and that sectors stop being rendered when you're in the layer above them, leaving a gaping hole below the player which can sometimes be quite big and which also looks like what's in the screenshot. The map I'm working on will be released within the next two months barring anything disastrous happens, so it would be preferable if major visual glitches can be fixed if possible before that happens. Oh and if the polymer lights shining through TROR portals hasn't been fixed yet that would be nice too

I hate to be a whinger, but the sprite dragging problem I mentioned a few posts back is also still an issue, with the sprites shifting to different layers upon being moved between sectors, and when this does happen it then means we have to flick through all the layers to find and delete the shifted sprite. Even in 3D mode sometimes, I press S on the ground, even on open ground away from walls, and the sprite would appear for a fraction of a second before disappearing to a different layer.

[Jblade]

The blocking problem's been fixed though, and quickly as well - thanks a huge bunch helix

[Micky C]

James, on 16 August 2011 - 02:49 AM, said:

The blocking problem's been fixed though, and quickly as well - thanks a huge bunch helix

+ rep for the pun

[Helixhorned]

Micky C, on 16 August 2011 - 02:47 AM, said:

I hate to be a whinger, but the sprite dragging problem I mentioned a few posts back is also still an issue, with the sprites shifting to different layers upon being moved between sectors, and when this does happen it then means we have to flick through all the layers to find and delete the shifted sprite. Even in 3D mode sometimes, I press S on the ground, even on open ground away from walls, and the sprite would appear for a fraction of a second before disappearing to a different layer.

Can you prepare a map that shows these problems, preferably one by one? Right now I don't have the time to roam around randomly in search of bugs, so anything direct helps me getting them fixed quickly.