Zandronum possibly changing engines

[Watermelon]

Zandronum will probably not be doing this anytime soon, but I'd like to see some varying discussion on this if anyone has thoughts on such a possibility.
Currently the three online doom ports we know of are Odamex, ZDaemon and Zandronum. They are all to my knowledge based off of ZDoom at one point or another.

• Odamex is based off of:

  The ZDoom 1.22 core engine, as well as the ZDoom 1.23 beta33 ACS interpretor.

  Source: http://odamex.net/wiki/Odamex

• ZDaemon is based off of:

  ZDaemon is a network port based on the ZDoom 1.23 release.

  Source: http://zdoom.org/wiki/ZDaemon

• Zandronum is based off of:

  ...is based on ZDoom 2.3.1 revision 1551 and GZDoom revision 127/323.

For anyone in the development scene who is familiar with the tracker will find that there are always requests that end up being "please request on the ZDoom forum" and then if done will get backported. This is a good idea in theory, however the amount of updates that come to zdoom are very far and few between, of which most of the suggestions get No'd for whatever reason. Some of them would be really useful in moving forward of our port, like more parameters for scripts, better String support...etc.

Unfortunately at this point, it feels like we are just getting 'hacky' fixes to solutions without addressing the problems. There is nothing wrong with this really in my opinion because the end product works... though I feel that one day it will end up becoming a problem if the port itself continues to move forward. So far it seems like (based on my discussion with other developers in this community) that zdoom itself is becoming more or less a clusterfuck of things to manage, making addition of features very difficult. If you want to customize something, at this point there is a lot of things you can do, but there are some underlying areas that developers do not have access to. Of course, there is good reason because it'd be very easy for a person to break a wad by simple mistakes, though this can happen anyways if you loop a 0 tic state.


Possible benefits
If a port was to be made from the ground up, there could be exposure of all the internal components. For example, what if you want to access actor pointers (like what tid is being pointed at as a master, or an enemy...etc)? You can manipulate that in zdoom, but the developers have to add a whole new function and create an array of constants for people to use. If you could directly modify the object itself with a scripting language, any new features would become immediately available. As a developer, I like to be able to control intricate parts of the playing experience, of which at this point I cannot really do anything with.
How about checking a list of entities? With a proper scripting language, you could possibly enumerate the entire list of in game actors, and then go through them one by one checking for certain properties. As of now, it is only possible to check pre-defined TID's of monsters or actors. This hurts games like zdoomwars where if you want to iterate through a group of monsters for whatever reason, you will need a loop that checks each and every single number from 1 to whatever (which could be thousands high with how the game gets, or maybe even more in co-op mods which employ ridiculous amounts of monsters). Something like that can only be accomplished by tagging everything and mass reading every actor. While this can work... it becomes a drain on the machine that is using it. For those who develop games in ACS will one time or another run into the "Runaway script" termination legitimately. Little problems like these come up that hinder us from moving forward. We could always do what ZDaemon did and increase the runaway limit to 2 million instructions, though it doesn't solve the underlying problem.


Without droning on, there are other examples (you can probably think of some you would run into if you were to create a dream wad). A new engine could support the classic mode, but also bring in a true 3D element.
There are other ports that have done this I think (like Doomsday), but the biggest problem is that zdoom wads are not compatible with doomsday, and therefore the port is stuck with running mainly vanilla wads. Unfortunately the doom community is too small for it to gain a strong hold on developing an abstract port that would allow some of the ideas proposed above. This also leads us to "are we too far down the rabbit hole?" where we reach a point that it would be too much work to have a zdoom -> new port converter? At this point, for anyone to create a successful competitive port that would allow more access pretty much would require a method of converting wads created with zdoom and gzdoom to run under the new system. With vanilla wads, that is easy; with all the new ACS/Action specials/Action functions/what have you, it is not so easy.




The major problem with such an idea happening is that it would require a multitude of people, of which I doubt doom has. It'd be nice to have a competant openGL developer doing something (because Graf Zahl is a walking bundle of 'no too much work you're dumb for asking'), but without turning this into a huge list of items, it'd be interesting to see where the staff, developers and/or community would stand with such a project.

