[Helixhorned]

 Micky C, on 04 January 2013 - 09:56 PM, said:

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.

Possible with r3376+.

[Micky C]

So I tried out 3387, and the crosshair seems to take on the shade and (fogpal?) of the map, making it damn near invisible a lot of the time.

BTW, what's the deal with the auto sloping feature? (alt [/]), it seems to be very, very inconsistent with how it works. I like dealing with quadrilateral sectors with my sloping, and sometimes when you do the auto-slope when pointing at the sector's floor it works, but a lot of the time it doesn't, and I have to point at the wall I want it to slope to. To further add to the inconsistency, sometimes I can slope the floor by pointing at a wall adjacent to the firstwall, but not always, sometimes I need to point at the wall opposite the firstwall. However in these situations I see no reason why it shouldn't work with the adjacent wall, it leads to a lot of tedious manual slope adjustment. Is this a bug or something?

What would be cool is if there was an option in the special functions menu that allowed you to highlight a bunch of sectors, then automatically allign the slopes of the selected sectors to the walls opposite their firstwalls, which would definitely work for quadrilateral sectors, not sure about triangles. Combine this with the new feature to resize sectors independently by x and y axis then suddenly if you make one construction like a hill, you can quickly make a lot of different variations of that. It would cut down the time required for sloping to less than half.

[Helixhorned]

 Micky C, on 11 January 2013 - 04:58 PM, said:

So I tried out 3387, and the crosshair seems to take on the shade and (fogpal?) of the map, making it damn near invisible a lot of the time.

Right, fogging was applied to the crosshair, but that became especially noticeable with "r_usenewshading 2". Fixed in r3389.

Quote

BTW, what's the deal with the auto sloping feature? (alt [/]), it seems to be very, very inconsistent with how it works. I like dealing with quadrilateral sectors with my sloping, and sometimes when you do the auto-slope when pointing at the sector's floor it works, but a lot of the time it doesn't, and I have to point at the wall I want it to slope to. To further add to the inconsistency, sometimes I can slope the floor by pointing at a wall adjacent to the firstwall, but not always, sometimes I need to point at the wall opposite the firstwall. However in these situations I see no reason why it shouldn't work with the adjacent wall, it leads to a lot of tedious manual slope adjustment. Is this a bug or something?

The way I understood auto-sloping in the BUILD editor is that you basically shoot a ray from your viewpoint in the direction you're aiming, and the wall that is hit (assuming walls that extend infinitely above and below, and passing through ceilings or floors) is the one whose nextwall's coordinates (x, y, floor/ceiling z) are used as alignment target. This is the behavior I coded into Polymost's "which wall is targeted when aiming at ceiling or floor?" code, and subsequently ported to Polymer.

You can stick the following code into M32Script's EVENT_DRAW3DSCREEN,

    ifge searchwall 0
    {
        qsprintf TQUOTE "searchwall = %d" searchwall
        printext256 TQUOTE 30 30 -15 0 0
    }

to see which wall Mapster32 considers targeted at any time. If there's any big discrepancy with what I described, it's probably a bug.

Quote

What would be cool is if there was an option in the special functions menu that allowed you to highlight a bunch of sectors, then automatically allign the slopes of the selected sectors to the walls opposite their firstwalls, which would definitely work for quadrilateral sectors, not sure about triangles. Combine this with the new feature to resize sectors independently by x and y axis then suddenly if you make one construction like a hill, you can quickly make a lot of different variations of that. It would cut down the time required for sloping to less than half.

Doable with M32Script: the engine functions to align a floor or ceiling to particular coordinates are exposed:

Quote

alignceilslope sectnum x y z
alignflorslope sectnum x y z

[Gambini]

Some quick notes:

In newer Mapster32 snapshots cloning bunches of sprites has became a hassle because you can´t hold the template anymore, when making several copies. Before you´d shift-select the bunch of sprites, drag it with the left button and press insert wherever you wanted a copy. Now everytime you press insert, you have to click again on the bunch to re-select it. I really hope this wasn´t intentional, because it is a pain in the ass.

