[Stabs]

just for example, as this could be a mod for normal dp activators

if xvel is set on an Activator, its yvel cannot be activated untill the xvel has been first

when going through areas twice i could make it activate something different the 2nd time around

[Danukem]

DanM, on Jan 18 2010, 06:21 PM, said:

an extra bit for the origin sleeper so the player still has full control before the effect begins (for delayed cutscenes that change players position afterwards)
a gib spawner (just spawns blood and chunks of meat)
and an activator that cant be activated untill its activated, i think that will completley remove any limitations i have to work around.

I uploaded some new code. Here's what I've changed/added since the last code update:

the regular DP helicopter should be able to work before the player sees it

food items are eaten when picked up

overhauled skycar movement, shows speed in hud, shows bomb bay view at all times with bomb impact point, bombs track towards target impact point

improved visuals for the BFG firing effects

spawners can spawn jibs, but you must use one of the following hitags:
2246 // spine
2251 // eyeball
2256 // heart
2261 // intestines
2266 // ribs

I'm not sure what you want regarding the sleeper effect. Are you saying you want the option to not have it paralyze the player until the moment he is teleported? That is equivalent to saying the origin sleeper does not paralyze him at all.

EDIT: oops forgot to include the new dukeplus.def with the updated code; fixed now

[Stabs]

yeh pretty much gives the player full movement when its activated, but if an extra bit could be made to cameras so the last one makes it become the players new start position i could pretty much do the same thing and it would be alot more flexible than the sleeper effect combined with that activator mod.

[Sobek]

I've just been having a play with some moving cameras, and I had a quick question. With regards to EXTRA being set to 4, the change in angle (from the start position to the next camera in the chain) doesn't really seem gradual, but rather extremely fast. For example, I tried setting up a camera on a long straight line, with the start and end angles being opposite of each other (start was pointing directly to the right in Mapster, end to the left). The total trip for the camera takes about 20 seconds or so, however the camera changes the angle to match the end camera about 2 or 3 seconds in at most...

I thought that perhaps it would have averaged out the speed of the turn to coincide with the distance between the cameras, but I'm guessing that's now how it works?

*edit* I'm not sure if I really worded that clearly sorry. What I meant was, I thought that perhaps the camera's movement would be even across the transition... In that it would automatically adjust how fast it changed the angle, based on the distance between the cameras. Argh, is this making any sense? I can't seem to explain it right.

I take it the speed at which the angle changes is tied in to the overall speed of the camera itself?

[Danukem]

DanM, on Jan 18 2010, 10:39 PM, said:

if an extra bit could be made to cameras so the last one makes it become the players new start position i could pretty much do the same thing and it would be alot more flexible than the sleeper effect combined with that activator mod.

That makes perfect sense and I will do that for the next update.

[Stabs]

ok cool, but i will still that activator mod, i can use that for so much stuff

i did notice your edit and grabbed the unofficial code stuff, but i dont seem to be able to pick up the fooditems, and the dp heli seemed to just hover in the cutscene aswelll duke is not actually anywhere near the heli when that happens.

[Danukem]

Like I said earlier about the food items, you can't pick them up unless picking up objects is enabled. I know they worked because I tested them. I don't know what is going wrong with the heli though.

@Sobek: I'm going to improve the camera turning. When I'm done, I think you will want to use the default setting for the moving cameras.

[Danukem]

I uploaded some new code. I have added the portal SEs from WGR2. So far I have used them to fix the portal effect in DPCBP (not included), which has been broken in recent snapshots. I also changed the way the camera turns for the moving cutscene camera effect.

I have included the complete and updated instructions below. Here is what I changed: Moving cutscene cameras will gradually turn to match the angle of the next camera in the sequence. It is timed so that they finish changing their angle when the next camera is reached. This behavior cannot be modified. Adding 4 to extra on those SEs now does something completely different from before: it causes the player to take the camera's position. So you will have to change the extra on your SE 90's if you were using that bit. This has been tested, but not very much, so please let me know about bugs.

@DanM: I still don't know why your helicopter isn't activating when it is supposed to.

Quote

