[Besli]

empy, on 17 July 2011 - 05:04 AM, said:

Made some textures today.

I really like tile #6837, but also the crates are very good, and very close to the original.
Nice work, empy!

[m210®]

Hi for all. A want to offer my idea with sprites in rotatesectors.
As I understand sprites is move if it have statnum = 0, but is possible to make other else statnum for useractor for moving, for example statnum =14?
What do you think about this?

[m210®]

Btw, I start to make new AI of zombie and changed animation of moving. Now zombie can't attack, just go to player, but it can go to player if one away to wall and zombie can't see a player.
also zombie can turn(avoid?) obstacles of sprites. Code isn't complete and zombies don't attacking other enemies whos damaged it, but I want to know what are you know about this new AI code.
There is a my new con files of BloodTC
http://rghost.ru/14974161
It also have fixes of dynamite, flare pistol projectile, correct the height of player jumping and some small addition to code

[Spiker]

Zombie movement is much better now! But at the momment they are immortal Cultists can't be killed too if they shoot the zombies. The dynamite works better now. You should make napalm launcher explosion shake the screen as well, it's very noticable it doesn't move. When jumping in real Blood the camera seems to make a slight crouching movement when player hits the ground, I can't notice that here.

EDIT: flare pistol alt fire sometimes spaws flares on monsters too but it should never do that, only regular fire should do that.

[m210®]

Spiker, on 19 July 2011 - 12:46 AM, said:

EDIT: flare pistol alt fire sometimes spaws flares on monsters too but it should never do that, only regular fire should do that.

Hm...I never saw this, I'll try to check it, thanks) btw, in last archive flarefire projectile works not true, because I forgot to set width and height of enemies and projectile stick to center of enemies.

Spiker, on 19 July 2011 - 12:46 AM, said:

Zombie movement is much better now! But at the momment they are immortal Cultists can't be killed too if they shoot the zombies.

Because zombie not complete, I just made movement that's all

Spiker, on 19 July 2011 - 12:46 AM, said:

You should make napalm launcher explosion shake the screen as well, it's very noticable it doesn't move. When jumping in real Blood the camera seems to make a slight crouching movement when player hits the ground, I can't notice that here.

I made offset of weapon when player hits the ground, I think is need to made offset of cameraZ also for good effect. Shake the screen I'll make too

[Micky C]

Keep up the good work M210

[Helixhorned]

M210, on 18 July 2011 - 10:02 AM, said:

Hi for all. A want to offer my idea with sprites in rotatesectors.
As I understand sprites is move if it have statnum = 0, but is possible to make other else statnum for useractor for moving, for example statnum =14?
What do you think about this?

I asked M210 to repost his PM'd question to me in the hope of getting some discussion going on, but I think I've settled on an acceptable solution. The problem is that actors can't, in general, be roundoff-error-accumulation-corrected (phew) because that requires the sprites to have a fixed position with respect to the rotating sector. My idea is to add a new <actortype> token to the useractor definition, effectively giving a hint to the game, "this actor will never move on its own".

[m210®]

I thinks it's a good idea

[m210®]

Spiker, on 08 June 2011 - 09:53 AM, said:

Also if you want to make it really close, bear in mind there are different names for secret areas and not just one. Including "super secrets?" which get additional remark in the level summary if you happen to find one. The one which is probably well known is in the last area of E1M1, it's hard to find but you need to jump from the hole in the wall and behind a masked wall there is the secret with hidden plasma.

Ok, I made it, and It was not difficult

[Spiker]

Cool! Hopefully this thing works automatically without a need to put it into the maps directly. I remember there is one secret area in the game that says "I can't believe you have found this...." Actually the game is full of super secrets but they are very well hidden.

[m210®]

Spiker, on 23 July 2011 - 02:10 AM, said:

I remember there is one secret area in the game that says "I can't believe you have found this...." Actually the game is full of super secrets but they are very well hidden.

Yeap, there is e1m6 and I made it...for unique message you need to place triggerquote sprite.
A SECRET IS REVEALED. and YOU FOUND A SECRET. displaying automatically

[m210®]

Well, I made a new release win new zombie and new secret system. e1m1 was changed also

