[Helixhorned]

Mark., on 20 January 2014 - 04:55 PM, said:

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?

Yeah, maybe I should have a bit more explicit in the commit log -- the bits are 4096, 8192, 16384 and 32768, for disabling the the four episode ending scenes, respecitvely. LOGO_FLAGS as a CON gamevar is a strange thing: if you don't define it using gamevar, it maintains its default value of 255. That's documented on the wiki, by the way.

[pmw]

Helixhorned, on 21 January 2014 - 08:28 AM, said:

CON's quake, besides starting the EARTHQUAKE sound, merely sets an unexposed timer to the provided value, which is then decremented every game tic. So, you could code an actor that simply issues quake at certain intervals. Another option would be initializing the quake timer to a huge value, but since it's currently an unsigned 16-bit integer, you'd have at most 65535/30/60 = approx. 36 minutes of quake then.

Sounds OK. But if I change quake timer's value to huge one, isn't it gonna affect to all *quakes* on my game?

[Helixhorned]

The effect of "quake <somevalue>" is like this:

play EARTHQUAKE
g_earthquakeTime = <somevalue>

So, issuing quake simply unconditionally sets the timer to a new value.

Taking another look at the source code, what you should be worried about is g_earthquakeTime being set from C code. This happens on the following occasions:

- detonating a SEENINE or OOZFILTER
- when a DUKECAR or HELECOPT (sic) explodes
- on activation of an SE2, obviously

[Jblade]

Would there be a way to disable an enemy's speed being affected by a projectile? at the moment melee monsters are rendered trivial by fast-firing weapons, I was thinking of how to change that so only high-damage projectiles actually stop it. I haven't taken a crack at it yet but I'm just asking here if anybody else has experimented with it.

[Danukem]

James, on 10 March 2014 - 06:03 AM, said:

Would there be a way to disable an enemy's speed being affected by a projectile? at the moment melee monsters are rendered trivial by fast-firing weapons, I was thinking of how to change that so only high-damage projectiles actually stop it. I haven't taken a crack at it yet but I'm just asking here if anybody else has experimented with it.

I wasn't aware that projectiles stopped monsters, unless the monsters are CON coded to flinch from getting hit. So yeah, I would just code them to only flinch if the damage is over a certain percentage of their hit points.

EDIT: IIRC, the default game code actually makes monsters get pulled towards the player when they get hit. This is one of those things that can be changed in CON, and which you may have changed already, by messing with the monster's xvel or using movesprite on them after an impact.

[Jblade]

No, they definitely do - if you use a chaingun and shoot at a newbeast it can't move forward at all. I've just looked at their code and there's no code telling them to stop moving when hit.

[Danukem]

James, on 10 March 2014 - 12:05 PM, said:

No, they definitely do - if you use a chaingun and shoot at a newbeast it can't move forward at all. I've just looked at their code and there's no code telling them to stop moving when hit.

OK, I'm assuming that you have already verified that the newbeast isn't stopping because of its flinching. It could be that those little movements forward involve it's xvel constantly getting reset every time it is hit -- that would explain it. So what I would do is, save its xvel in a variable each tic when it is not getting hit. When it is hit, set the xvel to the stored variable. I hope that made sense.

[Jblade]

I'll give that a try and see how it goes, hopefully it's not something too hardcoded into the game engine.

[Helixhorned]

It's hard-coded game functionality. Writing a test enemy which only seeks the player,

Spoiler

define MYENEMY 58  // space suit
ai MY_AINEWBEASTGETENEMY ANEWBEASTSTAND NEWBEASTWALKVEL seekplayer faceplayer

useractor enemy MYENEMY 2000
    ifaction 0 ai MY_AINEWBEASTGETENEMY 
    fall
enda

definequote 999 sprite[%d].xvel: %d

define Q 1000
definequote Q <temp>

gamevar ii 0 0

onevent EVENT_DISPLAYREST
    findnearactor MYENEMY 10000 ii
    ifvarg ii -1
    {
        qsprintf Q /*<-*/ 999 ii sprite[ii].xvel
        minitext 100 8 Q 0 0
    }
endevent

and setting a watchpoint on sprite[number_known_from_the_map].xvel shows that the culprit is in sector.c:A_DamageObject().