I understand this is not even remotely feasible at this point in time, but it's more of a theoretical 'what if' question.

[Llewellyn]

I'm not going to get into particulars right now but I've been really mad lately with the "hand holding" in modding. Modders should know what is going to break and what isn't going to break if you do something wrong, I don't want some error saying "You can't do X", LET ME DO X then I'll find out if there's a problem.

Example I had recently was me wanting to edit the base Inventory class that Zandronum.pk3 loads with, but I can't redefine a "native" class.

[ibm5155]

About the true 3D it could only be used on a new kind of format of map, just like udmf,hexen format,... the only "problem" is zdoom/gzdoom woudn´t be able to run it and maybe the software render would be adapted to support it...

I know a little of C language, but i don´t think it would help in something =/

About the opengl, i know it´s not the best idea but what about take somethings from others opengl renders that allow to do that things?

edit:It´s not everyone that would use all the power of the new engine, but look if people like wad´a´holic could do with the opengl render, With a true 3D engine much more people could do the same thing with much less work...

The problem that I see on the actual engine is it limit many ideas that you must use polyobjects/3D floors to do something similar, and it cost alot of performance, just look the akzos city from revilution, it´s a huge well done city, but because of the engine you MUST need a nasa computer to be playable on software and opengl render.

[Blzut3]

Insert elaborate post that basically boils down to: I want ZScript.

A few things to mention. First of all, ZDoom is not a "clusterfuck." Yes there is a lot of code, but for what it does, it is quite easy to manage. Heck you can separate a lot of it into another engine (shameless plug) if you wanted to. The hacks in ZDoom come down to supporting old mods (for vanilla or old versions of ZDoom), not the features themselves. Rewriting anything from scratch really isn't going to give any benefit in the short term or the long term. It is certainly not difficult to add features to ZDoom.

What you want is the ZScript we've been waiting for for years.

I'm not going to get into particulars right now but I've been really mad lately with the "hand holding" in modding. Modders should know what is going to break and what isn't going to break if you do something wrong, I don't want some error saying "You can't do X", LET ME DO X then I'll find out if there's a problem.

Example I had recently was me wanting to edit the base Inventory class that Zandronum.pk3 loads with, but I can't redefine a "native" class.

You can't redefine a native class since it's backed with C++ code, which you obviously can't have in a mod. Also, if we allowed mod authors to decide if something is broken or not, we wouldn't be able to do backwards compatibility.

[Watermelon]

Insert elaborate post that basically boils down to: I want ZScript.

A few things to mention. First of all, ZDoom is not a "clusterfuck." Yes there is a lot of code, but for what it does, it is quite easy to manage. Heck you can separate a lot of it into another engine (shameless plug) if you wanted to. The hacks in ZDoom come down to supporting old mods (for vanilla or old versions of ZDoom), not the features themselves. Rewriting anything from scratch really isn't going to give any benefit in the short term or the long term. It is certainly not difficult to add features to ZDoom.

What you want is the ZScript we've been waiting for for years.

What is ZScript?

If it's easy to add stuff, why do the developers always no many things (like for example, extending the number of args (or parameters, crap whats the appropriate term again?) for a script from 5 to a lot more.
It'd also be so awesome to access each actor as an object.

[Qent]

If it's easy to add stuff, why do the developers always no many things

I'm no dev, but it seems to me that if they didn't, then it really would become a "clusterfuck of things to manage." Remember backwards compatibility? That means that, for every crazy thing you and a hundred other modders convince them to add, they commit to support it forever.

args (or parameters, crap whats the appropriate term again?)

script 123 (int x) { return x; }
ACS_Execute(123, 0, 5, 0, 0);

x is the parameter. 5 is the argument. https://en.wikipedia.org/wiki/Parameter ... _arguments

BTW, why do you need more parameters?

[Spleen]

Insert elaborate post that basically boils down to: I want ZScript.

A few things to mention. First of all, ZDoom is not a "clusterfuck." Yes there is a lot of code, but for what it does, it is quite easy to manage. Heck you can separate a lot of it into another engine (shameless plug) if you wanted to. The hacks in ZDoom come down to supporting old mods (for vanilla or old versions of ZDoom), not the features themselves. Rewriting anything from scratch really isn't going to give any benefit in the short term or the long term. It is certainly not difficult to add features to ZDoom.