First time I notice the new "question" when joining overlapped sectors. Great addittion.

Alligning wall textures in a human way is no longer possible in Mapster32. I noticed that, about a month back, it became slightly better. But this complete function is several steps backwards to what it was like in the Build times. Also, stretching walls is also now a hassle too, because texture size seems to be clamped to the wall´s dimension. These two things are quite old, but I´d really consider going back to the original behavior. So far it has been delaying my work a lot and making me curse in languages I didn´t even know I was able to speak.

Map stats (sectors, walls count etc) are now reserved for ninjas and supernatural men. In order to see them you have to move the mouse away from any object in the map and be ready to take a mental snapshot of the stats that will appear on screen for about 0.0005 seconds.

Dragging vertices doesn´t seem to show wall´s measures anymore. That was a great feature and now I can´t live without it.

That´s it (for now).

[Mike Norvak]

THIS

 Gambini, on 14 January 2013 - 04:53 PM, said:

In newer Mapster32 snapshots cloning bunches of sprites has became a hassle because you can´t hold the template anymore, when making several copies. Before you´d shift-select the bunch of sprites, drag it with the left button and press insert wherever you wanted a copy. Now everytime you press insert, you have to click again on the bunch to re-select it. I really hope this wasn´t intentional, because it is a pain in the ass.

THIS

 Gambini, on 14 January 2013 - 04:53 PM, said:

Alligning wall textures in a human way is no longer possible in Mapster32. I noticed that, about a month back, it became slightly better. But this complete function is several steps backwards to what it was like in the Build times. Also, stretching walls is also now a hassle too, because texture size seems to be clamped to the wall´s dimension. These two things are quite old, but I´d really consider going back to the original behavior. So far it has been delaying my work a lot and making me curse in languages I didn´t even know I was able to speak.

AND THIS

 Gambini, on 14 January 2013 - 04:53 PM, said:

Dragging vertices doesn´t seem to show wall´s measures anymore. That was a great feature and now I can´t live without it.

[Helixhorned]

 Gambini, on 14 January 2013 - 04:53 PM, said:

In newer Mapster32 snapshots cloning bunches of sprites has became a hassle because you can´t hold the template anymore, when making several copies. Before you´d shift-select the bunch of sprites, drag it with the left button and press insert wherever you wanted a copy. Now everytime you press insert, you have to click again on the bunch to re-select it. I really hope this wasn´t intentional, because it is a pain in the ass.

What? When you duplicate a set of highlighted sprites with the Insert key, they stay highlighted, so you can drag them away or repeat the procedure. That they may not "blink" when non-highlighted sprites are at the same position is another question...

Quote

Alligning wall textures in a human way is no longer possible in Mapster32. I noticed that, about a month back, it became slightly better. But this complete function is several steps backwards to what it was like in the Build times.

Well what can I say, I guess I screwed that function. What's the biggest issue with it? As far as I can recall, you may need to press [.] twice, which is kind of an annoyance, but no inherent limitation.

Quote

Also, stretching walls is also now a hassle too, because texture size seems to be clamped to the wall´s dimension.

Actually, when you drag a wall vertex, the wall's initial length-by-xrepeat ratio (i.e. how much the texture is stretched in absolute units) is kept. I consider this a feature. You'd rather want the texture to stretch or shrink when you drag a vertex?

Quote

So far it has been delaying my work a lot and making me curse in languages I didn´t even know I was able to speak.

Let's see... it's either Russian or Klingon, right?

Quote

Map stats (sectors, walls count etc) are now reserved for ninjas and supernatural men. In order to see them you have to move the mouse away from any object in the map and be ready to take a mental snapshot of the stats that will appear on screen for about 0.0005 seconds.

You just have to move away the mouse at someplace there's no sector underneath...

Quote

Dragging vertices doesn´t seem to show wall´s measures anymore. That was a great feature and now I can´t live without it.

Works for me.

[Gambini]

 Helixhorned, on 15 January 2013 - 11:44 AM, said:

