[Danukem]

 The Commander, on Jan 14 2010, 10:00 PM, said:

I haven't really looked at how the cameras work, so I'm not sure if it does do this but the cameras could be good if they worked on tagged sectors like they seem to be in this video.

http://www.youtube.c...h?v=CCUqQoSYTDA

That way you could make a cool duke bike jump scene so that each time you jump the bike over the sectors it cuts to a nice cinematic view of the player doing the jump while still giving him the controls.
This could also lead to some interesting game play effects IMO.

The cameras can be triggered in a number of ways, including by entering a sector (if they are triggered by a DPTOUCHPLATE). They can also be set to allow the player to move. However, there are three things that currently prevent them from being used for action like in that video: 1) the player sprite is invisible (and making it visible would require forcing F7 mode), 2) the cameras expire on timers, 3) the cameras are permanently dead once the view shifts away from them. The first two are trivial (2 is not really a problem because the timers could be set to very high values), but dealing with 3) would require coding them a lot differently.

[The Commander]

setplayer[THISACTOR].over_shoulder_on 1 would also eliminate the first one.

[Stabs]

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

I can do that, but there's no reason to limit them to cutscenes. They will have an activation tag that makes them appear, and another that makes them disappear. Whether they are linked to a cutscene is up to you.

iam just going for whatever would be simple, but the more flexible the better if you have no problems going into depth with stuff
it would be helpful, making this disapeer incase i want to cutscene in the same area twice (or nearby which would limit my camera angles)

and iam sorry about yet another request

just 2 sprites, red and blue light that flash with a radius relative to a hitag of 2000, i really need them for the emergency vehicles, it would be a +10 to atmosphere

[Danukem]

I have added the temp sprites and uploaded some new CONs. Here is the documentation:

Temp Sprite
Temp sprites are visual props that can be made to appear upon activation, and then later disappear with another activation. These are useful for making areas that change appearance after certain events. All temp sprites are tile number 2955 (the red P). They become invisible when the map loads, and upon activation they change to look like another tile specified by the mapper. Note that these are not like RESPAWN; they do not spawn another tile, they just look like it. This is important to remember, because they will not run any of the code specific to the tiles they are made to look like (for example, they will not take damage if you shoot them). Also, they may not block like the other tile because tile 2955 is very small (so, for example, it would be inadvisable to use the effect to make s sprite bridge appear, unless it is purely decorative and the player never has to walk on it).
HITAG: This is the activation number that makes the temp sprite visible. Hitag 0 temp sprites are visible when the game starts.
LOTAG: This is the activation number that makes the temp sprite die (note that it cannot die unless it has been activated first).
EXTRA: This is the tile number that the temp sprite looks like when it has been activated. Note that it will not display animation unless the animation is defined on the tile in an .art file or a def file.


Note: There seems to be a problem with recent builds of mapster where if you press 'M on sprite in 3D mode, you cannot enter a number for EXTRA that is more than three digits long. However, you can enter longer numbers by pressing F8 on the sprite and editing EXTRA that way. It's too bad, because I was careful to only use tags on this sprite that can be edited in 3D mode, but that mapster bug interfered.

Question about pulsing dynamic lights: Would it be okay if they could only be point lights? SE 49 has a tag or two that is not used which could define the pulsing, but spotlights use all the tags and that complicates things.

Oh and one more thing: I also have a texturizer effect from WGR2 that changes textures upon activation (it makes all textures in the map of one tile number into textures of a different tile number). I don't know if that would be useful.

[Stabs]

ill give that new code a try now, i do have places i could actually make it use the sprite in game, so thats good it can be used that way too

as for the lights, as long as they pulse like a cop car that would that would be great, whatever works, i like how the dp flare works, if thats any indication of how i would like it too flash

cant hurt to have the pal thing there, i am sure ill come across something i could i use it for

EDIT : only suggested change is to not draw the player model in camera view, because duke just stands there with the running animation

[Danukem]

 DanM, on Jan 15 2010, 03:09 AM, said:

EDIT : only suggested change is to not draw the player model in camera view, because duke just stands there with the running animation

Would it be ok if he was standing instead?

Anyway, I upload new CONs again, this time with the pulsing light effect on SE 49.

EXTRA is the speed of the pulse (higher == faster)
SHADE is the time offset on the pulse (so you can have two pulsing lights of the same speed but timed differently).
Other settings are the regular SE 49 ones.


Here is how you can make a red/blue cop light:

Place two SE 49.
Give one an xvel of 255, the other zvel 255 (one red and one blue)
Give them both hitag 8192 (that will be the MAX light value as they oscillate)
Give them both an EXTRA of 64
Give one of them a shade of 16, the other a shade of 0.
Move them both to the same map coordinates.

[Stabs]

having alot of fun with these lights although i think i may have to brand my episode with a strong epilepsy warning

[Stabs]

ok ive had a big play around with all the new stuff this weekend got alot done and my only few suggestions are

an extra bit for cutscenes so it wont draw player or dukebots (sometimes they run through a cutscene), its just the way i use the cutscenes with sector activation and such, i could do alot more this way, and i need it as an extra because on bike jumps i just want it to show the player doing the jump.

also the dukeplus helicopter, it only seems to activate when the player sees it and not when the cutscene cam does, & i need that black hawk heli i sent you via email a few months ago, if u need it again i can send it. i would import it has a def hack myself but the angle borks things up.

[Danukem]

 DanM, on Jan 16 2010, 07:15 PM, said:

ok ive had a big play around with all the new stuff this weekend got alot done and my only few suggestions are

an extra bit for cutscenes so it wont draw player or dukebots (sometimes they run through a cutscene), its just the way i use the cutscenes with sector activation and such, i could do alot more this way, and i need it as an extra because on bike jumps i just want it to show the player doing the jump.

I can make it not draw the player easily enough; in fact, I can make it that way by default. Making it draw the player actually requires extra code that I can remove. But the Dukebots are a different matter. Can't you just not have any Dukebots in the bike areas? There's a way to prevent them from teleporting to the player, if that's the issue.

 DanM, on Jan 16 2010, 07:15 PM, said:

also the dukeplus helicopter, it only seems to activate when the player sees it and not when the cutscene cam does, & i need that black hawk heli i sent you via email a few months ago, if u need it again i can send it. i would import it has a def hack myself but the angle borks things up.

I'll work on the helicopter, probably tomorrow.

[Stabs]

thats fine, i use 1024 and 256, so ill just stick to using zvel stop points / sectors of hitag 666, and just spawn the bot again, they are just my work around for it, just thought there mite be something easier way with a couple of lines of code, but its good it cant draw player in some parts, this will be very useful.

iam not adding any dukebots to the bike level tho, nine one one is centering around all the story stuff, there wont be too much of that stuff in other levels.

[Spiker]

The cutscenes should look really awesome when you combine them with the motorbike, especially while in the air

[Stabs]

limitless potential with the new cutscene SE + prop sprites, i have been using them alot

i have done stuff over the past day i never ever thought possible, even used the sleeper effect in combo with a timer to make it so the players position changes to place they are displayed in the cutscene when it ends, works great

now for the minor tweaks,

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.

[Danukem]

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

and an activator that cant be activated untill its activated, i think that will completley remove any limitations i have to work around.

As opposed to activators that can be activated before they are activated? I don't understand.

[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.