Alright, I played it fool to not feel too harsh, but it start to be difficult... And it's a pity because the game look promising, well at least if you don't look behind it.
Code:
text_effect = renpy.curry( text_effect )
is absolutely
not a "duplicate object declaration".
Since more than 30 years, (almost) all the scripting languages store their data in a NAMESPACE, one by module/unit/whateverForThisLanguage. And since more than 20 years, (almost) all the scripting languages removed the obligation to prefix the names. This imply that (almost) all the modern scripting languages aren't "weak typed", they are completely type free. That's why, by example, the notion of variables don't exist in Python ; they call them "attributes", because it's what they are, an attribute of the module, whatever this attribute is a scalar value, a structure, a code, an object or even a module.
This is especially true with Ren'py since it recreate its own NAMESPACE to store the attributes declared in the game code (
You must be registered to see the links
). Every single attribute declared in a Ren'py code is nothing more than an attribute of the renpy.store object.
If you want to play, type "renpy = 1" on the console. You'll overwrite all the Ren'py engine. It will crash the game right after you stroke the enter key ; just run the game again, it don't touch the files, just what was in the memory of the running game.
So, no, it's not a "duplicate object declaration" error, it's a "just after the creation of my function I completely overwrote it, replacing it by a curried version of itself" error. It can happen to everyone to make this error, even people who code since half a century. But misnaming it, no, it don't happen.
With this, the number of fundamental errors made by your coder goes up to six :
1) Don't know the difference between calling a code and referencing it ; the difference is the same in (almost) all the scripting language created after the mid 90's.
2) Don't know that in modern scripting language, variables and code share the same NAMESPACE and so are, basically speaking, the same thing.
3) Don't read the part of the doc regarding the use of Python. The example for "
You must be registered to see the links
" clearly imply that a code will be addressed in the same way than a variable. Put in perspective with the "store" thing, recalled just above the part I linked, it's clear that "def test_effect([...])" and "test_effect = [...]" will concern the exact same thing.
4) When reading the doc (or more surely an example), don't understand what is wrote and try to improvise. Whatever he read the part regarding
You must be registered to see the links
or he found on the web an example of its use, the code, more than surely, clearly shown that you shouldn't use the "()". Thinking that "(file, speaker)" will mean "add these two parameters to the usual parameters", I really don't know when it can come from.
5) I'll stay gentle, and say nothing, but it regard this :
Code:
if event == "show_done":
pass
if file and _preferences.text_cps != 0:
6) Don't search in the doc, before searching on the web (if he searched on the web), if there's already a feature doing what he want to do. Whatever the true intent behind text_effect, the voicing feature will do the same.
And still he was able to wrote so many lines of code :/ Don't know, change your coder or let him some times to learn the basis of Python coding ? But do something before
@Darkaura's
You must be registered to see the links
become reality.
]
