this will make migrating doom3-mods to OTE and testing our code with D3BFG harder.

I don't see any advantages.

but wasn't one of the points of the project to dedoomize the scripts? it's only renaming the script files to the new names, there is no problem in doing that isn't it?

why should we dedoomize anything?

the point of this project is not to become incompatible with d3bfg - that may happen, but only if avoiding it would be too painful or restrict us.

changing the name of files is not becoming incompatible, is just changing the names of files, you can still be compatible if you extract those files and change their names.

besides why keep the main script file as doom_main.script and not main.script, it makes more sense to call it main.script

speaking of which, is your position the same with the scripts and the definitions? do we need to do the scripts and the def so doom3BFG is compatible with them? or we are free to do d3BFG didn't do, even to the point of breaking compatibility?

the engine remains compatible any ways

not 100% sure on that.. on the one hand duplicating all the scripts and definitions from doom3 would be tedious and mostly useless for standalone games, so creating our own things as needed makes more sense - except for non-game specific standard entities like func_* trigger_* etc

on the other hand it would probably be nice if doom3 maps or "total conversion" like mods could migrate to OTE without too much pain.

we can always add functionality that d3bfg didn't have, maybe we can avoid reusing old names when changing interfaces/behavior of those definitions/scripts/...

it would suck if all knowledge (and tutorials) of how to map for and script for doom3 (and similar games like quake4) would be mostly useless for OTE because we changed names or behaviour of existing things.

oh, common! there is nothing we do in OTE that can break any tutorial.

so you propose do a OpenArena-like game? where the maps from doom3 could work in OTE?
this means recreating all the materials, all the textures, all the defs, all the scripts, all the GUIs, all the sounds, all the AF, all the skins, all... etc. and everything has to be open (wheter GPL like OpenArena, or WTFL-whatever)

this is a lot of work, why do it? and for what?

why not instead, make an engine where people can do their own game out of it, with some scripts some models that people can use in order to start a session, nothing ground-breaking just to see the player in a room? and be able to start form there to your own game.

if you wanna play doom3 maps get doom3, isn't it?

also there is a solution:

main.script:

#include "script/doom_main.script"

there, done
[oh, the irony] damn it was so hard to implement that! [/oh, the irony]

I'm not proposing to do that (and I certainly won't do it myself), but if someone wants to do that with OTE it shouldn't be more painful than necessary.

indeed IT ISN'T painfully as I already exposed in the last comment

I was referring to your question:

speaking of which, is your position the same with the scripts and the definitions? do we need to do the scripts and the def so doom3BFG is compatible with them? or we are free to do d3BFG didn't do, even to the point of breaking compatibility?

not to the renaming of these scripts.

renaming the scripts only causes little pain, but for no gain.

I see, if you don't have experience, getting the OTE engine as well as assets and having the main script file named doom_main.scripts makes understanding the scripting so quick, because that name makes so much sense.

Sorry to barge in on the conversation. I was playing around with Blenders Logic Bricks earlier, made a quick small Quake 1 styled fps in a few minutes. I read the logic bricks are hard coded in C++ for better performance over the python scripts. It has support for object and material based properties to affect sensors and rays. So integrating it may be faster way to create new code and prototyping.

@yetta1 the problem I see with this, is the translation of the code bricks into actual scripts, it is like creating a coding language, yes it is easy on the user side, but implementing it has to be a difficult thing, I think we should look into it on the future, any ways I wouldn't close the door to manual typing of the code, but having the two options.