[underTaker]

I'm not really sure if this causes of the issue and if spawning is in any way affected by code - just throwing my suggestions. I know nothing about CONs, never worked on them.

[Ninety-Six]

I know the fixes worked on the "respawn" thing, so if your map uses that function as it was vanilla that may be related.

I'm also not a coder; I just note an overlap between your explanation and one of the fixes.



Take it with a grain of salt; I could be entirely wrong.

[Darkus]

LeoD, on 02 July 2019 - 07:39 AM, said:

Hi Darkus,

there's an issue with newly released Blink of an Eye when using your GAME.CON. I'd appreciate if you'd look into that.

Both your 2016 and 2019 versions are affected, the EDuke32 version doesn't seem to matter.

I just saw it. I think it's related to the boss actors, when a lotag is set (difficulty), it trigger the ending when the actor is removed from the map at the beginning. It should be an easy fix.

[Darkus]

It took me longer than expected, but it should be fixed now. Since EVENT_KILLIT is not always reliable with complex events, I also made a check in EVENT_LOADACTOR to be sure that the ending doesn't trigger accidentally (or not). Also made some little changes in the code that shouldn't change gameplay from the previous version. Download below.

Changes:
- Prevent boss actors with a lotag set (difficulty) triggering the ending when starting a map.
- Replaced state by defstate for the definitions.
- Removed THISACTOR from userdef. According to the wiki, it's not needed.



PS: It is possible to edit the first post to put most recent version here?

[Mark]

That requires PM'ing a moderator and they will do what you need.

[Ninety-Six]

Thank you.

[F!re-Fly]

Glad to see Darkus again. Happy New Year to you.

It's cool for code changes. Me, the problem I have for boss purposes is that there is the cinematics of E1, for the four instead of having the appropriate ones.

While testing my demo, I noticed that the "KILLIT" event was sometimes not properly functional. I sometimes had two dead instead of one, or see no dead. Otherwise, it doesn't really matter for the gameplay. Using your codes, I have already added over 50 additional enemies.

[F!re-Fly]

Is there any reason why the death counter does not work properly from time to time?

[Darkus]

Firefly Trooper, on 29 January 2020 - 10:22 AM, said:

Is there any reason why the death counter does not work properly from time to time?

I don't know, happened a couple of times when playtesting on nuts.map long ago, and never happened since. Probably FPS drop and mass destruction combined, made the kill counter erratic. Since I can't replicate the problem, no worries for now.

[Danukem]

While on that subject, I have a question about the kill counter. I apologize if this has already been asked and answered.

What is the proper behavior for respawns? If a respawn was never activated in the map, should the enemy it spawns be counted as a missed kill? I'm inclined so say no, since that would force the player to kill civilians that are tied to respawn triggers if they want get all kills.

[Darkus]

I also thought about it, I could make the kill counter counts the respawns at map start for a more complete count, but as you say, reaching the maximum kills involve killing civilians (also some other sprites like the trashcan could spawn monsters). So I choose to stay like the original behavior, the max. number of monster depends on how many are already spawned in the map. Anyway, the ends results are displayed in precise numbers, not in percentage like Doom. It also matches the behavior of other BUILD games like SW.

[Danukem]

As a player, what I would want is for the kill counter to include all the possible kills (including respawns) EXCEPT with the civilian triggered respawns excluded. Then I would want some kind of gameplay reward if I get a 100% (like an atomichealth to start the next level or something).

[Jimmy]

I think max kills should only count active "killable" monsters at the close of the level. Some maps have alternate routes, you might not ever trigger the respawn but kill everything active. I think that's most fair. I don't know how I feel about "rewards", that's definitely not "intended" and goes beyond a fix in my opinion. Could be cool as an option.

[Danukem]

Multiple routes where you are unable to reach an alternate route after making a choice -- those maps do exist but they are rare. What's much more common is just neglecting to enter a certain room that had respawns you could have killed. I'm not sure if you would include those as "killable" but as a practical matter the code will not be able to differentiate those from respawns in an unreachable location.

The reward for 100% would only be for a gameplay mod, not for a fixes mod.

[LeoD]

As it seems, back in the 90's 3DRealms forgot to animate the open faucet. Adding this snippet to GAME.CON will fix it.