What? When you duplicate a set of highlighted sprites with the Insert key, they stay highlighted, so you can drag them away or repeat the procedure. That they may not "blink" when non-highlighted sprites are at the same position is another question...

Is not that, What I mean is that before I could make infinite in different positions with my finger stuck on the left button. I just had to move the cursor around and press insert everytime I wanted a copy. Now, everytime I press insert I have to let go the left button and press it again on the bunch to keep repeating the procedule.

Quote

Well what can I say, I guess I screwed that function. What's the biggest issue with it? As far as I can recall, you may need to press [.] twice, which is kind of an annoyance, but no inherent limitation.

It´s been so much time that I don´t recall all details of how the old way worked. But what I´m sure is that I could allign walls with holes and walls without holes with a couple of steps (if the allignment doesn´t success at the first try, just press O on the wall with a hole). Now, if you have (for example) a solid wall, one window, another solid wall and then other window and then a solid wall again The task takes AGES. Aligning the first (solid wall) with the first window will take pressing . 2 times but then, all other textures will be misallined, and there´s where you have to go again and repeat the procedule wall by wall. And if you have a loop, everytime you aling the next wall, all the previous ones will be fucked up. It is literally faster to align an example like the aforementioned, manually.

Quote

Actually, when you drag a wall vertex, the wall's initial length-by-xrepeat ratio (i.e. how much the texture is stretched in absolute units) is kept. I consider this a feature. You'd rather want the texture to stretch or shrink when you drag a vertex?

Your feature is useful for modifying/resizing props (vending machines, computers, etc) For everything else I find it unnecesarily time consuming. Maps are mostly built of walls, walls are usually textured with bricks. Bricks look better if all them have the same lenght. Hence, I find myself wasting time stretching wall textures much more than I used to waste time fixing pillars, screens and other props that require fixed texture coordinates.

Quote

Let's see... it's either Russian or Klingon, right?

One is the language the Blood monks speak.

[Micky C]

 Helixhorned, on 15 January 2013 - 11:44 AM, said:

Actually, when you drag a wall vertex, the wall's initial length-by-xrepeat ratio (i.e. how much the texture is stretched in absolute units) is kept. I consider this a feature. You'd rather want the texture to stretch or shrink when you drag a vertex?

Hmm? When you drag a wall vertex, the texture is stretched. I'm not a coding expert but isn't keeping the length/xrepeat ratio the same going to cause stretching/shrinking whenever you change the wall length? You make it sound like it's designed not to shrink/stretch which in practise isn't the case.

As for looking at wall lengths when you drag the vertex, it is a bit tedious, you kinda have to have the mouse cursor on the side of the vertex with the wall you're trying to see the length of, which means you can't see the lengths of all the walls attached to the vertex at once.

Btw while I'm posting, can anyone tell me how to change that usenewshade thing? I try typing "r_usenewshade 0/1/2" and it's saying it's not a valid command or whatever. And I can't find it in the wiki.

[Forge]

THIS:

 Gambini, on 15 January 2013 - 05:10 PM, said:

It´s been so much time that I don´t recall all details of how the old way worked. But what I´m sure is that I could allign walls with holes and walls without holes with a couple of steps (if the allignment doesn´t success at the first try, just press O on the wall with a hole). Now, if you have (for example) a solid wall, one window, another solid wall and then other window and then a solid wall again The task takes AGES. Aligning the first (solid wall) with the first window will take pressing . 2 times but then, all other textures will be misallined, and there´s where you have to go again and repeat the procedule wall by wall. And if you have a loop, everytime you aling the next wall, all the previous ones will be fucked up. It is literally faster to align an example like the aforementioned, manually.

aargh! this sucks!

the textures above/below windows don't align together with non-window walls no matter how many times "." gets tapped (lord help you if you hit "rt-alt-." or "rt-ctrl-.")
using "o" still doesn't work properly
the solution is tedious no matter how you slice it: either avoid the "." button at all costs and manually align textures above/below windows - or hit "o" on each and every wall (with and without widows) so "." will work properly