Last time I looked at the codebase, it was difficult to turn into a client-server architecture without changing the code in a lot of places. This is really the biggest thing that bothers me about the way ZDoom is coded.

I think the biggest code quality improvement they could make would be to refactor to improve this kind of flexibility. Basically, change the ZDoom code structure so that changing it into a client-server architecture requires minimal code changes, without actually turning ZDoom into a client-server engine.

I'm not very familiar with the way Quake and later idtech engines are coded, but wasn't that one of their advantages compared to the Doom engine?

But I realize that this is an unrealistically large amount of work for anyone to take on, so I don't have any hope at this point.

[Llewellyn]

You can't redefine a native class since it's backed with C++ code, which you obviously can't have in a mod. Also, if we allowed mod authors to decide if something is broken or not, we wouldn't be able to do backwards compatibility.

I'm aware that if I redefined a native actor, the C++ backed code could change in future revisions, but at this point I honestly didn't care since changing the code actually works.

The code in question here was the native Inventory actor, from the Zandronum.pk3:

Code: Select all

ACTOR Inventory native
{
	Inventory.Amount 1
	Inventory.MaxAmount 1
	Inventory.UseSound "misc/invuse"
	Inventory.PickupSound "misc/i_pkup"
	
	action native A_JumpIfNoAmmo(state label);
	action native A_CustomPunch(int damage, bool norandom = false, bool useammo = true, class<Actor> pufftype = "BulletPuff", float range = 0);
	action native A_FireBullets(float spread_xy, float spread_z, int numbullets, int damageperbullet, class<Actor> pufftype = "BulletPuff", bool useammo = true, float range = 0);
	action native A_FireCustomMissile(class<Actor> missiletype, float angle = 0, bool useammo = true, int spawnofs_xy = 0, float spawnheight = 0, bool aimatangle = false, float pitch = 0);
	action native A_RailAttack(int damage, int spawnofs_xy = 0, int useammo = true, color color1 = "", color color2 = "", bool silent = false, float maxdiff = 0, class<Actor> pufftype = "BulletPuff");
	action native A_Light(int extralight);
	action native A_Light0();
	action native A_Light1();
	action native A_Light2();
	action native A_LightInverse();
	action native A_WeaponReady(int flags = 0);
	action native A_Lower();
	action native A_Raise();
	action native A_FirePistol();
	action native A_FireShotgun();
	action native A_FireShotgun2();
	action native A_OpenShotgun2();
	action native A_LoadShotgun2();
	action native A_CloseShotgun2();
	action native A_FireCGun();
	action native A_FireSTGrenade(class<Actor> grenadetype = "Grenade");
	action native A_FireMissile();
	action native A_FirePlasma();
	action native A_FireRailgun();
	action native A_FireRailgunLeft();
	action native A_FireRailgunRight();
	action native A_RailWait();
	action native A_BFGsound();
	action native A_FireBFG();
	action native A_ReFire();
	action native A_ClearReFire();
	action native A_CheckReload();
	action native A_GunFlash();
	action native A_Saw(sound fullsound = "weapons/sawfull", sound hitsound = "weapons/sawhit", int damage = 2, class<Actor> pufftype = "BulletPuff");
	action native A_CheckForReload(int counter, state label, bool dontincrement = false);
	action native A_ResetReloadCounter();
	action native A_RestoreSpecialPosition();
	action native A_RestoreSpecialDoomThing();
	action native A_RestoreSpecialThing1();
	action native A_RestoreSpecialThing2();
	
	// [BB] Skulltag specific code pointers
	action native A_CheckRailReload();

	States
	{
	HideDoomish:
		TNT1 A 1050
		TNT1 A 0 A_RestoreSpecialPosition
		TNT1 A 1 A_RestoreSpecialDoomThing
		Stop
	HideSpecial:
		ACLO E 1400
		ACLO A 0 A_RestoreSpecialPosition
		ACLO A 4 A_RestoreSpecialThing1
		ACLO BABCBCDC 4
		ACLO D 4 A_RestoreSpecialThing2
		Stop
	Held:
		TNT1 A -1
		Stop
	HoldAndDestroy:
		TNT1 A 1
		Stop
	// [BC] Hide this item until told to return.
	HideIndefinitely:
		TNT1 A 1050
		Loop
	}
}