BROADCASTER = SE 88
SHOWS A SCENE FROM A DIFFERENT PART OF THE MAP. THE SCENE IS “BROADCAST” IN THE BACKGROUND, AND IS VISIBLE WHEREVER THERE ARE BLANK TEXTURES (WALLS, FLOORS OR CEILINGS WITH BLANK TEXTURES) NEAR THE SE. PLACE TWO SE88 AND GIVE THEM THE SAME HITAG. ONE WILL BROADCAST THE POV OF THE OTHER.
OPTIONS: GIVE THE SE A YVEL, AND THAT WILL BE ITS ACTIVATION NUMBER, IN WHICH CASE IT WILL NOT BROADCAST UNTIL AN ACTIVATOR OR GAME EFFECT (SUCH AS MONSTER ACTIVATION) TURNS IT ON. MAKE SURE TO HIDE THE BLANK TEXTURES UNTIL THE ACTIVATION USING A SLIDING DOOR OR SOME OTHER TRICK.
THE SE WILL BROADCAST FROM ITS OWN ANGLE. BY DEFAULT, IT WILL USE THE PLAYER’S CURRENT Z ANGLE (LOOK UP/DOWN ANGLE). TO SET A FIXED Z ANGLE, SET EXTRA ON THE SE. 100 = STRAIGHT AHEAD. HIGHER VALUES LOOK UP, LOWER VALUES LOOK DOWN (IN POLYMOST, MAX 299, MIN -199).

TELEPORTER = SE 89
SIMILAR TO THE NORMAL TELEPORTER SE7, BUT WITH MORE OPTIONS. LIKE SE7, IT TAKES THE PLAYER TO ANOTHER SE OF THE SAME HITAG WHEN HE ENTERS ITS SECTOR (BUT THERE CAN ONLY BE ONE DESTINATION).
OPTIONS: GIVE THE SE A YVEL, AND THAT WILL BE ITS ACTIVATION NUMBER, IN WHICH CASE IT WILL NOT TELEPORT UNTIL AN ACTIVATOR OR GAME EFFECT (SUCH AS MONSTER ACTIVATION) TURNS IT ON. NOTE THAT TWO SE89 WITH THE SAME HITAG COULD HAVE DIFFERENT ACTIVATION NUMBERS. THIS COULD BE USED TO MAKE A ONE WAY TELEPORTER. LEAVE YVEL AT 0 AND IT WILL START UNLOCKED.
SET XVEL TO THE SOUND NUMBER TO PLAY UPON TELEPORTATION (LEAVE 0 FOR NO SOUND).
CERTAIN PALS ON THE SE WILL CAUSE A COLORED FLASH WHEN THE PLAYER TELEPORTS: PAL 1=BLUE, PAL2=RED, PAL3=WHITE, PAL4=BLACK, PAL7=YELLOW, PAL8=GREEN. PALS NOT LISTED DO NOTHING.

LOTAG 90 Cutscene camera

This SE can be used to change the player’s view to the view from the SE. It can be triggered by an event in the game, or it can occur when the level starts. Cutscene cameras can be either stationary or moving, and they can be chained together to show a sequence of views. The view can be displayed on the entire screen, or it can be displayed in a box in the corner. By default, the player is paralyzed while this effect is ongoing. Tags on the SE control different aspects of the effect:

Hitag: Set to 0 to switch to the SE view at level start. Otherwise, hitag is the activation number. The SE can be activated by an activator having a lotag equal to the SE’s hitag, or by a switch, monster, or other DP sprite which has a YVEL equal to the SE’s hitag. The player will view from the SE immediately upon activation.

Pal: 0 = stationary camera, 1 = moving camera. A moving camera will not work unless there is another SE 90 which has a hitag equal to the YVEL of the moving camera.

Shade: The up/down view angle. 0 looks straight ahead, negative numbers look up and positive numbers look down. The exact formula is camerahoriz = shade*2 +100

XVEL: In a stationary camera, this is the number of game tics that the camera’s view will last. In a moving camera, XVEL is the speed at which the camera travels. If not set, XVEL will default to 130 (five seconds of view time for a stationary camera, and about ½ of Duke’s running speed for a moving camera).

