Doomsday & new ACS

I want to know whether it was possible to make the doomsday understand the new ACS?
Ie to work that something like this:

script 1 (void)
{
int var0;
int var1;
for( var0 = 0; var0 < 5; var0++ )
{
var1 = ThingCount(4,5);
if(var1 != 0)
{
var0 = var0 - 1;
delay(35);
}
}
Thing_Activate(6);
}

script 2 (void)
{
int var0;
int var1;
for( var0 = 0; var0 < 5; var0++ )
{
var1 = ThingCount(0,6);
if(var1 != 0)
{
var0 = var 0 - 1;
delay(35);
}
}
Teleport_NewMap(2,0);
}

It is a classical example of Russian aggression and invading!!!

Hecktor -> i iddqd ru

entryway said:

It is a classical example of Russian aggression and invading!!!

It is not agression and invading...

If you know some English, please use it, because it's the language used in these forums. If you don't, at least try using some sort of translator to help you out. Use the edit feature to change your text here.

If you browse around you'll see there aren't posts in other languages (other than a handful of non-serious ones in a few threads).

I changed the first post, using a translator google.
I do not know how it all translated correctly.

Yeah, I think that'll work (the question seems clear enough), thanks.

It looks like all the same translator is not correctly translated my question.
The scripts that I overlaid, only work with the new ACS. Doomsday does not agree with them. Mainly because of this line: var1 = ThingCount (0,6);
He did not understand what it means zero.
Who knows how to rewrite the program Doomsday, that everything worked as gzdoom or zdoom?

The scripts I write myself. But to reprogramme the port, I do not have sufficient knowledge. Maybe someone knows how to do it?

jHexen does not understand any of the "new ACS" stuff that has been added in ports like ZDoom. That includes new constructs, value types and routines. jHexen expects a BEHAVIOR lump to be in the exact same format as expected by the original Hexen.exe.

For the foreseeable future this is a situation that is very unlikely to change. We feel that a much better direction for project is to leapfrog ACS entirely, rather than extend it.

DaniJ said:

For the foreseeable future this is a situation that is very unlikely to change. We feel that a much better direction for project is to leapfrog ACS entirely, rather than extend it.

:o Do you have any specific plans in mind for scripting, or is this a long ways off and not really concrete yet?

DaniJ said:

For the foreseeable future this is a situation that is very unlikely to change. We feel that a much better direction for project is to leapfrog ACS entirely, rather than extend it.

Would it be possible to establish a scripts without ACS?

I imagine DoomsdayScript will happen before ZDoomScript. :P

esselfortium said:

:o Do you have any specific plans in mind for scripting, or is this a long ways off and not really concrete yet?

Over the past few years skyjake has been working off and on, on an entirely new engine core that integrates all forms of script that are currently used within the engine itself and all supported games. Not only will it allow externalizing the game logic into scripts but even core engine functionality will be scriptable.

skyjake said of the scriptable core in August 2006:

Fully scriptable:
All objects in the game world, starting with hubs and maps, are accessible via the console. The scripting language is simple, yet powerful: it's purpose is to be an efficient way to implement customizations and map scripts without the need to modify the source.

Things like menus (both the game's and the engine's) are set up using scripts. Only things that are difficult to script, or need to be highly efficient, are compiled into the game module. As a rule, it should be possible to do just about everything using scripts, from defining new mobj types to modifying the environment settings in sectors with a specific tag.

In short, the scripts should combine the functionality of ACS, DED, XG and InFine, plus menu config/control and access to low-level engine subsystems such as event processing, audio and the file system (which combines data lumps and real files into one virtual filesystem, where the actual data may be remote, in a data file or in an actual file somewhere under the Doomsday root directory).

Last I heard the majority of the mechanisms required for such a system are complete (including virtual threading with integral debugger) and that work had begun on the various subsystem interfaces.

Originally this work was intended for the Hawthorn project (Doomsday 2.0). However in light of the advances seen in the current Doomsday architecture as we head towards the proposed 1.9.0 design, it is now likely that it will be integrated with Doomsday. We have no fixed time-frame for when this is likely to happen but certainly not until after the full 1.9.0 release.

For those interested, the original Hawthorn road map document can be found here:
http://deng.svn.sourceforge.net/viewvc/deng/trunk/attic/de2/milestones.txt?revision=3523&view=markup

Hecktor said:

Would it be possible to establish a scripts without ACS?

Currently ACS is the only means to access such functionality in jHexen.