[Helixhorned]

Oops, thanks for noticing. The z value was uninitialized, in fact.

@anyone who is mapping near the limits: you're encouraged to try out the latest revision. Don't forget to follow Gambini's good example and keep backups, though!

[Stabs]

cheers helix

i thort i was going mad

[Gambini]

hehe thanks for the encourage man! I was somewhat afraid of crossing that safe line of 16200 walls that Forge pointed out. But i had to backdate my mapster copy today to 1798 because with 1800 and ahead. In some instances, when trying to drag vertices, they don´t get highlighted and you drag the nearest vertice or sprite instead. This doesn´t happen to all vertices (in my case these were vertices very close to some line of another vector) but with the ones it happens, there is no way to drag nor select them (for much you move away neighbour vertices/sprites).

note: There´s no corruption message when loading the map, and the problem doesn´t exist in a mapster copy i have from january 2009 nor in 1798*.

*that number stands for the synthesis snapshot, and not the year. Just in case some genious had in mind to make a joke.

[Plagman]

If I start a new map and draw a test room, all of the walls have repeat set to 0,0. Is that intended?

[Stabs]

Helix, this is not a bug but a suggestion,

In mapster 3d mode has a default global vis 512 changed via alt + ctrl + numpad+/- , setting this to 128 is far more like the edukes default 1.0 ambient lighting.

i think it would be best if mapsters global default vis is 128 which is very similar to edukes 1.0 setting
this will give mappers a far truer indication what their map will look like in-game.

off topic the vis is so heavy in this, there is no point for vis levels 120+ as it makes no difference at that point, but i guess thats an eduke issue, it could scale out the vis so much better, there is the 240 - 255 values but they are too extreme and leave things looking to bright.

[Danukem]

DanM, on Feb 28 2011, 12:36 AM, said:

Helix, this is not a bug but a suggestion,

In mapster 3d mode has a default global vis 512 changed via alt + ctrl + numpad+/- , setting this to 128 is far more like the edukes default 1.0 ambient lighting.

i think it would be best if mapsters global default vis is 128 which is very similar to edukes 1.0 setting
this will give mappers a far truer indication what their map will look like in-game.

I know you have been making a map for WGR2 lately, so keep in mind that the default visibility in WGR2 is different from regular Duke. If you are basing this off that map that may explain the discrepancy between mapster and game.

[Helixhorned]

Reported bugs fixed. I was reorganizing some code, mainly for easier reading, and they crept in. There are probably more, so keep them coming!

As for the visibility -- I always thought that it was one of the more mysterious corners of Duke. Besides sector and per-player visibility, there's now also the Polym{ost,er} switches and I'm rather ignorant about how they relate to each other. What Mapster32 calls "global visibility" appears to be a preview feature for the game's per-player one, as seen in DNWMD's "blinding" Octabrains.

[Gambini]

Quote

Reported bugs fixed.

Great.

I don´t think visibility should be changed in mapster. in 8bits it´s pretty much accurate, and in polymost it used to be like that too. And with this i mean i didn´t ever notice a difference between game and editor.

[Stabs]

well if wgr has tweaked vis that prolly where the difference is

personally i wish the vis could get some good medium balance, its either too far away or too close

[Danukem]

DanM, on Feb 28 2011, 12:22 PM, said:

well if wgr has tweaked vis that prolly where the difference is

personally i wish the vis could get some good medium balance, its either too far away or too close

DEFAULTVISIBILITY as set in the standard USER.CON is 512. For WGR2 I changed it to 256, which lets you see twice as far. At that time all the maps were big outdoor daytime maps and it was annoying to have it fade to black a few hundred feet in front of your face for no apparent reason.

[Gambini]

New/old problem, used to happen before every once but now it´s happening a lot more often:

When aligning a sprite to a wall (pressing O either in 2d or 3d mode) it usually gets stuck into the wall but facing it at 90 degrees.

[Gambini]

Sorry for being this good reporting bugs but here´s another one, pretty old too (it´s just that today i figured out why it happens)

