Blengine! Module!! (Updated!)

Welcome fellow humans, dragons, and other life forms!

Anyway here’s the Blengine! Module! You’re probably wondering what it is, well if you haven’t played UFO yet click the link in my sig and have fun. This module was originally started when UFO was being developed to save time. It have awesome scripts like the gravity manipulator. It’s very easy and I wrote full documentation on the functions! To learn more about it read the documentation.

New: Mouselook support!
The new mouselook() function has been documented with a tutorial in our documentation!

Download: MediaChicken
Documentation: MediaChicken

Enjoy people! It’s still very largely in development. I will post a link in my blog now… http://www.mediachicken.com/blog

C&C

OH one more thing, it you’d like to submit scripts or anything please do so, just give me the script in normal .py format and I’ll edit it to make it work with Blengine!. Submit script at garet@mediachicken.com.

If you want to request features to-be-added just put the suggestion in a reply!

ENJOY!!!

Time for an update! I’ve made a lot of progress and added some new “handy” features!

New Features:
levelsys() (basically, as it sounds, an automated leveling system)
getPosition(axis) (get the position along a fixed axis)
getOrientation(vector,axis) (get the orientation inside any vector and axis)

I will update again soon, but not many more releases will be in the blengine! future. I am hoping to release BlengineX before long (maybe mid april? after 2.5 is released) I am writing tons of new fuctions for it and actually coding some logic bricks! Well I didn’t get time to update the documentation so here’s the documentation for the levelsys (not on mediachicken yet)


BLENGINE LEVEL SYSTEM!

about:
These are all very new features that have not yet been added into the documentation. This is the all new level system! It’s a very powerfull system that uses math to calculate the increase of levels.

How it works:
Basically you run the standard functions for running any blengine script, but to activate you must run blenging.levelsys(). Notice how we’ve cut back on arguments that blengine requires. For the gravity script you need to type in 7 arguments, for this we use our all new methods to use no arguments saving you time! Instead of weak variables we use strong properties. Prior to running you setup the increase and the starting level and blengine does the rest!

Tutorial:
So let me guess… you’ve just made an RPG game and need a leveling system… but one problem… you don’t know python and logic bricks would get a bit “hairy”. There is a sane way of doing this, and all you’ll need is 4 properties and 2 lines of python. Let’s go!

First let’s setup our properties, I will first tell you the type (float, int, bool) then the name, then the value:
INT: xp = 0
INT: level = (put in your stating level, usually 1)
INT: levelxp = (put in the xp required for the first level)
FLOAT: increase = (I usually do a 1.5 increase, if you enter 2 and the levelxp is 10 to get to level 3 you’ll need 20, then 40, 80, 160,320,etc)

So now we got our props done, that’s the hardest part! Finding a good increase rate depends on 2 things: your game type; the speed of your game. I usually do a 1.5 increase, this gives a good variation without making your game crazy hard. So now we have to setup our logic:

For this demo I used a property sensor connected to the python controller with our script in it. I set the property sensor to “changed” and the variable to xp. This means our python script will check to see if you can level up each time you gain xp. Now I set a keyboard sensor to a property actuator adding +1 to the prop: xp. Now everytime you hit the keyboard key you gain 1 XP.

Time for python!!


import blengine
blengine.levelsys()

Wow… that was very simple. Now you have a fully fledged leveling system!!

Questions, Comments? Contact the admin at: garet@mediachicken.com


And I’m attaching the file for the 1.2 release. It has different demos in different layers. Layer 1 > levelsys, Layer 2 > getPosition, Layer 3 > getOrientation

Enjoy!

Attachments

blengine.blend (138 KB)

So is this an entirely new python module for the BGE or just a set of functions interpreting long python scripts?

Because it would be fastest to code in the new python module for the BGE the same way other python functions get coded.

Also if you have it where the functions are really fast, and I mean faster than the old methods, then it’ll be good to have Ben take a look at it if you mean this is a python logic patch for the BGE.

