[Fox]

oneventonevent?

[darkcaleb]

Fox, on 07 July 2013 - 05:13 AM, said:

oneventonevent?

Sorry this is what is in the dkgame.con file:

onevent EVENT_GETLOADTILE
setvar RETURN <3281>
endevent

[Fox]

Remove the <>, also it would be better to use LOADSCREEN instead of 3281.

[darkcaleb]

Thanks Fox. It did work. But i want to give it animations, I want to use a picture that has 4 frames. I want this to be the loading screen for something I'm working on. I have already put animation in tile file with duke-res.

[Fox]

I think this would work:

onevent EVENT_GETLOADTILE
  setvarvar RETURN totalclock
  divvar RETURN 16 // animation speed
  andvar RETURN 3
  addvar RETURN LOADSCREEN
endevent 

[darkcaleb]

Hey Fox thanks! I did work very well. Still I was wondering about the what this all means

onevent EVENT_GETLOADTILE (don't know this purpose)
setvarvar RETURN totalclock (don't know this purpose)
divvar RETURN 16 // animation speed (this is the speed)
andvar RETURN 3 (don't know this purpose)
addvar RETURN LOADSCREEN (this is the tile 3281 as I'm right?)
endevent (This is the end of the event)

Thanks again.

[Fox]

onevent <event>
endevent

This is used to call an event, which allows you to use some code at a specific occasion. For example, the EVENT_GETLOADTILE occur during the loading screen.

totalclock

It is a variable which value is constantly increased. It serves for the purpose of providing a timing for the animations.

andvar 3

Cycles the current value (totalclock divided by speed) through 0-3 (four frames).

LOADSCREEN

Same as 3281, as defined in DEFS.CON.

[darkcaleb]

Thanks Fox! At least now i understand the coding a little bit.

[m210®]

Quote

I need help with own rotate sectors.
I can't make move of player in such sectors

Well, I did it

        getplayer[THISACTOR].i PLAYERID
	setvarvar spriteid PLAYERID
	getactor[THISACTOR].sectnum rot_sect
	getactor[spriteid].sectnum se_sector
	ifvarvare rot_sect se_sector
	{
		getactor[THISACTOR].x x
		getactor[THISACTOR].y y
		getactor[spriteid].x x2
		getactor[spriteid].y y2
		subvarvar x2 x
		setvarvar dx x2
		setvarvar rot_actspeed rot_angspeed
		ifvare rot_turnway 1 mulvarvar rot_actspeed -1
		cos mycos rot_actspeed
		mulvarvar dx mycos
		divvarvar dx TRIG_MAX
		subvarvar y2 y
		setvarvar dy y2
		sin mysin rot_actspeed
		mulvarvar dy mysin
		divvarvar dy TRIG_MAX
		addvarvar x dx
		subvarvar x dy
		//setactor[spriteid].x x
		setplayer[THISACTOR].posx x
		setvarvar dy y2
		mulvarvar dy mycos
		divvarvar dy TRIG_MAX
		setvarvar dx x2
		mulvarvar dx mysin
		divvarvar dx TRIG_MAX
		addvarvar y dy
		addvarvar y dx
		//setactor[spriteid].y y
		setplayer[THISACTOR].posy y
		
		//getactor[spriteid].ang se_ang
		getplayer[THISACTOR].ang se_ang
		addvarvar se_ang rot_actspeed
		setplayer[THISACTOR].ang se_ang
		//setactor[spriteid].ang se_ang
	}

[Fox]

Could someone explain to me how exactly guniqhudid works? I tought it was to store the model animation, but the weapons.con values seems to confuse me:

chaingun: none
rpg: none
mighty boot: 0
freezer firing top half: 0
pistol: 1
shotgun: 2
shotgun firing: 4
pipebomb: 5
shrinker: 6
right devastator: 7
left tripbomb hand: 8
freezer: 9
pipebomb detonator: 10
expander: 11
shrinker crystal: 12
left devastator: 14
right tripbomb hand: 16
expander crystal: 22
tripbomb: 32
quick kick: 100
right shrunk fist: 101
left shrunk fist: 102

[Mblackwell]

http://wiki.eduke32....wiki/Guniqhudid

Quote

The purpose of the guniqhudid command is that models drawn to the screen via rotatesprite do not have a sprite id like all other sprites in the game world. The engine needs some sort of ID so that it knows where and what to draw.

This command will allow you to select a different slot so that any HUD models you are drawing can store their animation state independently, without conflict. By default it uses the first slot, 0. If you need several animating HUD models, you should switch to another slot, draw the model with rotatesprite, then switch back using guniqhudid 0.

guniqhudid is short for "g (game? gun?) unique HUD ID".

In weapons.con (written by Hendricks) it just looks like he assigned all of the hud models a unique id (which is not necessarily necessary unless the models are going to display simultaneously or you need the animation state preserved but it's fine). No big deal.

[Hendricks266]

I think the wiki page sums it up: for the renderers to draw a model on the screen, internally they get assigned a unique sprite ID in some extra space allocated after the array of sprites.

I copied the guniqhudid values in weapons.con.sample verbatim from what is used in player.c.

[Mblackwell]

From the horse's mouth.

[Mark]

While testing some replacements for original enemies I noticed that when they drop into a non submersible water sector they pop back up to the surface height for their shooting animation and at other times randomly. I fired up a non modified version of the game and verified the original enemies acted the same way. I'm sure something this obvious has been mentioned before. Is it possible to fix this in cons? If you have an answer or a link to previous discussions on the topic let me know.Thanks.

[Fox]

No. It is a glitch that has something to do with Eduke32 submerging code.

Hendricks266, on 10 July 2013 - 06:49 PM, said:

I think the wiki page sums it up: for the renderers to draw a model on the screen, internally they get assigned a unique sprite ID in some extra space allocated after the array of sprites.

I copied the guniqhudid values in weapons.con.sample verbatim from what is used in player.c.

The values appear to be almost random. Every piece should be separated in a different layer defined by MAXWEAPONS times the layer.

[Mark]

Spoiler

define DOGSTRENGTH 40

action DOGRUN 16 1 1 1 0
action DOGTROT 15 1 1 1 0
action DOGBITE 8 1 1 1 0
action DOGSTAND 0 1 1 1 0
action DOGJUMP 7 1 1 1 0
action DOGDIE  13 1 1 1 0

move DOGSPEED 100

ai AIDOGBITE DOGBITE faceplayer
ai AIDOGCHARGE DOGRUN DOGSPEED faceplayer
ai AIDOGDYING DOGDIE faceplayer
ai AIDOGSTAND DOGSTAND randomangle

useractor enemy DOG DOGSTRENGTH
sizeat 48 48
cstator 257        

ifaction 0
{ ai AIDOGCHARGE }

else
{
ifhitweapon
  {
    ifdead
    {
      guts JIBS6 1
      spawn BLOODPOOL
      sound DEAD_DOG
      ai AIDOGDYING
    }
    else
    {
      guts JIBS6 3
      sound WHINING_DOG
    }
  }
 
 }
 ifactornotstayput
  {
    ifp palive
      ifcansee
        ifpdistl 200
    {
      ai AIDOGBITE
      addphealth DOGBITESTRENGTH
      sound DUKE_GRUNT
	  break
 }

    ifai AIDOGCHARGE
    {
      ifp palive
        ifpdistl 1200
          ifcansee
      {
        ai AIDOGBITE
        addphealth DOGBITESTRENGTH
        sound DUKE_GRUNT
        break
      }
 }
    else
      ifpdistg 2048
    {
      ai AIDOGCHARGE
      break
    
 }
 }
 enda

Its taken me pretty much the whole day, on and off, but I've got a basic enemy coded from scratch. I'm waiting for this day to be declared a national holiday.

Its real basic stuff right now and will be expanded upon as I learn more coding. But I need help with a problem that I've spent the last 2 hours on and can't figure out the fix. When the dog charges the player and gets within a certain distance it goes into the DOGBITE mode. The problem is that it only performs the actions ( action, sound, player health) once instead of multiple times. When the player backs away and the dog approaches again its the same thing. Just one bite and then nothing. I'm guessing I need to nest some lines in a better place but I tried and tried and couldn't figure it out.

[Mblackwell]

You might want to change the last digit in your actions to 1. I seem to recall having odd errors if I didn't but that was back in ye olde 1.3d days so what the hell, things just become habits. Also IIRC if you're using ai commands you need to make sure that ifai AIDOGBITE is not true before you run it or it will cancel itself.

Generally I recommend avoiding AI commands and just using simple actions/actioncount/move commands. Then again I also tend to define everything as notenemy and then manually adding in spriteshadow and kill counts but I'm an oddball I guess.

[Mark]

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.

[Fox]

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.

[Mark]

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.

[Fox]

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.

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.

[Mark]

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?

[Fox]

The AMYENEMY_STOP is not a definition, but an action. This would be enough:

action AMYENEMY_STOP 0

I would recommend you not to never use saved games if you are editing the CONs.

[Mblackwell]

Save games save the current CON state. So any modifications you make will not be reflected in your save game.

[zazo]

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 ?

[Mark]

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.

[zazo]

Is a batch command exist to launch editart automatically in dosbox ??

[Mark]

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.

[Fox]

Don't bother with the view after the death, it's too complicated.

[Mark]

What about the switching to 3rd person part?