Linked Group not working like it should

Hi
Created a blend file called player.blend
I created a FPS character player made up of a cube, armature, flashlight (with animation), camera.
Camera is child of cube, armature is child of camera.
Added logic/python to make it move and look.
Added all 3 objects to a group called “player”. This group is the only thing in the blend file.
Created a blend file called level.blend. Deleted default cube and default camera. Kept the default light.
Added a plane and gave it a material.
Linked group “player”.
Hit “numpad 0” to select camera. Nothing happened. Cannot look through the camera in the group.
Hit “P” to start internal game player. Movements working, sound working, animations working…except for the flashlight lamp does light up now…
Other problem is I can’t can’t play the game from FPS view because for some reason I cannot look through the camera.
Not sure what to do.

Did you instantiated the group?

I believe so.
From the level.blend I linked the group player to a scene.001. Then went to Scene.
Then Add/Group Instance/player and got the problems.
I must be doing something wrong.

When you instantiate a group (which is perfectly fine) you can’t access the instance members in Blender. You can only select the dupli group object.

That means you will not be able to switch to the camera as it is part of the instance.

This is only an issue in Blender (as you can’t directly switch the view).

In the BGE you can switch the camera with the scene actuator.

While thinking about it… I’m not sure if your can refer to the camera in the instance. let me check …

if not, just do



import bge
cont = bge.logic.getCurrentController()
own = cont.owner

added = bge.logic.getCurrentScene().addObject('GroupInstance',own,0)


for obj in added.groupMembers:
    if 'CameraTag' in obj:
         Cam =bge.logic.getCurrentScene().active_camera
         Cam.worldPosition = obj.worldPosition
         Cam.worldOrientation = obj.worldOrientation
         Cam.setParent(obj,0,1)

just add a property ‘CameraTag’ to a empty, and align the empty to the way your camera should be.

Why group and instantiate the Player? I’ve never seen this. Is there an advantage?

The instantiated camera can’t be set via GUI.

but you can use something like this:


import bge

GROUP_CAMERA_NAME = "Camera.group"

controller = bge.logic.getCurrentController()
owner = controller.owner

members = owner.groupMembers
camera = members[GROUP_CAMERA_NAME]

actuator = controller.actuators[0]
actuator.camera = camera
controller.activate(actuator)

Yeah I read that along time ago, and I use it quite often. But not on a player char. Musta missed that.
But I’ll dive a little deeper. Thanks Monster. :slight_smile:

Could you just remove the camera from the group, or would that defeat the purpose?

Monster…pardon the noobie question…but how do I run the script when the level (new blend file) loads?
And do I need to rename my group to Camera or is it okay to leave the group named the way I have it.
I’m learning python scripting but not quite there yet!

I also don’t have any idea why the flashlight animation isn’t working (lift arm when light goes on. lower arm when light goes off)
The armature animation works but the spotlight’s animation (power level 0 to power level 2) doesn’t play. In other words…the light doesn’t light when I “click” the switch.

theoldguy…I need the camera for my game “eyes”.

I also had a thought about just appending the player to every level (blend file), positioning it where I want it, and bringing the data from the last level with it. But with that said, I’m thinking that will not allow me to go back a level cleanly, if need be. (Missed a required pick up from the previous level).

You can move the active camera relative to a player anyway, or more specificially
You can align to his mouselook
It does not really matter =)

Always [no level triggering] -> Controller

To be more specific, this runs the controller the frame after creating the object (which is usually after scene loading).

To run the code snippet you need this setup to the instance object:

Always -> Python controller Script: <name of textblock> -> Scene actuator Mode: Set Camera

This is a code sample for demonstration, rather than for easy to use. Usually I create models rather than scripts, avoid to hard-code names and do not force users to change the code. In a demonstration it shows the principles expecting that you adjust the code to your needs.

If you do not want to touch the code, you need to name the camera in the group “Camera.group”.
Otherwise you change the name in the code.

Other options:

Instance sets up camera
You assign the camera changing logic within the group -> inherited by the instance. This might be possible without Python as the references are fixed in that case. The problem is that you can’t disable this behavior within your level file. This means when you want to set another camera in a different level (e.g. to show a cut scene) you can’t guaranty that the right camera is set. If that is not an issue, this method might be better for you.

Separate camera from player
Dynamically attach the camera to the player. This can be achieved by dynamically parenting the camera to the instantiated player (better: camera hook) which is part of the group and therefore part of the instance.
It needs some Python code too. But I think it might be a bit too advanced for you right now.
The benefit would be that you can look through the camera while in Blender.

I used that method in my old mouse orbiter demo. Since 2.62 the code is much simpler with better configuration options.

Linking is what you need. Otherwise you spread separate copies all around the scenes. Which is really hard to maintain.

Something like the SaveLoader might help. A simpler version might be more sufficient.

I think all you gotta do is add a scene actuator to the group’s camera, unless there’s a special requirement I didn’t catch.



Mode = Set Camera
Camera Object = leave empty

Sorry if this was already answered but that’s a lot of text to go through

I’m really interested in your game, and how you decide to make it. And can’t wait to play it. So I hope you finish it. :slight_smile:

I also had a thought about just appending the player to every level (blend file), positioning it where I want it, and bringing the data from the last level with it.

Do you mean using the game actuator to go from one Blend to another, instead of using Scenes as levels?

That’s the way I did it on one of my big silly games a long time ago. And my favorite way. I was able to get 22 levels by moving from blend file to blend file. It was less messy, and allowed me to make a big game that would run on a small PC. It made it easier (for me) to upgrade the player. But I couldn’t get my points, collectables, inventory etc to update from one blend to the next, consistently, 'cause I’m not good with Python.

But with that said, I’m thinking that will not allow me to go back a level cleanly, if need be. (Missed a required pick up from the previous level).

Don’t let your player leave until he has met all the requirements.

Have you thought about linking your levels to your player blend, and moving the levels to a inactive layer?
Spawning them when you need them?

BluePrintRandom…
Do you have an example of what you are talking about?

Monster…
I got it somewhat working!
I added an Always sensor and Python controller to the camera in my Player group. (using the code you provided.)
Then in my level blend, I linked the Player group and ran the internal game player. I am now looking through the camera just like I wanted and my player moves correctly.
(I am getting a python error about line 9, but everything is working so I will figure that out later.)
I did NOT instantiate the group and it works fine. (other than I still don’t get my flashlight to light up…I need to fix that somehow…lol)
Why exactly do I need to instantiate if just by linking the group from one file to another seems to work? (I apologize if you already explained that…I’m probably missing something.)

I also like the option you mentioned about dynamically attaching the camera. Going to look into that later on as well! Not sure I really need to do that though.

theoldguy…

Do you mean using the game actuator to go from one Blend to another, instead of using Scenes as levels?

That’s the way I did it on one of my big silly games a long time ago. And my favorite way. I was able to get 22 levels by moving from blend file to blend file. It was less messy, and allowed me to make a big game that would run on a small PC. It made it easier (for me) to upgrade the player. But I couldn’t get my points, collectables, inventory etc to update from one blend to the next, consistently, 'cause I’m not good with Python.

That is exactly what I was suggesting!

Don’t let your player leave until he has met all the requirements.

That’s a good idea. Didn’t think of that.

I wish I could see the big picture here…
A flow chart or a blueprint of how everything works together…it’s not clicking yet. lol

I do know that this is how I want to do it:
Player is in a blend.
HUD is in a blend.
Levels are their own blends.
When you start the game…the first level runs and the Player is “spawned” in.
then when player is ready to go to next level, before the new level is loaded, the player saves his data (scores and what not) to a file and then the player ends. When next level runs, Player “spawns” and all old data is loaded.
Rinse and repeat until the end of the game.

That’s a basic run down of course cuz I also want to have check and save points…

My reasons for this approach are:
To have a player and a HUD that can be dropped into any “level” (blend file). (This will allow me to create additional levels later on.)
I want the game to load quickly and not be one ginormous file.

Your plan sounds reasonable and should work pretty fine.