to

Code: Select all

ACTOR Inventory native
{
	Inventory.Amount 1
	Inventory.MaxAmount 1
	Inventory.UseSound "misc/invuse"
	Inventory.PickupSound "misc/i_pkup"
	
	action native A_JumpIfNoAmmo(state label);
	action native A_CustomPunch(int damage, bool norandom = false, bool useammo = true, class<Actor> pufftype = "BulletPuff", float range = 0);
	action native A_FireBullets(float spread_xy, float spread_z, int numbullets, int damageperbullet, class<Actor> pufftype = "BulletPuff", bool useammo = true, float range = 0);
	action native A_FireCustomMissile(class<Actor> missiletype, float angle = 0, bool useammo = true, int spawnofs_xy = 0, float spawnheight = 0, bool aimatangle = false, float pitch = 0);
	action native A_RailAttack(int damage, int spawnofs_xy = 0, int useammo = true, color color1 = "", color color2 = "", bool silent = false, float maxdiff = 0, class<Actor> pufftype = "BulletPuff");
	action native A_Light(int extralight);
	action native A_Light0();
	action native A_Light1();
	action native A_Light2();
	action native A_LightInverse();
	action native A_WeaponReady(int flags = 0);
	action native A_Lower();
	action native A_Raise();
	action native A_FirePistol();
	action native A_FireShotgun();
	action native A_FireShotgun2();
	action native A_OpenShotgun2();
	action native A_LoadShotgun2();
	action native A_CloseShotgun2();
	action native A_FireCGun();
	action native A_FireSTGrenade(class<Actor> grenadetype = "Grenade");
	action native A_FireMissile();
	action native A_FirePlasma();
	action native A_FireRailgun();
	action native A_FireRailgunLeft();
	action native A_FireRailgunRight();
	action native A_RailWait();
	action native A_BFGsound();
	action native A_FireBFG();
	action native A_ReFire();
	action native A_ClearReFire();
	action native A_CheckReload();
	action native A_GunFlash();
	action native A_Saw(sound fullsound = "weapons/sawfull", sound hitsound = "weapons/sawhit", int damage = 2, class<Actor> pufftype = "BulletPuff");
	action native A_CheckForReload(int counter, state label, bool dontincrement = false);
	action native A_ResetReloadCounter();
	action native A_RestoreSpecialPosition();
	action native A_RestoreSpecialDoomThing();
	action native A_RestoreSpecialThing1();
	action native A_RestoreSpecialThing2();
	
	// [BB] Skulltag specific code pointers
	action native A_CheckRailReload();

	States
	{
	HideDoomish:
		TNT1 A 1050
		TNT1 A 0 A_JumpIf(ACS_ExecuteWithResult(899), "StopState")
		TNT1 A 0 A_RestoreSpecialPosition
		TNT1 A 1 A_RestoreSpecialDoomThing
		Stop
	StopState:
		TNT1 A -1
		Stop
	HideSpecial:
		ACLO E 1400
		ACLO A 0 A_RestoreSpecialPosition
		ACLO A 4 A_RestoreSpecialThing1
		ACLO BABCBCDC 4
		ACLO D 4 A_RestoreSpecialThing2
		Stop
	Held:
		TNT1 A -1
		Stop
	HoldAndDestroy:
		TNT1 A 1
		Stop
	// [BC] Hide this item until told to return.
	HideIndefinitely:
		TNT1 A 1050
		Loop
	}
}

Point being that, barring future compatibility, this code change would work, would allow me to change every inheriting actor, and would allow comparability with every mod ever.
Currently I cannot modify this actor and then allow other actors to inherit from my modification without redefining actors, which would mean I would have to redefine every actor in every mod or IWAD ever that used "Inventory"

[Watermelon]