Spoiler

                if (PN != TANK && PN != BOSS1 && PN != BOSS4 && PN != BOSS2 && PN != BOSS3 && PN != RECON && PN != ROTATEGUN)
                {
                    if (sprite[i].extra > 0)
                    {
                        if ((sprite[i].cstat&48) == 0)
                            SA = (sprite[sn].ang+1024)&2047;
                        sprite[i].xvel = -(sprite[sn].extra<<2);
                        j = SECT;
                        pushmove((vec3_t *)&sprite[i],&j,128L,(4L<<8),(4L<<8),CLIPMASK0);
                        if (j != SECT && (unsigned)j < MAXSECTORS)
                            changespritesect(i,j);
                    }
                }

This function is one of the things that could use some form of scripting interfacing, so that its effects could be selectively disabled.

[Jblade]

Helixhorned, on 10 March 2014 - 01:30 PM, said:

It's hard-coded game functionality. Writing a test enemy which only seeks the player,

Spoiler

define MYENEMY 58  // space suit
ai MY_AINEWBEASTGETENEMY ANEWBEASTSTAND NEWBEASTWALKVEL seekplayer faceplayer

useractor enemy MYENEMY 2000
    ifaction 0 ai MY_AINEWBEASTGETENEMY 
    fall
enda

definequote 999 sprite[%d].xvel: %d

define Q 1000
definequote Q <temp>

gamevar ii 0 0

onevent EVENT_DISPLAYREST
    findnearactor MYENEMY 10000 ii
    ifvarg ii -1
    {
        qsprintf Q /*<-*/ 999 ii sprite[ii].xvel
        minitext 100 8 Q 0 0
    }
endevent

and setting a watchpoint on sprite[number_known_from_the_map].xvel shows that the culprit is in sector.c:A_DamageObject().

Spoiler

                if (PN != TANK && PN != BOSS1 && PN != BOSS4 && PN != BOSS2 && PN != BOSS3 && PN != RECON && PN != ROTATEGUN)
                {
                    if (sprite[i].extra > 0)
                    {
                        if ((sprite[i].cstat&48) == 0)
                            SA = (sprite[sn].ang+1024)&2047;
                        sprite[i].xvel = -(sprite[sn].extra<<2);
                        j = SECT;
                        pushmove((vec3_t *)&sprite[i],&j,128L,(4L<<8),(4L<<8),CLIPMASK0);
                        if (j != SECT && (unsigned)j < MAXSECTORS)
                            changespritesect(i,j);
                    }
                }

This function is one of the things that could use some form of scripting interfacing, so that its effects could be selectively disabled.

Thanks for clearing it up, maybe a new spriteflag could be added to disabe that or something?

[Kyanos]

setplayer[THISACTOR].over_shoulder_on 1

I'm using this as a little hack for a map effect in Link3D. Basically F7 is locked out and over the shoulder view is only accessible once the player has the map. My problem is that when I use the map in one level and switch back to another it doesn't work anymore. It's like it uses old coordinates from the previous level? maybe? Does anyone have any idea why this behaves like this? I've tried reading through some source code to no avail. I've run debug.exe it didn't provide anything useful either.

[Danukem]

I'm having some trouble understanding your post. Are you saying the effect works fine in one map (you can turn it on and off with no problem) but when you try to use the effect again in another map, it shows the player from invalid coordinates?? There must a lot more going on here than the one line of code you are showing.

[Kyanos]

Yeah, it works fine. Then works fine in the next map too. Then is glitchy once I go back to the first map. I use the savemapstate command too. And event enterlevel plus more mess.

[Danukem]

Are you basing your map caching code on the code I wrote for WGR2?

EDIT: Anyway, from what you have said, I would guess it has something to do with how you are using the loadmapstate command.

[Kyanos]

code...

Spoiler

I've got this in Aplayer,

	ifvarn MAPMODE 0
	{
		setplayer[THISACTOR].over_shoulder_on 1
		setvar Bbutton 5
		setvar MOVE_UP 0
		setvar MOVE_DOWN 0
		setvar MOVE_LEFT 0
		setvar MOVE_RIGHT 0
	}
	else setplayer[THISACTOR].over_shoulder_on 0
	
	ifvarn loadvars 0 
	{		
		readgamevar MAXLIFE
		readgamevar LIFE
		readgamevar GOTIT
		readgamevar Abutton
		readgamevar Bbutton
		readgamevar compass	
		readgamevar triforce
		readgamevar bow	
		readgamevar candle
		readgamevar potion
		readgamevar wand	
		readgamevar keys
		readgamevar ring
		readgamevar arrows
		readgamevar rupies		
		readgamevar bombs
		readgamevar sword
		readgamevar boomerang
		setvar loadvars 0
	}
	