// Faucet2 animation
define FAUCET2 670
action FAUCET2_FRAMES 0 2 1 1 1
actor FAUCET2 0 FAUCET2_FRAMES
enda

You can test this in E4L1.

[F!re-Fly]

Having added your correctifs work in my mod, it seems to me that the problem of the counter only apply with "EGG" and "TANKS" I also found that it was not possible to add a "RECON" from a different "pal" directly on the map. Once the map is started, the RECON disappears instantly and is already counted as "dead". Maybe there is something missing in your code "EVENT_SPAWN, hardcoded respawn pal"

[Darkus]

LeoD, on 15 February 2020 - 06:24 AM, said:

As it seems, back in the 90's 3DRealms forgot to animate the open faucet. Adding this snippet to GAME.CON will fix it.

// Faucet2 animation
define FAUCET2 670
action FAUCET2_FRAMES 0 2 1 1 1
actor FAUCET2 0 FAUCET2_FRAMES
enda

You can test this in E4L1.

I dont think it's necessary to modify the CON file to only animate a sprite, this involves creating new actors. You can just create a DEF file and put this to modify only the tiles without modify ART files:

animtilerange 670 671 3 1

There's also another light, and offsets of the freezer HUD:

animtilerange 1034 1036 4 1

tilefromtexture 2551 { xoffset 34 yoffset 28 }
tilefromtexture 2552 { xoffset 34 yoffset 28 }
tilefromtexture 2553 { xoffset 34 yoffset 28 }

Firefly Trooper, on 15 February 2020 - 06:43 AM, said:

Having added your correctifs work in my mod, it seems to me that the problem of the counter only apply with "EGG" and "TANKS" I also found that it was not possible to add a "RECON" from a different "pal" directly on the map. Once the map is started, the RECON disappears instantly and is already counted as "dead". Maybe there is something missing in your code "EVENT_SPAWN, hardcoded respawn pal"

EGG and TANK are modified to match whether they survive in a certain way or not. For example, if a pigcop survives from his own tank explosion, it won't count as a kill.

But for the RECON case, it's weird. I tested with an unmodified GAME.CON and all RECON sprites that have a palette above 0 don't appear in the map (they are counted by the kill counter and are removed at some point). I suspect this is an EDuke bug.

EDIT: I just tested with 1.5 and 1.3D dos versions and it's the same thing. So it's a very old bug...

[LeoD]

Darkus, on 15 February 2020 - 12:39 PM, said:

I dont think it's necessary to modify the CON file to only animate a sprite, this involves creating new actors. You can just create a DEF file and put this to modify only the tiles without modify ART files:

animtilerange 670 671 3 1

Yeah, but that additional DEF could easily interfere with other DEFs' hierarchies. Do both solutions end up the same internally, or does the CON way imply a performance penalty?

[F!re-Fly]

LeoD, on 15 February 2020 - 02:54 PM, said:

Yeah, but that additional DEF could easily interfere with other DEFs' hierarchies. Do both solutions end up the same internally, or does the CON way imply a performance penalty?

Good question ! For my part, I had the idea of ​​extracting the sames sprites and dragging it into a folder like this:

tilefromtexture 1410 { file "tiles/customtiles/1410.png" xoffset 2 yoffset -34 }

tilefromtexture 1411 { file "tiles/customtiles/1411.png" xoffset 3 yoffset -34 }

tilefromtexture 1412 { file "tiles/customtiles/1412.png" yoffset -34 }

tilefromtexture 1413 { file "tiles/customtiles/1413.png" yoffset -34 }

tilefromtexture 1414 { file "tiles/customtiles/1414.png" xoffset -3 yoffset -34 }

This is a good example to fix the bug of the frozen Duke "floating"

I copied the same images, placed in the appropriate places and correctly modifying the position "x / y-offset"

This will at the same time avoid "breaking" original Duke's animation.

[Darkus]

LeoD, on 15 February 2020 - 02:54 PM, said:

Yeah, but that additional DEF could easily interfere with other DEFs' hierarchies. Do both solutions end up the same internally, or does the CON way imply a performance penalty?