If it's easy to add stuff, why do the developers always no many things

I'm no dev, but it seems to me that if they didn't, then it really would become a "clusterfuck of things to manage." Remember backwards compatibility? That means that, for every crazy thing you and a hundred other modders convince them to add, they commit to support it forever.

args (or parameters, crap whats the appropriate term again?)

script 123 (int x) { return x; }
ACS_Execute(123, 0, 5, 0, 0);

x is the parameter. 5 is the argument. https://en.wikipedia.org/wiki/Parameter ... _arguments

BTW, why do you need more parameters?

If I could pass an array as a parameter I would never ask for anything more :D

[Synert]

BTW, why do you need more parameters?

I'm pretty sure ijon can give you a lot of examples of times he's needed more.

[Qent]

Well yeah ijon, but I was asking why Watermelon needs more.

[Watermelon]

Well yeah ijon, but I was asking why Watermelon needs more.

My biggest complaint is when I want to pass server -> specific player clientside stuff


Lets say I want to transfer 32 numbers to Player 2 only, I have to do the following

Code: Select all

script 1 (int playerNum) 
{
    for (int i = 0; i < 32; i++) {
        ACS_ExecuteAlways(2, 0, playerNum, placeToStore, dataValue[i]);
    }
}

Script 2 (int playerNum, int placeToStore, int data) CLIENTSIDE
{
    if (getPlayerNumber != playerNum)
        terminate; // Don't modify a players number if we don't want to target them, since 63/64 possible players all receive this script

    switch (placeToStore) {
        case STORE_ARRAY_ONE:
              myVariable = data;
              break;
        case STORE_ARRAY_TWO:
              mySecondVariable = data;
              break;
        // etc
    }
}

Since I'm stuck with three parameters, I can't load them into an array without adding the index into the number if I'm able to, so I'm limited to specifying everything with a case statement. It'd be so nice for example to have infinite arguments and just pass them all in one function to prevent the server from sending 64+ packets (which can get really costly bandwidth wise if you use the functions a lot)

If I could do

Code: Select all

ACS_ExecuteAlways(script, 0, playerNumber, 1, 2, 3, 4, 5, 6 ...);

Then I could effective do everything in one packet. The packet itself will be 4 bytes * number of integers I assume.
Since packets require a header, the more packets we send... the more space is required. I figure it'd be like sending everything in one box instead of 100 small boxes and wasting cardboard space.
In addition, since zandronum uses reliable UDP there will need to be MUCH more communication that it received all the ACS commands, whereas with just one big packet the client needs to only say "yeah I just got the single packet" instead of flooding 64+ confirmations to the server. Furthermore we don't have to worry about order it is received since it will be in one nice line, if you ever puke yourself 64 acs things from number 0 to 64, you will find that you get random order at times since UDP packets arrive whenever they want and not in order. This means that with one script I wrote, I had to have a termination sequence and check to make sure there weren't any empty numbers sent... which in turn requires the processor to constantly iterate over the incoming data to see that every packet has arrived properly, adding more commands to be done on the server and/or client.

I may have stuff wrong in there, if so can someone correct me but that is what I was led to believe through asking various dev's.

[Torr Samaho]

Then I could effective do everything in one packet. The packet itself will be 4 bytes * number of integers I assume.
Since packets require a header, the more packets we send... the more space is required. I figure it'd be like sending everything in one box instead of 100 small boxes and wasting cardboard space.
In addition, since zandronum uses reliable UDP there will need to be MUCH more communication that it received all the ACS commands, whereas with just one big packet the client needs to only say "yeah I just got the single packet" instead of flooding 64+ confirmations to the server.

Zandronum automatically collects as many network commands in a single UDP packet as possibly before sending them. So you don't need to worry about flooding the clients with packets this way. In your analogy Zandronum is packaging the 100 small boxes into a big box before sending them. This makes the outer big box a bit bigger than necessary, but it's still only one box (unless you have some many small boxes that you need more than one big box).

Furthermore we don't have to worry about order it is received since it will be in one nice line, if you ever puke yourself 64 acs things from number 0 to 64, you will find that you get random order at times since UDP packets arrive whenever they want and not in order.