later followed by this tied to cave sprites.

state levelchange
	findnearactor LINK 128 TEMP
    ifvarn TEMP -1
	ifcount 64
	{
		resetcount
		getactor[THISACTOR].lotag lotag
		savemapstate
		savegamevar MAXLIFE
		savegamevar LIFE
		savegamevar GOTIT
		savegamevar Abutton
		savegamevar Bbutton
		savegamevar compass	
		savegamevar triforce
		savegamevar bow	
		savegamevar candle
		savegamevar potion
		savegamevar wand	
		savegamevar keys
		savegamevar ring
		savegamevar arrows
		savegamevar rupies		
		savegamevar bombs
		savegamevar sword
		savegamevar boomerang
		setvar loadcached 1
		startlevel VOLUME lotag
	}
ends

plus this in evnts.con called at the start of game.con before all this.

onevent EVENT_ENTERLEVEL
	ifvare loadcached 1
	{
		loadmapstate
		setvar loadcached 0	
		setvar loadvars 1
	}
endevent

To answer your question, yes it is based off WGR2 code, but without the pdestination stuff and se 67s, you come back to the map at the point that you exited. The 64 count timer stops going straight back to reload the original map.

edit: added spoiler

[Kyanos]

Trooper Dan, on 12 March 2014 - 06:56 PM, said:

Are you basing your map caching code on the code I wrote for WGR2?

EDIT: Anyway, from what you have said, I would guess it has something to do with how you are using the loadmapstate command.

Exactly. What would the old mapstate have in it that I can manually edit to fix this?

[Danukem]

Drek, on 12 March 2014 - 07:12 PM, said:

To answer your question, yes it is based off WGR2 code, but without the pdestination stuff and se 67s, you come back to the map at the point that you exited. The 64 count timer stops going straight back to reload the original map.

That's what's puzzling me. The code you posted doesn't change the player's position at all, so I don't see how the coords could get messed up.

Does the problem occur the moment the player reenters a map? And what exactly is happening? Did you try DNDEBUG and look at the results (e.g. where the player is on the map).

[Kyanos]

The problem is triggerable by pressing alt fire while holding the map. Hence Bbutton 5 being forced while over the shoulder is on, so you can switch back. Yes it is like this any time after using the effect in one map, then trying to do it again in another.

The maps in question are just different variations of themselves. Each has overworld and dungeons in same location, with starting points being what makes them different. I can plainly see that the over the shoulder on starts where I did it last in the previous map, it (the f7 camera) will "float" or "travel" to where I am now and eventually with many on / off switches begin to work properly again... sometimes, or gets stuck in level geometry, player never dies. I will see what DNDEBUG says.

[Danukem]

Drek, on 12 March 2014 - 07:58 PM, said:

The problem is triggerable by pressing alt fire while holding the map. Hence Bbutton 5 being forced while over the shoulder is on, so you can switch back.

Well then it sounds like the crucial part of the code is probably the code associated with pressing alt fire, which you didn't post...

[Kyanos]

ok, there is this code too.

Spoiler

		ifvare attack 0 ifvarn ALT_FIRE 0
		{
			setvar attack 32
	
			state shootstate
			
			ifvare Bbutton 1 ifvarg boomerang 0 ifvare GOTIT 1
			{
				state diagshootstate
				espawn BOOMERANG
				subvar SAVEZ 768
				setactor[RETURN].ang MANG
				setactor[RETURN].x SAVEX
				setactor[RETURN].y SAVEY
				setactor[RETURN].z SAVEZ
				ifvare boomerang 2 { setactor[RETURN].pal 46 }
				addvar SAVEZ 768	
				setvar GOTIT 0
				setvar GOTITEM 0
			}
			
			ifvare Bbutton 2
			ifvarg arrows 0
			{
				eshoot ARROWPROJ
				subvar SAVEZ 768
				setactor[RETURN].ang MANG
				setactor[RETURN].x SAVEX
				setactor[RETURN].y SAVEY
				setactor[RETURN].z SAVEZ
				addvar SAVEZ 768		
				subvar arrows 1
			}		
			ifvare Bbutton 3
			ifvarg bombs 0
			{
				espawn BOMB
				setactor[RETURN].x SAVEX
				setactor[RETURN].y SAVEY
				setactor[RETURN].z SAVEZ
				subvar bombs 1
			}				
			
			ifvare Bbutton 4
			ifvare wand 1
			{
				state wandstate
				
				eshoot WANDPROJ
				subvar SAVEZ 768
				setactor[RETURN].ang MANG
				setactor[RETURN].x SAVEX
				setactor[RETURN].y SAVEY
				setactor[RETURN].z SAVEZ
				addvar SAVEZ 768
			}			
			ifvare Bbutton 5
			ifvarg havemap 0
			{
				ifvarn MAPMODE 0 setvar MAPMODE 0 else setvar MAPMODE 1
			}		
		}  	

