[Reaper_Man]

NightFright, on 25 November 2015 - 11:49 AM, said:

I can provide you with the latest con file for Grins since I have removed some warnings in the meantime. Would save me some time if you managed to work with that one and add your fixes there.

I will give Grins another playthrough shot before Xmas, provided that a solution is found for that problem EDuke32 currently seems to have when applying sprite resize bug fixes.

Sure, go ahead and send them to me. My email is msleeper (at) gmail.

If I remember correctly, the first map is kind of a hassle because of the timer, but the rest aren't so bad.

What's the issue with resizing? I know we made the sprites gigantic and sized them down to preserve details, and even back in 2002 that caused some problems. Nowadays there's probably a better way of doing that, but it's been a minute since I've done any Eduke modding.

[Mblackwell]

You were probably doing sizeat in the beginning of the actor code, but if the actor was asleep (for example an enemy out of player view, or a pickup sprite) you'll see the transition. In EDuke32 you can get around this by setting x/yrepeat in EVENT_LOADACTOR for those picnums.

[NightFright]

The thing right now is that my resizing fix code that I applied works, but for some reason EDuke32 adds dummies of the resized sprites randomly throughout the levels. No idea why this happens. I have already asked Hendricks to look into this matter and hope it gets solved before Xmas. Dunno if it's something in my fix code or EDuke32 itself, but I know that the patches I had written used to work at some point. However, by now I am unable to find any snapshot that actually does the trick, so it's kinda... complicated.

Maybe you can fix the problematic sprites while reviewing the con file, too. Then these fixes may not be necessary any more.

@Reaper:
You should have the con in your mailbox by now.

[Danukem]

NightFright, on 25 November 2015 - 02:08 PM, said:

The thing right now is that my resizing fix code that I applied works, but for some reason EDuke32 adds dummies of the resized sprites randomly throughout the levels. No idea why this happens. I have already asked Hendricks to look into this matter and hope it gets solved before Xmas. Dunno if it's something in my fix code or EDuke32 itself, but I know that the patches I had written used to work at some point. However, by now I am unable to find any snapshot that actually does the trick, so it's kinda... complicated.

Maybe you can fix the problematic sprites while reviewing the con file, too. Then these fixes may not be necessary any more.

@Reaper:
You should have the con in your mailbox by now.

I have seen a lot of strange stuff over the years, but I have never seen EDuke32 randomly add tiles into a map. Since you describe them as "dummy" tiles, I'm guessing they are not the same picnum as the actor (i.e. they are uncoded tiles). Perhaps there is an art file that has a duplicate of the tile on a different tile number, and those sprites were already in the maps, but for some reason they were not being displayed before. They could have been intended as stayput versions of the actor, for example, but were never coded. If the tiles had 0 size and your code changed them to large size, or if they had a tag (such as for difficulty level) that got removed somehow, then that would account for it.

[NightFright]

The thing is that it happens in every single addon that has these fixes applied, so it doesn't look like a coincidence to me. What strongly contradicts the assumption that EDuke32 is to blame for it is that there isn't any snapshot where this issue doesn't show up. Still, I am pretty sure I haven't seen this problem when I released v1.0 of the compilation. One way or the other, it needs to be solved since it's a pretty annoying glitch. Maybe something is wrong with the way I inject the patch code, or even the patches themselves are flawed.

As an example, in "The Gate", it works like this:

The game is launched by using thegate.con which contains this code:

include BDEFS.CON
include BUSER.CON
include PATCHES.CON
include BGAME.CON
include BDP.CON

patches.con is loaded before the actual game.con code (bdp.con contains custom, mod-exclusive code) and looks like this:

// Disable ep.4 intro + Duke team outro
gamevar LOGO_FLAGS 1575167 0

// Sprite resize bugfix for Predator (4818 PREDATOR/4819 PREDSTAYPUT)
onevent EVENT_SPAWN
   switch sprite[THISACTOR].picnum
   case 4818
   case 4819
      setactor[THISACTOR].xrepeat 42
      setactor[THISACTOR].yrepeat 36
   break
   endswitch
endevent

The only relevant part is the sprite resize stuff at the bottom. The first time you notice the glitch is when you jump out of the window right to the bottom of the street. There is a "fake" Predator on top of a huge stone/rock/whatever thing blocking the street, doing nothing at all.

[Danukem]

