Custom Personality Core
I'm in the process of building one from scratch in Blender. I will emulate as near as possible the relevant animations from the main personality core model. The model will be implemented in game as a prop_physics, and animated by a combination of trigger brushes. It seems feasible to emulate most of Wheatley's behaviors this way, and I was wondering if anyone had tried something like this.

In addition, I'm having some issues making this guy distinct. In the first place, he'll be physically different from the normal cores simply by virtue of being a custom-created model, but I want him to be different at a glance. Which leads me to the very silly question, what color do I make his eye? His core personality trait is paranoia, which is a major driving force behind the story, so I'll have some animations to convey that, but I need to come up with a way to color the player's impression of him through the personality core equivalent of body language, and eye color is a big part of that. (Tell me you would have trusted Wheatley at all if his eye hadn't been that cheerful, friendly blue color.)

Interaction With Atlas/P-Body

My custom core, who so far is only known as Paranoia Core and is not yet named, will lead the player into a BTS area where they will observe Atlas and P-Body (prop_dynamic or prop_pysics models - I'm leaning towards the former, but may have to use the latter for reasons explained in the very next paragraph) being outfitted with ASHPDs. A conveyor belt then carries the bots up to a couple of pneumatic pipe intakes, then there is a brief pause, an offscreen explosion, and the bots respawn to be outfitted again. This will continue until the following event.

On an area trigger, the Personality Core will bump Atlas into a grinder and prompt the player to take his place to be outfitted with an ASHPD (probably mandating Atlas being a prop_physics for best appearance).

This is where things take a (thankfully temporary) turn for the "what the heck are you getting yourself into, idiot?" and I attempt to make a map that doesn't behave normally.

The map is intended to conclude with a dirt-simple tail-end-of-a-coop-map area where the two bots have clearly bypassed a long series of extremely brutal puzzles. All that's left is a couple of things for the player to do. To emulate coop play without actually requiring an AI or a full-fledged mod, I plan the following:

1) The ASHPD the player has will not be fully upgraded.
2) The P-Body entity will follow a strictly scripted path, guiding the player through the remainder of the map. env_instructor_hint entities should do a fair approximation of the ping system, letting P-Body tell the player what needs to be done.
3) If need be, once the portals are in position, I will replace P-Body with an identical prop_physics (the puzzle involves him hopping onto a faith plate) and swap that back out again after he arrives at his destination.

The things I need to know to make this happen:
1) Can prop_dynamic entities be affected by the script that makes Faith Plates work?
2) I presume there's no feasible way to just change an entity's type, but assuming there is, would that work?

Yes, this is all insanely ambitious. Fortunately, it's only for the one map. Further maps in the story would follow a more normal single-player progression.

EDIT: Okay, I have more time now.

A generic_actor and aiscripted_schedule is the best way to get a walking NPC. The way VALVe did it the one time you see P-Body in SP is to bake in a custom animation, but that's really hard. I believe actors can be faithplated and such, and you can make some system to send the NPC to arbitrary locations in Hammer.

For the personality core, remember that physics and animations don't mix. Probably the best way to do it would be to make your new model, use the Face Poser to do your choreo, then use a one-line VScript to swap out the model of an npc_personality_core.

And a phys_convert will help for some of the things you want. You can use AddOutput classname to change the class of an object, but it won't change its behaviors, only how filters affect it.

FelixGriffin wrote:
A generic_actor and aiscripted_schedule is the best way to get a walking NPC. The way VALVe did it the one time you see P-Body in SP is to bake in a custom animation, but that's really hard. I believe actors can be faithplated and such, and you can make some system to send the NPC to arbitrary locations in Hammer.

I shall make a quick dummy routine to try this out. If I can get this thing to even pretend to behave, I will be happy.

FelixGriffin wrote:
And a phys_convert will help for some of the things you want. You can use AddOutput classname to change the class of an object, but it won't change its behaviors, only how filters affect it.

Well, that saves me from having to try that incredibly kludgey workaround I was thinking of... I think. We shall soon see.

Edit: Not gonna work. I'll try scripted_sequence instead, it offers a lot more control.

FelixGriffin wrote:
It certainly does, just remember to rebuild scenes.image if you modify anything in Face Poser.