YVEL: This is the number that the camera activates upon completion. In a stationary camera, completion occurs when its time runs out. In a moving camera, completion occurs when it has traveled all the way to the next camera in the sequence. The camera will activate any respawns, activators, masterswitches, or DP sprites which have activation numbers equal to the camera’s YVEL. This includes other cutscene cameras. If the camera is stationary, it does not have to be set to activate anything. If it is a moving camera, it must be set to activate another SE 90 (see Pal, above).

ANG: The angle of the SE sprite will be the angle that the camera faces. If it is a moving camera, then it will start at this angle and gradually turn to face the angle that the next camera is facing.

EXTRA: This is a bitfield which determines some additional camera functions. Add together the numbers you want, or leave EXTRA at its default value (-1) if you don’t want any of the options.
1 does a quick fade to black right before the camera’s view time ends (does not work with moving cameras)
2 shows the view in a box in the lower right corner of the screen (the rest of the player’s view is normal)
4 if this bit is set, the player will be moved to the camera’s position.
8 allow the player to move (best used in combination with 2)
16 transition effect: when camera activates, its view starts in the center and quickly expands to fill the screen (do not use with 2)

[Sobek]

Cool beans, thanks. Trying now Also, that broadcaster sounds awesome too... It's great to see you whipping up these new effects again!

Just noticed the uploaded code changed again, fixed?

*edit* Yep, works PERFECTLY. Man that's so cool .Going to have some real fun with this one

[Stabs]

thanks, iam sure that extra bit on the camera will sort out my heli problems now anyway

yeh i tried eating that food with pickup objects and didnt seem to do anything, but iam sure it will in future

EDIT : is there a possible way to keep all of eternitys user.con data ive written in a seperate file that just merges with the normal duke plus userplus.con? just be any easier way to keep up-to date with dukeplus

[Danukem]

DanM, on Jan 19 2010, 10:06 PM, said:

EDIT : is there a possible way to keep all of eternitys user.con data ive written in a seperate file that just merges with the normal duke plus userplus.con? just be any easier way to keep up-to date with dukeplus

Yes. Anything you put in USER.CON will be loaded before USERPLUS.CON. Duplicate definitions are ignored, which means that the definitions read first are the ones used.

You can also edit EDUKE.CON and tell it to include your own code. Right now EDUKE.CON has one line:

include DukePlus/dpcons/DUKEPLUS.CON

You could make a DNE directory, put all your code in "DNE.CON", and then change EDUKE.CON so that your code is loaded first:

include Dukeplus/DNE/DNE.CON
include DukePlus/dpcons/DUKEPLUS.CON

You can put your own definitions, actors etc. in there. Depending on your code, there could be some problems. For example, if your actors use states that are defined in DUKEPLUS.CON, then it won't compile (in that case you could try having your code load _after_ DUKEPLUS.CON). You can even have code for events, such as EVENT_GAME, even though the events are also in DUKEPLUS.CON. For events and actors (unlike definitions), when the compiler finds a duplicate, it appends the new code. That's why you are able to use Muelsa's Dukebike mod with Duke Plus -- his EVENT_GAME code (along with other stuff) is being tacked on to the end to the Duke Plus EVENT_GAME (or the other way around, depending on the order you load things). By the way, it is buggy as it stands (for example, the Dukebike fights for control of the camera with my dynamic F7 view mode; that's one of the things that will be fixed when the code is properly integrated).

[Danukem]

DanM, on Jan 19 2010, 10:06 PM, said:

yeh i tried eating that food with pickup objects and didnt seem to do anything, but iam sure it will in future

Did you have less than 100 health when you tried it?

[Sobek]

Hey just a question, more out of curiosity than anything else... Remember a while back when I was having issues with shooter performance and you whipped up the EXTRA tag to kill their dynamic lights? I'm still having pretty big framerate drops with more than 1 or 2 shooters that use the FIRELASER projectile... What I've noticed is that it seems the FIRELASER shots are incredibly CPU intensive (at least I'm quite sure it's the CPU, it's hammering along at 100% usage the whole time anyway) compared to almost any other kind of projectile. I tend to have to put an invisible barrier of some kind very close to where they fire from so as to keep them from travelling too long, otherwise when too many FIRELASER shots are flying through the air it rapidly kills the framerate to the point where the game all but locks up.

To put it into perspective, with no shooters, my little BSG test map (set in space to the shots have to travel a bit of distance before hitting a barrier) runs at a constant 200fps or so. If I set 2 FIRELASER shooters up for constant firing at an average speed - roughly 2 per second I think - and with a close wall to stop them going to far, the framerate is instantly down to maybe 50 or 60 - though the further the barrier and the further they travel, the lower the framerate. Each successive shooter after that brings it down an additional 10 fps or more at a time. By comparison, I could have 10 RPG shooters firing at the same steady rate, with NOTHING to stop them from travelling too far, and end up with hundreds of RPG's flying through the air (that being lots of models and little smoke sprites) and it still manages to run far better than with just those two FIRELASER shooters.

I'm just wondering why that is... Does the FIRELASER use some kind specific code which chews through CPU cycles? I was thinking I might just use one of the more CPU friendly shooter tiles and just change the texture to something custom.

Mind the long rant, I just like to be clear on stuff

[Danukem]

The most likely explanation is that the FIRELASER is still emitting dynamic light, despite the code that is intended to stop it. What I do is have the SHOOTER with flag 256 set the corresponding bit on the htflag of the FIRELASER projectile right after firing it. This is supposed to prevent it from being a polymer light: http://wiki.eduke32.com/wiki/Htflags

Try setting up a simple situation where you have one SHOOTER shooting FIRELASER and there is a floor near the path of the projectile so you can easily see if it is giving off light (just let the shooter fire at the player and watch as it comes towards you). If it is giving off light, then that is your problem. I can think of no other reason why FIRELASERs would lower fps that much.

[Stabs]

do'h /facepalm -supreme

they work but you can destory them which is bad balance wise, i think it mite be best to just make them pick upable like the boxes too as you could stack stuff and circumvent a whole lot of stuff in my levels, although i do use the box in some parts for advancement.

as for how my mod structure works, atm i just use a .def in a zip for everything models and texture wise, i just mod for the userplus.con for quote lines and episode name and structure, so its very light stuff and that should work nicely, i loaded all of the dukebikes resources into my own zip and def and just added the con to dukeplus.con, i just needed it for jump distance testing and to see the feasibility of a bike level in polymer given the really open environments

[Danukem]

DanM, on Jan 20 2010, 12:52 AM, said:

they work but you can destory them which is bad balance wise, i think it mite be best to just make them pick upable like the boxes too as you could stack stuff and circumvent a whole lot of stuff in my levels, although i do use the box in some parts for advancement.

The potential for stacking stuff to reach high places is THE reason why a lot of mappers don't like that feature. If I could just figure out a way to make it impossible to stack stuff, it would help a lot. Either objects could become non-blocking or maybe I could make them slide off of each other (except for the boxes which are supposed to stack).

[VinsaneOne]

Whew! Wish I could understand all this! Ah, I read it all just the same.

[Stabs]

non blocking but still hitscan so ppl could use them cover would work best
slight activation problem with the cameras, the moving ones in particular

they don't seem to activate anything between cameras, i can use the yvel on the stationary ones to call up quotes and prop sprites, but in between 2 moving cameras to activate a prop sprite i had to use 2 stationary ones with a xvel of 1 and use the 2nd one to activate the prop sprite.

[Danukem]

DanM, on Jan 20 2010, 04:52 AM, said:

non blocking but still hitscan so ppl could use them cover would work best
slight activation problem with the cameras, the moving ones in particular

they don't seem to activate anything between cameras, i can use the yvel on the stationary ones to call up quotes and prop sprites, but in between 2 moving cameras to activate a prop sprite i had to use 2 stationary ones with a xvel of 1 and use the 2nd one to activate the prop sprite.

oops yeah i see the bug -- i was having the camera switch to the next one without activating anything else; it will be fixed for next update

[Sobek]

DeeperThought, on Jan 20 2010, 06:14 PM, said:

The most likely explanation is that the FIRELASER is still emitting dynamic light, despite the code that is intended to stop it. What I do is have the SHOOTER with flag 256 set the corresponding bit on the htflag of the FIRELASER projectile right after firing it. This is supposed to prevent it from being a polymer light: http://wiki.eduke32.com/wiki/Htflags

Try setting up a simple situation where you have one SHOOTER shooting FIRELASER and there is a floor near the path of the projectile so you can easily see if it is giving off light (just let the shooter fire at the player and watch as it comes towards you). If it is giving off light, then that is your problem. I can think of no other reason why FIRELASERs would lower fps that much.

I took your advice and setup a small room to test out the shooters, and you were right - the FIRELASER shooter is still emitting dynamic lights. I must have buggered something up when I originally tested out the code you implemented, because I was sure they didn't... I tried just using an EXTRA of 256, and they emitted light, then I tried the EXTRA of 280 that I would normally use (no polymer lighting + random trajectory + variable speed of fire), and it was the same - still emitting polymer lighting.

I guess that explains that. I take it that's just an issue with the code? I do recall you didn't get the chance to test it out yourself originally.

[Danukem]

Sobek, on Jan 20 2010, 04:41 PM, said:

I guess that explains that. I take it that's just an issue with the code? I do recall you didn't get the chance to test it out yourself originally.

This is what my code does:

ezshootvar peractor1 hitag
setactor[RETURN].ang position
ifvarand monstflags 256
{
	getactor[RETURN].htflags temp
	orvar temp 256
	setactor[RETURN].htflags temp
}

RETURN is the projectile being fired, and setting the 256 bit on htflags on that projectile is supposed to stop the light. I don't know what else I could do. For all I know, it's a bug in the source code which is preventing that flag from turning off the light.

[Stabs]

ahh ok cool

you mite also want to look at what happens with stationary cams, after 2 or 3 cam changes the shooter that would be shooting 5 chains for example would just stop shooting after that, i know i can use activation via cams, but my chain + shooter method can be very useful if you need something specific and may limit something down the line

the cutscnes without a cam that does not change seem to keep destroying the chain line and the shooter dosn't stop

oh and btw is that double activator mod feasible?

[Danukem]

DanM, on Jan 21 2010, 01:08 AM, said:

ahh ok cool

you mite also want to look at what happens with stationary cams, after 2 or 3 cam changes the shooter that would be shooting 5 chains for example would just stop shooting after that, i know i can use activation via cams, but my chain + shooter method can be very useful if you need something specific and may limit something down the line

the cutscnes without a cam that does not change seem to keep destroying the chain line and the shooter dosn't stop

oh and btw is that double activator mod feasible?

I can probably add the double activator thing.

I just uploaded new cons (the only difference is the activation fix for moving cutscene cams).

I don't know what is going on with the shooter stopping, but I don't see how it could be related to the cam changes. Maybe you accidentally set the shooter to have a limited number of shots? At any rate, depending on those to fire at chains seems inherently risky and I would try to avoid it if I were you.

I need to get this 2.07 update done and official soon, I don't think I'll be changing much more.

[Micky C]

I've noticed a rare problem with early activation of cameras. I have a swinging door with an activatorlocked with the same lotag as the SE 90's hitag, and when I'm ontop of the door, it opens (even thought it's locked, but that's not the problem) and when it opens it triggers the camera instead of when it's meant to be triggered later on.

Did that make any sense? Anyway it's not really an issue since there are a few ways I can work around it, but I just thought I'd point it out.

[Sobek]

DeeperThought, on Jan 21 2010, 11:44 AM, said:

This is what my code does:

ezshootvar peractor1 hitag
setactor[RETURN].ang position
ifvarand monstflags 256
{
	getactor[RETURN].htflags temp
	orvar temp 256
	setactor[RETURN].htflags temp
}

RETURN is the projectile being fired, and setting the 256 bit on htflags on that projectile is supposed to stop the light. I don't know what else I could do. For all I know, it's a bug in the source code which is preventing that flag from turning off the light.

That's ok, it's not too big a deal I suppose. I'm still working on it but before I left the office earlier I basically made a texture similar in look to the FIRELASER texture, and defined it as an animation in place of the COOLEXPLOSION1 textures. I did a real quick test and it looks like that's a perfect compromise... I can control what texture I want it to use, and it doesn't cast any polymer lights that I can tell so when I replace all of the shooters with that one, it should work wonders.

Thanks for looking into that though, I might try lining up a bunch of shooters that I know cast polymer lights and see if that 256 EXTRA works on ANY of them

[Merlijn]

If this has been brought up before, my apolegies.

Anyway, I'm constructing a sequence for the Imperium episode with bot-allies and newbeasts. And for some reason all of the newbeasts only move to attack the bots and they never attack me. I should mention that I gave the newbeasts the 'melee attack only' tag. Is this how all monsters behave when there are botallies in the game? If so, is there a way to fix this behavior? To be honest, I never really noticed this before..

[Danukem]

Merlijn, on Jan 21 2010, 09:52 AM, said:

If this has been brought up before, my apolegies.

Anyway, I'm constructing a sequence for the Imperium episode with bot-allies and newbeasts. And for some reason all of the newbeasts only move to attack the bots and they never attack me. I should mention that I gave the newbeasts the 'melee attack only' tag. Is this how all monsters behave when there are botallies in the game? If so, is there a way to fix this behavior? To be honest, I never really noticed this before..

I have changed the code so it should be fixed as of the next update.

Here's an explanation of what was happening (which admittedly may not interest anyone). By default, monsters don't have a designated target sprite; they automatically treat the nearest player as the target. To make them shoot at a bot or other player ally, I must make them find a suitable target sprite. When they have a target, it overrides their normal behavior and they attack it instead of the player. Here's where the bug comes in. If the monster does not have a target sprite, and it knows that there are nonplayer targets around, it will look for one. Once it finds one, it stays on that target until there is some reason not to. This means that if there are nonplayer targets around, the monsters will quickly find them and stay on them, overriding their normal behavior to attack them instead of the player.

One solution would have been to treat the player as another possible target sprite, so the monsters would be as likely to find the player when looking for targets as any other enemy. The problem is that would change and in some ways simplify the monster AI, because the player would be treated in the way that nonplayer targets are normally treated (all of the commands normally directed towards the player, such as faceplayerslow, ifcanshoottarget, etc. would become irrelevant). So instead of doing that, I simply made it so that if the player is visible, shootable and nearby, then there is a large probability that the monsters will not search for a target (and if they already have one, there is a large probability that they will drop it to go after the player after a few seconds).

[Danukem]

DanM, on Jan 18 2010, 08:36 PM, said:

just for example, as this could be a mod for normal dp activators

if xvel is set on an Activator, its yvel cannot be activated untill the xvel has been first

when going through areas twice i could make it activate something different the 2nd time around

There's something I still don't get. How would this add something that you couldn't do already? Also, I don't know what you mean by "normal dp activator"; there are no dp activators, only dp touchplates. I am not going to mess with the hardcoded activators, because it might be buggy or dangerous and I don't want to deal with the consequences.

[Stabs]

yeh the dp touchplates, so if i make the player go back through an area they have been through i can get them to activate new stuff on the second trip around

if xvel is set on the dp touchplate you can enter the sector and its yvel will not activate anything untill the xvel has been activated first

1st dp touchplate

x = 0
y = 101
z = 0

2nd dp touchplate

x = 101
y = 102
z = 0

1st one makes the 2nd one active, 2nd one activates new effects in areas you have already been through

this would make it so on the 2nd trip around the level it could activate new cutscnes and spawns anywhere i wanted, at anytime, i could put stuff on timers for a 2nd trip but there is no gurantee the player will be there to see it or it may seem out of place if its a cutscene.

[Danukem]

Ok I understand now. What you want is the ability to make a touchplate dormant, so that entering its sector does not activate it unless the it has been made active. Yes, I can do that. And then I will release 2.07