Mapster32 problems and bugs "Please post them exclusively here"
#1201 Posted 20 December 2014 - 05:41 PM
This post has been edited by Mark.: 20 December 2014 - 05:42 PM
#1202 Posted 20 December 2014 - 06:57 PM
Hendricks266, on 20 December 2014 - 05:34 PM, said:
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
#1203 Posted 20 December 2014 - 07:26 PM
#1204 Posted 21 December 2014 - 08:53 AM
Razzy, on 19 December 2014 - 05:54 PM, said:
That was a Polymer invalidation logic issue, fixed in r4833. Thanks for reporting!
#1205 Posted 10 March 2015 - 08:48 AM
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 File(s)
-
mapster32.crash.log (4.23K)
Number of downloads: 281
This post has been edited by Paul B: 10 March 2015 - 09:08 AM
#1206 Posted 10 March 2015 - 01:56 PM
#1207 Posted 10 March 2015 - 02:04 PM
Hendricks266, on 10 March 2015 - 01:56 PM, said:
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: 342
This post has been edited by Paul B: 10 March 2015 - 02:53 PM
#1208 Posted 16 March 2015 - 06:41 PM
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?
#1209 Posted 16 March 2015 - 07:32 PM
Nukey, on 16 March 2015 - 06:41 PM, said:
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).
#1210 Posted 16 March 2015 - 09:35 PM
#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?
This post has been edited by Nukey: 16 March 2015 - 10:26 PM
#1211 Posted 16 March 2015 - 10:47 PM
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.
This post has been edited by Nukey: 16 March 2015 - 11:45 PM
#1212 Posted 21 March 2015 - 04:56 PM
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!
This post has been edited by Paul B: 22 March 2015 - 09:24 AM
#1213 Posted 22 March 2015 - 08:57 AM
Paul B, on 21 March 2015 - 04:56 PM, said:
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.
#1214 Posted 22 March 2015 - 10:08 PM
#1215 Posted 22 March 2015 - 10:42 PM
Helixhorned, on 22 March 2015 - 08:57 AM, said:
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.
This post has been edited by Micky C: 22 March 2015 - 10:43 PM
#1216 Posted 24 March 2015 - 11:13 AM
Micky C, on 22 March 2015 - 10:42 PM, said:
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. =)
#1217 Posted 25 March 2015 - 08:12 AM
#1218 Posted 27 March 2015 - 06:04 AM
Fox, on 25 March 2015 - 08:12 AM, said:
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. =)
This post has been edited by Paul B: 27 March 2015 - 06:10 AM
#1219 Posted 30 March 2015 - 04:26 PM
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 File(s)
-
mapster32.log (12.46K)
Number of downloads: 256 -
mapster32 latest.crash.log (6.37K)
Number of downloads: 276
This post has been edited by Paul B: 30 March 2015 - 06:57 PM
#1220 Posted 01 April 2015 - 07:13 AM
I hope that made any sense, I can demonstrate better if required.
#1221 Posted 08 July 2015 - 01:56 PM
- 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.
#1222 Posted 08 July 2015 - 04:56 PM
LeoD, on 08 July 2015 - 01:56 PM, said:
- 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
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
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.
#1223 Posted 08 July 2015 - 05:13 PM
TerminX, on 08 July 2015 - 04:56 PM, said:
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.
This post has been edited by Paul B: 08 July 2015 - 05:14 PM
#1224 Posted 08 July 2015 - 05:47 PM
#1226 Posted 09 July 2015 - 06:52 AM
TerminX, on 08 July 2015 - 04:56 PM, said:
The representation of tile1426 is still hard to spot, but I suppose we can't have everything, can we?
#1227 Posted 09 July 2015 - 04:43 PM
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 File(s)
-
mapster32.crash.log (2.49K)
Number of downloads: 168
This post has been edited by Paul B: 09 July 2015 - 05:02 PM
#1229 Posted 13 July 2015 - 07:53 PM
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.
This post has been edited by Paul B: 13 July 2015 - 07:59 PM
#1230 Posted 13 July 2015 - 10:50 PM
TerminX, on 08 July 2015 - 04:56 PM, said:
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.