The performance penalty should be minimal with CON (that's not a complex actor), and non-existent in DEF. The result is 'almost' the same, but in the first case since it's an active actor (and is supposed to do complex things), and the second, a simple animated tile which is part of the scenery (and don't interact to anything).

Firefly Trooper, on 15 February 2020 - 05:25 PM, said:

Good question ! For my part, I had the idea of ​​extracting the sames sprites and dragging it into a folder like this:

tilefromtexture 1410 { file "tiles/customtiles/1410.png" xoffset 2 yoffset -34 }

tilefromtexture 1411 { file "tiles/customtiles/1411.png" xoffset 3 yoffset -34 }

tilefromtexture 1412 { file "tiles/customtiles/1412.png" yoffset -34 }

tilefromtexture 1413 { file "tiles/customtiles/1413.png" yoffset -34 }

tilefromtexture 1414 { file "tiles/customtiles/1414.png" xoffset -3 yoffset -34 }

This is a good example to fix the bug of the frozen Duke "floating"

I copied the same images, placed in the appropriate places and correctly modifying the position "x / y-offset"

This will at the same time avoid "breaking" original Duke's animation.

You can use the copytile option that I've documented there, that will prevent you to extract tiles.

[F!re-Fly]

Wow, it's really great. It could also help me add more pal for enemies.

Thank you Darkus!

[F!re-Fly]

Small suggestion to improve the file.

Possibility to add the full sounds of the jetpack for the flying Liztroop. Sounds nicer, rather than just having a "DUKE_JETPACK_IDLE soundonce"

So add the two missing sounds "DUKE_JETPACK_IDLE_ON and _OFF" when it is about to take off and when it lands on the ground again.

[F!re-Fly]

I noticed a very rare bug on the liztroop, when they teleport.

When they are invisible, they can be killed by explosions. Or if you manage to touch them, at the last frame before being invisible, they become invincible and will never reappear. You will have to place a "break" command when they become "cstat 32768"

[Darkus]

Sorry, I didn't managed to reproduce the bug. I don't think I missed anything. How it works: he's only vulnerable at the first teleport frame animation, and the trooper is becoming invincible when the teleport effect is initiated. When the trooper reappear, I put setactor[THISACTOR].htextra -1 to erase the accumulated damage.

However, nobody noticed that the fat commander shrink bug was still here...

[F!re-Fly]

Darkus, on 31 March 2020 - 09:28 AM, said:

Sorry, I didn't managed to reproduce the bug. I don't think I missed anything. How it works: he's only vulnerable at the first teleport frame animation, and the trooper is becoming invincible when the teleport effect is initiated. When the trooper reappear, I put setactor[THISACTOR].htextra -1 to erase the accumulated damage.

However, nobody noticed that the fat commander shrink bug was still here...

I understand perfectly, but I must have expressed myself badly. inside the state troophidestate when it becomes invisible (cstat 32768) it can still be killed by explosions:

  ifaction ATROOPHIDE
  {
    ifactioncount 2
    {
      spawn TRANSPORTERSTAR
      sound TELEPORTER
      action ATROOPWALKING
      move TROOPWALKVELS faceplayer
      cstat 32768
    }
    else
    {
      sizeto 4 40
      sizeto 4 40
      sizeto 4 40
      sizeto 4 40
      spawn FRAMEEFFECT1
    }
  }

It would be really nice if he could be totally invincible when he owns this property.

I coded a new soldier in the Advance version and he behaves differently when he dies.

I don't know if it's a bug, if it's intentional or not, but in any case it could also help me for some enemies that I added.

[Darkus]

Time for another update. This time there are improvements concerning the sound effects, I wish having some feedback on this, just in case something is broken. I also fixed other things.

- Reformatted the file, size is now a bit smaller.
- Improved sound handling, you can now hear looping sounds correctly. For example, you can hear several sentry drones flying around you, unlike before when the same looping sound could be played only once at time. Same thing with non-looping sounds, but to keep with original behavior, some sounds coming from monsters (usually roaming sounds) are still played only once, while some others are only 'once per actor' (attack/pain sounds, or other), so it's a compromise.
- Now troopers have their correct jetpack ON/OFF/LOOP sounds (see above).
- LIZMANSTAYPUT, OCTABRAINSTAYPUT and BOSS1STAYPUT are no longer invincible when inactive (statnum 2)
- Tweaked how monsters handle radius damage. Now inactive actors should be jibbed properly using explosives (with pipe bombs, SEENINE, OOZFILTER...), rather than using normal death animation, because active and inactive actors (statnum 1 and 2) don't handle radius damage the same way.
- Fixed CANON actor, which when used, spawned too many projectiles, risking killing the player. Now when used, projectiles are spawned in a more reasonable rate.
- FEM10 and TOUGHGAL have correct animation when recovered from their shrunk state
- Fixed COMMANDER shrink bug
- And many other little things than I forgot...

I've archived the previous version.

 fixed GAME CON.zip (86.97K)
Number of downloads: 470

[F!re-Fly]

Darkus, on 10 April 2020 - 05:25 AM, said:

Time for another update. This time there are improvements concerning the sound effects, I wish having some feedback on this, just in case something is broken. I also fixed other things.

- Reformatted the file, size is now a bit smaller.
- Improved sound handling, you can now hear looping sounds correctly. For example, you can hear several sentry drones flying around you, unlike before when the same looping sound could be played only once at time. Same thing with non-looping sounds, but to keep with original behavior, some sounds coming from monsters (usually roaming sounds) are still played only once, while some others are only 'once per actor' (attack/pain sounds, or other), so it's a compromise.
- Now troopers have their correct jetpack ON/OFF/LOOP sounds (see above).
- LIZMANSTAYPUT, OCTABRAINSTAYPUT and BOSS1STAYPUT are no longer invincible when inactive (statnum 2)
- Tweaked how monsters handle radius damage. Now inactive actors should be jibbed properly using explosives (with pipe bombs, SEENINE, OOZFILTER...), rather than using normal death animation, because active and inactive actors (statnum 1 and 2) don't handle radius damage the same way.
- Fixed CANON actor, which when used, spawned too many projectiles, risking killing the player. Now when used, projectiles are spawned in a more reasonable rate.
- FEM10 and TOUGHGAL have correct animation when recovered from their shrunk state
- Fixed COMMANDER shrink bug
- And many other little things than I forgot...

I've archived the previous version.

fixed GAME CON.zip

It's perfect ! I will take this opportunity to correct all of this in my files.

I have two questions. Was the suggestion of jetpack sounds for the "Liztroop" already an idea for you or did you take my previous message into account? What exactly is file reformatting?

[Ninety-Six]

Hey Darkus, I have a question. I've noticed a discrepancy in behavior depending on what revision of eduke is being used. Now obviously this means that the fault lies in eduke itself, but I want to ask which behavior is the intended one.

When using the freezethrower against a pigcop, if they go into the crouch/prone/whatever state: in one version (current), autoaim will track the target and react accordingly. In another (older), the projectiles will keep shooting at where the center of the pig used to be. (yes I use autoaim but considering how spotty projectile collision detection can be at times, I like the extra insurance).

I'm legitimately unsure of which behavior is the right one, because I could see either as the bugged or correct version. Is it wonky hit detection making a target harder to hit? Or is this something a pig cop can do to protect itself? If it's the former then everything is working correctly as of now. But if it's the latter, then one of the recent changes broke it. If that's the case, I'm not sure what you could do about it but I figure it's worth bringing to your attention anyway.

[Darkus]

I don't use autoaim, but the problem sould be from EDuke. Normally, the auto aim is lowered as the sprite size is lower, even if it's the same actor who is changing it's own size (whatever it is shrinking, or playing crouching animation). The same trick could be also applied to the DOS version (if patched).

F!re-Fly, on 10 April 2020 - 10:37 AM, said:

I have two questions. Was the suggestion of jetpack sounds for the "Liztroop" already an idea for you or did you take my previous message into account? What exactly is file reformatting?

1) I wanted to do it first, but I thought it was useless, and could cause problems. Then I saw your post and I thought "why not, I'll take the risk"

2) It's just reorganization by deleting empty spaces/lines, that kind of thing.

[LeoD]

Darkus, on 14 April 2020 - 12:13 PM, said:

2) It's just reorganization by deleting empty spaces/lines, that kind of thing.

I think that's not a great idea, because it is a lot harder now to compare to the original CON and check out your modifications.