[Mike Norvak]

Yes sorry for all the complains. Is not like all we aren't grateful with all the enormous amount of work put on fixing bugs and enhanced features, anyway what is a bit frustrating is that sometimes when you come back to mapster it seems like if everything has been changed which turns mapping into a cumbersome task.

Imagine you call a plumber to fix a leak in a pipe on your kitchen (is that the correct term?) or even better, your pipe line is working correctly but the plumber told you about a much modern intelligent water system, the plumber installed it and then he goes away (BTW he works for free ) and everything works as expected in the kitchen, but later when you go to the bathroom you realized that when you open the sink faucet a stream of water comes out from the shower head, if you go to the shower the faucet controls the water in the WC, the other sink faucet controls the garden sprinkler and so on. You could get used to that kind of life, but simply that's not the way it should work...

Sorry for the poor example but what I meant is that is cool to have new features but without breaking the good ol' stuff that in the first place doesn't need to be changed.

Also it'd be cool that the 3 renders would look the same as 8-bit (shading,vis, etc) but the problem is that there are lots and lots of user maps that would result broken :/ [For example: Polymost have always been less dark than 8-bit, if you load a dark map made with Polymost in mind with the new shade tables (or whatever its name is) the map would look just too dark making unplayable] In my opinion 8-Bit looks okay and Polymost shouldn't look like 8-bit, nor Polymer. Or in the best of the cases there should be an option on the start up screen that allows to keep compatibility with the old maps (just like the autoload check-in box) that keeps the old parameters, as well as in mapster.

So for now the problems are those pointed by Gambini plus the newshade issue.

 Micky C, on 15 January 2013 - 10:44 PM, said:

Btw while I'm posting, can anyone tell me how to change that usenewshade thing? I try typing "r_usenewshade 0/1/2" and it's saying it's not a valid command or whatever. And I can't find it in the wiki.

Type "usenewshading" not "usenewshade"

[Paul B]

Since there seems to be an influx of people posting problems. I would just like to share my biggest beef at the moment. Since the new shading renderer has been implemented I can no longer properly shade textures in Polymer using Mapster. Basically what happens is Mapster doesn't properly reflect the shade. I'm not sure if this is a work in progress but it has become almost impossible for me to shade anything without having to load Eduke to see how it looks then go back into Mapster and adjust the shade while memorizing shade values because the visibility of the shade is not very obvious when reaching shade 23 to 32 there seems to be huge problems with knowing what is dark and what isn't. Any suggestions ?

Regardless of the issues.. Helix we're still big fan's of your contributions. You Rock!

[Helixhorned]

OK, almost all of Gambini's complaints have been taken care of in the new revision. I couldn't reproduce the issue with highlighted sprite dragging: I can keep the mouse button pressed and paste as many copies as I wish. Maybe it's a Windows-only thing?

 Micky C, on 15 January 2013 - 10:44 PM, said:

Hmm? When you drag a wall vertex, the texture is stretched. I'm not a coding expert but isn't keeping the length/xrepeat ratio the same going to cause stretching/shrinking whenever you change the wall length? You make it sound like it's designed not to shrink/stretch which in practise isn't the case.

By "keeping" the absolute stretching, I mean that wall[].xrepeat has to be corrected for the new wall length. The equation is:

walllength * xrepeat
-------------------------- = reps,
128 * tilesizx

where reps is the (real) number of repetitions of the texture across the wall (i.e. a value reciprocal to how stretched it is).

 Norvak, on 16 January 2013 - 10:33 AM, said:

Imagine you call a plumber to fix a leak in a pipe on your kitchen (...)
(...)
Sorry for the poor example but what I meant is that is cool to have new features but without breaking the good ol' stuff that in the first place doesn't need to be changed.

The analogy isn't that bad, but small changes may have wide, not always intended effects. So it's good that you cry out from time to time so they're actually noticed.

Quote