You also don't need to worry about this. Clients process packets in order. If a packet is lost, the clients re-requests the lost packet and will not process the following packets till the missing one arrived.

[Watermelon]

Then I could effective do everything in one packet. The packet itself will be 4 bytes * number of integers I assume.
Since packets require a header, the more packets we send... the more space is required. I figure it'd be like sending everything in one box instead of 100 small boxes and wasting cardboard space.
In addition, since zandronum uses reliable UDP there will need to be MUCH more communication that it received all the ACS commands, whereas with just one big packet the client needs to only say "yeah I just got the single packet" instead of flooding 64+ confirmations to the server.

Zandronum automatically collects as many network commands in a single UDP packet as possibly before sending them. So you don't need to worry about flooding the clients with packets this way. In your analogy Zandronum is packaging the 100 small boxes into a big box before sending them. This makes the outer big box a bit bigger than necessary, but it's still only one box (unless you have some many small boxes that you need more than one big box).

Furthermore we don't have to worry about order it is received since it will be in one nice line, if you ever puke yourself 64 acs things from number 0 to 64, you will find that you get random order at times since UDP packets arrive whenever they want and not in order.

You also don't need to worry about this. Clients process packets in order. If a packet is lost, the clients re-requests the lost packet and will not process the following packets till the missing one arrived.

Damn thats nice in that case

Does the same go from client -> server? Like if clients pukes a script with an increasing first argument value like 1, 2, 3... should they also arrive in the same order or is it only server -> client that ensures it arrives in the proper order?

I made a string sender at one time where it chops it up into ascii characters and sends it character by character, I noticed on the receiving end that they came in a bit scrambled and it resulted in myself having to create a buffer to wait until its full before proceeding. Therefore I don't know if this is intended (since it was an array of pukes from client -> server), or if it's supposed to work both ways... and if its supposed to work both ways should I consider trying to reproduce what I had and if it occurs again, report on the tracker?

[Torr Samaho]

Does the same go from client -> server? Like if clients pukes a script with an increasing first argument value like 1, 2, 3... should they also arrive in the same order or is it only server -> client that ensures it arrives in the proper order?

No, the packet loss handling is only for the server -> client communication. Lost "client -> server" packets are not resend and they are also not necessarily parsed in order. The system assumes that it's not worth to resend "client -> server" packets since they are mostly movement commands that are obsolete by the time it would take to resend them. The ACS communication didn't exist when this was designed...

[ibm5155]

It would be nice to see some quake 2 lights kind in software mode, I don´t know if it´s pocible to adapt but it´s there, and would make some mods almost 100% playable on software and opengl(ex: who dun it that almost have 0 light in some parts, but use alot of dynamic lights...)
someday I´ll look how they did the lights for software and compare to the dynamic lights to see if it´s pocible to do some hacky there ^^(I´ll not do it, unless I see it´s a really easy thing todo)

[Blzut3]

someday I´ll look how they did the lights for software and compare to the dynamic lights to see if it´s pocible to do some hacky there ^^(I´ll not do it, unless I see it´s a really easy thing todo)

They did it by designing the renderer from the ground up to do dynamic lighting. There is not one single way to do software rendering, nor is there a single way to do hardware rendering. So licensing issues aside, this is why you can't just port features from one renderer into another.

To make things more clear here. It is possible to run OpenGL in software (at like 1fps, but possible), but you wouldn't expect to take dynamic light code from that and run it in Doom's software renderer.

[Ivan]

A bit off topic but, I find the title of this thread a bit misleading. It gives the impression that you are trying to spread a rumor.

[ibm5155]

3D floos to software render was impocible too, but I don´t have all the know to create a single light...
I think the huge problem in doom is the doom itself, it´s a great game, but it´s a hardware eater for open areas and the mapping is too limited...
What could be done is to use a new kind of map format, a true 3D map, you wouldn´t be limited to 3D floors/sloopes anymore, even trying to simulate many effects like HDR,...

I don´t know how it would work, like suporting two different kind of maps, if it would require another render,...

But for me the only problem at the engine is id tech 1 itself.

[Ænima]

So then play another game?