You know that if you move sprites either one by one or by groups (sector selection seems to be the only exception) all the ones that are clipping into the floor/ceiling will be readjusted in their height (to be fully inside the space between floor and ceiling). Ok.

Now, the problem: When manipulating relative to floor sprites, if their z coordinate is higher than what it would be if they weren´t floor relative sprites mapster will adjust their height anyway. I mean: It´s difficult to explain: The sprites think they are relative to view and thus they are readjusted like if they were clipping the ceiling, even when they aren´t. It doesn´t happen with the floor AFAIK because their z position is taken from the bottom.

If it´s still difficult to understand, make this simple test:

- Put any no actor sprite sized z:8192 (the sector should be taller).
- Aling it to the ceiling, pressing ctrl+pgup.
- Press pgup a few more times (always aiming to the sprite) to make it clip the ceiling.
- Then go to 2d mode and move the sprite (or simply hold it with the mouse right buttom).
- Go to 3d mode again and you´ll see the sprite is again aligned to the ceiling.

Now, repeat the aforesaid process this way:

- Put any no actor sprite sized z:8192 (the sector should be taller).
- Make it relative to floor and two sided (the latter, just to make it easier to be seen).
- Aling it to the ceiling, pressing ctrl+pgup.
- Then go to 2d mode and move the sprite (or simply hold it with the mouse right buttom).
- Go to 3d mode again and you´ll see the sprite got moved down 8192 units.

As seen, in the second example, there´s something wrong.

I hope it´s easy to fix because every time I copy or move spritemade roof lamps, have to align its sprites manually.

[Helixhorned]

Nice catch! Annoyances like this should be exterminated!

[Stabs]

i move all ceiling clipping sprites by selecting the with left shift first, seems to keep their height

[Scott_AW]

I noticed my sprites where placing high in 3d mode, but I'll check out the newest build which I think fixes this?

Anyone know what I'm doing to occasionally duplicate sprites when I select a sector with right-shift? It doesn't happen all the time, just some times.

[Stabs]

"insert" & c dupes sprites, its got me a few times and had to go back delete quite a few sprites

maybe it should say in the status bar "X SPRITES SELECTED" when you have sprites selected

[Gambini]

The grid limit has been reduced, and editing mapster32.cfg doesnt help. I have a big part of the map outside the reacheable area and can´t edit it now.

[TerminX]

Use an older version to move the section of map back into a space that won't cause all sorts of calculations in the game and engine to overflow.

[Danukem]

TX, on Mar 3 2011, 06:07 PM, said:

Use an older version to move the section of map back into a space that won't cause all sorts of calculations in the game and engine to overflow.

Wait, are you saying that the max grid size is going to be smaller from now on because it was discovered that large grids caused the problems you just mentioned?

[TerminX]

Sorta. The grid size was reduced, but that change was made months (maybe more than a year?) ago.

[Forge]

...around a year ago. i made the same complaint as gambini, you told me to shut up or you'd shove a puppy up my arse, i said I'll just backdate my mapster32 & move my map to where i can work on it...

[Gambini]

Is this related to polymer? because i don´t really use it, so i guess you could just put a warning instead of limiting the grid size to all users. I mean: the Dukeplus community build project is utterly fucked up now because it has a corruption outside the grid that i can´t fix. If i use an older version of mapster to move the part inside the new limit, all the map will be a mess because not everything fits.

Also: another thing that has nothing to do with this:

The map where im working on now makes eduke32 crash when dnshowmap+textured automap are enabled. i wanted to run the debug eduke32 just to see if it could drop some usefull information but SURPRISE: there´s no way to make it crash in exactly the same situation! There HAS to be a difference between one and the other, and i suggest we could just take the good from one to the other.

[TerminX]

No, it has nothing to do with Polymer, it has to do with the engine and everything itself. It's a simple fact of the coordinate values being so large that the various calculations the engine has to do involving them start to overflow and produce completely incorrect results. Think of weird movement problems, projectiles aimed where they shouldn't be, interpolation issues, monsters that think Duke is in the wrong place, etc. The possibilities for problems are fairly endless. The grid size never should have been made that large in the first place and nobody noticed the problems for a long time because nobody was using that much of the grid. Why would the map be a mess with the one section moved back into a safe area? I'm not really seeing how that's possible since there's no way the map takes up THAT much space.

