[Helixhorned]

Arwu, on 07 February 2013 - 01:52 PM, said:

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 : )

Glad you're enjoying the Mapster features! You (speaking of everyone) should get into the habit of backing up your work, at least by pulling it on an external stick/HDD from time to time.

Quote

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.

That's what LShift-[ and LShift-] are for, which will take you through all matching sprites starting at a particular one.

[Gambini]

I make backups every two hours of work and prior to any important change. I send emails to myself with these files.

[Micky C]

I only just started storing a few of my Duke folders on Google Drive. So even if my hard drive crashes, I can just download all my work on any computer. It syncs automatically which streamlines the whole backup procedure. Dropbox is just as good, but Drive offers more than twice as much space for free use.

@Helixhorned, glad I could help
The feature will make the mapping of my Serious Sam episode less tedious for wave management.

[Gambini]

I´m utilzing this thread since it´s the one that Helix checks the most, and AFAIK he´s the one on charge of these things. Once again my problems aren´t worth a thread (not even an answer in most cases). So, sorry for the OT.

Software renderer shows an ugly edge on all sprites with non solid borders. It is more noticeable on big flat sprites but it´s not limited to them:

(I´m using original maps as examples just to show it´s not because if intrincate stuff I made)

Sky is replaced to make it easy to see the glitch

Now, with a smaller sprite:



And, even visible in small view relative sprites:



I´m not sure if this is new, I could check if needed. But it all sounds like the game didnt have such ugly visual glitch, and either way calls for a fix (or an attempt at least).

Now, this is another glitch and this one is definetely new. It happens with maskwalls and only in software mode. Basically when there are a couple of sprites behind a maskwall -even if they are far away, even if the maskwall is solid- they will be drawn on top of it. I didn´t find an original map where this is obvious, but I don´t know the original maps too well. This is the best shot I could take but I warranty the problem is much worse. Again, this wasn´t like that in the old times:



That´s all for now. I hope there´s a fix for them next to the corner.

[Micky C]

Thanks for pointing that out gambini, software renderer is very important.

Btw guys I'm having a problem. I'm using the HRP, and the menu is filled with white boxes!
Also, the RPG looks off. I can provide pictures if needed.

But still, despite these issues I think eduke32 is the best mod ever

[Hendricks266]

FUCK YOU NOOB! DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE DIE!

Spoiler

[Gambini]

You should be friendly with newcomers. At least until they feel comfortable, then bury them fucking down!!

[Helixhorned]

Gambini, on 08 February 2013 - 02:07 PM, said:

Software renderer shows an ugly edge on all sprites with non solid borders. It is more noticeable on big flat sprites but it´s not limited to them:

Alright, more or less fixed in SVN HEAD. This was one of the hardest classic renderer bugs to track down, involving sitting for hours over a nine-page source code printout. Just to make sure, that bug existed in the original Duke3D, but how it looks changed with the introduction of proper non-power-of-two y size texture mapping. (For sprites, it doesn't significantly change the appearance, but it prevents accessing tile memory out-of-bounds.)

Quote

Now, this is another glitch and this one is definetely new. It happens with maskwalls and only in software mode. Basically when there are a couple of sprites behind a maskwall -even if they are far away, even if the maskwall is solid- they will be drawn on top of it.

This seems like an instance of an already reported sprite drawing bug in the presence of masked walls, the one where the OP provided a map with a liztroop between two fences. By the way, to the engine, masked walls are the same regardless of whether they contain see-through texels (value 255). If you want a red wall to behave so that sectors behind it aren't collected for drawing etc., you should set it to one-sided in Mapster32 (you'll notice an FPS increase when standing close to it).

[Gambini]

But if i set it to 1 sided the translucent part becomes black solid!

BTW Thanks for fixing the ugly edge thing! Really appreciated!

[Paul B]

The problem I was having with the shift key and aligning textures not working properly and all those glitches I was complaining about in Mapster was because I had two keyboards connected to the same PC unknowingly. I use my PC as a Media Center PC as well as a computer. I have a long HDMI cable that runs from my PC to my Stereo Tunner which feeds a 3D TV upstairs. I also have a 50ft USB cable that runs from my PC downstairs to a USB hub upstairs for my keyboard and mouse so I can watch downloaded movies or play the occasional car racing game on the couch upstairs. As you can tell I prefer wired devices over wireless =P. Anyway, needless to say, when my upstairs USB keyboard\mouse were left connected to my PC downstairs it would cause many really frustrating annoyances in Mapster which I thought was a fault of Mapster.

I know Helix thought it might have been something to do with the keyboard layout or regional settings of my PC or a key mapping config fault. However, since unplugging the extra USB hub\keyboard\mouse upstairs I am not experiencing those glitches in Mapster. Just wanted to share my grief and solution as maybe... one day it might help someone else.

Note to self: Don't try using two keyboards and mice on the same computer it won't make you more efficient in Mapster! =)

Thanks for having patience with me Helix and everyone else who was putting up with my whimper.

[Forge]

it's not a bug, but it can get annoying:

mapster32: when alt-tabbing out and back in

texture in the clipboard is replaced by texture that is in current

it'd be nice if there's a way to over-ride tab when alt-tabbing beside messing with the key bindings

[Helixhorned]

Forge, on 23 February 2013 - 08:28 AM, said:

it's not a bug, but it can get annoying:
mapster32: when alt-tabbing out and back in
texture in the clipboard is replaced by texture that is in current
it'd be nice if there's a way to over-ride tab when alt-tabbing beside messing with the key bindings

What happens if you lower the console/OSD first?

[Forge]

dropping the console or just simply switching to 2D mode is fine. i just need to change my habits to do that instead of working in 3d mode when i alt-tab in and out.

i wasn't paying attention to the clipboard and i was texturing something. i would alt-tab in and out to reference my notes and pictures of real-world locations that had texture combos i found interesting. course tabbing changed the clipboard and surprised me when i tried to texture a wall and got something i wasn't expecting. then it's annoying having to re-scroll through the textures to get the one i want.

stupid thing is i know what causes it, but i get so caught up in what i'm doing and it's an unconscious action to tab out, that i keep doing it over and over.

i was thinking that there was some way to make alt "cancel" the tab button.

for example (in 3D mode) using "t" on a sprite makes it transparent, but pressing '+t only changes its tag, it doesn't make it transparent as well. the use of the ' key "cancels" the transparent command

[The Commander]

Helixhorned! you broke Mapster with r3509.

You can no longer move around the board in 2D or 3D with the arrow keys!

[Helixhorned]

Oops, I forgot to initialize a variable, but that wouldn't be noticeable when running with a.m32 because it's constantly set from there. Thanks for the alert; fixed in r3532.

[Micky C]

Let's see how well I can explain this. The yellow squigly line represents a sector, and the green squigly line represents another sector that's been made from the void area, and stretched out so that the green and yellow sectors overlap.
But when I enter the green sector as a player across the red line, then go past the white wall, and try to leave the sector the way I came, the white wall (circled in blue) is actually blocking the player. That's not how it used to be right? I swear in the past you could go in and out of a SOS situation like this without any trouble, it feels like a bug to me. The white wall has nothing to do with the green sector. The map uses TROR BTW.

There's also a visual glitch in that you can see the back of the void sector through the opening, and the texture kind of zooms as you move closer or further away. I also swear you used to be able to look out of one of these sectors without that happening.




Another thing, the mode that removes sector boundaries (ctrl-alt-a I think) doesn't work when you restrict the editing height range with ctrl-r. Can this be made to work with ctrl-r as well? I don't see why it should only work for the automatic ctrl-a height restriction. I'm working on a very, very complex map (in terms of TROR) and it's gotten to the stage where it's almost impossible to work with because of this.

[Arwu]

-.- It is possible to insert in mapster a function to make highlightened ceilings/floors/sprites to set on some height simply in maybe 'F menu ??
... ;p. for now it is only possible using some m32 scripts . These needed and simple functions should be in mapster..

[Forge]

Arwu, on 27 March 2013 - 03:12 PM, said:

-.- It is possible to insert in mapster a function to make highlightened ceilings/floors/sprites to set on some height simply in maybe 'F menu ??
... ;p. for now it is only possible using some m32 scripts . These needed and simple functions should be in mapster..

not sure exactly what you're trying to accomplish, but using F7 (or F8?) in 2D mode lets you adjust height(one item at a time?) by manually punching in the number you want

[Arwu]

; p. Im thinking about seting many sectors at once to specific height. something similiar is already done: set sky height (in 2D mode 'F menu)

[Micky C]

Ah, I think he's talking about a Z-coord shift. There's already a global Z-coord shift in the special functions menu, HOWEVER that's pretty useless IMO. Currently you need to copy map sections to different maps to shift their z position and copy them back, and you might have to do that several times to get the right height. So I think this is an absolutely essential feature.

Actually I'm not sure what he's talking about. Either way, the feature I talked about above would be incredibly useful.

[Arwu]

in 2D mode, with F7 (or F8 ? ) it is possible to change height but only one floor/ceiling at a time. My point is: all highlightened floors/ceilings should go to desired height It will be nice if that working for sprites too.

[Helixhorned]

Trooper Mick, on 22 March 2013 - 08:50 PM, said:

Let's see how well I can explain this. The yellow squigly line represents a sector, and the green squigly line represents another sector that's been made from the void area, and stretched out so that the green and yellow sectors overlap.
But when I enter the green sector as a player across the red line, then go past the white wall, and try to leave the sector the way I came, the white wall (circled in blue) is actually blocking the player. That's not how it used to be right? I swear in the past you could go in and out of a SOS situation like this without any trouble, it feels like a bug to me. The white wall has nothing to do with the green sector. The map uses TROR BTW.

I'll reply to you in PM.

Quote

Another thing, the mode that removes sector boundaries (ctrl-alt-a I think) doesn't work when you restrict the editing height range with ctrl-r. Can this be made to work with ctrl-r as well? I don't see why it should only work for the automatic ctrl-a height restriction. I'm working on a very, very complex map (in terms of TROR) and it's gotten to the stage where it's almost impossible to work with because of this.

This is what I said when I wrote that functionality:

Helixhorned, on 04 July 2011 - 01:29 PM, said:

Revision 1928 addresses posts #180 and #181. Specifically,

(...)

• Make it possible to not display inner gray walls, toggled with Ctrl-Alt-A, but only when no manual grayout (Ctrl-R) is in effect.

For the non-displaying of gray walls, the restrictions -- only inner walls, no manual grayout -- are there because otherwise you could end up with "dangling walls". The very first TROR version (r1888) suffered from that.

I think what I meant is that you could end up with "loose" red walls displaying without their enclosing sectors, and that would be confusing because you might end up accidentally creating invalid geometry (e.g. overlapping walls of the same sector). I'll commit a change that will make it easy to disable that restriction, but I don't think removing it from mainline Mapster32 is a good idea.

Arwu, on 27 March 2013 - 03:12 PM, said:

-.- It is possible to insert in mapster a function to make highlightened ceilings/floors/sprites to set on some height simply in maybe 'F menu ??
... ;p. for now it is only possible using some m32 scripts . These needed and simple functions should be in mapster..

Should be easy with a M32-Script one-liner (untested):

do for i selsectors, set sector[i].ceilingz SOME_Z_VALUE

,
similarly for .floorz.

Oh, and m32script states can be hooked to menu entries by writing a menu name after the defstate. For example, from a.m32:

defstate extendhlsectors
    "Extend all hl. sectors"
    // the actual code...
ends

more edit: then there's getnumberfromuser. Now all that's left to do is to connect these pieces .

[fgsfds]

Enemies don't drown in ror water.
This water has blocking bit from both sides and SE7.

[Fox]

They have not been coded to.

[fgsfds]

Why? They sink in regular non-ror water.

[Forge]

he may be referring to your use of the word "drown"

enemies don't run out of air and drown like the player

[fgsfds]

Yeah, I meant, they shouldn't walk on water surface.

[Forge]

you should have posted or read here:

http://forums.duke4....post__p__154516

or here:

http://forums.duke4....post__p__154876

since they're already talking about similar issues

[fgsfds]

These 2 are completely different cases and have nothing to do with what I've described.

Also, the same thing with pickups. They sink normally in simple water but bounce for a few seconds on ror water surface.

Attached thumbnail(s)

• 

[Forge]

don't get your fur up

i didn't say the "same". i said "similar"

i was suggesting posting in the other location to get more attention to your observations since technically this isn't a "mapster32" issue, it's a game mechanics issue.

you also didn't follow the guidelines when posting the "bug"

http://forums.duke4....dpost__p__43774

but i'm sure our delightful back and forth banter has attracted some attention. positive or negative has yet to be seen

good luck with your "mapping" bug