[DeusExMachinaV42]

So many years ago (read: decades) now when the Build engine source for DN3D was released I spent some time getting Python to integrate with it - for which I had some success. In Python there was a straightforward model for integrating Python with C and I had a proof of concept using the function to show and scale sprites in the intro using Python rather than building into the C or via a CON file - for which no such thing to do this existed.

I recall at some point the JonoF modifications had Lua support but I have been unable to find any information on that. Since it seems that is abandoned and that the current EDuke source port is a combination of these things the question for me is - what exactly is the nature of such support if any?

The original idea was that you would have access to all the C functions via some Python mapping - including the CON functions - such that use of CONs/Python could be integrated as appropriate. The main advantage to using Python being that unlike the more adhoc specialised CON system there's a whole lot of stuff out there already done for Python that could be used - for example someone writing some AI thing for Python for general use versus somone writing CONs for it.

I've checked but so far I've found no solid information but I'd assume the people here would be familiar with:
1) What is there
2) Whether such as proposed would still be a relevant thing to attempt

Thanks.

[Kyanos]

You can build Eduke32 with lua for scripting, it's not in the default builds iirc and will probably need some restorative bug fixing after this much time not in use officially. Builds from 2014??ish would have it I think.

[DeusExMachinaV42]

I could certainly have a go at it if bits already exist - if it's not in general use that would imply there's basically nothing using it though?

[Hendricks266]

If you don't have extensive experience working with our codebase and modding for it then I'm afraid there is not much you can do to help. It is one thing to stab in language bindings. The hard thing is designing a proper, future-proof modding API. If all you do is let the user program in Python then now you have two problems, and the source port will have to forever support whatever slapped together API was introduced or else break all content that uses it. Client/server multiplayer at the very least needs to be robustly implemented before new APIs are considered. API design is a task which is independent of the language you choose and requires the experience I speak of.

To answer your question on languages, the JF ports never had Lua. It was an experimental EDuke32 feature set from a few years ago. Unfortunately the ultimate intent of that project was to rewrite the entire game logic in Lua, including the CON parser, which was a misguided idea incompatible with the real world use cases we've seen since then. The work done toward that is on the chopping block, but has not yet been removed because all of it is inactivated at compile time anyway unless you request it specifically. I am not opposed to maintaining simple Lua bindings as a fun curiosity. Ultimately I would like to see an AngelScript JIT as the blessed path forward. It should be part of the engine and not the Duke game so that it can be useful to all the Build games running on our technology.

[DeusExMachinaV42]

Hendricks266, on 30 December 2019 - 10:59 AM, said:

If you don't have extensive experience working with our codebase and modding for it then I'm afraid there is not much you can do to help.

That seems inherently defeatist for doing anything at all.

Quote

The hard thing is designing a proper, future-proof modding API. If all you do is let the user program in Python then now you have two problems, and the source port will have to forever support whatever slapped together API was introduced or else break all content that uses it.

I see no inherent reason for this to be the case. All I did in the past was simply put the main control flow through a bit of python so it could be organised from that point.

If there is nothing there to use then it's just the same existing control flow.

Quote

rewrite the entire game logic in Lua, including the CON parser, which was a misguided idea incompatible with the real world use cases we've seen since then.

My plan was not that. As far as con comptability really no reason to have to change anything there - just use the existing code if desired. A rewrite is on your shoulders if you want to do all that as a modern- not the maintainers who simply provide that option.

The simplest way to do this within a CON system extension off the top of my head (although as below that does imply being tied to Duke specifics). Given the sort of things subsequently introduced braced code blocks I would think an inlining code mechanism with the appropriate spec to get variables and set variables would be sufficient to have a useful piece of execution. Of course the way of getting/setting would make the most logical sense if the CON commands were all visible to any scripting language which you're going to want to have anyway.

Quote

Ultimately I would like to see an AngelScript JIT as the blessed path forward.

The specific technology desired is a "whatever" for me - I have no knowledge of AngleScript but I'm guessing another javascript variant. The main thrust is maximising flexibility.

Quote

It should be part of the engine and not the Duke game so that it can be useful to all the Build games running on our technology.

Exactly what I'm saying and frankly the most relevant part that given any base Build engine not requiring incompatible changes between games such an extension would be entirely reasonable given the primary purpose of being able to call the various functions in the Build engine's main loop that the combination of C and CONs achieves specifically elsewhere.

[DeusExMachinaV42]

Ok having checked what AngelScript is I can see why you would prefer it as a scripting language given its high integration with C code with minimal effort.