[Forge]

new one for me when I started using r1855

2d mode works fine. 3d mode works fine.

when i use 'v" to select or change a texture, the screen goes crazy like an old antennae tv that's getting poor reception, or one of those scrambled cable channels.

it clears up as soon as i scroll with the mouse wheel and stay put on one screen, but if i start to scroll again the screen gets all blurry and wavy until i stop again.

didn't do this until r1855

[Forge]

This is what I'm dealing with when I bring up the texture screen in r1855 & r1856

what's not seen is in the screen shot that the 3d view is visible in the background is the "broke tv" scrolling of thick blurry lines

also i have no idea what's going on with the background. i have the programs minimized to the task bar, and the task bar hidden. The only thing i can see is the desktop

i jumped from r1849 to 1855. I can backdate to r1849 and I don't experience this problem so whatever caused it on my machine happened somewhere in between.

[Helixhorned]

Gambini, on 25 March 2011 - 03:52 PM, said:

In Valve Hammer when you enter a name (it uses names as tags) it will look bold if the name is already used by another entity and it will look bold and red if the tag doesn´t connect to anything yet.

Just an example of how it could work, although its implementation would be a little bit harder since some sprites use lotag as channel and some others use hitag. This would require a smart script that determines which sprite/sector/wall is using what and what purpose it has.

Good idea, I might code something like this. It would have to be "dumb" though, because the effectors can have any crazy tagging scheme.

The Commander, on 26 March 2011 - 01:57 AM, said:

When will see some textured mode for the whole 2D side view mode?

That's not planned.

Forge, on 27 March 2011 - 07:32 AM, said:

This is what I'm dealing with when I bring up the texture screen in r1855 & r1856

what's not seen is in the screen shot that the 3d view is visible in the background is the "broke tv" scrolling of thick blurry lines

also i have no idea what's going on with the background. i have the programs minimized to the task bar, and the task bar hidden. The only thing i can see is the desktop

i jumped from r1849 to 1855. I can backdate to r1849 and I don't experience this problem so whatever caused it on my machine happened somewhere in between.

I'll look into this, though I can't reproduce it.

[Forge]

Helixhorned, on 08 April 2011 - 04:00 AM, said:

Good idea, I might code something like this. It would have to be "dumb" though, because the effectors can have any crazy tagging scheme.


That's not planned.


I'll look into this, though I can't reproduce it.

I'm not the only one having this problem.

Polymer and EDuke32 2.0!

[Gambini]

I am using 1855 yet and there are a few important issues:

1- when moving up/down a ceiling in 3d mode (pgup/pgdown):
The way it should work: only sprites aligned to it are moved along with the ceiling.
The way it works now: Any sprite, aligned, stuck or within the ceiling are moved.

2- When selecting a group of sectors and moving ceiling/floor up/down in 3d mode:
The way it should work: All selected ceilings/floors are affected by the height increase/decrease
The way it works now: Only the ceiling/floor which is aimed is moved.

Also, i see you have retrieved the shade preview system but it was broken and so is still broken. I´ll quote myself in case you have missed this:

Quote

1st rule: Any pal value not equal to 0 in the floor of a sector will turn all the sprites within this sector to that pal value.

2nd rule: The shade of a sprite will be taken from the floor unless the ceiling is parallaxed, in which case will be taken from the ceiling. but not the pal which always follow the 1st rule.

3rd rule: relative to wall sprites will keep their own shade unless they´re actors, but they will still retain the floor pal.

The two former things are way more important, but the latter is still a pretty gross glitch.

[Helixhorned]

Gambini, on 08 April 2011 - 04:27 PM, said:

I am using 1855 yet and there are a few important issues:

1- when moving up/down a ceiling in 3d mode (pgup/pgdown):
The way it should work: only sprites aligned to it are moved along with the ceiling.
The way it works now: Any sprite, aligned, stuck or within the ceiling are moved.

Yes, that was deliberate. I never understood why sprites are moved along with ceilings/floors only when they're exactly aligned. Is there any reasoning behind this?

Quote

2- When selecting a group of sectors and moving ceiling/floor up/down in 3d mode:
The way it should work: All selected ceilings/floors are affected by the height increase/decrease
The way it works now: Only the ceiling/floor which is aimed is moved.