So what is the patch code? I am guessing that you are using code for more than just resizing sprites. If you are moving or copying tiles to different tile numbers in order to avoid conflicts between .art files, then lots of problems are possible, depending on how it's done.

[NightFright]

Actually, the code above is everything I am adding to what's already there. It definitely works because it avoids the Predators to shrink when encountering them, but however it has this weird side effect.

You can take a look at the complete code by analyzing all the con files of the addon in the attached zipfile. I have merged bdp.con into gategame.con (formerly bgame.con) for convenience purposes.

[Danukem]

NightFright, on 26 November 2015 - 02:34 AM, said:

Actually, the code above is everything I am adding to what's already there. It definitely works because it avoids the Predators to shrink when encountering them, but however it has this weird side effect.

You can take a look at the complete code by analyzing all the con files of the addon in the attached zipfile. I have merged bdp.con into gategame.con (formerly bgame.con) for convenience purposes.

Your code:

// Sprite resize bugfix for Predator (4818 PREDATOR/4819 PREDSTAYPUT)
onevent EVENT_SPAWN
   switch sprite[THISACTOR].picnum
   case 4818
   case 4819
      setactor[THISACTOR].xrepeat 42
      setactor[THISACTOR].yrepeat 36
   break
   endswitch
endevent

Instead of using EVENT_SPAWN, I would use EVENT_LOADACTOR

You can do that right now and I'm pretty sure the problem will be fixed, but to know why, read on. EVENT_LOADACTOR only applies to the sprites in the map at map load time. EVENT_SPAWN applies to all sprites (excluding certain statnums) when they enter the game, whenever that is. This may not sound like it would be a problem, but I believe it is in this case. Without looking at the other code I can't be sure, but it's most likely that this TC has one or more actors that behave differently depending on whether they were in the map from the start, or spawned later (this could have been detected using the "ifspawnedby" CON command, before eduke). The key fact here is that when a sprite is spawned by another sprite using CON code, it normally starts with a size of 0. If the author is using that sprite as an effector of some sort, then keeping it at size 0 is desirable, because it makes the sprite invisible. Having spawned actors start at size 0 is desirable, because otherwise you would see them get resized in game. The only actors you see get resized are the ones placed directly using the map editor -- respawns aren't an issue because they are invisible until their actor code resizes them (or in the case of actors with hardcoding, they are sized appropriately right away).

[NightFright]

I appreciate your help with this investigation, DT. Your explanation was even understandable for me, and I am quite a noob with these things. xD Let's see if we can figure this out together!

Regarding your suggestion: Well, that's basically the approach I took in the beginning if you check this old post here. Fox recommended to use EVENT_SPAWN instead back then, so I did.

The thing is, not so long ago, in an attempt to fix this issue by myself, I actually replaced EVENT_SPAWN with EVENT_LOADACTOR to see what happens. The result was that the dummy/fake sprites were gone, but so were the fixes. Sprite resizing happened again as if the patch code hadn't been applied at all. I will try again now with latest EDuke32 snapshots, but somehow I have my doubts that the result will be any different.

[Danukem]

NightFright, on 26 November 2015 - 12:21 PM, said:

The thing is, not so long ago, in an attempt to fix this issue by myself, I actually replaced EVENT_SPAWN with EVENT_LOADACTOR to see what happens. The result was that the dummy/fake sprites were gone, but so were the fixes.

Yeah I would try it again, and when it doesn't work, then we'll figure out why and go from there.

EVENT_LOADACTOR should do the job if the wrong-sized sprites were placed in the map using the map editor. If the sprites are spawned in-game, then no fix should be necessary.

There are, of course, possible wildcards that could muck things up. For example, I'm not sure what would happen if you had two different instances of EVENT_LOADACTOR without using "appendevent". Would it only use code from the first instance?

If it turns out to be a tough problem, I would use DNDEBUG near the location of one of the errant dummy sprites. Check the picnum of the sprite in debug.map in mapster to verify the picnum, and then check that location in the original map to see what picnum of sprite (if any) occupies that location.

[Danukem]

I have an update about the resizing issue, and since it may involve a bug that will interest others, I'll post about it here.