Also it'd be cool that the 3 renders would look the same as 8-bit (shading,vis, etc) but the problem is that there are lots and lots of user maps that would result broken :/ [...] In my opinion 8-Bit looks okay and Polymost shouldn't look like 8-bit, nor Polymer. Or in the best of the cases there should be an option on the start up screen that allows to keep compatibility with the old maps (just like the autoload check-in box) that keeps the old parameters, as well as in mapster.

I agree that there's a need of such a per-map option system; it's planned. However, the three renderers should attempt to look the same where possible IMO.

 Paul B, on 16 January 2013 - 11:57 AM, said:

Since the new shading renderer has been implemented I can no longer properly shade textures in Polymer using Mapster. Basically what happens is Mapster doesn't properly reflect the shade.

You need to set r_usenewshading in the editor and game to the same value.

[Gambini]

 Paul B, on 16 January 2013 - 11:57 AM, said:

Since there seems to be an influx of people posting problems. I would just like to share my biggest beef at the moment. Since the new shading renderer has been implemented I can no longer properly shade textures in Polymer using Mapster. Basically what happens is Mapster doesn't properly reflect the shade. I'm not sure if this is a work in progress but it has become almost impossible for me to shade anything without having to load Eduke to see how it looks then go back into Mapster and adjust the shade while memorizing shade values because the visibility of the shade is not very obvious when reaching shade 23 to 32 there seems to be huge problems with knowing what is dark and what isn't. Any suggestions ?

I think your problem comes by having a shadescale value stored in your eduke32.cfg and a different one (or none at all) In mapster32. I had that issue in the past too and it was because once you type shadescale xx in the console that value is automatically stored in eduke32.cfg. It´s either that, or you have an autoexec.cfg with that parameter.

Helix: Once again, thanks for your commitment. I´m gonna be using that revision from now on in order to keep providing "useful" reports.

[Paul B]

Okay I think you guys mis-understood what I was trying to say. Forget about Eduke.cfg and mapster.cfg for a minute.

This problem is only specific to mapster 3d editor mode. If I set a shade on a wall between shades 23 and 33 There is no visual gradient to tell how dark the shade is. It goes from one kind of shade to pitch black. There is absolutely no stepping to shading using mapster anymore. This has nothing to do with r_usenewshading in a config file. Basically the shading is now broken using Polymer and rshading2. That's all I was trying to say.

[Mike Norvak]

 Paul B, on 16 January 2013 - 07:15 PM, said:

Okay I think you guys mis-understood what I was trying to say. Forget about Eduke.cfg and mapster.cfg for a minute.

This problem is only specific to mapster 3d editor mode. If I set a shade on a wall between shades 23 and 33 There is no visual gradient to tell how dark the shade is. It goes from one kind of shade to pitch black. There is absolutely no stepping to shading using mapster anymore. This has nothing to do with r_usenewshading in a config file. Basically the shading is now broken using Polymer and rshading2. That's all I was trying to say.

Type in the console:

r_usenewshading 0

r_shadescale 1.05 or some value like that.

[Paul B]

 Norvak, on 16 January 2013 - 08:41 PM, said:

Type in the console:

r_usenewshading 0

r_shadescale 1.05 or some value like that.

yes changing that value does make it easier to shade stuff. The problem is I am trying to make a map using the latest Rshade value of 2. Because obviously this is what everything is going to so I want to keep current so my maps aren't obsolete with the old shaders. So i've been using Shader 2. Maybe I shouldn't be? I want my maps to look good when people download eduke and play them. So what are people going to be using?

[Micky C]

 Paul B, on 16 January 2013 - 09:53 PM, said:

I am trying to make a map using the latest Rshade value of 2. Because obviously this is what everything is going to

I think Helix admitted that rshade 2 is a bit broken or that it's still not perfect or anything like that. Granted maps using that shading are too dark in the GL modes.

For the moment I think people are using rshade 1, however the goal to have the same shading across all 3 renderers is an ongoing process and I wouldn't be surprised if later on there's an rshade 3 or maybe even 4
Still, another reason not to use different vis values within a map to achieve different shades

[Paul B]

 Micky C, on 17 January 2013 - 04:34 AM, said:

I think Helix admitted that rshade 2 is a bit broken or that it's still not perfect or anything like that. Granted maps using that shading are too dark in the GL modes.

For the moment I think people are using rshade 1, however the goal to have the same shading across all 3 renderers is an ongoing process and I wouldn't be surprised if later on there's an rshade 3 or maybe even 4
Still, another reason not to use different vis values within a map to achieve different shades

Thanks buddy, I didn't get that memo about the shader2 not being totally functional. I'm glad to hear its not an isolated incident with my computer and the mapster editor. I'll hardcode my shader settings to 1 and leave it at that since every other user map uses that shader.

[Helixhorned]

 Micky C, on 17 January 2013 - 04:34 AM, said:

I think Helix admitted that rshade 2 is a bit broken or that it's still not perfect or anything like that. Granted maps using that shading are too dark in the GL modes.

For the moment I think people are using rshade 1, however the goal to have the same shading across all 3 renderers is an ongoing process and I wouldn't be surprised if later on there's an rshade 3 or maybe even 4
Still, another reason not to use different vis values within a map to achieve different shades

No, r_usenewshading 2 is as close as it can get to classic with only using distance-based per-fragment attenuation. The only minor issue is that I determined the distance constant in the fog factor equation experimentally. If I ever find out its real value by inferring it from the code, it will amount to a minimal tweak. Paul B's problem was with r_shadescale, which now is 1.0 by default. I guess it existed to correct for the too bright appearance of the legacy fogging mode, but it has its own share of problems.

To motivate the new fogging mode, take a look at this album. It shows the beginning of E2L1, where the light on one end of the corridor pulsates. When it's off, the area is shrouded in almost complete darkness. In the original Polymost fogging mode, you still see the whole room, and that "mysterious" atmosphere is lost. Similar thing with E3L4, in the lower elevator room with the pigcops.

[Gambini]

It´s really great you are trying to approach the original look of the game. Even if maps made for polymost when it was the old way will look fucked up now. My very own "Blown Fuses" looks awful with that newshade 2 but it´s still worth to do something to merge all worlds.

Just one thing I´d like to mention, it´s likely second hand information for you but since nobody ever mentions it: Classic´s visibility didn´t have any effect on height, while opengl´s black fog does (imagine classic like a cylinder of visibility and open-gl as a sphere). This is important because if you look up in e1l1, in classic, you´ll see the shading stay the same along the whole height of the skycrappers, while as in opengl they fade to black. I personally think there´s no advantage at all on having z-angle visibility. Visibility per se is a cheap solution to add depth, we want to replicate it because it has been always there, so... why not replicating as cheap as it always have been?

[Micky C]

Gambini, on 17 January 2013 - 05:01 PM, said:

imagine classic like a cylinder of visibility and open-gl as a sphere

Well visibility is more like a flat wall that's always perpendicular to where you're looking, and in openGL it also stays perpendicular to the vertical angles. I wish it was more like a cylinder and sphere, because then it wouldn't change just by looking around on the spot.

What's your actual question though? I can't really extract any question or request from your post.

[Plagman]

Well, doing it that way is actually cheaper, it would require more computation to only take the XY plane distance into account. And shade/visibility is still a meaningful tool for "next-gen" maps as well, unlike other classic features. Making it cylindrical there wouldn't make much sense visually, would it?

[Hank]

For what it is worth, visibility should be in relation to distance, my problem I have now is that some remote items should stay fully visible. Even if a street is completely dark, the light from a window should maintain it's visibility. So when you look up at the sky box of a city sky line, it should not become dark because I look up.

[Gambini]

Micky C, on 17 January 2013 - 05:26 PM, said:

What's your actual question though? I can't really extract any question or request from your post.

It wasn´t a question. It was a remark. Since Helix is trying to make renderers look more or less the same, he should definetely bear that in mind.

Plagman, on 17 January 2013 - 05:29 PM, said:

Well, doing it that way is actually cheaper, it would require more computation to only take the XY plane distance into account. And shade/visibility is still a meaningful tool for "next-gen" maps as well, unlike other classic features. Making it cylindrical there wouldn't make much sense visually, would it?

I may have not chosen the right words, but with cheap I meant like "bungler". I understand it may require more work for the coder and for the computer. On the other side, next gen maps aim to look modern. No modern engine has a thing even barely similar to our visibility. Visibility only accomplished the mission of hiding simple geometry at the distance and breaking the flatness of simple shading. If a modern map is detailed enough, and moreover, has light sources, there´s no point on using visibility, at least not to have an exclusive visibilty system. Mappers should dismiss it by default.

Hank, on 17 January 2013 - 06:12 PM, said:

For what it is worth, visibility should be in relation to distance, my problem I have now is that some remote items should stay fully visible. Even if a street is completely dark, the light from a window should maintain it's visibility. So when you look up at the sky box of a city sky line, it should not become dark because I look up.

That´s another problem I think, in Open-GL visibilty fades exponencially, it´s also heavily compromised by the surface´s shading. It should not be like that.

[Plagman]

Modern engines do have ambient lighting, which is (roughly) equivalent to what you can achieve with shading in mapster. If you just use the minimum shade on your whole map and work with dynamic lighting only, every shadow will be completely pitch-black, resulting in the "Doom 3" effect.

[Gambini]

Another misunderstanding. Visibility and shading are two separate things, quite different from each other. In fact visibility plays against "fake ambient light" because most manually shaded sectors will fade to black at some distance.

[Gambini]

Quote

In newer Mapster32 snapshots cloning bunches of sprites has became a hassle because you can´t hold the template anymore, when making several copies. Before you´d shift-select the bunch of sprites, drag it with the left button and press insert wherever you wanted a copy. Now everytime you press insert, you have to click again on the bunch to re-select it.

This keeps happening.

Also, just had an idea (well had it from a lot of time ago actually). See attachment:


The idea is to make a mini tile of the monster in question show above all respawns, that would be quite handy!

Attached thumbnail(s)

• 

[Micky C]

That would be the most epic convenience to mapster32 since the smart tagging system! It'd be especially super useful for constructing my Serious Sam episode which heavily revolves around respawns, and will make the management of waves of enemies much easier.

I'm guessing the best way to do it would be via the a.m32 included script?


On a slightly related matter for WGRealms 2, there are some coded sprites that emit lights in-game, and it would be sweet if those lights could be seen in mapster but not be inserted as SE sprites (otherwise the lights would be duplicated), but this would be a job for Drek or Trooper Dan, I just hope it's possible somehow, since I know direct control of lights via con/mapster script isn't hooked up yet.

[Helixhorned]

Gambini, on 28 January 2013 - 09:24 PM, said:

Also, just had an idea (well had it from a lot of time ago actually). See attachment:


The idea is to make a mini tile of the monster in question show above all respawns, that would be quite handy!

Great idea, simple and effective! Now implemented in a.m32. If you want the spawned picnums to display always instead of when locking onto a RESPAWN sprite with LMB/SPACE, change the line

gamevar showrespawn_always 0 0

to

gamevar showrespawn_always 1 0

.

Interestingly, implementing that feature exposed a bug in the m32script interpreter where tsprite members sometimes wouldn't be set to the expected values, so the preview fails on some occasions, like the E1L5 boss respawn sprite.
Also, I mixed things up and credited Micky C for the idea in the commit log. Well, you get a +1 instead.

[Arwu]

mapster groving nicely ! : )
Im happy because it is my favourite not modern engine editor. sadly.. my HD with all my duke work is damaged.. I started from begining. : (
I use mapster since rev.1860~ . I liked all the new features made in duke and mapster like smart tag system, tror and its all improvements, 5th mouse button working, now graphical icons in mapster above respawns, etc : )

I have question:

in 2D mode when pressing Lshift on sprite, red lines are displayed to linked effects. is there a way to display these lines even if cursor is away from sprite?
sometimes lines are too long to show them confortably in mapster.