@26: the developers will not need to learn a new sintax because, after bgt, people usually learn python.
@25: Thank you for the support. You sead that angelscript is not hard to use, seriously? Have you tried to wrap it for .net or even jvm for that matter? I tryed it with swig and no success, so, unless you don't want to try for your self which I advise to try, you'll have to believe me when I say that's hard, if not impossible.
@24: sorry if I'm rood, but whatever you say, I'll still debelop it, but rest assured because your opinion was noted and I will try not to overwhelm the poor people using it.

How about bgt working on other platforms or why not o other systems? Like android will that be posible? How will you use iron python on android with mono and xamarin how will you make it accesible? On linux windows forms does not work in iron python with mono, and i do not know for exzample how android will react to it?

Version 0.01 private release:
Implemented the base skeleton for making it easy to add  new features in the future
Added a sound object to control an individual sound as well as a sound manager to store global aspects like the listener position, global volume, efects, etc
Added pastebin support for saving config files, practically for burdom
Trying to add twitter  support, but no good api documentation found
Added a dummy tts object because there is no cross-platform solution for mono as far as I know
Added a configuration file parsor as well as a pe file parsor
Added a simplified interface around pickle that allowes serializing entire objects, not only a dictionary like the old bgt does

This is a private release, so I would not provide a download link. I only provided that because I don't want you to think that I make such a fuss about the new bgt, new bgt here, new bgt there, and the development has stopped before it began.
This is the last oportunity to criticize the development flow of this product, so don't hesitate to post here. Any opinions?

I totally understand the point around not doing it: the advantages of python, the limitations of BGT, I really get and those are very fair points.

Despite that, I go with Liam and 26. There are people who would really like to have this New BGT (NGT?), I certainly would love to try it, and if you feel like doing this job, then we are truly grateful and look eagerly forward to check out the first public release. Good luck.

Angelscript? Gods above, not again, never again.
As I sead above, ironpython will be used as the script interpreter, though I found some bindings for lua with .net, what do you guys think about a future lua version of bgt?
To finish with angelscript once and for all, I would ask of those who use swig to run it on angelscript.h and post the c# wrapper that was generated for all to see, after that, if people still want angelscript in the ultimate game kit, then I will replace iron python with it.
One more reason for me using ironpythonn is  that iron python is managed code while angelscript and lua are unmanaged code, so I'd need to compile them on every platform mono and .net core would run on with no or allmost no modifications required to my codebase and, since I could not compile angelscript for windows without vs complaining about target incompatibilities and codeblocs about sintactical errors that aren't there, I am stuck with that.

I am not making a custom interpreter, I will not changing the python's sintax or anything, I only tailuring it to audiogames, like one may do with lua.
I don't make this into a python library because I know what problems people face when dealing with imports, dependencies and so on, so I decided to make it in a standalone package, including the interpreter and probably a kind of compiler in the future.
Can you clarify your post abit? What do you mean by saying a custom interpreter?

Would it be better embedding lua instead? Isn't it the same thing? Didn't the creator of bgt do the same thing with angelscript? Isn't pythonnet inferior to ironpython?

Honestly I'd much rather it be done with angelscript since the syntax makes a lot more sence at least to me, but I can work with python and I'll still check it out when it gets released. I'd still advise you try to stick with angelscript though purely because that way at least devs won't have to rewrite there games just to work with your system.

@43: Problems like installing the module and one or more dependencies might be missing and, boom, import errors and so on.
Another problem might be that, when trying to import a module from a file x.py writing from . import x, even if class y exists, python might give me attribute errors saying that the class y does not exist.
@42: I would use angelscript only when someone would post the swig generated .net output for all to see and then decide if they still want bgt with angelscript.
@41: Then why is the python interpreter only an executable that only calls functions from python37.dll to do all the heavy lifting like lua.exe does if python wasn't designed for embeding?

@44
The use of the from statement extensively is really discouraged because it could cause circular dependency in the long run.
And as long as you provide a requirements.txt file, unless the dependency in question has been removed you should not run in any issues.
Besides, when you install a package from pip, it usually collects it's dependencies too.
the AttributeError you're mentioning is not the interpreter's fault. You have to debug and find out what's going on.
I could then say that if you miss a dependency from a c# project the compiler will bitch about it.
If you even miss a reference to an assembly you'll go boom anyway. I'm sorry but I can't really take your point as valid. Of course the project is yours and you do whatever you want with it, but I've just given my point of view.

@47 the only problem I had with this application was that parser would raise an ImportError.
But the reason was quite simple. parser, is a builtin module, and it would conflict with the module the user created. Renaming the file was sufficent.