and this in evnts.con

onevent EVENT_AIMUP
    setvar RETURN -1
    setvar ALT_FIRE 2
endevent


onevent EVENT_DISPLAYREST
    setvar RETURN -1
endevent


eventloadactor APLAYER
    palfrom 63 0 0 0
    setplayer[THISACTOR].knuckle_incs 0
    setplayer[THISACTOR].gotweapon 1 0
enda

onevent EVENT_NEXTWEAPON
	setvar RETURN -1
	addvar Bbutton 1
	ifvarg Bbutton 5
	{
		setvar Bbutton 0
	}
endevent

onevent EVENT_PREVIOUSWEAPON
	setvar RETURN -1
	subvar Bbutton 1
	ifvarl Bbutton 0
	{
		setvar Bbutton 5
	}	
endevent

I made a quick video. The only way to describe it short of sharing the tc with you. Which I'm willing to do too. I can pack it up neat tomorrow.
https://www.mediafir...g4lf3j1sxxt5ljk here is my sample video, 4 mins 41 MB, shows off a few weapons and effects too.

[Danukem]

Kickass TC you've got there

But please, please increase Link's walking speed!

As for the bug....looking at the video, it's pretty clearly a problem with the camera positioning, and I don't think you have posted the relevant code. I think you are messing with the camera vars (camerax, cameray, cameraz, cameresect, camderadist). Perhaps you have saved values from a different map, and when you switch to the external cam it is starting from those saved values and the code isn't able to get the camera to a sane position.

EDIT: Try putting the camera vars in your savegamevar/readgamevar routines. Especially your own camera vars, since the ones I mentioned get updated automatically.

[Kyanos]

Thanks.
I'm looking into the camera vars today, but you assumed wrong, I never once manually setup a camera. It is all seen from the perspective of Dukes first person view, with [THISACTOR].ang, and .horiz being forced within certain limits. It's as if the world and link exist down at his feet, very hackish IMO, yet simple and effective.

I'm sure that by playing with the camera vars you mention I'll be able get this world map effect working proper. Still it doesn't explain why my F7 view hack is not working atm, which is irrelevant really.

Thanks again. And yes, Link will be faster.

Added:
I simply added a few lines to log the camera vars when the map gets turned off and on, definitely found the issue with those camera vars. It's logging camerasect as -1 when it's glitchy for me.

Spoiler

