Do you mean a Ray Sensor or Touch Sensor or Collision Sensor or etc…
Looks like a good start. I’d try to decrease the polycount of the enemies a bit though. The stars could also use some work.
not exactly. I mean an actual invisible ghost sphere with a property creating radius around the object. like this:
it’s not very practical, but it could work … and … IT WORKS!!!
Does anyone have any tips on how to lower logic use?
Use python? XD
XD? what does that mean? 
I DON"T UNDERSTAND YOUR MOON LANGUAGE!!!:(:D:D
“XD” is a emotion-symbol, like 
, =/ and so on. XD = Laughing and crossed eyes…
Just as James said, the only way that you could “lower” logic use would be to use python. Unless your asking something else.
Exactly XD (Sidenote: I love this emoticon +XD+)
By the way, I loved Total Anhilation, it was/is a cool game XD
The best way to lower logic use is to set your pulse rates higher. If your pulse rate on your always sensor is 0, then it is running 50 times a second. if you set it to 25 it will take half the logic power to run it. Pulse rates can help allot in framerate. I find that even changing from 0 to 5 pulse rate dramaticly speeds up your game.
-Gomer
I can’t believe the garbage I’m hearing about logic here! “The only way to lower logic use is to use Python.” What are you guys talking about? Almost every game I’ve seen on this board could reduce brick count and increase speed without adding a speck of Python.
Here’s a primer on increasing speed and decreasing brick count using purely logic solutions or using Python:
Sensors are conditional statements in disguise. Every sensor represents a set of “if - then” statements. When the conditions (the "if"s) are met, then a pulse is fired to the controllers. As such, every sensor must be evaluated every frame (logic tic) regardless of the pulse rate or whether the sensor is firing a pulse (activated by key press or mouse click or whatever). Even when you have a pulse rate set, the engine has to evaluate the brick to see if it is ready to be evaluated (for an action) or not. Because of this, I recommend tip number 1:
1. Use as few sensors as possible. Do not use four always sensors when you could combine them all into one. Using the AllKeys button on the keyboard sensor and handling key presses in a script is probably more efficient than using 10 separate keyboard sensors. If you want to test a property value when the player clicks the mouse, don’t use a property sensor and a mouse sensor. Use a mouse sensor hooked to an expression controller instead.
Also,
1.5 Do what gomer said. While setting higher pulse rates will not stop sensors from being evaluated every logic tic, it will stop them from activating the controllers they are hooked to as often. I should mention, though, that I rarely ever set a pulse rate. If you plan your logic out well enough it will be very uncommon to find a sensor that is firing unnecessary pulses. Pulses are great for controlling the rate of weapon fire, though.
Controllers are also conditional statements. Controllers are only evaluated when a Sensor connected to them fires a pulse. Then the conditions in the controller are evaluated, and if the conditions are met, then the controller calls the actuator. Controllers in and of themselves (except Python controllers, that is) are pretty cheap to run (they don’t bog down the game too much). Actuators only run when the conditions of the controller are met. You can lower your logic rate by avoiding unnecessary running of actuators. Usually this means planning your use of sensors and controllers well.
2. Only run actuators when you need them. Some good examples of common over usage of actuators would be the “Edit Object > Track to” actuator or the Camera actuator. Both of these only need to be activated once and they “stick” until they are deactivated. However, most people use a standard always sensor to activate them at startup, so they are constantly being unnecessarily fired every frame. To avoid this, use a so-called “Once” sensor (an Always sensor with TRUE level pulse turned off). It will fire once at startup, causing the actuators to activate and stick, then it will never make it past the Once sensor for the rest of the game.
3. Python controllers with multiple sensors attached will run their scripts even when only one sensor fires. Because of this, you should hide the bulk of the code behind conditional (if) statements so it only runs when all necessary conditions are met. Even variable initializations and gathering values (getting object positions, etc.) should be hidden inside the conditionals when possible. For example, let’s say you’re handling a mouse click on an object. You need a “Mouse Over” and a “Mouse Click” sensor hooked together on a Python controller. Let’s say you named your sensors “MouseOver” and “LeftClick”. Start your code like this:
cont = GameLogic.getCurrentController()
own = cont.getOwner()
mOver = cont.getSensor("MouseOver")
lClick = cont.getSensor("LeftClick")
if mOver.isPositive() and lClick.isPositive():
## <i>everything else goes here</i>
4. Fix all of your Python bugs! The most common reason for incredibly high logic rates is unresolved Python errors. Sometimes a scripting error will not stop your game from running, but it will bog down the logic rate like mad. If you have a logic percentage higher than 10% or 20%, you are either using a ton of sensors, a considerable amount of objects (enemies, powerups, etc.), or (most likely) you have unresolved Python errors. Check the terminal window (also called the “console”, it’s the text window that opens with Blender) for all errors.
5. Write efficient code. This is the hardest one to do well. Writing good code takes practice, but basically your goal is the same as in logic. Only run code when it needs to be run, and avoid running it when it doesn’t. Don’t use five separate “if” statements when you could use one “if block” (one “if” with four “elif” statements). In an if block, put the most likely condition first, followed by the next most likely, and so on. This will create the shortest possible path through the block in the highest number of cases.
Hope that helps you (or anyone else for that matter). I know I’m not “THE expert,” but I have been complimented on my logic use and framerates before, so I can say with confidence that using Python is not always the only way, the easiest way, or the best way to reduce your brick count and get better speed.
-blendenzo
Heh, yeah. I use that one too as a free pass to be a smartass. /jk
Seriously though, you hit all the points perfectly.
try modeling the KROGOTH nextime!
I know I’m not “THE expert,”
are you sure? Everything I’ve seen you post (mainly in Gameblender.org) and everything has been extremely useful and accurate. Also your website is the best reference site I’ve seen yet!
I bow to you
try modeling the KROGOTH next time!
I never had CC so explain his weapons systems, speed, defense etc!:eyebrowlift:
It might be a good idea to add all that info to your site Blendenzo…
3 quick questions:
1.Where do you see the poly count?
2.Does inter-object logic linking slow things down?
3.is there something special about empties?
Poly count is on the top of the screen, It has vert and face counts listed.
- Top right of screen, next to blender version number. The polycount is the FA: number
- No, it just makes things a bit more cluttered as far as layout goes.
- Empties are like little gnomes. Very closely related to lawn gnomes, but slightly different.
Edit: Don’t mind my strange humor on the last answer. Ask a more specific question and I can give a better answer. There are many special things about empties. What do you want to know?
So you can “lower logic use”? Ha, didn’t know that. I love you Blendenzo, always teaching new things/techniques ;).
Empties are like little gnomes. Very closely related to lawn gnomes, but slightly different.
Ha! Random comedy can always lighten the mood! What I meant was that I have always seen people using empties, but is there something that they can do that an invisible plain can’t?:eek:
I’m also getting a “bad call to addqueue: 0 <18,1>” What does that mean and how do I fix it?:spin:
ps: thanks guys! my game is now stable @ 34fps for the moment!