I'm doing all this to avoid having to reubild scenes.image. Sadly, scripted_sequence is teleporting my model around, which means I'm going to have to do even more work to get this dang thing to work as intended. Blargh.

FelixGriffin wrote:
Change "Move to Position" to 0 ("No").

That doesn't actually help. My problem isn't that it's moving the model, it's that all of the movement types bypass any sort of actual movement and just teleport the model there. This brings me back to parenting the model to something else and operating it like a puppet, which I may end up doing anyway. Portals are going to be a bit of a challenge, though. I may have to fake them as well. (Have multiple puppets with collisions off so they can pop out from behind walls and such.)

I'll continue testing various ideas while I work on the level itself. The uglier the behind-the-scenes workaround, the less I'll want to use the character... Thankfully, I haven't got a deadline or anything.

EDIT: Actually, they seem to have just renamed the activities. Try using Custom Movement and ACT_MP_RUN.

FelixGriffin wrote:
Try using Custom Movement and ACT_MP_RUN.

Trying it now!

Edit: Still a no go. The sequence itself runs fine using both animations and actions (tried both ACT_MP_DROWNING_PRIMARY and taunt_big_wave), but he still teleports around...

...

...

Wait...

What if the sequence action is itself walking...? ....... That would be so awesome if that worked, though it would more than double the number of entites needed to make it work.

Oh, well, so I'll have more of those. I can always cut back a bit on props...

Further Edit:
That, too, is a no-go. Puppetry ahoy!

Thus, the retitling of this thread. Who knows? Maybe documenting my learning process will help others in the future?

As I make alterations to my plans, some things will be removed for one reason or another, and others will be added. New additions will be in italics, and removals will be struck through, so the decision making process can be seen. Reasons for removals will be explained at the end of the class post.

The Original Concept

The Story

A whole lot of blather here. If you don't care about this part, or want to experience it if/when you play the level(s), then do not click this button-->
||Upon her escape from Aperture Science in Portal 2, Chell finds herself stuck in a Portal mindset. When presented with a roadblock in her exploration of the world around her, she notes a place where a portal would get her past it in a heartbeat. Unfortunately, when she left, she wasn't given the ASHPD as a parting gift, and the Weighted Companion Cube is a lot less useful without buttons to press.

In her explorations, she noticed a familiar logo, leading her to a very poorly placed storefront in a ruined city. This is where the level begins: In an Aperture Technologies store that is, for unknown reasons (I find it amusing personally) stuck down a back alley in a large city.

In her exploration of the store, she finds little that hasn't already been looted. A few packaged turrets, some detritus from previous scavengers, a few "some assembly required" ASHPD boxes, and a portal gun. Unfortunately, the door is locked, and the window surprisingly intact, making portaling out of the store impossible. Despite having achieved her goal, she must continue on.

Behind the counter, she finds a jolly, candy-like button, which opens a hidden panel in the back wall. Exploring this area takes her down a hallway to a distinctively Aperture Science elevator (Portal 1 style design). As the only way out is through (a running theme in her life), she takes the elevator down to a seemingly disused testing facility.

