Help
Duke4.net
DNF #1
Duke 3D #1
BTW, I still have had zero success in coding any climbing abilities for new enemies.
EDuke32 Scripting "CON coding help"
#1368 Posted 14 July 2013 - 02:01 AM
That is the double edged sword of con coding. It has the flexability of coding the same thing different ways. But that makes it more difficult to learn when I can't find a consistant way to code something after looking at other people's projects for help.
BTW, I still have had zero success in coding any climbing abilities for new enemies.
BTW, I still have had zero success in coding any climbing abilities for new enemies.
This post has been edited by Mark.: 14 July 2013 - 04:44 AM
- Fraka kaka kaka kaka-kow!
-
#1369 Posted 14 July 2013 - 10:07 AM
I don't think you should worry about the last digit of the action unless you use ifactioncount. In fact you would be fine by having just the first digit.
You seems to be confused with the use of {} and break.
You seems to be confused with the use of {} and break.
This post has been edited by Fox: 14 July 2013 - 10:07 AM
#1370 Posted 14 July 2013 - 11:45 AM
Yes I am. What you see in the previous posted code is where I left off after about 45 tries to get something right. Bringing the break command in was one of the last things I tried before posting for help. I feel like I have most of what I need there, but not grouped properly and maybe missing just one or two small but important commands. I tried to learn from the code of other people but every project I look into, the coder does things in a different way. Some prefer actions to ai, some prefer using states, others borrow previously defined gamevars and TEMP values from elsewhere in their code. Its tough to follow. But I can't believe I've gotten this far after my first feeble attempts and then gave up. I'm glad I made this second serious attempt. But its still VERY frustrating and slow with all this trial and error. And I've got a long way to go to get all these new enemies up to my expectations.
This post has been edited by Mark.: 14 July 2013 - 11:47 AM
- Fraka kaka kaka kaka-kow!
-
#1371 Posted 14 July 2013 - 02:27 PM
There must be a logic behind every code. By trial and error you will never get far, and probably will result in a defective code. I will try to explain the basic for you.
First of all you must understand that a code is constantly running. By default Duke 3D works at 30 time units (tics) per second, meaning that if you simply add a code inside of an actor (sprite), the code will run 30 times each second.
The code above would basically increase the player health 1 point to a maximum of 100 points, and do so every tic, 30 times per second. There is no condition to it, so the moment you start the level, you would feel the effects.
An if condition basically makes the code works only under a specific circumstance. Example:
Here I am telling the game to only heal the player if his distance to the current actor is less than 1024 Build units (same as the map editor). However the command would still run 30 times every second non-stop once you meet the condition, but I will return to this subject later.
An else is used for the opposite effect. Example:
This would heal the player by 10 points if the player is at a distance of 1024 units to the actor, otherwise it will be just 1 point.
A nullop is a void command, and is used as a hack to tell the game to do nothing. Example:
This basically tells the game to do nothing if the player is at less than 1024 units away, otherwise heal the player. In other words, it is the same as telling the game that the code should work only the player is 1024 or more units away. Of course this is just an example, there is a ifpdistg command so you wouldn't need to do that in this case.
The {} are used to enclose a piece of the code that works under the if condition. This is because by default an if condition only take affect on the first command used after it (normally on the first line below it). In other words, the {} you want to make the same condition apply to multiple commands. For example:
The code above heal the player by 1 point and increase the Pistol ammo by 1 shot if the player is at a distance of 1024 units. Below is a code that does the same thing, the difference is that the code above is more pleasing — and efficient.
Now you must understand how to use the {} with multiple if conditions.
The code above is very simply, the two commands will only work if the player is at a distance of 1024 units and is facing the current actor. However you can change it:
Now the player health will be increased by 1 health if he is at a distance of 1024 and facing the actor, however the ammo will only be increased if you are at a distance of 1024 regardless regardless of the direction the player is facing.
Above is a more complex example of how to handle the {} and if conditions. Inside the condition of the player at a distance of 1024 units, if the player is facing the current actor increase the health by 10, otherwise increase the ammo by 1; if the condition of the player being at a distance of 1024 is false, then increase the health by 1.
And here is an example of a series of if conditions, which is used a lot in GAME.CON:
The code above tells the game to increase the health by 100 if the player is at a distance of 1024 units, otherwise increase the health by 50 if the player at a distance of 2048 units, otherwise (i.e. the two previous conditions must be false) increase the health by 10 if the player is facing the actor direction, and if none of these conditions are true, increase the health by 1.
Now let's talk about the code running non-stop as I mentioned back then. That what you use actions for.
By default an actor starts with an action that equals zero, that's why I check if it is zero. Once the distance of 1024 units is meet, increase the player health by 1 point, and make the current actor action AMYENEMY_STOP. As a result, this code will only run a single time in the life.
Now here is a code that would make the code stop once the condition is meet, however it will be reset if the player is 1024 away again. Meaning that the player must walk forth and back to make the code works multiple times.
I hope this helped you to understand the logic behind the CON code.
First of all you must understand that a code is constantly running. By default Duke 3D works at 30 time units (tics) per second, meaning that if you simply add a code inside of an actor (sprite), the code will run 30 times each second.
useractor notenemy MYENEMY addphealth 1 enda
The code above would basically increase the player health 1 point to a maximum of 100 points, and do so every tic, 30 times per second. There is no condition to it, so the moment you start the level, you would feel the effects.
An if condition basically makes the code works only under a specific circumstance. Example:
useractor notenemy MYENEMY
ifpdistl 1024
addphealth 1
enda
Here I am telling the game to only heal the player if his distance to the current actor is less than 1024 Build units (same as the map editor). However the command would still run 30 times every second non-stop once you meet the condition, but I will return to this subject later.
An else is used for the opposite effect. Example:
useractor notenemy MYENEMY
ifpdistl 1024
addphealth 1
else
addphealth 10
enda
This would heal the player by 10 points if the player is at a distance of 1024 units to the actor, otherwise it will be just 1 point.
A nullop is a void command, and is used as a hack to tell the game to do nothing. Example:
useractor notenemy MYENEMY
ifpdistl 1024
nullop
else
addphealth 1
enda
This basically tells the game to do nothing if the player is at less than 1024 units away, otherwise heal the player. In other words, it is the same as telling the game that the code should work only the player is 1024 or more units away. Of course this is just an example, there is a ifpdistg command so you wouldn't need to do that in this case.
The {} are used to enclose a piece of the code that works under the if condition. This is because by default an if condition only take affect on the first command used after it (normally on the first line below it). In other words, the {} you want to make the same condition apply to multiple commands. For example:
useractor notenemy MYENEMY
ifpdistl 1024
{
addphealth 1
addammo PISTOL_WEAPON 1
}
enda
The code above heal the player by 1 point and increase the Pistol ammo by 1 shot if the player is at a distance of 1024 units. Below is a code that does the same thing, the difference is that the code above is more pleasing — and efficient.
useractor notenemy MYENEMY
ifpdistl 1024
addphealth 1
ifpdistl 1024
addammo PISTOL_WEAPON 1
enda
Now you must understand how to use the {} with multiple if conditions.
useractor notenemy MYENEMY
ifpdistl 1024
ifp pfacing
{
addphealth 1
addammo PISTOL_WEAPON 1
}
enda
The code above is very simply, the two commands will only work if the player is at a distance of 1024 units and is facing the current actor. However you can change it:
useractor notenemy MYENEMY
ifpdistl 1024
{
addphealth 1
ifp pfacing
addammo PISTOL_WEAPON 1
}
enda
Now the player health will be increased by 1 health if he is at a distance of 1024 and facing the actor, however the ammo will only be increased if you are at a distance of 1024 regardless regardless of the direction the player is facing.
useractor notenemy MYENEMY
ifpdistl 1024
{
ifp pfacing
addphealth 10
else
addammo PISTOL_WEAPON 1
}
else
addphealth 1
enda
Above is a more complex example of how to handle the {} and if conditions. Inside the condition of the player at a distance of 1024 units, if the player is facing the current actor increase the health by 10, otherwise increase the ammo by 1; if the condition of the player being at a distance of 1024 is false, then increase the health by 1.
And here is an example of a series of if conditions, which is used a lot in GAME.CON:
useractor notenemy MYENEMY
ifpdistl 1024
addphealth 100
else
ifpdistl 2048
addphealth 50
else
ifp pfacing
addphealth 10
else
addphealth 1
enda
The code above tells the game to increase the health by 100 if the player is at a distance of 1024 units, otherwise increase the health by 50 if the player at a distance of 2048 units, otherwise (i.e. the two previous conditions must be false) increase the health by 10 if the player is facing the actor direction, and if none of these conditions are true, increase the health by 1.
Now let's talk about the code running non-stop as I mentioned back then. That what you use actions for.
useractor notenemy MYENEMY
ifpdistl 1024
ifaction 0
{
addphealth 1
action AMYENEMY_STOP
}
enda
By default an actor starts with an action that equals zero, that's why I check if it is zero. Once the distance of 1024 units is meet, increase the player health by 1 point, and make the current actor action AMYENEMY_STOP. As a result, this code will only run a single time in the life.
Now here is a code that would make the code stop once the condition is meet, however it will be reset if the player is 1024 away again. Meaning that the player must walk forth and back to make the code works multiple times.
useractor notenemy MYENEMY
ifpdistl 1024
{
ifaction 0
{
addphealth 1
action AMYENEMY_STOP
}
}
else
ifaction AMYENEMY_STOP
action 0
enda
I hope this helped you to understand the logic behind the CON code.
#1372 Posted 14 July 2013 - 03:27 PM
Thanks. After reading your post this morning I went back and cleaned up and aligned my code lines so that it was a lot easier to see the flow. All the brackets pairs and their contents are now easier to follow. Actually, there have been few errors in the log file as I messed around. Just stuff not executing in the proper order or at all. I really should have waited until my cleanup before posting yesterday.
3 things really stand out from your latest post.
1. I assumed all if / else code had to be in brackets but I see in the first examples that is not so.
2. That multiple else's can be strung together.
3. The nullop command for when you don't have an alternative to fill in.
Concerning the last code snippet, what is AMYENEMY_STOP defined as?
BTW, I really screwed myself earlier today. I got tired of scrolling the menu down to the newboard map every time I tested something. So I thought " hey I'll save the game right after it starts so I can use load game at the menu. Turns out that was a big mistake. The dog wouldn't start to run because "action" did not start at 0 in a saved game. So I butchered my code trying to figure out that one. Live and learn. Does this mean that I need to do something so that it will load properly on a saved game?
3 things really stand out from your latest post.
1. I assumed all if / else code had to be in brackets but I see in the first examples that is not so.
2. That multiple else's can be strung together.
3. The nullop command for when you don't have an alternative to fill in.
Concerning the last code snippet, what is AMYENEMY_STOP defined as?
BTW, I really screwed myself earlier today. I got tired of scrolling the menu down to the newboard map every time I tested something. So I thought " hey I'll save the game right after it starts so I can use load game at the menu. Turns out that was a big mistake. The dog wouldn't start to run because "action" did not start at 0 in a saved game. So I butchered my code trying to figure out that one. Live and learn. Does this mean that I need to do something so that it will load properly on a saved game?
This post has been edited by Mark.: 14 July 2013 - 03:38 PM
- Fraka kaka kaka kaka-kow!
-
#1373 Posted 14 July 2013 - 03:44 PM
The AMYENEMY_STOP is not a definition, but an action. This would be enough:
I would recommend you not to never use saved games if you are editing the CONs.
action AMYENEMY_STOP 0
I would recommend you not to never use saved games if you are editing the CONs.
- Evil Overlord
-
#1374 Posted 14 July 2013 - 06:08 PM
Save games save the current CON state. So any modifications you make will not be reflected in your save game.
#1375 Posted 16 July 2013 - 02:09 AM
I try to make a enemy that break decorative objects around him when he is moving: a kind of hitradius not acting like an explosion (burst the enemies) but a sort of knee weapon with a radius of action ...
"shoot knee" seems to aime the player everytime and is not usefull ?
"shoot knee" seems to aime the player everytime and is not usefull ?
#1376 Posted 16 July 2013 - 06:35 PM
I'm taking a short break from the Dog's con coding. If I run the seperate actions one at a time and comment out the rest, they all work. I still haven't quite figured out how to get them all to work in harmony together. There always seems to be one part that doesnt run when they are joined. So tonight I switched over to prepare the Pigcop code for another new enemy. The first thing I needed to do was get rid of the diving and diveshoot actions. When I first tried this months ago it was unsuccessful, uneducated trial and error. Tonight I was able to carve out the "offending" code with the precision of a surgeon. No errors and I was successful the first time. I guess some of this is finally sinking in.
This post has been edited by Mark.: 16 July 2013 - 06:37 PM
#1377 Posted 25 July 2013 - 03:33 AM
Is a batch command exist to launch editart automatically in dosbox ??
#1378 Posted 27 July 2013 - 05:20 AM
When the player falls to their death, is there some way to have the view switch to 3rd person and the view NOT be upside down after impact?
Second question. How do I make an enemy model run a different dying animation when hit with the RPG? My thoughts are that I create a second version of the model with only the second dying animation in it. Then when the enemy is hit with the RPG I use "killit" to get rid of the first model and then have the second model spawned in.
EDIT: I tried out the spawning and it wasn't working. Then I remembered that only certain tile numbers will spawn so I'll have to replace one of those tiles with my dying model.
Second question. How do I make an enemy model run a different dying animation when hit with the RPG? My thoughts are that I create a second version of the model with only the second dying animation in it. Then when the enemy is hit with the RPG I use "killit" to get rid of the first model and then have the second model spawned in.
EDIT: I tried out the spawning and it wasn't working. Then I remembered that only certain tile numbers will spawn so I'll have to replace one of those tiles with my dying model.
This post has been edited by Mark.: 27 July 2013 - 07:15 AM
- Fraka kaka kaka kaka-kow!
-
#1379 Posted 27 July 2013 - 07:30 AM
Don't bother with the view after the death, it's too complicated.
#1380 Posted 27 July 2013 - 07:35 AM
What about the switching to 3rd person part?
This post has been edited by Mark.: 27 July 2013 - 07:57 AM
- Fraka kaka kaka kaka-kow!
-
#1381 Posted 27 July 2013 - 10:29 AM
This should work rudimentarily:
onevent EVENT_DISPLAYROOMS
ifp pdead
setvar cameradist 65536
endevent
#1382 Posted 27 July 2013 - 01:45 PM
It didn't seem to do anything. Thanks. I'm going to forget that request for now and try to solve my other more important problem about having 2 different dying animations depending on which weapon did the killing. As mentioned before I have 2 versions of the model . One for all the regular animations and death number one. The second version contains a flying apart animation for when the RPG does the killing.
I can't get something to spawn if the enemy is killed with the RPG. I assume I'm overlooking something easy again.
1. GreenPuke, 4389, is one of the spawnable items in the game so I defined my new MONSTERDIE to that tile number in DEFS.CON
2. The MONSTERDIE model was def'ed into tile 4389 and will show up in Mapster if I place that tile number in a test map so I know its working.
3. Towards the beginning of GAME.CON I created a useractor called MONSTERDIE since the wiki states that the spawnable item needs to be an actor.
4. In the TROOPER code, which my new enemy is using, I added the line "spawn MONSTERDIE" right after the entries for sound and killit. This is nested in the " ifdead " code.
ifwasweapon RPG
{
sound ROCK_BUST
killit
spawn MONSTERDIE
}
The sound and killit parts run fine so I know I didn't mess up the lines of code. But the MONSTERDIE actor will not appear after the enemy dies. Any ideas what I am forgetting?
I can't get something to spawn if the enemy is killed with the RPG. I assume I'm overlooking something easy again.
1. GreenPuke, 4389, is one of the spawnable items in the game so I defined my new MONSTERDIE to that tile number in DEFS.CON
2. The MONSTERDIE model was def'ed into tile 4389 and will show up in Mapster if I place that tile number in a test map so I know its working.
3. Towards the beginning of GAME.CON I created a useractor called MONSTERDIE since the wiki states that the spawnable item needs to be an actor.
4. In the TROOPER code, which my new enemy is using, I added the line "spawn MONSTERDIE" right after the entries for sound and killit. This is nested in the " ifdead " code.
ifwasweapon RPG
{
sound ROCK_BUST
killit
spawn MONSTERDIE
}
The sound and killit parts run fine so I know I didn't mess up the lines of code. But the MONSTERDIE actor will not appear after the enemy dies. Any ideas what I am forgetting?
This post has been edited by Mark.: 27 July 2013 - 02:12 PM
- Fraka kaka kaka kaka-kow!
-
#1383 Posted 27 July 2013 - 02:14 PM
I don't see the point is duplicating the tile definition, instead you could just use PUKE. Also PUKE already has a hard-coded behavior similar to BLOODPOOL, which you should keep in mind.
A code won't work if you place it after the killit command, since the sprite ceases to exist and the actor code is aborted when killit is used.
A code won't work if you place it after the killit command, since the sprite ceases to exist and the actor code is aborted when killit is used.
This post has been edited by Fox: 27 July 2013 - 02:15 PM
#1384 Posted 27 July 2013 - 02:18 PM
Fox, on 27 July 2013 - 02:14 PM, said:
I don't see the point is duplicating the tile definition, instead you could just use PUKE. Also PUKE already has a hard-coded behavior similar to BLOODPOOL, which you should keep in mind.
A code won't work if you place it after the killit command, since the sprite ceases to exist and the actor code is aborted when killit is used.
A code won't work if you place it after the killit command, since the sprite ceases to exist and the actor code is aborted when killit is used.
I didn't duplicate the tile definition. I just replaced the word PUKE with MONSTERDIE so I could keep track of things. If I don't use the killit command how do I get rid of the first model when the second model takes it's place? My uneducated guess is that after the new actor model spawns I have to detect if its in the game and if so, THEN use killit on the first model? Or is my logic laughable?
BTW, I tried some other tiles besides Puke and still no luck. It would be great if I could just use a newly defined tile but the game only allows to choose from a list of spawnable tiles. Which known to work tile numbers do others replace in their mods. Anyone?
This post has been edited by Mark.: 27 July 2013 - 02:37 PM
- Fraka kaka kaka kaka-kow!
-
#1385 Posted 27 July 2013 - 02:41 PM
Just use your code before killit:
By default sprites in Duke 3D spawn with a scale of 1 by 1. So if you are not spawning a hard-coded sprite, it is necessary to set the scale when a new sprite is spawned...
spawn MONSTERDIE killit
By default sprites in Duke 3D spawn with a scale of 1 by 1. So if you are not spawning a hard-coded sprite, it is necessary to set the scale when a new sprite is spawned...
onevent EVENT_EGS
ifactor MONSTERDIE
sizeat 64 64
endevent
#1386 Posted 27 July 2013 - 02:55 PM
EDIT: I figured it out and then found your post. 
Two odd things though. One, I managed to get a completely new tile 8421 to spawn instead of only replacing something from the "pre-approved" list of original sprites. The second odd thing is I had to massively increase the scale of the second model by 150 to bring it up to proper size.
Two odd things though. One, I managed to get a completely new tile 8421 to spawn instead of only replacing something from the "pre-approved" list of original sprites. The second odd thing is I had to massively increase the scale of the second model by 150 to bring it up to proper size.
This post has been edited by Mark.: 27 July 2013 - 03:00 PM
#1387 Posted 03 August 2013 - 04:57 PM
Is there an easy way to bypass the VOLUME1 end of level sequence? I know I could disable or replace all the relevant sounds and pics that make up the cutscene but an easy line or 2 of con would be preferable.
Searching only turned up something about disabling the VOLUME4 intro.
Searching only turned up something about disabling the VOLUME4 intro.
#1388 Posted 09 August 2013 - 05:15 AM
Hello,
im trying to do my own projectile in game, everything is ok, but function PROJ_FLASH_COLOR doesn't seem to work.
syntax is:
but it doesn't do anything, i've tried many combinations...
Is there any way to attach the light on the projectil?
thanks for any help,
im trying to do my own projectile in game, everything is ok, but function PROJ_FLASH_COLOR doesn't seem to work.
syntax is:
Quote
defineprojectile <tile number> PROJ_FLASH_COLOR <number>
Where <number> is the color of the light. The number can be determined from RGB color values by adding the red value plus the green value shifted left 8 bits plus the blue value shifted left 16 bits. So, RGB of 100, 100, 100 would be 6579300 = 100 + 100<<8 + 100<<16 = 100 + 25600 + 6553600. 150, 100, 255 would be 16737380.
Where <number> is the color of the light. The number can be determined from RGB color values by adding the red value plus the green value shifted left 8 bits plus the blue value shifted left 16 bits. So, RGB of 100, 100, 100 would be 6579300 = 100 + 100<<8 + 100<<16 = 100 + 25600 + 6553600. 150, 100, 255 would be 16737380.
but it doesn't do anything, i've tried many combinations...
Is there any way to attach the light on the projectil?
thanks for any help,
This post has been edited by Mblackwell: 09 August 2013 - 07:41 PM
- Judge Mental
-
#1389 Posted 17 August 2013 - 07:08 PM
Is there a way to make the security camera's not take player control/freeze the player?
#1390 Posted 17 October 2013 - 06:37 AM
Hum, is a way to force the third person view when then game starts, in the goal to make a better view in melee fights instead of first person view ?
- EDuke32 Developer
-
#1391 Posted 17 October 2013 - 08:47 AM
Mark., on 03 August 2013 - 04:57 PM, said:
Is there an easy way to bypass the VOLUME1 end of level sequence? I know I could disable or replace all the relevant sounds and pics that make up the cutscene but an easy line or 2 of con would be preferable.
Oh well... since that was requested once already, I went ahead and added four new LOGO_FLAGS bits.
r4109 said:
CON: Add LOGO_FLAGS bits 4096-32768 to disable E1-E4 bonus scenes, respectively.
Each scene is disabled in its entirety, there's no way to disable only a
particular part.
Each scene is disabled in its entirety, there's no way to disable only a
particular part.
However, I made that revision not produce a synthesis build because 20 megs on the server for such a small change feels wasteful to me. You'll have to wait until more changes have accumulated...
#1392 Posted 20 January 2014 - 12:23 PM
Any advice how to to do a continuous earthquake?
Like, sprite which activates world's shaking and wouldn't ever stop it - until the map changes.
Is it hard-coded function, or what? I have no ideas where to look at.
Like, sprite which activates world's shaking and wouldn't ever stop it - until the map changes.
Is it hard-coded function, or what? I have no ideas where to look at.
#1393 Posted 20 January 2014 - 04:55 PM
Helixhorned, on 17 October 2013 - 08:47 AM, said:
Oh well... since that was requested once already, I went ahead and added four new LOGO_FLAGS bits.
However, I made that revision not produce a synthesis build because 20 megs on the server for such a small change feels wasteful to me. You'll have to wait until more changes have accumulated...
However, I made that revision not produce a synthesis build because 20 megs on the server for such a small change feels wasteful to me. You'll have to wait until more changes have accumulated...
I'm not sure if I used your info properly or not. I saw that LOGO_FLAGS was considered a gamevar so at the beginning of my defs.con file I added in
gamevar LOGO_FLAGS 0 4096
right after a bunch of other gamevars. What happens is that instead of bypassing the E1 ending screen, the game's loading screens at the beginning are bypassed and the menu appears directly. A handy feature but not what I was expecting. Did I do something wrong on my end?
This post has been edited by Mark.: 20 January 2014 - 04:56 PM
- Ancient Blood God
-
#1394 Posted 20 January 2014 - 04:58 PM
It's a bitfield, LOGO_FLAGS. Combine all the numbers together for the effects you want it to do.
Ie. if you want to remove the 3D Realms logo and the Duke Nukem 3D title screen, you change the value to 24.
EDIT: Derp, what. I forgot if you had to enable it or something.
Ie. if you want to remove the 3D Realms logo and the Duke Nukem 3D title screen, you change the value to 24.
EDIT: Derp, what. I forgot if you had to enable it or something.
This post has been edited by Daedolon: 20 January 2014 - 05:00 PM
#1395 Posted 20 January 2014 - 05:01 PM
I'll have to check again. I thought that the list of bitfields showed that 4096 was to bypass E1 ending screen.
- Ancient Blood God
-
#1396 Posted 20 January 2014 - 05:03 PM
It's the "BONUS" screen, which I assume means the score screen, in the same way as the bonusmusic is the score screen music.
- Weaponized Autism
-
#1397 Posted 20 January 2014 - 05:05 PM
The value you want is 4351, because whoever designed this variable decided to make it work as an enabler with a default value that must be maintained, instead of zero.
