Well, I have been re-structuring my game format to make updating things easier, and it’s coming along well. There is one small problem though.
There are 3 blends:
And each blend contains the objects it implies, along with logic, linked by adding everything in the blend to a group with the blends name.
So then how can I get an addObject actuator attached to an enemy in enemy.blend to add an explosion from effects.blend. Even though they are logic’d up, they will never be played from their actual blend, they will only by played from main.blend, where both blends are linked.
I don’t want to link the objects in effects.blend to enemy.blend, because then when I link enemy.blend to main.blend it may add in two copies of the objects of effects.blend.
In 2.49 you could type in the name, and then it would hunt for that name regardless of it it exists or not, meaning that while it gives an error in playing from it’s blend, in a linked blend it would find the correct blend. In 2.5+ if will not accept values of objects that don’t exist.
Yes, I can write a script that will update the explosions, but I would rather not, to me it seems there must be a way like the 2.49 method for 2.5.
Anyone got ideas here?
This is my method:
After object creation it searches the scene for all necessary objects (nav meshes, objects to add, waypoints etc.).
Any logic brick that needs such an object (e.g. TrackToActuator, AddObjectActuator) gets the found objects set as parameter.
This way it is possible to drop a group instance into any file. It takes the required objects automatically.
It is important to defined an interface to perform such things. E.g. how to recognize an object?
Here is the “property marker” method:
The group instance searches for objects with a specific property e.g. “player”.
Additionally the objects get another property to tell the purpose e.g. “waypoint”, “navmesh”.
The group instance “Player” looks for objects with “player”
If the found object has a property “waypoint” it is treated as waypoint (e.g. stored in a list)
If the found object has a property “navmesh” it is treated as navigation mesh (applied to a steering actuator).
This way you can have
- several objects for different purposes (waypoints, health packs, point of interests etc.)
- one object for several group instances (an enemy might share the same navigation mesh)
An enemy (“enemy_type_badGuy”) looks for waypoints. He collects objects with “waypoint” and “enemy_type_badGuy”)
An NPC (“npc_friendlyGuy”) looks for “waypoint” too but takes waypoints with “npc_friendlyGuy”.
Not quite what I was asking.
Let me try again.
I have weapon bullets in “effects.blend”
main.blend links to effects.blend and gets these bullets.
I have “enemies.blend”
enemies.blend needs to have some bullets.
If I link the bullets to enemies.blend (with the link under file) then it will see them as dependencies for the enemies, and drag in two copies of the weapons. How can I stop this happening???
I could just get rid of the link between effects.blend and main.blend, and rely on it linking from enemies.blend though to the main.blend, but this doesn’t seem property.
Ideally I would be able to have trackTo actuators pointing to objects that do not exist now, in this blend. But will exist later, in the blend that it will be linked to.
I do know how to identify objects by property, and now in my scripts there is no reference to object names at all!
Are you saying that I do have to assign if from script for every object’s actuator? What a pain, because these happen to be bullets, and having another script that assigns all the correct bullets to all the guns seems like a waste of time.
Well, I see your problem!
In 2.49, you could just type the name of the object to add, like i n you enemy blend, even without linking the bullets. Once the bullets were linked to the main blend, the enemy actuator would find the bullet object there.
Now you need a python solution.
So my solution is similar to Monster’s.
Since you can’t ask the actuator to look for a non existent object, have a property do it.
you get bullets=own[“effect1”]
then in you actuator, you set that bullets as object, act.object= bullets, I think… knowing that act=controller.actuators[‘addBullet’].
Since I’m still a noob at python, there might be some syntax errors.
But I’m doing something similar for my game, but I’ll use libLoad.
Urgh, yup, suppose so. You’re quite right about the python too.
I think that I will determine the bullet type from the name of the actuator.
An add object actuator with the name “Laser 2” will fire lasers of power class 2, or “Plasma” will fire plasma rounds.
The reason for this is because some enemies will possibly have more than one type of weapon. Ideally each weapon should know about itself (reload time, reload state, temperature if I were pedantic etc) but this probably won’t happen. Actually it might, I’ll have to do some testing. Lets see, how do I find an object that I have the actuator of…
this is a typical object orientated approach.
What makes a weapon a weapon?
The player (or whatever) can use it as weapon.
That means you setup an interface that defines how to use a weapon.
- a weapon must be parented to a “shooter”
- a weapon fires when a property “fire” gets a value “True”
- a shooter fires by setting property “fire” of a parented weapon to “True”
The shooter knows this interface.
The weapon knows this interface.
The shooter does not know how the weapon works.
The weapon does not know how the shooter works.
It does not matter how you implement a weapon (or a shooter). As long as it can process this interface (parenting/property) it is a weapon and can be used by any object that can interact via this interface (e.g. a bot, player).
This way you can even create weapons that can not be used by any shooter. You implement a different interface.
To go a step further … you can implement multiple interfaces (e.g. a player can use different kind of weapons, a bot can use a sub-set only)
using a weapons and picking up weapons are two different things = two different interfaces