This area, in extreme disrepair, houses a disposal facility with a bin full of defective personality cores, two of which are still active. One core is a useless byproduct of a failed marketing scheme in which Aperture attempted to make memetic advertising. All it does is spout memes uselessly and constantly. The other (whom I've now decided to call "Dave" as a reference to 2001) begs her to take him with her.

[s]Dave informs Chell that the portal gun she's carrying is defective, and invites her to prove it by having her attempt to attach a portal to a nearby wall. As soon as the portal is established, it vanishes and the gun begins sparking and fizzling. Chell discards the gun, and[/s] Dave tells her he can help her get her hands on a portal gun if she'll help him get away from the recycle bin.

From there, Dave has her attach him to a wall panel, which he uses to unlock a door and attach himself to a Management Rail and lead her to a testing facility.

In the testing facility, they see Atlas and P-Body participating in the Cooperative Testing Initiative from behind the scenes -- after being killed in a test, the two are deposited in an equipment room, issued portal guns, and taken back to the test by Pneumatic Diversity Vent.

Dave positions a Management Rail so that he can knock into Atlas and send him into a conveniently placed wall grinder, then urges Chell to step up and take Atlas's portal gun.

In doing so, Chell finds herself dragged by the conveyor belt into the vent and from there into the testing facility itself. Dave promises to meet up with her in the test chamber, where they can make a break for it.

In the test chamber, Chell must make her way through a simple set of puzzles before her solo track comes in sight of P-Body's. He indicates to her that he needs her help setting up a fling to get him to the exit, where he can open the path for her to get through.

If the player chooses, once P-Body has stepped onto the Aerial Faith Plate that launches him into the Fling, they can change the destination portal to one whose sole purpose is for one test subject to sabotage the other for laughs. Doing so nets an "achievement" which will be shown in the end-of-level elevator lobby. Doing so bypasses a quick interlude at the end of this area, as Dave opens a wall panel and ushers the player out of the level area.

If the player clears the level with P-Body, Dave opens a panel in the ending chamber, urging the player not to step into the disassembler. Doing so [s]nets a different "achivement" and[/s] kills the player.

Everything up to this point is introductory to the real level, which follows:

Upon following Dave behind the scenes, the player enters an area with a long climb punctuated by puzzles in which they must use him as an Edgeless Safety Cube and attach him to various docking stations to switch various devices (stairs, platforms, doors, etc, the usual mishmash of Portal paraphernalia) on and off. The pressure in this area comes from a slowly rising column of goo which automated announcements declare to be due to a malfunction in a pressure control relay and Dave claims is clearly a trap because "she's onto us." At the end, the player attaches Dave to a docking station to activate the elevator out of this level.||

Technical Details

What's been done so far:
- Basic layout of the store and planning (lots of planning).- Implementation (and subsequent removal) of the malfunctioning portal gun.- Modeling of Dave (about 75% done)- A dummy texture for Dave, which is serving as a placeholder for now because it's hideous.
Things that have worked:
- The malfunctioning portal gun: A func_portal_detector wrapped around the entire area triggers an env_spark and a command_console (which is used to fizzle the portals) after a half second delay, just enough time for the portal to form and for the player to attempt to place a second portal before the portal vanishes. I added a counter which would keep track of how many attempts to place a portal were made, then, instead of just triggering SparkOnce, just enable the trigger.- The hidden panel. Well, come on, it's just a func_movelinear on a wall with a piston behind it for decoration.- Fun with lighting -- making the lights flicker and either come on or die was more fun than it should be.- Testing the use of env_instructor_hint for later use as P-Body's pings.Things that have failed me utterly:
- Did you know there is no way to take away the portal gun once it's been given? Nothing I've tried works. This defeats the entire purpose of the malfunctioning portal gun bit. At least it frees up a couple of entities for use in other parts of the level.- Linked Portal Doors. I knew that sticking a linked portal door behind a func_door would cause it to disappear. Apparently, the same holds true for func_movelinear? Or the linked portal door has to be in a space connected to the player directly, and the fact that my func_movelinear is, in the level design, already in the "closed" position is killing it? In any case, my reason for using it in the first place (to make keeping my level from leaking easier) was pure laziness on my part. I went through the level, tracking down every possible leak instead of enclosing it in a giant skybox like a lazy bastard.- NPCs. Oh my GOD NPCs. I've tried aiscripted_schedule and scheduled_script (or whatever the hell it's called) and neither one functions properly. I've decided to go the puppetry route and parent the "NPC"s to brushes with func_movelinear and func_door_rotating. It's going to be a hella-ugly heirarchy, but it should work. Fingers crossed.Other changes:
- I removed the disable turrets because (a) it's mentioned in the commentaries that they never actually shipped them out, only sent them to another part of Aperture Science to be unboxed and disassembled, perpetually. Also, they're entities and I want to run out of entities because of the meat of the level, not because I wanted a bit of scenery. On that note, I may replace the entities I have stuck on the shelves (food cans and water bottles) with brushes textured with some fake Aperture Science Food-Substitute Products (I'm envisioning PORTAL-Os, an inedible Cheerios knock-off featuring a friendly cartoon turret on the box) and free up even more.Learning Experiences:
- I learned the hard way that displacement maps' lack of visible surfaces on the backside causes leaks. I made a cave area as an experiment, and everything connected to that area leaked until I enclosed the cave in a box. So, yeah, knowledge for the future, yay!- A lot of the sounds in the sound browser don't work. Ah, well, live and learn.- Some textures show through other textures. I have no idea why this is, but it's true of a few of the Aperture Laboratories logo textures. Specifically the ones that have transparent parts. This forced a redesign of the store area, at least until I get around to making some new textures for it.Plans for the Future
- Dave will consist of a prop_dynamic or a prop_dynamic_override with collisions disabled, parented to a sphere, which will be inside of him. To help keep him from rolling away when he's set down, the sphere will have a couple of invisible brushes parented to it overlapping his handles.- The NPCs are still in. If I can't make them at least pretend to behave like NPCs, I will keep bashing my face against the keyboard in the hopes of magic happening... or out of frustration.

BlackWolfe wrote:
[list][*] Did you know there is no way to take away the portal gun once it's been given? Nothing I've tried works. This defeats the entire purpose of the malfunctioning portal gun bit. At least it frees up a couple of entities for use in other parts of the level

Use a trigger_weapon_strip then you can just spawn a model of the portal gun that the player drops or gets fizzled.

LoneWolf2056 wrote:
BlackWolfe wrote:

[list][*] Did you know there is no way to take away the portal gun once it's been given? Nothing I've tried works. This defeats the entire purpose of the malfunctioning portal gun bit. At least it frees up a couple of entities for use in other parts of the level

Use a trigger_weapon_strip then you can just spawn a model of the portal gun that the player drops or gets fizzled.

YOU ARE MY HERO.

Why did this trigger not show up when I searched using the term "strip weapon"?!

And now it does...

Wait... I didn't use the term "strip" when searching the wiki, I used "remove". I used "strip" when google searching.

Although I think I'm going to try to use the point entity instead (assuming it works in Portal 2) as I won't have to wrap half my map in it, and it will help keep my map tidy. (I'm going to be reorganizing soon, moving all my logics and similar point entities to a single location where I can easily sort through them. I may graph out their relationships with brushes, too, like a flowchart.

FelixGriffin wrote:
Make a small weapon strip, parent it to the player, SetParentAttachment forward, now it'll always be covering the player.

LoneWolf2056 wrote:
Use a trigger_weapon_strip then you can just spawn a model of the portal gun that the player drops or gets fizzled.

I'm seeing a pattern here... Is there a reason you guys prefer using brush triggers to point entities? My understanding was that both count as entities, so I would prefer to use a point entity for consistency, personally. However, that's just me, and if you guys have a reason I should use the brush instead, I'll definitely listen.

BlackWolfe wrote:
FelixGriffin wrote:

Make a small weapon strip, parent it to the player, SetParentAttachment forward, now it'll always be covering the player.

LoneWolf2056 wrote:

Use a trigger_weapon_strip then you can just spawn a model of the portal gun that the player drops or gets fizzled.

I'm seeing a pattern here... Is there a reason you guys prefer using brush triggers to point entities? My understanding was that both count as entities, so I would prefer to use a point entity for consistency, personally. However, that's just me, and if you guys have a reason I should use the brush instead, I'll definitely listen.

From my experience with custom tank based weapons, a point entity of it just puts down the portalgun, but still allows you to shoot.

Another learning experience: Did you know prop_dynamic_override doesn't disable the weight of the model? I parented a personality sphere to a ball as a test, and the darn thing was too heavy for the portal gun to lift above eye level.

And try a logic_playerproxy or a game_ui. The OnFire... inputs are only for weapon_portalguns, which don't exist once the player grabs them.

FelixGriffin wrote:
Really? Children shouldn't affect their parents as far as physics is concerned. Try setting its collisions to Not Solid, sometimes the portalgun decides it doesn't have LoE to the object and drops it if you have a parented model.

It already was set to Not Solid. Also, the personality_core.mdl is slightly smaller than the ball.mdl, so nothing was visible anyway. Still muddling through on that one... I may be able to use my custom core as a generic_actor and just use SetParentAttachmentMaintainOffset to pick him up and ClearParent to put him down. Actually, I'll try that with Wheatley right now...

FelixGriffin wrote:
And try a logic_playerproxy or a game_ui. The OnFire... inputs are only for weapon_portalguns, which don't exist once the player grabs them.

That's really weird, because the primary fire worked like a charm. So the OnFire routines are supposed to trigger when (for example) a mounted portalgun is fired by a trigger (like the ones in Portal 1)?