As for the 2d map issue, the only difference between the exes is the optimization flags passed to the compiler/linker. The bug you're running into exists in both, it's just causing more problems that you can actually see in the optimized build because of how the compiler decided to move stuff around. Feel free to email us the map and we'll run it through valgrind or something.

[Scott_AW]

Thankfully the grid space has been big enough for me, but it makes me wonder about build games that increase this area and what they might of did to compensate for that. Redneck Rampage and I think another one did this.

Personally I'd like to see the limits on at least walls increased, but thats just a suggestion. I find that you're more likely to run out of walls then sectors or sprites.

[TerminX]

The grid in Mapster32 is much, much bigger than Redneck Rampage or any other BUILD game ever was. It's variable sized. What we're discussing is the max value for the "editorgridextent" setting.

[Gambini]

TX, on Mar 4 2011, 01:10 AM, said:

No, it has nothing to do with Polymer, it has to do with the engine and everything itself. It's a simple fact of the coordinate values being so large that the various calculations the engine has to do involving them start to overflow and produce completely incorrect results. Think of weird movement problems, projectiles aimed where they shouldn't be, interpolation issues, monsters that think Duke is in the wrong place, etc. The possibilities for problems are fairly endless. The grid size never should have been made that large in the first place and nobody noticed the problems for a long time because nobody was using that much of the grid. Why would the map be a mess with the one section moved back into a safe area? I'm not really seeing how that's possible since there's no way the map takes up THAT much space.

Granted. Now, i just have this thought: why not making something that enlarges (or just offsets) the grid when the map has gone beyond the limits? Case, this DPCB map. So people can keep editing the map, without the need of running into such a trouble of backdating mapster to an old and most likely unsafe version. I´m certainly scared of fucking things up if the snapshot i take has any kind of corruption problems like those we already know from a few years back.

The case of this map is that it is a community build project, and that isolated area i should move has been made by somebody that isnt around anymore, if i move the area within the new limit, some effects will stop working (as all those SE´s that are stuck underground) and i can´t really tell how they did them so i can´t fix them. Also, the rest of the map is just as big as the new grid limit and it´s also slightly outside of it. So overall i have to re-arrange the whole map with all the potential problems... just to delete a few sprites that are outside the valid sectors, and to fix a few sprites sectnum that are wrong.

Quote

As for the 2d map issue, the only difference between the exes is the optimization flags passed to the compiler/linker. The bug you're running into exists in both, it's just causing more problems that you can actually see in the optimized build because of how the compiler decided to move stuff around. Feel free to email us the map and we'll run it through valgrind or something.

What´s valgrind? If the problem persists i´m gonna send you the map, but not before the beta stage. It´s just that the map is going to be an epic experience in your life, to the point that you will be ringing all your ex-classmates from elementary and high school to tell them how amazing it was! And i dont want to spoil an unfinished version yet.

[TerminX]

Valgrind is a debugger available on Linux which audits memory reads and writes to look for errors. It's useful to catch cases of memory corruption which are otherwise hard to track down because they don't necessarily crash the game.

[Hendricks266]

Is there a tutorial for hubmaps anywhere? That's the ideal solution.

[Danukem]

Hendricks266, on Mar 3 2011, 09:07 PM, said:

Is there a tutorial for hubmaps anywhere? That's the ideal solution.

It's too late for that. Even if the map were split up into multiple maps (which would be a nightmare at this point), there is still the problem of moving the part that is off the grid, and as Gambini explained that is the real problem.

Last time I checked, the map worked fine (aside from low frame rate in Polymer), so maybe it's best to leave it alone.

[Gambini]

No i don´t want hubmaps. My goal is to make a map, that is fun and gives to the player a memorable experience, all that in one and nothing more than one file.