For a completely unrelated reason I used EVENT_SPAWN to resize HEAVYHBOMB. To my surprise, pal 1 HEAVYHBOMBs started appearing in single player. (Items marked with pal 1 are only supposed to appear in multiplayer). Also, the sprites were dummies, I could not pick them up like normal pipebombs. So this suggests that we have an eduke bug here. Apparently, if EVENT_SPAWN is used on a sprite, the hardcoding which normally causes a sprite to not appear (at least in the case of multiplayer-only tags, possibly in other cases) does not work.

[Nevander]

edit: nevermind

[Hendricks266]

Trooper Dan, on 28 November 2015 - 12:01 AM, said:

So this suggests that we have an eduke bug here.

I was able to replicate the behavior you describe--as far back as OldMP, which is based on r1199 from 2009. This tells me that it is EVENT_SPAWN's intended function. It's a feature: you can intercept sprite deletions on map start by changing their size and statnum.

Looking at the source where is called, what you'll need to do is only resize sprites that have a non-zero xrepeat.

@NightFright:

// Sprite resize bugfix for Predator (4818 PREDATOR/4819 PREDSTAYPUT)
onevent EVENT_SPAWN
    switch sprite[THISACTOR].picnum
    case 4818
    case 4819
        ifvarg sprite[THISACTOR].xrepeat 0
        {
            setactor[THISACTOR].xrepeat 42
            setactor[THISACTOR].yrepeat 36
        }
        break
    endswitch
endevent

[Fox]

Note that internally the game sets some sprites scale to zero to delete them. So naturally if you change the scale during the spawning tics, these sprite will remain.

[Danukem]

Fox, on 29 November 2015 - 10:34 PM, said:

Note that internally the game sets some sprites scale to zero to delete them. So naturally if you change the scale during the spawning tics, these sprite will remain.

If the game does that to delete multiplayer only sprites when starting a map in singleplayer, then that would certainly explain it.

[NightFright]

Hendricks266, on 29 November 2015 - 10:16 PM, said:

I was able to replicate the behavior you describe--as far back as OldMP, which is based on r1199 from 2009. This tells me that it is EVENT_SPAWN's intended function. It's a feature: you can intercept sprite deletions on map start by changing their size and statnum.

Looking at the source where is called, what you'll need to do is only resize sprites that have a non-zero xrepeat.

@NightFright:
[Stuff]

That code seems to do the trick, at least in "The Gate". No dummies any more while resizing is still prevented. Need to check it in the other four addons that are affected.

I was also wondering if this kind of code makes any sense (from ZeroHour):

   case LIZTROOP
      setactor[THISACTOR].xrepeat 25
      setactor[THISACTOR].yrepeat 25
      ifspritepal 3
         setactor[THISACTOR].xrepeat 40
         setactor[THISACTOR].yrepeat 35
      ifspritepal 9
         setactor[THISACTOR].xrepeat 30
         setactor[THISACTOR].yrepeat 30   
   break

Somehow I am sceptical about the "ifspritepal" parts, I don't think the game recognizes that. There's no warning or error message about it in the logs, but it doesn't mean it's correct.

[Danukem]

NightFright, on 30 November 2015 - 02:49 AM, said:

Somehow I am sceptical about the "ifspritepal" parts, I don't think the game recognizes that. There's no warning or error message about it in the logs, but it doesn't mean it's correct.

It's fine, but you need to use braces because it is followed by 2 commands. So it should be:

ifspritepal 3
{
      setactor[THISACTOR].xrepeat 25
      setactor[THISACTOR].yrepeat 25
}
ifspritepal 9
{
         setactor[THISACTOR].xrepeat 30
         setactor[THISACTOR].yrepeat 30
}
break

Some languages care about indenting but CON isn't one of them.

[Hendricks266]

NightFright, on 30 November 2015 - 02:49 AM, said:

I was also wondering if this kind of code makes any sense (from ZeroHour):

You would need curly braces surrounding what you want to do ifspritepal because you have more than one statement.

        ifspritepal 3
        {
            setactor[THISACTOR].xrepeat 40
            setactor[THISACTOR].yrepeat 35
        }

Since you're setting the size on the current actor, you can use sizeat instead of structure access.

Here is the code posted in your previous thread, updated. It was actually broken in some respects due to the lack of curly braces, and of else statements for your ifcount statements.

[code removed]

What were you intending with "ifcount" for Duke, It's ZeroHour's ORGANTIC and Infestation in Time's BLUESLIME? EVENT_SPAWN only takes place during the first tic of an actor's execution.

[NightFright]