did you decide to do the game on game blender ? ( off topic sorry )

@Cyborg: Not sure I understand 100%. It started with UFO when I needed gravity changing and such 100 line scripts, and I wanted a faster way to tweak the values. If you still don’t understand read the documentation.

@Reaper: What game? tCoL? You mean in my blog where I was asking for an engine?

Nice idea!
To collect the most common python codes under a module and just call the appropriate
function :slight_smile: and may later Ben implementing this function in c for faster performance.

Did you try it out yet? Pretty sick, eh? I figured mouselook was one of the most common function in blender. I’m now trying to implement socket connections so you just type, blengine.socketconnect(ip=)

Great idea, I also love the you can’t copy this…

Here’s a few reasons why it’s in a module and not just a list of scripts:

A module runs faster than script, the reason for this is because python is a raw uncompiled script that compiles on running, this causes slowdown. When you save a module it is precompiled. Now when you run: import blengine blengine.mouselook() it is only compiling 2 lines of code making it run faster. The rest is loading the module that’s precompiled.

I tested the saving and when you use pure python is causes a 1/2 second freeze (more like a spike) which is not bad, but when running huge save scripts it could cause major slowdown. Now when you run the module it is a seamless save, it has no lag. The C language is a language that needs to be compiled to run, that is why logic bricks don’t cause [major] slowdown when using a lot.

Don’t forget to donate scripts! If you want you can document your script, but you don’t have to, I love writing tutorials and documentation!

So I’m assuming Topmax and Lowmax define the highest and lowest the camera can move up and down?

Cool, your link to “python” in the documentation (http://mediachicken.com/python/blengine/documentation/python.org) ends in a 404 page.

Nice idea, sort of like Apple.
I don’t think adding the socket function is much good as connecting to a socket only takes one line anyway.

Yea but python sockets are laggy, doing it in C would show give a decent performance boost I would assume.

I believe python sockets are a wrapper of the C sockets

I never saw apple. But this module has more documentation =D

feel free to submit scripts: garet@mediachicken.com

I will give you 100% credit for the original script. I will modify your script to make it work right. This library is all open source so I’m not just doing all the work, I hate doing work! So please I need your scripts to make this grow!

Speaking of documentation, you might want to explain what you’re actually doing there, what the sensitivities are and how they work, what TopMax and LowMax are, also the description says to copy and paste that but since it’s an image that would be useless.

Trial and error my friend…

I thought I made the names self-explanatory. The max top, and the max low.

I said if anyone has any questions to email me (in the documentation) not cry about it (not saying YOUR crying about it, but other noobs who may quesiton)

Seriously if you have any questions don’t hesitate to ask, if you don’t understand my answer I’ll write a step-by-step tutorial.

I still think it would make a lot more sense to have a Max and a Min(say like in the servo actuators)

You fool! blengine © blengine, nice work though, good resource… As time goes on people will start crediting me for this awesome module. Looking forward to it.

Haha, I didn’t even think of you! Now I’ll have to change the name!

Hey Killer thanks for this resource. I was looking at the script cause I’m trying to learn python in genral and more specifically how to make a good mouselook script. Anyhows I understand almost all of the script but have trouble with the following parts:
offsetY = -(Height/2-Ypos)*YSense
mRotX.setDRot(0,0,-offsetX,1)
mRotY.setDRot(0,0,0,1) here why do you set the DRot when in the next part you assign the y offset inside an if sensor anyway. Wouldn’t the DRot be 0 as standard anyway.

GameLogic.addActiveActuator(mRotX,1)
GameLogic.addActiveActuator(mRotY,1)
GameLogic.addActiveActuator(mRotX,0)
GameLogic.addActiveActuator(mRotY,0)
Here I understand why you have to add the actuator but why do you do it twice for ,0 ,1 as I understood that set whether the actuator was applied locally or globally.

One more question, in the gravity module what does the hasattr do I’ve never seen it before. Thanks again. P.S. Your documentation rocks. :smiley: