[Helixhorned]

Micky C, on 17 December 2011 - 07:04 PM, said:

There are several instances in the CBP where enemies are in a sector, but part of them is sticking up into an above TROR layer. The parts of them that show in the above layer cannot be hit by weapons, and this seems to be the case for Duke as well, because he's 'invincible' against enforcers in a place where the TROR layer is a bit below waist height. This also happens with the final boss, which is so big that's impossible not to make him stick through into the next layer. I really hope that this can be fixed somehow, this is a very serious bug that can have dire consequences for the map.

Well, my initial warning about how TROR is intended for 'large-scale work' only and that sectors be at least of 'Duke height' was for this very reason, but I see that this is flawed as scale is relative and a boss in a Duke-high sector would still be bugged. I think fixing this is mostly a matter of searching the TROR neighbors in clipmove() and hitscan() [here, even if the ray doesn't intersect the ceiling/floor], but as I wrote in the CON coding thread a while ago, a lot of time can be spent in these functions under certain circumstances, which is why I probably will make the TROR bits in their 'clipmask' argument mean "search TROR neighbors too".

TLDR version: needs thinking...

[Mark]

I updated from svn 2063 to the latest and this small problem appeared in Mapster. Is there some setting I need to re-select to remove that texture from showing in my TROR sections of the map? Or did I just goof up somewhere else?

[Stabs]

' + i removes invisible stuff

[Mark]

Thanks Danny boy.

[Stabs]

It also stays invisble if any polymer lights are touching that tror floor, so you will have to keep lighting preview of if you start needing the tror floors for some precise construction

[Plagman]

Urgh, did anyone report that before?

[Micky C]

Plagman, on 23 December 2011 - 06:57 PM, said:

Urgh, did anyone report that before?

It also seems to disappear at some angles when using polymer, I can't be any more specific than that, but it's not a big problem, at least for the moment.

The bug I reported a while ago from my WGRealms 2 maps where the textures on invisible TROR surfaces would reset to tile 0, has struck again in vanilla Duke. The annoying thing is that because it's invisible, it's very hard to tell when it's reset, hence making it very hard to tell what caused it to reset.

[Stabs]

Is there any particular reason that lights can only have a max hitag of 16000 i would really prefer to have one large light with this current project

[Paul B]

Hi Helix,

I see you're a busy guy! I hope you have had an excellent Christmas! Since the begining of Oct. and continuing on over the Christmas holidays I've been coordinating on a new map project with Micky. Micky and myself plan on dedicating this map to you. This map makes great use of TROR features you have implemented into Mapster and as an appreciation for your continual effort in supporting and maintaining the Mapster engine and Eduke32 environment we feel it is the least we can do. Since the map is not quite finished I'm not willing to show you just yet until it's complete but we're getting really close minus a few set backs. I do however have two questions that have surfaced during the creation of this map one of which never seemed to occur in my RCPD map.

In my RCPD map you might have noticed that it consists of many two way subway trains to initiate several different types of special actions / effects. They aren't playable subways as they are intended to be used for trigger effects within the map. In my RCPD map I also used Recon Pig cops in harmony with the 2 way subway trains. However, in this new map Micky and myself are working on this doesn't seem to be the case. Is this something that can be fixed and I am curious to know how I was able to get away with using both the two way subway trains and flying pig cops before and not now? Would it have been because I initially created the RCPD map in build and only later converted it to Mapster?

Secondly, we have a problem with TROR. For instance, when a flying Recon Pig cop flies into a different TROR sector on their own because they can automatically adjust their own height position vertically this can cause them to enter a TROR sector they weren't created in. An example of this would be having Duke's character either in another TROR sector above or below the Recon Pigcops. Two things can happen.

1) The Recon Pig Cops go off course and lose their ability to find their next locator and they freeze in one spot or float around aimlessly.

2) When the Recon Pig Cops leave their TROR sector they were created in they don't take any physical damage in an adjoining TROR sector. We have also encountered a similar problem with The Big Bosses who are large enough that they will appear in more then one TROR sector due to their size. The top of the boss which extends into another TROR sector Duke's missles or shots fired will not register on the Boss. However if Duke aims at the Boss in the TROR sector the Boss was created in he takes damage in that TROR sector. It doesn't matter what sector Duke is shooting from, as long as he is shooting at the Boss in the TROR sector the boss was created in he will hit his target. These problems definitely effect the way the game plays and definitely cause some major set backs for the player. Of course in the process of creating this map we were both unfamiliar with these symptoms until we implemented TROR on a large scale and really played around with it. Other than that the map sure looks good =)


Anyway don't work too hard, take care and happy New Year to you and your family!

-Paul

[Helixhorned]

Hi Paul B,

a CBP with advanced TROR features sounds very intriguing, and I'm looking forward to playing it. However, I cannot fulfill the two requests you mentioned at this time. The collision of projectiles with sprites extending over more than one TROR level is something that will need good thought to implement cleanly, and the problem with the recon cars concerns game code, the improvement of which is deferred to a later time. Right now, I would suggest working around those two problems by making the sectors taller and the patrolling pigcops stay in one sector. Improvements might come with time, but certain other things need to be finished as prerequisites first.

Paul B, on 29 December 2011 - 02:47 PM, said:

Anyway don't work too hard, take care and happy New Year to you and your family!

Thanks!

[Micky C]

I still don't have any new information on it, but that bug that resets the TROR textures to tile 0 happened what felt like a hundred times when I was working on the TROR CBP.

[Micky C]

There's a bug in mapster where if I try to collapse some vertexes, it gives the message: "invalid operation, delete or join sector instead" which doesn't make the slightest big of sense because it has nothing to do with getting rid of sectors, I'm trying to get rid of walls/vertexes.

Here's the log, but I'm not sure how much good it'll do:
http://pastebin.com/raw.php?i=vbSerBEW

[Helixhorned]

Micky C, on 05 January 2012 - 06:37 PM, said:

I still don't have any new information on it, but that bug that resets the TROR textures to tile 0 happened what felt like a hundred times when I was working on the TROR CBP.

I already have an idea where that bug comes from and only need to properly chase it down.

Micky C, on 08 January 2012 - 03:33 AM, said:

There's a bug in mapster where if I try to collapse some vertexes, it gives the message: "invalid operation, delete or join sector instead" which doesn't make the slightest big of sense because it has nothing to do with getting rid of sectors, I'm trying to get rid of walls/vertexes.

Here's the log, but I'm not sure how much good it'll do:
http://pastebin.com/raw.php?i=vbSerBEW

That happens when three vertices would be collapsed into two, leaving a two-walled sector which is generally not a good idea. It might not concern the immediate sector you're editing, but one connected via horizontal or vertical links.

[Mike Norvak]

Someone knows why this happens? every time I want to make a circle from a square corner like this (1) that's the result (2) What am I doing wrong?

Attached thumbnail(s)

• 
• 

[Mark]

The first idea that popped into my head was hit the G key so that the vertices are on grid intersections instead of floating in between them. Maybe that confuses mapster for circles.

[Mike Norvak]

Marked, on 11 January 2012 - 07:17 PM, said:

The first idea that popped into my head was hit the G key so that the vertices are on grid intersections instead of floating in between them. Maybe that confuses mapster for circles.

It sounds a bit logic, but it seems that's not the case. I tried that out and didn't work.

EDIT: I have increased the number of vertices and it didn't work neither, it must have something to do with the sector layout.

Attached thumbnail(s)

• 
• 

[Hank]

Norvak, on 11 January 2012 - 08:52 PM, said:

It sounds a bit logic, but it seems that's not the case. I tried that out and didn't work.

EDIT: I have increased the number of vertices and it didn't work neither, it must have something to do with the sector layout.

for some reason it looks like you have two white walls on top of each other, and one gets curved and the other stays straight.

Try the 'fix error' command. You may deal with a corrupted map. Once that is true a lot of funny stuff can happen. (In your first image, the white wall below the arrow looks suspicious.) Anyway, I tested with the latest Mapster version, no errors.

[Helixhorned]

Norvak, on 11 January 2012 - 05:55 PM, said:

Someone knows why this happens? every time I want to make a circle from a square corner like this (1) that's the result (2) What am I doing wrong?

Map, please?

Also, I can't reproduce this.

[Micky C]

Helixhorned, on 14 January 2012 - 09:59 AM, said:

Also, I can't reproduce this.

For what it's worth, that sort of thing has still been happening to me occasionally, even though you did something at one stage about it in regards to TROR. So it's not an isolated incident.
Sometimes if I put it back to how it was before, and try the circle function again, it works the second time, so I don't think it's a particular situation that's causing it, although I can't speak for Norvak's experience with the bug.

[Arwu]

hi. Im post here my problem with new map. . If I move verticle over another then one of them should be deleted, but I experienced some error and this is not happen. . Verticles stay one on another. .. . Better than words is looking by yourself, maybe someone is able to reproduce this in my map ? (attachment below).. Im using r2179 and earlier not have these problems. .

EDIT: Im deleted last sectors that I created, and problem is gone. But still it is some kind of bug

Attached File(s)

•  aNEW.zip (14.94K)
  Number of downloads: 239

[Mark]

This has been brought up before recently with people choosing both sides and no definitive conclusion.

I prefer and want to return Mapster to being able to drag a sprite in the 2D mode to another sector regardless of the new sector's height. If the destination sector is higher than the present one it won't move. This happens when trying to drag a sprite up a sloped sector too. You can't. I have been using the workaround which is holding down shift and selecting the sprite, move the sprite and then press shift again to deselect. With a lot of slopes and different heights in my latest projects, I find myself having to do that extra work a whole lot of times.

I vote for returning to the old way. Who's with me? This is a recent change to Mapster so I'm guessing a lot of long time mappers might agree with me.

[Hank]

Marked, on 22 January 2012 - 04:49 AM, said:

I vote for returning to the old way. Who's with me? This is a recent change to Mapster so I'm guessing a lot of long time mappers might agree with me.

I am against it and a very old mapper. Having the ability to locate sprites in the middle of no-player areas gives errors. And usually those errors get missed until it is too late.

[thatguy]

Norvak, on 11 January 2012 - 08:52 PM, said:

It sounds a bit logic, but it seems that's not the case. I tried that out and didn't work.

EDIT: I have increased the number of vertices and it didn't work neither, it must have something to do with the sector layout.

I can confirm this was happening to me. Trying to add a circular extrusion to the ground, but instead when I confirmed the position, another wall in the same sector took the effect over the area I selected.

[Mike Norvak]

Marked, on 22 January 2012 - 04:49 AM, said:

I vote for returning to the old way. Who's with me? This is a recent change to Mapster so I'm guessing a lot of long time mappers might agree with me.

+1

Anyway if this option isn't removed you always can copy the desired sprite and it does keep an appropriate height to move it.

s.b.Newsom, on 22 January 2012 - 01:42 PM, said:

I can confirm this was happening to me. Trying to add a circular extrusion to the ground, but instead when I confirmed the position, another wall in the same sector took the effect over the area I selected.

A map with an example of this will come in handy so Helixhorned can see what's wrong:

Helixhorned, on 14 January 2012 - 09:59 AM, said:

Map, please?

Also, I can't reproduce this.

EDIT: Attached an example map.

Attached File(s)

•  CirclesBug.rar (1.64K)
  Number of downloads: 217

[Micky C]

Marked, on 22 January 2012 - 04:49 AM, said:

This has been brought up before recently with people choosing both sides and no definitive conclusion.

I prefer and want to return Mapster to being able to drag a sprite in the 2D mode to another sector regardless of the new sector's height. If the destination sector is higher than the present one it won't move. This happens when trying to drag a sprite up a sloped sector too. You can't. I have been using the workaround which is holding down shift and selecting the sprite, move the sprite and then press shift again to deselect. With a lot of slopes and different heights in my latest projects, I find myself having to do that extra work a whole lot of times.

I vote for returning to the old way. Who's with me? This is a recent change to Mapster so I'm guessing a lot of long time mappers might agree with me.

Yes! I don't care how it was in build, I'm positive that at least for a certain time, you could drag sprites into any sector and their height would be changed so that it would be inside the actual player space rather than below the floor or above the ceiling. Having this as the default behaviour makes so much more sense.

[Helixhorned]

Circle insertion problem gone now.

Since the votes are 3:1 in favor of how the dragging used to work, I guess I'll have to think about it. Just keep in mind that it wasn't changed on purpose. Rather, it was just a consequence of the tweaks that were needed for TROR.

[Mark]

I'm not familiar with the TROR reason it was changed for. I wasn't using it at the time.

What I do know is that it is very tedious work when you have an area with hundreds of sprites or models on the terrain and you need to tweak the placement of lots of them. A quick and simple drag is needed.

[Hendricks266]

Helixhorned, on 24 January 2012 - 10:35 AM, said:

Since the votes are 3:1 in favor of how the dragging used to work, I guess I'll have to think about it. Just keep in mind that it wasn't changed on purpose. Rather, it was just a consequence of the tweaks that were needed for TROR.

When in doubt, make a cvar option.

[Helixhorned]

s.b.Newsom asked somewhere whether it's possible to make Mapster32 into a more modern-looking GUI application, here's my reply:

This has very low priority on my list, as evidenced by the delay I needed to make that post...

[High Treason]

I'm not sure as to wether this is a bug or not - it probably isn't and is just a side-effect of the engine's inner workings, basically, I have a floor which slopes down, when I tried to place a switch and a few other sprites at one end of the sector, it disappeared (the cursor could still find it though) - took me a while to figure out that it was something to do with the floor height, as soon as a sprite (unless it is floor aligned) goes below that (the height of the highest point of the floor), it starts to disappear.



It's not really causing problems anyway, because all I did was swap the first wall and slope the floor up instead. I am using the Polymost renderer. It behaves the same in-game as well.

Just thought I'd point it out on the off-chance that it actually is a problem that nobody noticed.