Actually I had already applied those braces today by myself just to be sure. ^^

Regarding ifcount (or ifspawnedby), I saw in the CON code that there were different cases for sizeto in the code and assumed that it works the same way with ifcount than with ifspritepal. If that doesn't make any sense, now is the time to fix it... if I know how it's supposed to be.

Examples from "Infestation in Time" where I potentially screwed up:

Spoiler

   // Blue Egg
   case BLUEEGG
      ifvarg sprite[THISACTOR].xrepeat 0
      {
         setactor[THISACTOR].xrepeat 18
         setactor[THISACTOR].yrepeat 18
      }
      ifspawnedby LIZTROOP
      {
         ifvarg sprite[THISACTOR].xrepeat 0
         {
            setactor[THISACTOR].xrepeat 25
            setactor[THISACTOR].yrepeat 27
         }
      }
   break

   // Blue Slimer
   case BLUESLIME
      ifvarg sprite[THISACTOR].xrepeat 0
      {
         ifcount 22
         {
            setactor[THISACTOR].xrepeat 19
            setactor[THISACTOR].yrepeat 19
         }
         ifcount 21
         {
            setactor[THISACTOR].xrepeat 20
            setactor[THISACTOR].yrepeat 20
         }
         ifcount 20
         {         
            setactor[THISACTOR].xrepeat 21
            setactor[THISACTOR].yrepeat 21
         }
         ifcount 19
         {
            setactor[THISACTOR].xrepeat 22
            setactor[THISACTOR].yrepeat 22
         }
         ifcount 18
         {
            setactor[THISACTOR].xrepeat 23
            setactor[THISACTOR].yrepeat 23
         }
         ifcount 17
         {
            setactor[THISACTOR].xrepeat 24
            setactor[THISACTOR].yrepeat 24
         }
         ifcount 16
         {
            setactor[THISACTOR].xrepeat 25
            setactor[THISACTOR].yrepeat 25
         }
         ifcount 15
         {
            setactor[THISACTOR].xrepeat 26
            setactor[THISACTOR].yrepeat 26
         }
         ifcount 14
         {
            setactor[THISACTOR].xrepeat 27
            setactor[THISACTOR].yrepeat 27
         }
         ifcount 13
         {
            setactor[THISACTOR].xrepeat 28
            setactor[THISACTOR].yrepeat 28
         }
         ifcount 12
         {
            setactor[THISACTOR].xrepeat 29
            setactor[THISACTOR].yrepeat 29
         }
         ifcount 11
         {
            setactor[THISACTOR].xrepeat 30
            setactor[THISACTOR].yrepeat 30
         }
         ifcount 10
         {
            setactor[THISACTOR].xrepeat 29
            setactor[THISACTOR].yrepeat 29
         }
         ifcount 9
         {
            setactor[THISACTOR].xrepeat 28
            setactor[THISACTOR].yrepeat 28
         }
         ifcount 8
         {
            setactor[THISACTOR].xrepeat 27
            setactor[THISACTOR].yrepeat 27
         }
         ifcount 7
         {
            setactor[THISACTOR].xrepeat 26
            setactor[THISACTOR].yrepeat 26
         }
         ifcount 6
         {
            setactor[THISACTOR].xrepeat 25
            setactor[THISACTOR].yrepeat 25
         }
         ifcount 5
         {
            setactor[THISACTOR].xrepeat 24
            setactor[THISACTOR].yrepeat 24
         }
         ifcount 4
         {
            setactor[THISACTOR].xrepeat 23
            setactor[THISACTOR].yrepeat 23
         }
         ifcount 3
         {
            setactor[THISACTOR].xrepeat 22
            setactor[THISACTOR].yrepeat 22
         }
         ifcount 2
         {
            setactor[THISACTOR].xrepeat 21
            setactor[THISACTOR].yrepeat 21
         }
         ifcount 1
         {
            setactor[THISACTOR].xrepeat 20
            setactor[THISACTOR].yrepeat 20   
         }
      }
   break

Also, is it needed to put the ifvarg line everywhere like this:

case LIZTROOP
      ifvarg sprite[THISACTOR].xrepeat 0
      {
         setactor[THISACTOR].xrepeat 25
         setactor[THISACTOR].yrepeat 25
      }
      ifspritepal 3
      {
         ifvarg sprite[THISACTOR].xrepeat 0
         {
            setactor[THISACTOR].xrepeat 40
            setactor[THISACTOR].yrepeat 35
         }
      }
      ifspritepal 9
      {
         ifvarg sprite[THISACTOR].xrepeat 0
         {
            setactor[THISACTOR].xrepeat 30
            setactor[THISACTOR].yrepeat 30
         }
      }  
   break

Or is this enough?

   case LIZTROOP
      ifvarg sprite[THISACTOR].xrepeat 0
      {
         setactor[THISACTOR].xrepeat 25
         setactor[THISACTOR].yrepeat 25
      }
      ifspritepal 3
      {
         setactor[THISACTOR].xrepeat 40
         setactor[THISACTOR].yrepeat 35
      }
      ifspritepal 9
      {
         setactor[THISACTOR].xrepeat 30
         setactor[THISACTOR].yrepeat 30
      }  
   break

CONS of "Infestation in Time" and "ZeroHour" are attached if needed for comparison. "Dukenstein", "The Gate" and "Grins of Divinity" don't have such cases and should be fixed already.

[Fantinaikos]

I corfirm from personal experience that Infestation In Time is pretty broken at first levels, the most striking example among many is scorpion tanks that doesn't move, don't attack and even not destructibles i guess. But remains a good challenging mod to complete.

Quote

CONS of "Infestation in Time" and "ZeroHour" are attached if needed for comparison. "Dukenstein", "The Gate" and "Grins of Divinity" don't have such cases and should be fixed already.

I don't get why it was decided to choose Dukenstein, it is really that remembered and appreciated to deserve a revised version? Why no one thinked about like this?

http://www.moddb.com...ass-destruction

I know it is a kind of Proto-Attrition, but it has certainly laid the groundwork for Attrition mechanics itself plus it's made from Trooper Dan in his "DeeperThought" period (so that could also eventually fill the empty section on its website http://fissile.duke4...sile_dnwmd.html).

Another nice choice for a classic style episode that need to get rid of some bugs could be Duke It Out In New York (to not be confused with New York Rebellion).

http://dukertcm.com/...e-new-york.html


Ps. Trooper Dan has already contacted you to have permission about add the updated maps in his mods?

[Hendricks266]

NightFright, on 30 November 2015 - 08:37 AM, said:

Also, is it needed to put the ifvarg line everywhere like this:
Or is this enough?

The first case is functionally correct but neither is optimal.

    case LIZTROOP
        ifvarg sprite[THISACTOR].xrepeat 0
        {
            ifspritepal 3
                sizeat 40 35
            else ifspritepal 9
                sizeat 30 30
            else
                sizeat 25 25
        }
        break

NightFright, on 30 November 2015 - 08:37 AM, said:

Regarding ifcount (or ifspawnedby), I saw in the CON code that there were different cases for sizeto in the code and assumed that it works the same way with ifcount than with ifspritepal. If that doesn't make any sense, now is the time to fix it... if I know how it's supposed to be.

Indeed it doesn't make any sense. EVENT_SPAWN is only needed to make sure sprites are the correct size before the actor block takes over. If the actor code has a sizeto, all we need to do in the event is make sure the sprite is what it should be before the sizeto takes over.

ifcount is entirely out of place in EVENT_SPAWN because it is only run once, before the actor's every first tic. Its count will never elapse.

Here is the fixed code I referred to.

The Gate

Spoiler

appendevent EVENT_SPAWN
    ifvarl sprite[THISACTOR].xrepeat 1
        break

    switch sprite[THISACTOR].picnum

    case PREDATOR
    case PREDSTAYPUT
        sizeat 42 36
        break

    endswitch
endevent

Grins of Divinity

Spoiler

appendevent EVENT_SPAWN
    ifvarl sprite[THISACTOR].xrepeat 1
        break

    switch sprite[THISACTOR].picnum

    // Ammo
    case 37
    case 40
    case 41
    case 44
    case 45
    case 46
    case 49
    case 5280
    case 5281
    case 5282
    case 5283
    case 5284
    case 5285
        sizeat 10 10
        break

    // Weapons
    case 21
    case 22
    case 23
    case 24
    case 28
    case 2595
    case 5270
    case 5271
    case 5272
    case 5273
    case 5275
        sizeat 14 14
        break

    // Weapon (rifle)
    case 32
    case 5274
        sizeat 20 20
        break

    // Weapon
    case 25
        sizeat 28 28
        break

    // CIA Agent (1680/5220), Recon (1960), White Hulk Robot (5120), Punk (5150), Barrel (5287)
    case 1680
    case 1960
    case 5120
    case 5150
    case 5220
    case 5287
        sizeat 40 40
        break

    // Parachute, Burnmark
    case 5215
    case 5288
        sizeat 48 48
        break

    // Jets
    case 5370
    case 5371
    case 5372
    case 5373
    case 5374
        sizeat 128 128
        break

    endswitch
