[Mark]

We need a few more people to check their verticle panning to see if its broke or not with newer versions of eduke starting at 4696. So far me, razzy and Hekix are the only ones.

[Razzy]

Hendricks266, on 20 December 2014 - 05:34 PM, said:

Are you using Polymer? That's a Polymer problem, not an editor problem.

Yeah, since I'm playing around with dynamic lighting. And I see, thanks.

Interesting thing about he panning problem, I found an exception. If you separate the panning of top and bottom wall textures, you can pan the bottom textures vertically just fine with alt+kp2&kp8. But only the bottom wall, the top one retains the problem.

cya
Razzy

[Hendricks266]

Helix: Could this possibly be related to the changes I made in the commit about removing *printf_nowarn, where I modified the display of 2D fields ([xy]{panning,repeat}, etc.) in astub.c and you somewhat reverted it?

[Helixhorned]

Razzy, on 19 December 2014 - 05:54 PM, said:

Mapster32 displays the current panning and that it changes, but the texture remains unchanged, no actual panning takes place.

That was a Polymer invalidation logic issue, fixed in r4833. Thanks for reporting!

[Paul B]

Hi Guys,

Today, I decided to try the latest version of Mapster (20150309-5056). I am running it in Window-ed Mode 800x600 Resolution in Windows 7 64-bit. Please see my attached crash dump log and my screenshots of the crash. This crash occurred when switching from 2D to 3D using the <Enter> key in Mapster.

I just realized that this PC I am using when I crashed is using an ATI Radeon HD5450 video card; driver date: 26.01.2011. What a crappy video card! Honestly, if I knew it was ATI beforehand I would have turned a blind eye.

*** Recently Added *** The crash occurs in 800x600 32 bpp but not in 8 bpp.

Thanks for taking the time to look into this, I hope this helps provide more stability to an already awesome port!

Attached thumbnail(s)

• 
• 

Attached File(s)

•  mapster32.crash.log (4.23K)
  Number of downloads: 283

[Hendricks266]

Do any of the three buttons presented as part of that prompt allow you to continue?

[Paul B]

Hendricks266, on 10 March 2015 - 01:56 PM, said:

Do any of the three buttons presented as part of that prompt allow you to continue?

Unfortunately, they dont. It just drops me back to the desktop or if I try to continue it loops with the same error. Sorry for some reason the log didn't completely record everything the first time. Here is a more in depth log report after I attempted to continue with the error.

Attached File(s)

•  mapster32.crash.log (14.82K)
  Number of downloads: 345

[Nukey]

A few random curiousities:

1) I noticed that the DNDEBUG cheat does not dump the map exactly as it exists. Sprites are generally replaced with their parent "actor" sprite. For example, HORSEONSIDE is swapped out with WOODENHORSE, etc. I was wondering if there was a specific reason for this, as it can be very misleading. I've almost documented false information quite a few times because of it (I usually double-check everything against DOS to prevent such mistakes).

2) Mapster32 prints out a fair amount of "changelog" information to the terminal, which is really useful. I was wondering if there were any plans to implement this fully, so that any and all changes to the map are documented as they happen. Occasionally, I'll accidentally change something in the map, and have no idea what it was, so I have to reload the map and start over. This is more of a "me" problem, so I'm not officially requesting this feature, just curious.

3) There are several discrepancies between the NAMES.H that shipped with the Atomic Edition, and all other copies of it that I've ever come across. The most notorious of which is "CANWITHSOMETHING" vs "SOMETHING". Even the source code that was released seems to use names somewhere in between v1.3d and v1.5, so I have to assume the released source is not actually the same code that was compiled when they shipped the Atomic Edition. I vaguely recall reading as much, so has the real v1.5 code been lost forever, or has it been recovered during the recent "vault" ruckus?

[Hendricks266]

 Nukey, on 16 March 2015 - 06:41 PM, said:

A few random curiousities:

1) I noticed that the DNDEBUG cheat does not dump the map exactly as it exists. Sprites are generally replaced with their parent "actor" sprite. For example, HORSEONSIDE is swapped out with WOODENHORSE, etc. I was wondering if there was a specific reason for this, as it can be very misleading. I've almost documented false information quite a few times because of it (I usually double-check everything against DOS to prevent such mistakes).