Initializing music...
Initializing sound... 32 voices, 2 channels, 16-bit 44100 Hz
Cache time: 49ms
E1L1: OVERWORLD
CONLOGVAR: L=741 camerasect (Global) =15
CONLOGVAR: L=742 camerax (Global) =51705
CONLOGVAR: L=743 cameray (Global) =14111
CONLOGVAR: L=744 cameraz (Global) =-17411
CONLOGVAR: L=741 camerasect (Global) =15
CONLOGVAR: L=742 camerax (Global) =51419
CONLOGVAR: L=743 cameray (Global) =15094
CONLOGVAR: L=744 cameraz (Global) =-35075
CONLOGVAR: L=741 camerasect (Global) =12
CONLOGVAR: L=742 camerax (Global) =50145
CONLOGVAR: L=743 cameray (Global) =17884
CONLOGVAR: L=744 cameraz (Global) =-17411
CONLOGVAR: L=741 camerasect (Global) =12
CONLOGVAR: L=742 camerax (Global) =50119
CONLOGVAR: L=743 cameray (Global) =18907
CONLOGVAR: L=744 cameraz (Global) =-39555
Cache time: 11ms
E1L2: DUNGEON ONE
CONLOGVAR: L=741 camerasect (Global) =17 (added by drek: this is where link is. I just switched map ON)
CONLOGVAR: L=742 camerax (Global) =39582
CONLOGVAR: L=743 cameray (Global) =37057
CONLOGVAR: L=744 cameraz (Global) =-17411
CONLOGVAR: L=741 camerasect (Global) =-1 (this is where the cam is, switched map OFF)
CONLOGVAR: L=742 camerax (Global) =36139
CONLOGVAR: L=743 cameray (Global) =-58114
CONLOGVAR: L=744 cameraz (Global) =7168
CONLOGVAR: L=741 camerasect (Global) =17
CONLOGVAR: L=742 camerax (Global) =39582
CONLOGVAR: L=743 cameray (Global) =37057
CONLOGVAR: L=744 cameraz (Global) =-17411
CONLOGVAR: L=741 camerasect (Global) =-1
CONLOGVAR: L=742 camerax (Global) =36625
CONLOGVAR: L=743 cameray (Global) =-44688
CONLOGVAR: L=744 cameraz (Global) =7168
CONLOGVAR: L=741 camerasect (Global) =17
CONLOGVAR: L=742 camerax (Global) =39582
CONLOGVAR: L=743 cameray (Global) =37057
CONLOGVAR: L=744 cameraz (Global) =-17411
CONLOGVAR: L=741 camerasect (Global) =-1
CONLOGVAR: L=742 camerax (Global) =36852
CONLOGVAR: L=743 cameray (Global) =-38422
CONLOGVAR: L=744 cameraz (Global) =7168
CONLOGVAR: L=741 camerasect (Global) =17
CONLOGVAR: L=742 camerax (Global) =39402
CONLOGVAR: L=743 cameray (Global) =36829
CONLOGVAR: L=744 cameraz (Global) =-17411
CONLOGVAR: L=741 camerasect (Global) =-1
CONLOGVAR: L=742 camerax (Global) =5368
CONLOGVAR: L=743 cameray (Global) =-11534
CONLOGVAR: L=744 cameraz (Global) =7168
CONLOGVAR: L=741 camerasect (Global) =17
CONLOGVAR: L=742 camerax (Global) =39402
CONLOGVAR: L=743 cameray (Global) =36829
CONLOGVAR: L=744 cameraz (Global) =-17411
CONLOGVAR: L=741 camerasect (Global) =-1
CONLOGVAR: L=742 camerax (Global) =74360
CONLOGVAR: L=743 cameray (Global) =-789
CONLOGVAR: L=744 cameraz (Global) =7168
CONLOGVAR: L=741 camerasect (Global) =17
CONLOGVAR: L=742 camerax (Global) =38934
CONLOGVAR: L=743 cameray (Global) =37261
CONLOGVAR: L=744 cameraz (Global) =-17411
CONLOGVAR: L=741 camerasect (Global) =-1
CONLOGVAR: L=742 camerax (Global) =13359
CONLOGVAR: L=743 cameray (Global) =6090
CONLOGVAR: L=744 cameraz (Global) =7168
CONLOGVAR: L=741 camerasect (Global) =17
CONLOGVAR: L=742 camerax (Global) =38934
CONLOGVAR: L=743 cameray (Global) =37261
CONLOGVAR: L=744 cameraz (Global) =-17411
CONLOGVAR: L=741 camerasect (Global) =-1
CONLOGVAR: L=742 camerax (Global) =48649
CONLOGVAR: L=743 cameray (Global) =15729
CONLOGVAR: L=744 cameraz (Global) =7168
CONLOGVAR: L=741 camerasect (Global) =17
CONLOGVAR: L=742 camerax (Global) =38934
CONLOGVAR: L=743 cameray (Global) =37261
CONLOGVAR: L=744 cameraz (Global) =-17411
CONLOGVAR: L=741 camerasect (Global) =-1
CONLOGVAR: L=742 camerax (Global) =49106
CONLOGVAR: L=743 cameray (Global) =27102
CONLOGVAR: L=744 cameraz (Global) =7168
CONLOGVAR: L=741 camerasect (Global) =17 ( here the camera finally caught up)
CONLOGVAR: L=742 camerax (Global) =38934
CONLOGVAR: L=743 cameray (Global) =37261
CONLOGVAR: L=744 cameraz (Global) =-17411
CONLOGVAR: L=741 camerasect (Global) =17
CONLOGVAR: L=742 camerax (Global) =38946
CONLOGVAR: L=743 cameray (Global) =37977
CONLOGVAR: L=744 cameraz (Global) =-34816
CONLOGVAR: L=741 camerasect (Global) =17
CONLOGVAR: L=742 camerax (Global) =38934
CONLOGVAR: L=743 cameray (Global) =37261
CONLOGVAR: L=744 cameraz (Global) =-17411
CONLOGVAR: L=741 camerasect (Global) =17
CONLOGVAR: L=742 camerax (Global) =38946
CONLOGVAR: L=743 cameray (Global) =37977
CONLOGVAR: L=744 cameraz (Global) =-34816
Cache time: 11ms
E1L1: OVERWORLD
CONLOGVAR: L=741 camerasect (Global) =12
CONLOGVAR: L=742 camerax (Global) =50169
CONLOGVAR: L=743 cameray (Global) =17572
CONLOGVAR: L=744 cameraz (Global) =-17411
CONLOGVAR: L=741 camerasect (Global) =-1
CONLOGVAR: L=742 camerax (Global) =49032
CONLOGVAR: L=743 cameray (Global) =-111569
CONLOGVAR: L=744 cameraz (Global) =3072
CONLOGVAR: L=741 camerasect (Global) =16
CONLOGVAR: L=742 camerax (Global) =51560
CONLOGVAR: L=743 cameray (Global) =17009
CONLOGVAR: L=744 cameraz (Global) =-17411
CONLOGVAR: L=741 camerasect (Global) =-1
CONLOGVAR: L=742 camerax (Global) =106089
CONLOGVAR: L=743 cameray (Global) =-87114
CONLOGVAR: L=744 cameraz (Global) =7168
CONLOGVAR: L=741 camerasect (Global) =15
CONLOGVAR: L=742 camerax (Global) =51680
CONLOGVAR: L=743 cameray (Global) =15749
CONLOGVAR: L=744 cameraz (Global) =-17411
CONLOGVAR: L=741 camerasect (Global) =-1
CONLOGVAR: L=742 camerax (Global) =62188
CONLOGVAR: L=743 cameray (Global) =-90278
CONLOGVAR: L=744 cameraz (Global) =7168
CONLOGVAR: L=741 camerasect (Global) =16
CONLOGVAR: L=742 camerax (Global) =51680
CONLOGVAR: L=743 cameray (Global) =16049
CONLOGVAR: L=744 cameraz (Global) =-17411
CONLOGVAR: L=741 camerasect (Global) =-1
CONLOGVAR: L=742 camerax (Global) =81416
CONLOGVAR: L=743 cameray (Global) =-77573
CONLOGVAR: L=744 cameraz (Global) =7168
CONLOGVAR: L=741 camerasect (Global) =15
CONLOGVAR: L=742 camerax (Global) =51680
CONLOGVAR: L=743 cameray (Global) =15701
CONLOGVAR: L=744 cameraz (Global) =-17411
CONLOGVAR: L=741 camerasect (Global) =-1
CONLOGVAR: L=742 camerax (Global) =20032
CONLOGVAR: L=743 cameray (Global) =-67964
CONLOGVAR: L=744 cameraz (Global) =7168
CONLOGVAR: L=741 camerasect (Global) =16
CONLOGVAR: L=742 camerax (Global) =51680
CONLOGVAR: L=743 cameray (Global) =16865
CONLOGVAR: L=744 cameraz (Global) =-17411
CONLOGVAR: L=741 camerasect (Global) =-1
CONLOGVAR: L=742 camerax (Global) =90842
CONLOGVAR: L=743 cameray (Global) =-52154
CONLOGVAR: L=744 cameraz (Global) =7168