endevent

Infestation in Time

Spoiler

appendevent EVENT_SPAWN
    ifvarl sprite[THISACTOR].xrepeat 1
        break

    switch sprite[THISACTOR].picnum

    // Bird Feces
    case BIRDFECES
        sizeat 4 15
        break

    // Spider
    case SPIDER
        sizeat 8 8
        break

    // Blue Egg
    case BLUEEGG
        ifspawnedby LIZTROOP
            sizeat 25 27
        else
            sizeat 18 18
        break

    // Dream Shadow, Chicken
    case SHADOW
    case CHICKEN
        sizeat 20 20
        break

    // Blue Slimer
    case BLUESLIME
        sizeat 20 20 // is this right???
        break

    // New Organtic, Ball 1+2, Bird, Monster, New Trooper
    case NEWORGANTIC
    case BALL1
    case BALL2
    case BIRD
    case MONSTER
    case TROOP
        sizeat 30 30
        break

    // Alien
    case ALIEN
        sizeat 32 32
        break

    // Organtic Predator, Terrorist
    case ORGAN
    case TERRORIST
        sizeat 35 35
        break

    // Floor Organtic, Superboss
    case FORGANTIC
    case SUPERBOSS
        sizeat 40 40
        break

    // Plate
    case NPLATE
    case PLATEBROKEN
        sizeat 47 47
        break

    // Small Turret
    case SMALLTURRET
        sizeat 50 50
        break

    // Old Pig Cop Tank, Trooper Tank
    case OLDTANK
    case TROOPTANK
        sizeat 56 56
        break

    // Dog, Private, Soldier, Nazi 1+2, Robot Gitler, Gitler, Sergeant (also dead states)
    case NAZIDOG
    case DEADDOG
    case PRIVATE
    case DEADPRIVATE
    case SOLDIER
    case DEADSOLDIER
    case NAZI
    case DEADNAZI
    case NAZI2
    case DEADNAZI2
    case GITLER1
    case DEADGITLER1
    case GITLER2
    case DEADGITLER2
    case SERGEANT
        sizeat 60 60
        break

    endswitch
endevent

Duke, It's ZeroHour

Spoiler

appendevent EVENT_SPAWN
    ifvarl sprite[THISACTOR].xrepeat 1
        break

    switch sprite[THISACTOR].picnum

    // Alien
    case LIZTROOP
        ifspritepal 3
            sizeat 40 35
        else ifspritepal 9
            sizeat 30 30
        else
            sizeat 25 25
        break

    // Homing Mine (SHARK), Spider (PIGCOP/OCTABRAIN)
    case SHARK
    case PIGCOP
    case OCTABRAIN
        sizeat 30 30
        break

    // Organtic Turret
    case ORGANTIC
        sizeat 48 18 // is this right???
        break

    // Blade Drone
    case PODFEM1
        sizeat 35 35
        break

    // Sentinel, Screamer, Turret 1+2
    case DRONE
    case COMMANDER
    case 2350
    case 2360
        sizeat 40 40
        break

    // Mech
    case BOSS3
        ifspritepal 3
            sizeat 75 75
        break

    endswitch
endevent

There are many subtleties to good code design and I'll try to teach some of the changes I made.

• sizeat used where structure access is unnecessary
  
• appendevent, which makes more sense for mutator-like code
  
• consistent 4-space width "tabs"
  
• break indented logically
  
• braces used whenever needed, but only when needed (EDIT: turns out to be nowhere)
  
• else used

You'll notice I decided to run the xrepeat check at the very beginning and break out of the entire event if it fails. This is a stylistic choice on my part to keep the code length small. Note that these EVENT_SPAWN invocations should only be used for this resizing purpose. If for some reason you needed to do something unrelated in EVENT_SPAWN, you can simply add a separate appendevent block.