2) Mapster32 prints out a fair amount of "changelog" information to the terminal, which is really useful. I was wondering if there were any plans to implement this fully, so that any and all changes to the map are documented as they happen. Occasionally, I'll accidentally change something in the map, and have no idea what it was, so I have to reload the map and start over. This is more of a "me" problem, so I'm not officially requesting this feature, just curious.

3) There are several discrepancies between the NAMES.H that shipped with the Atomic Edition, and all other copies of it that I've ever come across. The most notorious of which is "CANWITHSOMETHING" vs "SOMETHING". Even the source code that was released seems to use names somewhere in between v1.3d and v1.5, so I have to assume the released source is not actually the same code that was compiled when they shipped the Atomic Edition. I vaguely recall reading as much, so has the real v1.5 code been lost forever, or has it been recovered during the recent "vault" ruckus?

1. The maps dump the sprite's picnum, not tsprpicnum, so if WOODENHORSE uses an action to display the HORSEONSIDE frames, WOODENHORSE is the correct result in the dumped map. If it uses cactor, then that's an actual bug.

2. I don't imagine printing a full changelog would be difficult, but we do have an undo feature. Ctrl+Z in 2D mode.

3. I haven't actually compared them, but the latest Duke source in the data I was sent is mostly dated 1996-10-08, with a handful of later files dated variously up to 1996-11-20, and a zip dated 1996-12-16 that contains two files also from the October date. The zip itself that contains all this is dated 1997-02-18. This code identifies itself as v1.4. For reference, v1.5 DUKE3D.GRP is dated 1996-12-11.

As for NAMES.H, it and SOUNDEFS.H did have discrepancies between themselves and the shipped NAMES.H and DEFS.CON. I would chalk this up to a slip-up of informal organization, most simply. In EDuke32, both files should be accurate to the 1.5 CONs (plus #define FRAMEEFFECT1_13 3999, which is a v1.3D compatibility bugfix from JFDuke3D).

[Nukey]

It seems that eduke32's NAMES.H file is taken straight from the released source code (or at least JFDuke3D's slightly modified version of it). It has only these additions:

#define SPACESHUTTLE 487 (now uncommented)
#define CANNON 1810
#define CANNONBALLS 1818
#define FRAMEEFFECT1_13 3999

