[Helixhorned]

Paul B, on 14 July 2012 - 09:14 AM, said:

Found new sprite bug. (I think)

When you take a multiplayer switch if it has a palette of 1 it only appears in multi-player when it is wall aligned. If the switch is floor aligned it appears blue and isn't removed.

I am trying to do a ladder in my Duke map that is only available for multi-player so I want to give these sprites a palette of 1 so they only appear in multiplayer. I don't want people to use this ladder in single player. Shouldn't all switches that have a palette of 1 be removed from the game regardless of their alignment?

Not a bug, since that happens in Duke 1.5 too.

[Paul B]

Helixhorned, on 15 July 2012 - 02:23 AM, said:

Not a bug, since that happens in Duke 1.5 too.

Okay Helix thanks and sorry I don't mean to be wasting your time. I guess i'll have to think of something else instead of a multi-player ladder. Anyway, since I am on a rant on this topic I thought i'd mention that I am experiencing some annoying problems with the mapster clipboard or the tab and shift and enter functions. Sometimes they work sometimes they don't. Sometimes just the shade gets copied and not the texture other times the texture and not the shade. The most frustrating is when it totally changes the texture on me all together and only copies ths shade value. This occurs when trying to duplicate textures on walls and shade them.

Also another problem I've noticed is with sprites. When placing a sprite it seems I have severe corruption in memory because the wrong sprite is stuck in memory and always gets placed even if I copied another sprite and the relativity is not set properly on it. This is rather annoying and I never noticed these problems in earlier builds that I can remember it only seems within the last 3 months or so that these problems surfaced. If anyone knows what I am referring to and is experiencing these problems please reply to this thread. Surely I can't be the only one with these problems. These occurances are random but frequent and it definitely slows the process of mapping down because I have to do things sometimes serveral different times before it works.

Another problem that I also noticed as well. I tried to texture a swinging door. For the life of me hitting the "F" key to flip the texture a thousand times would not allow me to flip the texture in the other direction. I had to delete the wall then retexture and flip the texture before it worked again. This is also another issue. So it's like the X and Y and X flip occur but not the Y Flip maybe if that makes sense. It seems to skip the rotation and that drives me nuts as well. These are all things I don't ever remember running into when making the Parkade map and I suspect these problems started occuring shortly after March of this year. I hope that helps again my mapster version i'm running is build 2834.

Thanks

[Micky C]

Were sprites such as health and ammo always able to fall through blocking sprites? Both actors like vent panels and regular sprites?

[Paul B]

Something else i've encountered with TROR. When you have a TROR tile surface you can only align it on one axis. Either X or Y but you can't align textures on TROR tiles for both at the same time.

Is this suppose to be this way because its tough to make something look pretty when its going to be offset one way or another.

[Micky C]

Yep, that's how it's supposed to be. Part of that information is used for the TROR itself. It's always been like that.

[Paul B]

Micky C, on 19 July 2012 - 01:10 AM, said:

Yep, that's how it's supposed to be. Part of that information is used for the TROR itself. It's always been like that.

Not like I understand anything about that. I guess i'm just wondering if that will ever change or is planned on being changed at some point to free up that other axis.. Thanks Micky, you're a fountain of knowledge.

[Hendricks266]

Paul B, on 19 July 2012 - 06:58 AM, said:

I guess i'm just wondering if that will ever change or is planned on being changed at some point to free up that other axis.

Yes, it is.

[Player Lin]

Hendricks266, on 19 July 2012 - 12:52 PM, said:

Yes, it is.

......what? "Purely textual external map representation like UDMF(aka: TextMap)"?! Sounds like interesting for some reasons...

[Helixhorned]

@Paul: I think the first two, and maybe the flipping, may be related to your input problems. For example, it could be that some modifier keys get "stuck" for some obscure reason. Do you have a possibility to run Mapster32 from another system just to test this conjecture? Sprites are inserted like that in 3D mode: if a sprite has been copied to the clipboard, that picnum is inserted. Otherwise, the inserted sprite has that picnum which occurs most often in the map.

@Trooper Dan: I recall you posting an issue with Polymer and Attrition which looked like tile corruption. I never got around to testing it (and wouldn't know where to start looking anyway). Does it still happen?

[Helixhorned]

Paul B, on 16 July 2012 - 10:00 PM, said:

These occurances are random but frequent

That they're random makes hunting them down a little harder, though if they're frequent, wouldn't it be possible to construct a test map in which it's reproducible with high probability after a given number of trials? That would help a lot more that merely a description, since I'm not getting any of them.

[Danukem]

Helixhorned, on 22 July 2012 - 03:40 AM, said:

@Trooper Dan: I recall you posting an issue with Polymer and Attrition which looked like tile corruption. I never got around to testing it (and wouldn't know where to start looking anyway). Does it still happen?

I don't know, because I haven't been playing lately. That particular bug would be difficult to replicate because it would happen pretty far into a game. I only recall it happening on levels where there was a shitload of stuff going on.

[Nukey]

I've found an extremely minor bug/oddity which I may as well report since it will probably never be noticed again in the history of mankind. It's that minor.

A sprite using texture #625 (one of the camera frames) triggers the crane and will be picked up and carried in the original DOS version of the game, but not in EDuke32.

edit: I should probably also mention that the sprite 'floats' in mid-air when released, but this doesn't need to be fixed since the other camera frames and loads of other sprites do the same in both versions.

[Nukey]

Caught a bug!

The DNSHOWMAP cheat displays the "Show Map: On" message but not the "Show Map: Off" message. The game is practically unplayable now.

[LeoD]

Nukey, on 22 July 2012 - 01:01 PM, said:

Caught a bug!

The DNSHOWMAP cheat displays the "Show Map: On" message but not the "Show Map: Off" message. The game is practically unplayable now.

Get the latest version, cheater.

[Nukey]

The GREENSLIME enemy isn't responding to the DNMONSTERS cheat. Or has this been fixed already?

[Helixhorned]

Nukey, on 24 July 2012 - 06:21 PM, said:

The GREENSLIME enemy isn't responding to the DNMONSTERS cheat. Or has this been fixed already?

Ugh, DNMONSTERS is actually tri-state (code slightly rewritten for clarity):

// in G_DoCheats
                case CHEAT_MONSTERS:
                {
                    const char *s[] = { "On", "Off" };

                    g_noEnemies = g_noEnemies+1;
                    if (g_noEnemies == 3)   // <-- NOTE THIS
                        g_noEnemies = 0;

                    // Note that state 2 is displayed as "Off" ---------------vvvvvvvvvvvvvvv
                    Bsprintf(ScriptQuotes[QUOTE_RESERVED4], "Monsters: %s", s[g_noEnemies & 1]);
                    P_DoQuote(QUOTE_RESERVED4,g_player[myconnectindex].ps);

                    end_cheat();
                    return;
                }

and

// in G_MoveActors
        case GREENSLIME__STATIC:
            if (g_netServer && (!g_netServer && ud.multimode < 2))
            {
                if (g_noEnemies == 1)
                {
                    s->cstat = (int16_t)32768;
                    goto BOLT;
                }
                else if (g_noEnemies == 2)
                    s->cstat = 257;
            }

Someone else would have to say what the heck this is for. TX?

[Hendricks266]

The if (g_noEnemies == 3) g_noEnemies = 0; just looks like a shitty g_noEnemies %= 3;.

This is the general case for the noEnemies code. RECON and GREENSLIME have their own variant, which you pasted above.

        if (!g_netServer && (!g_netServer && ud.multimode < 2) && A_CheckEnemySprite(s))
        {
            if (g_noEnemies == 1)
            {
                s->cstat = (int16_t)32768;
                goto BOLT;
            }
            else if (g_noEnemies == 2)
            {
                s->cstat = 0;
                if (s->extra)
                    s->cstat = 257;
            }
        }

It looks like the intent of the command is to have a state which would "restore" the actors without it always being done when g_noEnemies == 0, which could affect things like shrunkenness and Assault Captains teleporting. If I am understanding the code correctly, it would be best to insert a g_noEnemies = 0 at the bottom of every (g_noEnemies == 2) case in the code and fix the quote display to be (g_noEnemies % 2) instead of (g_noEnemies & 1). I will verify my thinking now.

RECON and GREENSLIME have their own code, possibly because they are the two hardcoded actors, and possibly because they don't stick around as dead bodies after they are killed, so they bypass the extra != 0 check.

However, the problem causing GREENSLIME not to be affected is apparent in its if command:

compare:

RECON: if (!g_netServer && ud.multimode < 2)

GREENSLIME: if (g_netServer && (!g_netServer && ud.multimode < 2))

I don't think (g_netServer && !g_netServer) is going to be true any time soon.

[Helixhorned]

Hendricks266, on 25 July 2012 - 07:44 AM, said:

I don't think (g_netServer && !g_netServer) is going to be true any time soon.

Heh, how true! I totally missed that.

edit: you found it, you keep it then?

[Nukey]

Entering 3D mode in the attached map crashes both the editor and the game. The log doesn't give any indication as to why (just states "uninitializing..."). It only happens with floor-aligned sprites. I'm using a fairly new version, but if nobody else experiences this problem then I guess I'll have to update again.

Attached File(s)

•  crash - Copy.zip (1.28K)
  Number of downloads: 191

[Nukey]

I am working on the InfoSuite, so expect many posts from me for a while.

DOS: Setting the PODFEM as a collapsable sprite, and then igniting an OOZFILTER nearby does not cause the sprite to collapse.

EDuke32: " does cause the sprite to collapse.

?

[Micky C]

Oh yeah, I was meant to test out that sprites moving with rotaterise bridge thing for you. I'll have to dig up the email and take a look into it in a week or so. In the meantime if you look at the bachelor pad at the start of CBP 8 you'll see a whole bunch of random sprites on rotating sections that rotate with the sectors, some of them are bound to not be actors or anything.

[Helixhorned]

Nukey, on 28 July 2012 - 06:09 PM, said:

Entering 3D mode in the attached map crashes both the editor and the game. The log doesn't give any indication as to why (just states "uninitializing..."). It only happens with floor-aligned sprites. I'm using a fairly new version, but if nobody else experiences this problem then I guess I'll have to update again.

Nice find, fixed in r2850.

Nukey, on 28 July 2012 - 09:31 PM, said:

DOS: Setting the PODFEM as a collapsable sprite, and then igniting an OOZFILTER nearby does not cause the sprite to collapse.

EDuke32: " does cause the sprite to collapse.

?

This is a subtle difference that could be considered a bug, though EDuke32's behavior seems more logical to me. I'm wondering if it has practical implications. Why would anyone want to do this?

[Gambini]

When playing CBP8 noticed that frozen newbeasts don´t become blue (pal 1).

[Helixhorned]

That's in the area where the floor needlessly has pal 3. (Ceiling pal would suffice for the space sky not killing you.)

[Nukey]

Helixhorned, on 29 July 2012 - 05:19 AM, said:

This is a subtle difference that could be considered a bug, though EDuke32's behavior seems more logical to me. I'm wondering if it has practical implications. Why would anyone want to do this?

No idea, but it's within the realm of possibility.

It would seem more logical to me, except that the Seenine, Exploding Barrel, Gun Powder Barrel, Mortar Shell, Bounce Mine, etc, do not cause it to collapse. So it really just seems kind of arbitrary that the Ooz Filter is the only tangible explosive that causes it. This game engine is just riddled with subtleties and arbitrary compatibilities of this sort. It's quite frustrating at times (like the explosion effects in general, my god).

Unfortunately, these differences between the two versions of the game require me to double-test virtually everything... although I usually try to test in DOS only, at least when it's convenient enough to deal with.

Edit: And things get stranger still. Suddenly the Ooz Filter is working in DOS, and causing FEM textures to collapse. I have no idea why. In fact, I tested the exact same map twice in EDuke32, and got different results from the Ooz Filter both times. Maybe the actor simply wasn't initiating itself ("seeing" the player) quickly enough to respond to the explosion. In any case, the two versions of the game are equally inconsistent here, so you can ignore this whole issue.

Was the original source code held together with duct tape?

[Nukey]

1) Playtest a map (Ctrl + P is the method I was using)

2) Use the "dnskill5" cheat (Damn I'm Good mode)

3) Skill setting is now stuck there indefinitely (or until you manually reconfigure "settings.cfg"). Even restarting mapster32 doesn't reset it.


