[eniojr]

Hi, i'd like to know how to prevent the assault trooper with palette 0 to turn to green (pal 11). That's because I'm making each palette to shoot a different projectile. Here's the code in GAME.CON:

state troopshootstate
ifactioncount 2
{
    ifcanshoottarget
    {
        ifspritepal 0 { sound PRED_ATTACK shoot FIRELASER } else
        ifspritepal 10 { sound RPG_SHOOT shoot RPG } else 
        ifspritepal 11 { sound PRED_ATTACK shoot FIRELASER } else
        ifspritepal 12 { sound PLASMARIFLE_FIRE shoot PLASMAPROJ } else
        ifspritepal 15 { sound FLAMEALT_SOUND shoot FLAMEPROJ } else
        ifspritepal 16 { sound PISTOL_FIRE shoot 3980 } else
        ifspritepal 19 { sound GROWSPARK shoot GROWSPARK } else
        ifspritepal 23 { sound CAT_FIRE shoot FREEZEBLAST } else
        resetcount
        
        ifrnd 128
            ai AITROOPSEEKPLAYER
        ifcount 24
        {
            ifrnd 96
            ifpdistg 2048
                ai AITROOPSEEKPLAYER
            else
            {
                ifpdistg 1596
                    ai AITROOPFLEEING
                else
                    ai AITROOPFLEEINGBACK
            }
        }
    }
    else
        ai AITROOPSEEKPLAYER
}
ends

The problem is that the "ifspritepal 0 { sound PRED_ATTACK shoot FIRELASER }" doesn't shoot anything. If you change the palette to 11, fine, but in pal 0, nothing.

I also tried this:

ifspritepal 10 { sound RPG_SHOOT shoot RPG } else 
        ifspritepal 11 { sound PRED_ATTACK shoot FIRELASER } else
        ifspritepal 12 { sound PLASMARIFLE_FIRE shoot PLASMAPROJ } else
        ifspritepal 15 { sound FLAMEALT_SOUND shoot FLAMEPROJ } else
        ifspritepal 16 { sound PISTOL_FIRE shoot 3980 } else
        ifspritepal 19 { sound GROWSPARK shoot GROWSPARK } else
        ifspritepal 23 { sound CAT_FIRE shoot FREEZEBLAST } else
	sound PRED_ATTACK shoot FIRELASER else
        resetcount

In this case, even the trooper with pal 0 shoot, but the other ones with different color also shoot firelaser with another projectile, which is I don't want.

Is there a way to prevent the trooper with pal 0 to switch to pal 11, so that it keeps that standard blue color of palette 0? That would allow me to specify firelaser to pal 0 and shrinker to pal 11.

I think the reason for that problem is that there's some hard coded thing that makes the blue trooper turns into green trooper.

Is there a way I can prevent this by making some CON script? Maybe some condition to prevent the automatic switch from 0 to 11?

Here's a picture to give you some idea of what I'm making:



The troopers behind each door have a different color from 0, while the trooper in the corridor have color 0. The idea is that each color make the troop shoot a different projectile other than firelaser.

I also did the same thing to many other enemies and didn't have problems with this!

[Aleks]

Maybe it's a crude workaround, but you could just give the default trooper e.g. pal 3 so it stays blue?

[Danukem]

Make it a switch statement where FIRELASER is the default and then the other cases specify what the special pals do. Your current setup is bad because any pals not listed will simply not fire at all, and there are user maps where those exist. If you don't know how to overcome the hardcoding that makes pal 0 -> pal 11 then don't include pal 0 in the list, make it pal 3 like Aleks said.

[eniojr]

If only there was a program to convert source code to CON language... With this one could make an entire Duke Nukem 3D code based on CON, like Ion Fury. So it would be much easier to make new mods.

I think the way Duke Nukem 3D was designed was faulty (Shadow Warrior was the worst case), due to many hardcoded things not translated to CON. If the game was entirely made using CON or a more developed version of CON language in that epoch, maybe Duke Nukem would be as easy to mod as Doom is, so it would be more popular, I think.

I think Marcolino is trying to develop such thing, don't really know.

I don't plan modding Doom, since Doom engine is much more primitive, I don't like that much. I still prefer to deal with the complex CON language of Duke Nukem.

At least now I can do some cool things with that. I created 3 new simple sector effector effects with sound and visual effects, based on Legacy. Legacy has an effect in that you take damage while in space not wearing a spacesuit. Based on that, I made 2 similar effects, one in which represents taking cold damage and another representing a toxic effect. The cold damage also makes you shake (earthquake effect without sound) and makes you run slower too, taking small draining damage. The toxic effect is more similar to the space damage, but with different sounds and color. The third effect is a sector healing effect, in that you instead of taking damage, you gain health (suitable for maps with few medkits or even none, such as an alien planet or spaceship, like that healing effect on Xen in Half Life).

I also made something iconic from Doom in Duke Nukem... That iconic HUD face, but as Duke Nukem. It's animated and responds to loss of health, nearby attacks and there's animation for very low health, with a scared face bleeding. There's also a face for death and god mode. I also plan to make a god effect through an item with limited time, similar to that of ROTT. Eventually I'll show the results here. But for now the focus is on making new variations of enemies thorugh different colors, using palette values for that.


As for our little problem...

I just found a solution in Nuclear Winter mod to the palette color, which has this code:

      ifactioncount 2
      {
        ifcanshoottarget
        {
          resetactioncount
		
        ifspritepal 16 { sound PISTOL_FIRE shoot 3980 shoot SHOTSPARK1 } else 
        ifspritepal 23 { sound CAT_FIRE shoot FREEZEBLAST } else
        { sound PRED_ATTACK shoot FIRELASER }
        }
        else ai AITROOPSEEKPLAYER
      }
  }

So based on that I made this:

state troopshootstate
  ifactioncount 2
  {
    ifcanshoottarget
    {    
        ifspritepal 10 { sound RPG_SHOOT shoot RPG } else
        ifspritepal 11 { sound PRED_ATTACK shoot FIRELASER } else
        ifspritepal 12 { sound PLASMARIFLE_FIRE shoot PLASMAPROJ } else
        ifspritepal 15 { sound FLAMEALT_SOUND shoot FLAMEPROJ } else
        ifspritepal 16 { sound PISTOL_FIRE shoot 3980 shoot SHOTSPARK1 } else 
	ifspritepal 19 { sound GROWSPARK shoot GROWSPARK } else
        ifspritepal 23 { sound CAT_FIRE shoot FREEZEBLAST } else
        { sound PRED_ATTACK shoot FIRELASER }
      resetactioncount
      ifrnd 128
        ai AITROOPSEEKPLAYER
      ifcount 24
      {
        ifrnd 96
          ifpdistg 2048
            ai AITROOPSEEKPLAYER
          else
          {
            ifpdistg 1596
              ai AITROOPFLEEING
            else
              ai AITROOPFLEEINGBACK
          }
      }
    }
    else
      ai AITROOPSEEKPLAYER
	}
	
	ifspritepal 19
    ifpdistl 2048
    {
        state troopabouttoexplode
		sound LASERTRIP_ONWALL
		sound LASERTRIP_ARMING
	}
ends

I tried that case thing, but couldn't solve the problem that way. Maybe I'm still too dumb with CON anyway.

Now each color only shoots the desired projectile. Oh, and that state troopabouttoexplode I made for some enemies with pal 19. If you get close to them, they will explode in your face!

Enemies with spritepal 19, 30 and 31 causes damage when you approach them. 19 explode, 30 have a toxic effect and 31 a shock effect. The smoke spawned by enemies with spritepal 30 causes toxic damage by itself. Enemies with that same pal also spawn that greenslime enemy. I'm thinking in making an enemy (maybe a mini boss) that spawns sentry drones. Maybe if I recreate one of those ROTT robots... Maybe that NME thing, hehe!

For now, the results:






















The last image shows a mini boss I made, based on DPRECON from Dukeplus. It shoots many projectiles in sequence.




As for the map itself, it's somewhat similar to those _SE.map and _ST.MAP.

[eniojr]

There's another thing I noticed in the GAME.CON codes...

There seems to be a glitch related to the Assault Trooper and the Enforcer. The Assault Trooper is represented with a name that is very similar to the Enforcer. The Assault Trooper is listed as Trooper, but there are also references to Liztroop in the code on that actor, while the Enforcer is called Lizman. In my opinion, Lizman should be referred to as Enforcer in the code to avoid confusion, even in the codes. I think this was a flaw on the part of the developers, in addition to the automatic color change of the Assault Trooper.

Unless that was done on purpose (which I still think is a mistake).

If I had made the game, I would have chosen names that were not too similar for the enemies, to avoid confusion in the codes. For example, Trooper would be Assaulter, while Lizman could have remained that way or as Enforcer, while Pigcop would still have the same name, as would the others. If I had made the game, I would have added civilians, not just babes. That would have given the game more life.

I'm currently trying to apply an effect I added to the game, regarding the slippery floor. This effect works for the player, but for the enemies, so far it only works for Pigcop, and not for the others. It seems that there is something in the Trooper's movement physics that prevents him from moving slower on slippery floors with lotag 50. Or maybe because I got the slippery floor effect from DukePlus while the enemy slipping on the floor effect I got from Naferia... I'll try to get the slipping effect from Naferia to see if it works on the Trooper.

I don't understand why the developers made the CON language in a way that allowed Duke Nukem 3D to be modded, but even so only a part of the game is in the CON files, and not the entire game (in terms of source code), unlike what was done with Ion Fury. There is a lot of stuff in Duke Nukem that is obscured (hard coded). The Eduke32 developers could try to convert the entire game source code to the CON language.

If possible, of course. This would make it easier for new modders.

As a consequence, the GAME.CON, USER.CON and DEFS.CON files would have to be remade from scratch, and the game would probably end up having more CON files. In this case, if someone installed Eduke32 on the original game, the CON files would have to be replaced by the new Eduke32 files. This is just an idea I'm putting forward.

This would allow the entire game to be modded, if that was the developers' intention. But since the game is not as popular today as it was in the 90s and since it is already outdated, I believe there would be no problem in converting the entire game to the CON language, so that there would be no more hard-coded elements that are difficult to deal with or modify. This, of course, would make it easier to create better mods. The BUILD engine would remain the same, only the entire original game would be transliterated to CON. I heard of a newer version of the engine that was developed, but I don't think it ended up being very successful.



Maybe Eduke32 should support BUILD2, since it's the successor to the classic. Or maybe Eduke32 could have its own more modern version of BUILD. This would allow for more modern gameplay elements.

Maybe it's time for Eduke32 to be converted to Eduke64...



I've also heard of a new engine being tested for the game, a certain Brahma. The only change I would suggest for Build would be to double the maximum number of sectors, walls and sprites. The rest seems sufficient to me. Link to the Brahma engine channel: https://www.youtube....7qR4UGR2Y-dtgfm

Even though Duke Nukem 3D is already an old and obsolete game nowadays, I still see great potential if 3 things were done.

First: Transliterate all the source code to the CON language, so that the entire game could be modded, without difficult elements to deal with due to obscure coding, which would make it easier to create mods for both those who already know how to do it well and for beginners.

Second: If possible, modernize the CON language itself, which could be done by Eduke32 himself, along with more detailed examples on how to apply it in practice, more script creation models with several examples of scripts from various mods on the Eduke32 Wiki website. For example, scripts for various effects from mods such as Dukeplus, Naferia, AWOL, Duke Forces, Alien Armaggedon, AMCSquad, Kickass, Demon Throne, etc., as well as scripts for new monsters, civilians, items, among other things, such as creating new palettes.

The ultimate Duke Nukem 3D code modding tutorial!

Third: Modernization of the game's own engine, allowing for a more up-to-date version of the BUILD engine itself or perhaps the BRAHMA engine, which still seems to be in the testing phase, and which seems to be even more promising in terms of graphics and gameplay, although I'm still more familiar with BUILD itself.

Of these 3 things, the easiest would be regarding the CON language and more tutorials on the Eduke32 wiki. The slightly more challenging would be transliterating all of the game's source code into .CON files, which doesn't seem like an impossible task to me, although it is laborious and seeing if the game itself would be able to support it. The most complicated would be to make changes to the BUILD engine itself, through a major update from Eduke32 to Eduke64, lol.