I have a dream!

[Tamamo]

Part of the prob;em with moving c++ code to angelscript is that it's an extra layer of abstraction to work with. Debugging is harder, changes and bidings take longer, and runtime speed is slower. At the end of the day nobody really wants to deal with any of those aspects of it. That's why all new features happen in alpha stage, because hey, sometimes you don't know you don't like something until you try it. .

Then why the hell are we doing it. Thats settle it then. We're going to have to convert the enemies and link back to cpp and implement angelscript Differently if we still which to do that. This should be fun. >_>

[ZoriaRPG]

I see we are going with the bicker plan after all. :/ [disclaimer: I am not a psychic, but I did stay at a Holiday Inn Express last night]

Part of the prob;em with moving c++ code to angelscript is that it's an extra layer of abstraction to work with. Debugging is harder, changes and bidings take longer, and runtime speed is slower. At the end of the day nobody really wants to deal with any of those aspects of it. That's why all new features happen in alpha stage, because hey, sometimes you don't know you don't like something until you try it.

@ZoriaRPG : If I didn't have good reason to believe ZScript was staying around for a while and we're still 2.5 backwards compatible etc., then I wouldn't even bother updating some script functions.

(Emphasis mine.)

That's yet another of my problems, and it toes into my qualms about solving it with a JIT compiler. Suffice to say, that we'd be trading off either performance, or platform-independence in the process. I don't particularly want to do either, but the time itself, that it'd take to go from 3.0 alpha, to something viable, may solve the performance issue, by pushing the 'typical' HW base that runs the programme toward something newer.

Then why the hell are we doing it. Thats settle it then. We're going to have to convert the enemies and link back to cpp and implement angelscript Differently if we still which to do that. This should be fun. >_>

I frankly think that if we follow through on our 2.future plans, it'll become easier to implement an alternative scripting engine, as what we propose will eventually turn everything important, into a variable that can be set by the user. If we can add user-defined enemy movement patterns, and some of the other goodies on our list, it might be a good stopgap between 2.5 and whatever a full rewrite--which, let's admit, is what the AS proposal is--is when completed, if completed.

If you want to do any enemy rewrites as cpp, we'll probably use them one way or another. We absolutely need to add a few attributes to the npc class though, including a flag for 'IsCore()', and some other basic values that are missing at present. I'm thinking of adding IsPointer() to every class object, to return the pointer ID of anything as an int, and of course, the ability to reference any object by its numeric pointer; but now I'm straying off topic.
@Dimentio is the member of our group that has interest in cleaning up the enemy code. I was going to work on the 'Talking NPC' ZC class, as requested, and I was thinking of doing some modifications to a few of the other enemy types, but it's really not part of the engine that draws my attention, or interest.