Fixed in r1860 (bug category: own silliness).

Quote

Also, i see you have retrieved the shade preview system but it was broken and so is still broken. I´ll quote myself in case you have missed this:

(...)

The two former things are way more important, but the latter is still a pretty gross glitch.

Ditto, minus the actor part because the editor is rather unknowing what might be an actor and what not.


@Forge: did you edit out the images I recall seeing before? They were the only hints I had because I'm still groping in the dark: tried everything from tweaking some r_tex* cvars to running on a Mac computer, but without success.

[Gambini]

Quote

Yes, that was deliberate. I never understood why sprites are moved along with ceilings/floors only when they're exactly aligned. Is there any reasoning behind this?

Well, there are several reasons of that, just as the ones that apply to the floor and similar sprites situation. I can give you a few:

- Once a sprite is hidden in the ceiling there´s no way you can make it show back unless its height is reseted via 2d mode.

- When doing a "SE 32 Ceiling fall" effect usually the mapper puts the SE in the desired position and then moves the ceiling down to hide the SE. Right now that´s impossible to do.

- It is the way it worked all life. Your control updates are really cool when they make things easier. This time around it makes things harder. Also, a lot of mappers that don´t check this thread will trust their sprites aren´t moving with the ceiling because that´s how it always was!

That should be enough!

[Forge]

Helixhorned, on 09 April 2011 - 05:38 AM, said:

@Forge: did you edit out the images I recall seeing before? They were the only hints I had because I'm still groping in the dark: tried everything from tweaking some r_tex* cvars to running on a Mac computer, but without success.

I didn't think there was much you could do without being able to reproduce the problem on your end

r1854-r1861 do this. these are all on the tile selection screen

[Helixhorned]

Gambini: okay, that's convincing.

Forge: is r1862 any better?

[Forge]

Helixhorned, on 09 April 2011 - 07:37 AM, said:

Gambini: okay, that's convincing.

Forge: is r1862 any better?

Tried r1862. No difference.

r1853 works fine. r1854 and after do not.

I just got done experimenting around a bit. Deleted my mapster32.cfg and tried different resolutions

8 bpp works fine with no glitches
32 bpp (what i usually map in) has the problem

[Forge]

I think the only way you're going to crack this one is to figure out what changed from r1853 to r1854. Sounds like a long and tedious process, so with only a few people mentioning it, I wouldn't spend too much time trying to figure it out. Thanks for looking it to it though.

[Helixhorned]

What's troublesome is that I know exactly what caused it, but not why. In r1854, I committed code so that the hightiles in the tile selector would load one by one, making navigation possible in between. This is why you're seeing it only in 32 bit mode: it doesn't apply to classic at all because there, all tiles are drawn in one run, as before. Your screenshots look as if the screen isn't cleared to black each first iteration. Do you see the black transparent background with the console down?

[Forge]

yes

[Forge]

I have been using the GeForce drivers specific to my video card from the Nvidia site. I changed to using the GeForce/ION Driver v270.51 and the problem "went away".

[Helixhorned]

Revision 1867 introduces a tag labelling system that some of you have requested. Here's a mini-tutorial to get you started.

First, the system 'knows' what kind of tag is used to link things together, so it will only allow to label such tags. What's also important is that it keeps track of a one-to-one mapping of tags<->labels.

Open up some random map, and visit an area with some 'linking' sprites like SEs. Now begin assigning a hitag to one of the SEs. When you're queried for the number, you can start typing a name right away, but depending on what number you've entered before, and the state of the label<->tag mapping, the result what happens when you confirm the label ("ENTER") is different. The rules are basically as follows:

1. If, after having entered the name, the system finds that the label is mapped to a tag, that tag number is inserted.
2. Else, the result depends on whether the number (before pressing an alphabetic key) was zero or not:
2a. If it was zero, a 'fresh' tag number is determined and inserted. (It's the same that is displayed with F6).
2b. Else, the existing tag number is assigned to the label given.

The last point means that you don't need to use labels from the beginning, but can assign them freely afterwards.

Mappings are saved to <mapname>.maptags in the same directory as the map file.

[TerminX]

You really add some of the coolest stuff.

[Micky C]

This, and the easier sector copy/paste is mouthwatering stuff. You're doing quite a bit to help bring Duke mapping into modern times and keeping the editor competitive with other engines' level editors

[TerminX]

Just wait until the bigger thing he's been working on is done.

[bullerbullerseven]

Say what it is!

[Forge]

FYI, upgrading from nvidia driver 270.51_whql to 270.61 made that problem with the texture selection screen come back. (i tried to backdate, but it didn't work. I'd have to pick out all the files ( & reg entries) manually to get back to normal)

It's blurry mainly if "V" is hit once or when scrolling through the textures with the mousewheel or pgn up/down or arrow keys. Hitting "v" twice or stopping scrolling and moving the mouse a bit clears up the screen enough to be able to select a texture.

It's bad, but not as bad as it was before when using the geforce driver.

[Micky C]

In mapster r1866, in 3D mode when you point at a texture that has a detail texture defined, it shows the detail texture in the bottom right instead of the actual texture. Check the grey square in the pic.

[blizzart]

Micky C, on 20 April 2011 - 01:30 AM, said:

In mapster r1866, in 3D mode when you point at a texture that has a detail texture defined, it shows the detail texture in the bottom right instead of the actual texture. Check the grey square in the pic.

The texture is at the bottom left

[Forge]

No luck. Used the driver removal tool from guru, back-dated my video driver, and it didn't "fix" the blurry texture selection screen. Was causing crashes to boot, so I ended up back-dating to r1853

[Helixhorned]

Micky C, on 20 April 2011 - 01:30 AM, said:

In mapster r1866, in 3D mode when you point at a texture that has a detail texture defined, it shows the detail texture in the bottom right instead of the actual texture. Check the grey square in the pic.

I can confirm this, Polymer only. The code in question just calls rotatesprite, so it shouldn't be Mapster-specific.

[The Commander]

TX, on 17 April 2011 - 09:43 PM, said:

Just wait until the bigger thing he's been working on is done.

Auto generating a landscape .map based off a height map/black & white image with certain input variables?

[Micky C]

I've tried using a rotate-rise effect to turn a room 90 degrees, but instead, the whole set of sectors shoots off in one direction and seems to keep going to infinity. I can't understand why it's doing that, and I've attached the map in question so others can have a look. It's the circular room in the bottom-right corner, you can't miss it. (Also I'm betting the thing Helixhorned is working on is a type of ROR )

Also, is there a way of making a set of sectors rotate 90 degrees in one direction each time a button is pushed, as opposed to it rotating one way, then rotating back to its original position with the next activation?

Attached File(s)

•  problem.zip (83.21K)
  Number of downloads: 274

[Plagman]

Helixhorned, on 22 April 2011 - 10:52 AM, said:

I can confirm this, Polymer only. The code in question just calls rotatesprite, so it shouldn't be Mapster-specific.

Yeah, that came from my change that hooked up rotatesprite to Polymer for highpal. I took a quick look but couldn't find anything obvious, but I still need to debug it properly.

[Plagman]

This should be fixed as of rev 1873.

[Stabs]

Micky C, on 22 April 2011 - 09:01 PM, said:

I've tried using a rotate-rise effect to turn a room 90 degrees, but instead, the whole set of sectors shoots off in one direction and seems to keep going to infinity. I can't understand why it's doing that, and I've attached the map in question so others can have a look. It's the circular room in the bottom-right corner, you can't miss it. (Also I'm betting the thing Helixhorned is working on is a type of ROR )

Also, is there a way of making a set of sectors rotate 90 degrees in one direction each time a button is pushed, as opposed to it rotating one way, then rotating back to its original position with the next activation?

if your using any gpspeeds are they at odd numbers? only 2,4,8,16,32 etc

helix in lebuild it has a high low bit which lets me decide how much of the 2d map is drawn depending on how high/low it is and its great for SoS, could mapster support such a feature?

[Helixhorned]

DanM, on 27 April 2011 - 01:32 PM, said:

helix in lebuild it has a high low bit which lets me decide how much of the 2d map is drawn depending on how high/low it is and its great for SoS, could mapster support such a feature?

Just a bit patience . How does LEBuild handle that feature in not so clear-cut cases, for example when a sloped ceiling/floor intersects the z limit? After all, it's not only the drawing that needs to be modfied, but certain editing operations should then also be impossible on the invisible portions of the map.