[DavoX]

Good man! I love Blood!

[Spiker]

I love it too. I even played it from start to finish a few days ago (real game). However the new zombie is not convincing. I don't even know if it's possible to make it look right

[m210®]

yes, stupid duke engine AI makes it impossible to do it right But it still looks better than it used to be

[Danukem]

M210, on 27 July 2011 - 02:47 AM, said:

yes, stupid duke engine AI makes it impossible to do it right

What is the problem, exactly?

[Hendricks266]

That's why you don't use Todd's AI commands, and instead code your own from scratch.

Slightly off topic, but is there a way to add sprite movement interpolation to useractors?

[m210®]

DeeperThought, on 27 July 2011 - 09:30 AM, said:

What is the problem, exactly?

I think I can't tell all of problems on english, but I'll try it
For example - ai AIZOMBIEWALK AZOMBIEWALK1 ZOMBIEWALK <parameter>
If <parameter> leave equal 0, enemy will stay in one place without moving, it will have just animation of move.
I fount getv which doesn't forward ang of enemy to player, but if enemy is close to wall, its angle changed dramatically in the opposite direction, therefore I can't smoothly unfold a enemy.
The same problems make it impossible to correctly avoid obstacles, enemy begins to frantically spin around obstacles, performing my code and standard code AI.
This problems can be corrected by notenemy option, but then enemy becomes transparent to the player, if player is close to enemy.
Btw, with the "enemy' option, zombie moves in spurts, it is ugly...
I think this problems may correct if to write new code of moving through the change of coordinates, but is likely to yield a enemy beyond the level

Quote

That's why you don't use Todd's AI commands, and instead code your own from scratch.

What is it? I don't know about this AI.

[m210®]

Btw, I used hitscan and canseespr commands, and it's doesnt works fine...and I can increase IQ of my AI if I'll can correct rules of this commands

[Danukem]

M210, on 27 July 2011 - 09:55 AM, said:

What is it? I don't know about this AI.

He was referring to the old ai commands, such geth, seekplayer, faceplayer, and so on. And he is right that you can't rely on those to make a well coded monster. However, they are still useful.

@Hendricks266: It would be nice if all useractors were hardcoded to take advantage of movement interpolation. Barring that, there are two events that look promising: EVENT_ANIMATESPRITES and EVENT_FAKEDOMOVETHINGS. The latter is a mystery to me, but I remember TX saying something about it once that sounded relevant.

[Helixhorned]

What kind of sprite movement interpolation are you guys talking about? I put a couple of useractors (CANNON, NEWBEASTSTAYPUT and TANK, as representatives of the three actortypes) into a subway and they didn't jitter, but that's probably not what you mean.

EVENT_FAKEDOMOVETHINGS isn't used anymore, it was only meaningful with the old netcode.

[Danukem]

Helixhorned, on 27 July 2011 - 11:18 AM, said:

What kind of sprite movement interpolation are you guys talking about? I put a couple of useractors (CANNON, NEWBEASTSTAYPUT and TANK, as representatives of the three actortypes) into a subway and they didn't jitter, but that's probably not what you mean.

I'm not 100% of what I'm talking about, but here is how I understand it.

