Preferred Scripting Language

If there are "quirks" aka bugs in the current scripts, they are going to have to be corrected anyway you look at it, if you change the language or not.

 

Am I correct in assuming that you're using Unity to implement a ToEE engine?


And why have you decided to recreate the engine?
What do you think it will provide that is impossible with the current one?
Do you think it will only be a theoretical possibility?

I'm asking this because from what I could see, the limitations from the current engine are that you're not allowed to import 3D models as you wanted to (it requires lot of hammer-fu) and you're bound to the implemented AD&D rules.
Co8 did amazing work in fixing bugs and adding new content, but it's not as if there is crazy amount of content as in Morrowind mods.

My point is, will the new engine really be used by the community?

 

Nope,

I am using Ogre as the graphics engine. The engine will be opensource, so Unity is out of the question.

Regards,
Storm

 

I am not talking about bugs per se, but rather quirks and workarounds used by current mods. Those won't work out of the box in a new engine.

 

There are still many bugs that are hard coded, and some things like even better AI, interface improvements, intelligent NPC looting, etc., require altering the code too.

E.g. here's a wishlist of mine that's only possible with modifying the source:

Correct game.area for maps.
Necklace of Adaptation to work right.
Figure out a way to pan the camera without using dialogue.
Forcing the AI to move to a certain X,Y coordinate without predetermined Way Points.
Reset Sorcerer / Bard used up spells.
Add feats via script.
Add levels via script.
More than 5 dialogue replies.
Fix bugbear strength bug.
Make scrolls fail if silenced.
Make scrolls take AOOs.
Read and manipulate factions via script.
Allow for ally factions in combat (your party + faction X vs. faction Y)
Better control of AI targetting.



Will the engine be used by the community? I think so. If you build it, they will come

And, I don't mind redoing the scripts in a "proper" manner, without hacky workarounds. I'd very much like that in fact. Some things you just can't do or can't do reliably with the current scripting without resorting to workarounds.
Although, I'm curious as to what you think won't work out of the box - anything specific in mind? I'm guessing mostly stuff that's related to the Co8 file system (persistent variables).

 

Yeah the writing of files using the Python standard API is my biggest concern. For one because the directory layout simply won't be the same ;-)

My personal wishlist:
- Prestige classes
- More feats
- More races
- Seamless Zooming (only ingame, not interface)
- MUCH better interface (one of my primary concerns with ToEE)
- More resilient save game mechanism (saved in JSON - text format)
- Allowing "normal" authoring tools to be used (All 3D Modelling Tools with an Ogre exporter, Particle FX Designer for Ogre).
- Better shadows
- More graphical effects (using the standard Ogre mechanisms for this). I want to experiment a bit with crazy compositing effects, i.e. warping the viewport with "heat waves" (don't know the proper english word) in the fire nodes for instance
- Possibility of better water effects (Again: Ogre with full shader and plugin support)
- Better sound (OpenAL, Ogre plugin)
- "Far out": Community features like "upload your character", cloud saves, directy upload screenshot, profiles, and other stuff. With full access to the .NET class library, this is rather easy to do.
- And the most important one: having fun

And those are just the ones I can think of right now ;-)

Once you got the source itself, the doors for improvement are wide open.

 

Give me examples. I compiled a new version of python (2.7.2) for bloodlines and the only thing i thought of like that (a extreme workaround) was that the integration with the engine wasn't well done at the time - the pointers exposed to python code couldn't take arguments, so modders elaborated a rather costly IO workaround (they wrote to a file and then executed the file on a valve command to call valve console commands with arguments).

I worked around it now by adding a new function in my replacement that simply calls the console with the command by string - the problem wasn't in the game engine, but the old python version pointers not taking arguments - if there are new versions of the mods i guess they can use this (if wesp accepts the altered dll).

 

How about Co8 mods writing their own files into the savegame directory to persist additional state? The new engine's savegame directory will be somewhere else, thus breaking that functionality.

Regards,
Storm

 

Why would you want to make things harder for yourself for no real reason (change write directories)?

It's some retarded vista thing isn't it? I use wine.

Anyway, as always the solution for problems like this in informatics is abstraction. In the original games use a variable that points to the normal save dir.

In your new engine, use one that points to your appdefaults thing.

Use that variable in the scripts.

 

You do realize that in a rewrite, i don't "change" the write directory, i define it. But I guess those are semantics.

And using variables to store configuration properties is not abstraction from a system design standpoint, but again, that's irrelevant for this discussion.

But you make me wonder: Are you actually invested in scripting for ToEE, or why are you so interested in the scripting language?

 

Whatever. Do what you want.

 

For me the question is, are there things you can do with C# that you absolutely cannot do in javascript?

It seems like, for something the community would use to generate more content, the easier the better, but there may be some inherent limitations in javascript (something I'm not real familiar with) that create tanglible drawbacks.

Do you have any examples of what could be done in C# that can't in javascript?

 

Hey dear i just want top say that do what's easier for everyone. Now it's up to you.

 

Well that depends... From a solution standpoint, you can pretty much solve the problems at hand in both languages.

There's a tradeoff here. JavaScript has a lower barrier to entry in my opinion, but C# is more suited to more complex tasks. I would also say that while JavaScript knows no types, the static typing of C# will eliminate a lot of trial+error in scripting since the compiler will already detect a lot of common errors that in JavaScript you would have to find by running the script first.

 

I don't know very well how python scripts works with Toee. But if i've understand the question of this thread my suggestion, even if it should be the more complex choice, is to provide multiple scripting language support. I mean that you can start to provide only c# as first scripting language but at the end the communication between Engine and Script should be managed by some wrapper, or similar, that doesn't care about which scripting language we are using for our current mod.

It's an idea similar to Unity3d ( Where we can use C#, Javascript and Boo to script ). Maybe you can drop the possibility of using more than one script for each mod.

So in future with this implementation if i want to use in my new mod my preferred scripting language ( i.e. Lua ) someone else ( or directly me ) could provide an extension for it...

Sorry for the bad english....