Added more: I gave up using over_shoulder_on and just manually coded the same effect by moving the camera. It's actually better this way because it is customizable now.

[Mblackwell]

That's a known bug with over_shoulder_on. At least known to me... it's been that way since forever and basically locks out forcing over_shoulder_on to 1. Something internally must get toggled when pushing F7.

[Helixhorned]

Drek, on 13 March 2014 - 06:15 AM, said:

CONLOGVAR: L=741 camerasect (Global) =-1 (this is where the cam is, switched map OFF)

When the third person view is in effect, 3072 is subtracted from the player's z position, after which a hitscan() is issued to determine the ultimate camera position. The initial subtraction may get the camera into void space in very cramped situations, like in the "appended" space ship in E2L1. With revision 4369, when this happens, we try to determine the camera position a second time without the subtraction. This may or may not be the cause for your trouble, but my experiments in said space ship have shown that under Polymer, the outside view tends to be drawn less frequently then (still remaining possible though).

[Helixhorned]

James, on 10 March 2014 - 01:42 PM, said:

Thanks for clearing it up, maybe a new spriteflag could be added to disabe that or something?

Added with r4371.

For actors that you define yourself, usage from CON would be with the spriteflags directive. If you want to modify existing actor's behavior, it gets a little tricky though. The spriteflags directive (i.e. translation-time command) is "destructive" in the sense that it overwrites the previous actor flags with the passed value. This is in contrast to other sprite* directives like spritenoshade, which bitwise-OR them in. So if you wanted to remove the damage-pushing behavior for the newbeast, you'd have to issue "spriteflags 4610 SFLAG_NODAMAGEPUSH" before its definition in GAME.CON. This rules out its usage with mutators, as these get translated after the regular CON files.