Not sure if it's a bug or a design flaw. All it takes is for someone to use "dnskill5" or greater, and they'll never be able to playtest with cheats again until they reconfigure.

[Paul B]

Helix I'm frustrated after 5 and a half hours I finally figured out why the bridge wasn't working in my map. My problem was I was making the bridge shrink too small by squishing the sector with a high "speed value" and as a result it was failing to work after the second time being triggered. The relativity of the texture bugs me because you can see the texture move with the bridge and the relativity bit does nothing.

The damn floor tile is scrolling even though the Bridge is set for Relative Alignment. I am at a loss of what to do. Why does the relative alignment not work like its suppose to for the Bridge feature? For swinging doors and subways it works just fine.... ? I can't even cover up the texture with a sprite because the sprite moves too.

[Gambini]

In the bridge effect, the gspeed´s lotag must be equal to the distance the moving line will travel. And with moving line I mean that the SE will push the two closest vertexes to its position. The sector texture AFAIK will scroll twice as fast as the line moves. But you can always use a relative to floor sprite (that will move along with the sector) to fake a proper floor.

[underTaker]

I have just noticed some kind of bug with sector copying in Mapster32 2.0.0devel r2761. I can say it's pretty easy to reproduce, since it happened to me alot of times. It looks like this:

- First i do some sector, lets call it "sector A", and i attach some "sector B" to the left side of that sector, with few points at the splitting line.
- Next i want to copy "sector B" to the opposite side of "sector A", so i draw exact mirror of "sector B" where it has to be with all the points and stuff, and delete it with ctrl + del
- Then i select "sector B", click C to copy it, click X to flip it and place it on the designated place.

Everything goes okay, but there occurs map corruption! There are no visible bugs, but sometimes one or two little sectors can cause up to 7 errors and more. Also when i attempt to move some points attached to that sectors it's all screwing up!
Also - the corruption always happens after map saving.

I attached screen with an explanation, and the map with sample sector. The map contains only the sectors, there's nothing done in 3D mode.

Attached thumbnail(s)

• 

Attached File(s)

•  sample.zip (823bytes)
  Number of downloads: 182

[Helixhorned]

underTaker, on 01 August 2012 - 12:12 PM, said:

- Then i select "sector B", click C to copy it, click X to flip it and place it on the designated place.

Sector flipping was finally fixed in r2773!

r2773 commit message said:

Mapster32: Fix tweaking TROR wall links when flipping sectors ([X], [Y]).

This was actually broken all the time except when ALL sectors were selected
(which was what I tested incidentally when I wrote the first "fix"). D'oh!