I dug around a bit and found that the first three are officially defined within GAME.CON (I guess you could say they're... *ahem*... "canon"), and you've already explained why the fourth one is in there, so those tiles are all accounted for...


But there's still a few tiles which appear in eduke32's NAMES.H, yet don't exist in the atomic edition:

#define FOF 13
#define GROWSPRITEICON 32 (appears in atomic's DEFS.CON)
#define CANWITHSOMETHING 1232 (appears as SOMETHING in atomic's NAMES.H, but CANWITHSOMETHING in atomic's DEFS.CON)
#define CANWITHSOMETHING2 4580 (appears as SOMETHING2 in atomic's NAMES.H, but CANWITHSOMETHING2 in atomic's DEFS.CON)
#define CANWITHSOMETHING3 4581 (appears as SOMETHING3 in atomic's NAMES.H, but CANWITHSOMETHING3 in atomic's DEFS.CON)
#define CANWITHSOMETHING4 4582 (appears as SOMETHING4 in atomic's NAMES.H, but CANWITHSOMETHING4 in atomic's DEFS.CON)

and there seems to be a lone tile which is exclusive to atomic's NAMES.H file:

#define MIMON 4120


I don't really have a point to make here, I am only bringing this up because it's become a recurring issue whenever I try to refer to tiles by their official names in the InfoSuite.

I guess I was just sniffing out some reasons as to why the source differs so much from the atomic edition.

It's a bit of a Shakespearean dilemma really

to Something, or to CanWithSomething?

[Nukey]

After sorting through everything, I've decided on CANWITHSOMETHING as the de-facto official name for those tiles (though I may keep both).

Atomic defines tile 4120 as both SCREENBREAK14 and MIMON in NAMES.H, but only the former in DEFS.CON (and it looks like I've already been down this road before, because I stuck both versions of the name in the InfoSuite).

It seems likely that FOF 13 would have survived into the Atomic Edition source code, though I don't have any hard evidence for this.

I'm writing it all down this time so I don't come back next year with the same bloody issues.

[Paul B]

I have a TROR area that I'm trying to gradually sector rotate. This is a part of a production map I am making and this is a small piece of the level so I'd prefer if only the developers were to look at it to hopefully see what's going on. When I attempt to rotate the sectors it causes some big glitches and not all verticies rotate properly even though they are selected. The map i've included has the original sector and a copy of the sector that I've rotated to the left of the original copy. This happens in both Mapster 4065 and the current build 5056.

Thanks for your time,

Paul

*** UPDATED *** I removed the map because Helix's second solution has resolved my problem using Shift+RMB rotation. I never knew about this.

Thank you!

[Helixhorned]

 Paul B, on 21 March 2015 - 04:56 PM, said:

When I attempt to rotate the sectors it causes some big glitches and not all verticies rotate properly even though they are selected.

There are two ways to rotate a set of sectors. First, by sector highlighting and using Shift+[,]/Shift+[.] ("slowly rotate CW/CCW"). This way is discouraged, since the many rotations by small angles will tend to accumulate rounding ugliness. Second, there's the method of selecting the sectors' wall-points and using Shift+RMB rotation. This one shows a preview of the result and does the actual rotation only once. However, with TROR constructions you have to make sure that you have selected all points -- automatic grayout (Ctrl-A) has to be disabled.

[Paul B]

Well, I don't mean to sound like a pest but while mapping i've come across a strange occurrence and I'm not sure what causes it? Periodically the keyboard arrow keys when used in conjunction with the left shift key typically would Pan wall textures in 3D mode. However, recently it appears that the left shift key and arrow keys now just scale the wall texutures instead. This has forced me to use the mouse to pan textures while holding the left shift key instead of using the arrow keys on the keyboard. Any suggestions on how to fix this?

[Micky C]

Use alt instead.

 Helixhorned, on 22 March 2015 - 08:57 AM, said:

However, with TROR constructions you have to make sure that you have selected all points -- automatic grayout (Ctrl-A) has to be disabled.

I'm still sure I've come across times when automatic greyout and specific greyout are disabled but I'm still not able to select the objects on all layers. Doesn't happen often though.

[Paul B]

 Micky C, on 22 March 2015 - 10:42 PM, said:

Use alt instead.

Thanks Micky, I didn't realize they changed the key assignment I must have missed that memo. =) Alt works, feels a bit awkward but i'll get use to it. =)

[Fox]

What's your country? I believe it may be because of keyboard regional detection.

[Paul B]

Fox, on 25 March 2015 - 08:12 AM, said:

What's your country? I believe it may be because of keyboard regional detection.

Hi Fox, I'm in Canada but my keyboard, language and regional settings are US English. US keyboard layout. This only happened when I went from Build version 4065 to the most current that I noticed this specific key change. Anyway, I'm adjusting to the change so its all good. Sorry for the late reply. Working like crazy on trying to pump out a TROR Multiplayer Deathmatch level before the game itself is ready. I'm recreating a famous map from the half-life engine in Mapster thanks to TROR which makes this possible. Yes, I do have permission from the authors of the original map to do this. =)

[Paul B]

Here's another crash which just happened today running a newer version of Mapster. Please see the attached crash log & screenshot.
P.S - This was using an Nvidia Graphics card. All information can be found in Mapster32.log files.

I decided to try the most current release build and it crashed again. Please see the second crash log as well. This only started happening with the newer released versions. I know, I know I'm a heavy Mapster power user. =)


***** UPDATED ***** I rebooted my machine after the two crashes and so far it has been stable. I wonder if there is any relation to using Mapster after the system has resumed from System Standby? I'll keep you posted if I notice any other strange occurrences.


Thanks,
Paul

Attached thumbnail(s)

• 

Attached File(s)

•  mapster32.log (12.46K)
  Number of downloads: 259
•  mapster32 latest.crash.log (6.37K)
  Number of downloads: 278

[Daedolon]

Unsure if this is already known, but when selecting a sector with multiple stacks (say, 3 to 4 with walls in the middle) with the 2D Mode selection too (AltGr), and saving the map while the sectors are still hilighted yellow, the saved map will have the lower stacks cut at the middle walls.

I hope that made any sense, I can demonstrate better if required.

[LeoD]

Notes on Mapster32 r5282:

- I can't zoom in and out as far as before:


- The 2D mode status bar readability has been degraded significantly.

- The 2D mode sprite colour generation from the sprite's 8-bit tile makes some of them hard to spot or almost invisible:

This desperately needs further adjustment.

[TerminX]

LeoD, on 08 July 2015 - 01:56 PM, said:

Notes on Mapster32 r5282:

- I can't zoom in and out as far as before:

You're right, I limited it. It caused issues with other changes I made and it wasn't useful to zoom out so far that the entire map is half the size of a postage stamp. Likewise, it wasn't useful to zoom in so far that one sprite fills the entire screen--you can still zoom in so far that the smallest grid lines are 1:1 with the individual pixels of a texture when using the texture expansion bit.

Quote

- The 2D mode status bar readability has been degraded significantly.

Does it affect anything more than the additional text your custom builds add to the build string? I don't see a problem with the white and yellow text actually used by the status messages. It's easy enough to change it back, I just thought it was time for a change and it reminded me a bit of the 90's.

Quote

- The 2D mode sprite colour generation from the sprite's 8-bit tile makes some of them hard to spot or almost invisible:
1155-r5282.png 1155-r5282hover.png 1426-r5282.png 1426-r5282hover.png
This desperately needs further adjustment.

I agree with this one! There are definitely a few cases where the colors it picks need improvement, particularly anything that ends up with that darker blue shade.

[Paul B]

TerminX, on 08 July 2015 - 04:56 PM, said:

You're right, I limited it. It caused issues with other changes I made and it wasn't useful to zoom out so far that the entire map is half the size of a postage stamp. Likewise, it wasn't useful to zoom in so far that one sprite fills the entire screen--you can still zoom in so far that the smallest grid lines are 1:1 with the individual pixels of a texture when using the texture expansion bit.

I know in my last map I finished I appreciated the Zoomed in feature a lot. It helped me with tagging small sectors that you could barely see. I think the zoomed in feature is much more practical then the zoomed out feature. Is it possible to change one way and not the other? I'd prefer if we were able to zoom in far for doing detailed sector tricks.

[TerminX]

You can still zoom in pretty far, but I'll restore the previous zoom level. It turns out that the code I wrote that broke when zoomed in that far changed enough before I committed it that it doesn't break anymore.

[TerminX]

I committed r5283, it addresses all concerns.

[LeoD]

TerminX, on 08 July 2015 - 04:56 PM, said:

Does it affect anything more than the additional text your custom builds add to the build string? I don't see a problem with the white and yellow text actually used by the status messages.

I read that line a lot when making maphacks, so thanks for changing it back.

The representation of tile1426 is still hard to spot, but I suppose we can't have everything, can we?

[Paul B]

Hi TerminX,

Here is what happens when I try to use the new (picture in picture) feature using setrendermode 4 (Polymer) in Mapster.

I've noticed that if I start a newboard, the feature appears to work. If I load an existing map, the screenshot with the color bars is the end result and eventually this leads to a crash. I've attached the crash log and screenshot of the crash below.

Oddly enough, some maps work okay with the preview window and others do not. I'm not sure if this is because some maps have TROR and others don't? I'm not sure why some times it works with the preview and other times it doesn't. But it does depend on the map file or version in some way.

Yes, I can finally confirm that this problem seems to stem from maps that use the TROR feature. Hopefully this helps track down the problem.

Attached thumbnail(s)

• 
• 

Attached File(s)

•  mapster32.crash.log (2.49K)
  Number of downloads: 171

[TerminX]

I fixed that last night but didn't commit it yet.

[Paul B]

Not sure what's going on? I just updated to the latest synthesis build "20150713-5295" and I've noticed since switching to this build my latest map now suffers from massive texture tearing all over the place. I know for a fact I didn't release this map with any stretched or mis-aligned textures and now they are all over the map. Any suggestions as to what might have caused this?

Restoring back to 20150614-5267 corrects the problem. I'm not sure at what point this would have changed but probably just recently. I'm using Polymer to run my tests. When I have more time i'll try and narrow it down even more.

[Daedolon]

TerminX, on 08 July 2015 - 04:56 PM, said:

Likewise, it wasn't useful to zoom in so far that one sprite fills the entire screen--you can still zoom in so far that the smallest grid lines are 1:1 with the individual pixels of a texture when using the texture expansion bit.

Sounds like it still would make doing 1 build unit editing tougher than before, as it already was hard enough in most cases. It's one of the things I use constantly when mapping.