In Lunatic, we can have this:

-- Add NODAMAGEPUSH flag to NEWBEAST.
gameactor { D.NEWBEAST, AF.chain_end + AF.NODAMAGEPUSH, function() end }

Edit: corrected "spriteflags SFLAG_NODAMAGEPUSH" --> "spriteflags 4610 SFLAG_NODAMAGEPUSH"

[Hendricks266]

Why not

onevent EVENT_PREGAME
ifactor NEWBEAST
{
getactor[THISACTOR].htflags temp
orvar temp SFLAG_NODAMAGEPUSH
setactor[THISACTOR].htflags temp
}
endevent

[Kyanos]

Is it possible to load a savegame via con? I find it odd that save 9 works but load 9 is an error. I can't seem to figure out how Eduke prompts to load the last save when the player dies, I want the same effect. I've tried simply addphealth -999 to kill the player and prompt edukes load game system, it didn't work, also I've set dead_flag to a few non 0 values.

How can I script "load last save y/n?" for my TC like eduke32 does running Duke3D?

[Fox]

For htflags or mdflags, I prefer to set it once during LOADACTOR and EGS.

Drek, on 15 March 2014 - 02:01 PM, said:

Is it possible to load a savegame via con? I find it odd that save 9 works but load 9 is an error. I can't seem to figure out how Eduke prompts to load the last save when the player dies, I want the same effect. I've tried simply addphealth -999 to kill the player and prompt edukes load game system, it didn't work, also I've set dead_flag to a few non 0 values.

How can I script "load last save y/n?" for my TC like eduke32 does running Duke3D?

I think you need to use resetplayer command. Keep in mind it works differently in multiplayer, and ti simply respawn the player...

[Kyanos]

Thanks Fox... I had that at one point, it was just restarting the level though, I must have done something wrong. Works like a charm now.

[Helixhorned]

Hendricks266, on 15 March 2014 - 01:56 PM, said:

Why not

onevent EVENT_PREGAME
ifactor NEWBEAST
{
getactor[THISACTOR].htflags temp
orvar temp SFLAG_NODAMAGEPUSH
setactor[THISACTOR].htflags temp
}
endevent

For reasons of minimality. Having it set "statically" once is preferrable to running the check every game tic * every sprite. Personally, I'm not a big fan of EVENT_{PRE}GAME. First, they tend to spread code belonging together across one more location. For example, your snippet would really belong into the NEWBEAST actor [*]; alas, there's no way to chain actor code in CON. Second, their names suggest that they're run every game tic (which seems more logical as well), whereas it's that times every sprite! This misunderstanding has lead to performance issues in the past, such as with Darkus' flashlight mod, and has also bitten me once.

[*] OK, this argument really applies to code that you wrote yourself in the first place. For NEWBEAST, if you prefer to stay away from modifying the original GAME.CON, there's no difference.

Fox, on 15 March 2014 - 02:02 PM, said:

For htflags or mdflags, I prefer to set it once during LOADACTOR and EGS.

EVENT_SPAWN should run for both sprites present in the initial map state as well as those spawned during the game. Again, if a particular actor-tile is supposed to have some htflags bit set at any time, it's cleaner to specify that via the spriteflags directive.