The actual coordinates of things in the gameworld are updated once per game tic (30 times per second). However, many objects are rendered so that they appear to have coordinates which are updated more often. Thus, their movement appears silky smooth at high framerates, not jerky as you would expect it to be with only 30 updates per second. If I were to make a moving actor, and I were to use the setsprite command (which simply places a sprite at new coordinates) to update its position every tic, then it will move in a jerky fashion (although this wouldn't be obvious unless it were moving at a high velocity). On the other hand, a projectile moving at the same speed would have smooth movement, because its coordinates are being interpolated between tics.

Some of us have strongly suspected (AFAIK no one has actually looked at the source code to prove it) that useractors do not make use of hardcoded movement interpolation, and that is why their movements do not appear to be very smooth.

A moving sector, such as a subway, is one of those gameworld things that uses movement interpolation. Therefore, any sprites are are on the subway might enjoy the benefits of that, insofar as their movement is due to the movement of the sector.

[Helixhorned]

Just did some tests. It turns out that useractors are movement-interpolated, but their coordinates are updated in intervals longer than one game tic (I'd guess about 4), which makes them move around very jerkily indeed. You can verify it yourself by spawning, say, a NEWBEAST and setting the 120-Hz timer to e.g. a quarter of its normal frequency. ("inittimer <Hz>", debug build only.) Doing this will clearly show phases in which the monster moves, but also that the movements themselves are very well interpolated. My suspicion is that monsters are being computed only once every few tics to save CPU, for which there was likely a need back in the day.

[Jblade]

That's interesting, and explains alot about why the original enemies seem to look so smooth compared to useractor stuff. Is there anyway you can add a spriteflag or something so that they interpolate at the same rate as normal enemies? (either that or just do it automatically, but that'll probably effect performance alot I guess?)

[Danukem]

James, on 27 July 2011 - 12:53 PM, said:

(either that or just do it automatically, but that'll probably effect performance alot I guess?)

Nah, it shouldn't hurt performance at all to fix that. If the update lag is an optimization, it was made back when the Atomic Edition was developed. Most of the useractors that came with the game were the food and other destructible objects in episode 4. My guess is that they did it to help with poor performance when people played episode 4 on older PCs (like 486 and pentium 1)

[m210®]

James, on 27 July 2011 - 12:53 PM, said:

That's interesting, and explains alot about why the original enemies seem to look so smooth compared to useractor stuff. Is there anyway you can add a spriteflag or something so that they interpolate at the same rate as normal enemies? (either that or just do it automatically, but that'll probably effect performance alot I guess?)

Btw, it would be usefull!
And one question about AI

ai <name> <action> <move> <type>

Why enemy doesn't moving if <type> = 0(leave this parameter blank)? This greatly hinders in writing AI, because with this parameter the enemy is beginning to change angle depending on the circumstances, that I don't need.

[Danukem]

M210, on 27 July 2011 - 02:50 PM, said:

Btw, it would be usefull!
And one question about AI

ai <name> <action> <move> <type>

Why enemy doesn't moving if <type> = 0(leave this parameter blank)? This greatly hinders in writing AI, because with this parameter the enemy is beginning to change angle depending on the circumstances, that I don't need.

So what do you want the enemy to do when you set its ai type to 0?

As a rule of thumb, do not set ai or move or action to 0. (I know the original CONs set move to 0 in a few places, but it's a bad practice).

No offense, but if you think that is a big hindrance to writing AI, then you need to learn a lot more about coding AI. With proper collision handling, you should not be having problems with actors changing to unwanted angles. Probably all you need is a block of code that starts with "ifnotmoving" and then changes the monster's behavior as appropriate. If you let them keep using "geth" or "seekplayer" etc. after a collision, actors tend to bounce around like billiard balls.

[m210®]

hm...but can you help me with this part of code? I would really appreciate

[Danukem]

M210, on 27 July 2011 - 04:07 PM, said:

hm...but can you help me with this part of code? I would really appreciate

Maybe I could, but I don't want to download and play the TC because then I will get too involved. If you post the entire code for the actor, maybe I can make some suggestions.

[m210®]

Ok, I posted it, but i think it's not helps. You can write AI for your monster to eduke32, which will gradually unfold in contact with the wall or with sprites. This is all I need at the moment

ai AIZOMBIEWALK AZOMBIEWALK1 ZOMBIEWALK getv
ifai AIZOMBIEWALK
{
ifaction AZOMBIEWALK1 ifactioncount 3 action AZOMBIEWALK2
ifaction AZOMBIEWALK2 ifactioncount 4 action AZOMBIEWALK1
			
state enemymovingcode
ifvare enemyattack 1 ifvare shoot_var 0 { ai AIZOMBIESHOOT setvar shoot_var 1 }
getactor[ENEMYID].extra extra
ifcansee ifvarg extra 0 { ifvare enemyroam 1 soundonce AZOMROAM else ifvare enemyroam 2 soundonce AZOMSPOT else ifvare enemyroam 3 soundonce AZOMMOAN }
}


state enemymovingcode
	getactor[THISACTOR].htextra htextra
	ifvarg htextra 0 
	{
		getactor[THISACTOR].htowner spriteid 
		ifvarg spriteid 0 { getactor[spriteid].owner ENEMYID } 
	}
	
	ifvarg ENEMYID 0 
	ifvarvarn ENEMYID THISACTOR
	{
		getactorvar[THISACTOR].height height
		getactor[THISACTOR].z z
		subvarvar z height
		setactor[THISACTOR].z z
		canseespr THISACTOR ENEMYID see
		addvarvar z height
		setactor[THISACTOR].z z
		
		getactor[ENEMYID].x mx
		getactor[ENEMYID].y my
		getactor[THISACTOR].x x
		getactor[THISACTOR].y y
		subvarvar mx x
		subvarvar my y
		getangle mang mx my
		setvarvar saveang mang
		getactor[THISACTOR].ang ang
		getincangle mang mang ang
		mulvarvar mx mx
		mulvarvar my my
		addvarvar mx my
		sqrt mx targetdist //дистанция до ENEMYID
		
		getactor[THISACTOR].sectnum sectnum2
		getactor[THISACTOR].ang ang
		getactor[THISACTOR].z z
		divvar height 2
		subvarvar z height
		cos mycos ang
		sin mysin ang
		hitscan x y z sectnum2 mycos mysin 0 RETURN RETURN hitspritesaved coorx1 coory1 RETURN CLIPMASK0
		subvarvar x coorx1
		subvarvar y coory1
		mulvarvar x x
		mulvarvar y y
		addvarvar x y
		sqrt x DIST //дистанция до препятствия
		 
		ifvare turntarget 0
		{
			ifvare see 1
			{
				getactor[ENEMYID].x save_enemx
				getactor[ENEMYID].y save_enemy
				ifvarg mang -512 ifvarl mang 512
				{ setactor[THISACTOR].ang saveang } else setactor[THISACTOR].ang esaveang
			}
			else ifvare see 0
			{
				getactor[THISACTOR].x x
				getactor[THISACTOR].y y
				subvarvar x save_enemx
				subvarvar y save_enemy
				getangle mang x y
				addvarvar mang 1024
				setactor[THISACTOR].ang mang
			}
		}
		ifvare enemyattack 0
		{
			ifvare enemyturn 0 
			{
				ifvarvarn hitspritesaved ENEMYID { ifvarg hitspritesaved 0 ifvarl DIST 1536 { ifvare eturning 0 { ifrnd 128 setvar enemyturn 3 else setvar enemyturn 4 } } else ifvarl DIST 1536 { setvar turntarget 1 ifrnd 128 setvar enemyturn 1 else setvar enemyturn 2 } } else 
				{ ifvarl targetdist 1024 { setactor[THISACTOR].ang saveang setvar enemyattack 1 } }
				ifvare eturning 1 { addvar COUNTER 1 ifvarg COUNTER 18 setvar eturning 0 }
			}
			ifvare enemyturn 1
			{
				getactor[THISACTOR].ang ang
				addvarvar ang 32
				setactor[THISACTOR].ang ang
				ifvarg DIST 1535 { addvar COUNTER 1 ifvarg COUNTER 4 { setvarvar esaveang ang setvar COUNTER 0 setvar turntarget 0 setvar enemyturn 0 } }
			} 
			ifvare enemyturn 2
			{
				getactor[THISACTOR].ang ang
				subvarvar ang 32
				setactor[THISACTOR].ang ang
				ifvarg DIST 1535 { addvar COUNTER 1 ifvarg COUNTER 4 { setvarvar esaveang ang setvar COUNTER 0 setvar turntarget 0 setvar enemyturn 0 } }
			}
			ifvare enemyturn 3
			{
				getactor[THISACTOR].ang ang
				addvarvar ang 512
				setactor[THISACTOR].ang ang
				setvarvar esaveang ang
				setvar enemyturn 0
				setvar eturning 1
			} 
			ifvare enemyturn 4
			{
				getactor[THISACTOR].ang ang
				subvarvar ang 512
				setactor[THISACTOR].ang ang
				setvarvar esaveang ang
				setvar enemyturn 0
				setvar eturning 1
			}
		}
	}
ends