You'll want to check the two cases where the code formerly used ifcount to make sure they look right, and by "check" I mean test in-game, with this code, in multiple locations of these enemies. The "problem" here has existed since before you released the initial version of this pack, so something must have gone wrong during the testing phase when you were originally preparing it.

[NightFright]

@ Hendricks:
Great! This code also seems to work, just like the one with ifvarg. I will also apply this to Dukenstein. Afterwards, I guess the best thing will be to play through at least a full episode to see if there are any sprites which show glitches. Already found that a different sizeat value needs to be applied to #5120 (white robot hulk) in Grins (sizeat 32 32 instead of 40 40), will be fixed. Thanks a lot again for all the assistance you provided! I already suspected that it was rather a code issue than one with EDuke32. If I understood correctly (and to sum up my original mistake), the code I had originally used prevented EDuke from wiping/hiding sprites which would normally be gone after the levels had been loaded. I still don't get why the dummy sprites appeared in those spots since when checking those maps, absolutely nothing is there to find. Anyway, main thing is it doesn't happen any more.

@ Fantinaikos:
The choices of entries in this compilation are of course somewhat subjective. I tried to add as many as possible, but it's impossible to fulfill everyone's wishes. I try to avoid code-heavy addons which have been specifically written for EDuke as they inevitably break while new snapshots keep being released. I am aiming for a collection that will keep working, regardless what happens with EDuke32. That's also why I decided to remove "Nuclear Showdown" again for v2.0 (never got it fully working, anyway). It's disappointing for some of you, but we are still talking about a collection with far over 1.000 SP levels. And good ones.

Regarding Duke NY: I have taken a look at this addon a while ago already when I was looking for more candidates to add. This thing is, frankly spoken, a clusterf*ck. What worried me most was the fact that the author(s) cheated by reusing the exact same levels over and over again (with different names, even different files for 100% identical maps) to make the episodes appear longer than they actually were. What's left is a mess of broken and, if I may say so, pretty sub-par levels which are hardly worth anyone's time. I may take a look at this again later on, but the probability for this to find its way into the compilation in any form is quite low. I will add one more entry to the pack before the release, and that will be TamDuke by pmw. Trying to aim for a healthy mix of older and newer addons.

[FistMarine]

edit

[NightFright]

I already explained that I cannot add any more addons if I want to stick to my release deadline at the end of December. TamDuke should be easy to add since it will not involve any extra code, so it can just be used without any major changes. I have been working on this update for almost half a year now without interruptions, I guess it's not too harsh to ask for a break.

[FistMarine]

edit

[Fantinaikos]

Before release, it is possible do something to make possibly Vacation Cove ACTUALLY work with Duke Caribbean? Personally I did some basic CON editing by myself to play it as an episode (adding Sharks Cove also) and thats almost perfectly worked, but I'd like to see it officially. I can even post my CON if anyone is interested.

[NightFright]

That would go against the intention to stay as true to the original releases as possible. I have no means to ask the author(s) of that mod for authorization, and to respect their efforts, I cannot apply modifications that go against the original presentation of the addon. Besides, Vacation Cove works fine the way it stands. You could use the Caribbean art files to replace weapons and monsters maybe, but other than that...

[Fantinaikos]

NightFright, on 01 December 2015 - 11:27 AM, said:

That would go against the intention to stay as true to the original releases as possible. I have no means to ask the author(s) of that mod for authorization, and to respect their efforts, I cannot apply modifications that go against the original presentation of the addon. Besides, Vacation Cove works fine the way it stands. You could use the Caribbean art files to replace weapons and monsters maybe, but other than that...

Well I have not told the WHOLE story, me neither have touched the Vacation Cove CONs or the Carribean CONs, the CON i edited it was in VACAPLUS by Hendricks266. This has avoided an entire ART replacement process and a more extensive overwriting (even if VACAPLUS it's clearly based on original Carribean files).

By the way, Nuclear Winter Plus And Vacation Plus seems either stalled on github, any news about it?

[Hendricks266]

Fantinaikos, on 01 December 2015 - 11:55 AM, said:

By the way, Nuclear Winter Plus And Vacation Plus seems either stalled

HRPs are community projects, and there have not been any submissions to NW+ or Vaca+ in years.

Fantinaikos, on 01 December 2015 - 11:55 AM, said:

on github

Subversion is not Git, and Git is not GitHub.

[FistMarine]

edit