Zandronum

This topic is for open discussions in regards to the Zandronum Wiki. Such discussions can be anything from general site feedback, suggestions, using the wiki, etc.

Address to the Wiki: http://wiki.zandronum.com/

add all the new acs functions and decorate stuff thats zandronum/st only!

Catastrophe wrote: add all the new acs functions and decorate stuff thats zandronum/st only!

If you noticed, I already added all the ACS ones like a week ago.
Also, since the change on the website, EVERY PAGE has this ridiculous "Retrieved from" link now...

Should put that section under Level Development or a new section called "Modding" or something.

Ivan wrote: Should put that section under Level Development or a new section called "Modding" or something.

I mentioned this on the Main talk page, I agree, the ACS and DECORATE functions really have nothing to do with "Level Development" per se.

Llewellyn wrote:

Ivan wrote: Should put that section under Level Development or a new section called "Modding" or something.

I mentioned this on the Main talk page, I agree, the ACS and DECORATE functions really have nothing to do with "Level Development" per se.

I do have in mind on updating the Somnium table, though - it is going to take some time before I start any changes. Thus, for the time being, do you have any suggestions that can be expeditiously done right now? Some options could be to create a horizontal table (adjacent to Support) and bring all of the 'modding' structures to the front of the table, or another option could be to completely reorganize the 'Level Development' section along with renaming it. Any thoughts or suggestions?

Tiger wrote: I do have in mind on updating the Somnium table, though - it is going to take some time before I start any changes. Thus, for the time being, do you have any suggestions that can be expeditiously done right now? Some options could be to create a horizontal table (adjacent to Support) and bring all of the 'modding' structures to the front of the table, or another option could be to completely reorganize the 'Level Development' section along with renaming it. Any thoughts or suggestions?

My suggestion would be to rename Level Development to Modding, Make the categories under it: Special Lumps, ACS Functions, Decorate, Level Development, ZDoom Wiki

Then, an article called "Level Development" should be created that has links to internal and external refrences on the wiki about Level Editors, Creating a map, Etc.
I'll get around to making the Decorate article soon.

How about doing what Llewellyn suggests, but renaming the Level Development category to Level Development and Modding instead of just Modding? This would avoid confusing somebody who is used to seeing a Level Development category and then wondering why it "vanished", not realizing that it is still there and has been renamed.

The Wiki also need updated information on server administration, especially regarding how some of the RCON commands are supposed to work and Zandronum's command line parameters.

Camo Yoshi wrote: The Wiki also need updated information on server administration, especially regarding how some of the RCON commands are supposed to work and Zandronum's command line parameters.

From the front page:
Command Line Parameters
Console Commands
It has the RCON command, and it specifies that you need to use SEND_PASSWORD
Console Variables

Tiger wrote: This topic is for open discussions in regards to the Zandronum Wiki. Such discussions can be anything from general site feedback, suggestions, using the wiki, etc.

It would be very helpful if we had a volunteer who regularly collects the bits of information about Zandronum's inner workings that I post on the forum and the tracker when technical questions pop up and adds them to the wiki.

I was thinking of going through every single ACS function documented on ZDoomWiki and their Skulltag Features and making a list of what works clientside and what doesn't.

Watermelon wrote: I was thinking of going through every single ACS function documented on ZDoomWiki and their Skulltag Features and making a list of what works clientside and what doesn't.

Most of that can be deduced by logic, without real testing. If you know what the client knows, and you know what the client can modify, then you know which functions will and will not work. Some things are a little less obvious, however there may be work-arounds to problems like that in actual code management.
But I do believe a whole page should be dedicated to ClientSide ACS scripting. For example, Clientside scripts cannot access MAP or GLOBAL variables because they are stored serverside and and not sent to the clients, and vice versa. This is something that would be documented on such a page.
PS. The Zandronum Wiki should now contain everything in the Skulltag Features section (and more) of the ZDoom Wiki.

I thought any variable type (excluding local scope) is separate from client and server, is that not the case?


As you said, a lot of them would just be confirming common sense, but I'm sure we'd stumble across things that should or shouldn't be clientsided but aren't/are respectively.

Watermelon wrote: I thought any variable type (excluding local scope) is separate from client and server, is that not the case?

Like I said, they CANNOT access those variables because they are NEVER sent the data. I'm pretty sure they always return zero unless they were initialized with a value (which Global variables cannot be.)

My bad, I just checked after re-reading and confused MAP scope with WORLD scope.

Though I'm hoping Dusk can get shared variables between the server and client one day

If you set a variable clientside then it stays on the client only. At least I'm pretty sure that's how AOW got consoleplayer before ConsolePlayerNumber was a thing.

Watermelon wrote: My bad, I just checked after re-reading and confused MAP scope with WORLD scope.

Though I'm hoping Dusk can get shared variables between the server and client one day

Well IMO this kind of defeats the purpose of ClientSide scripting because you're sharing data inbetween the server and client, and waiting for the PING call again...
You can already share data by calling a Clientside script with the data you want to save in the arguments of the script, and then have that script set those variables using the data from those arguments.

Llewellyn wrote: For example, Clientside scripts cannot access MAP or GLOBAL variables because they are stored clientside and are not sent to the server.

Just to clarify this statement: Server and clients have their own copies of the ACS variables that are not synchronized. So the client can access its copy of the variables, but it has no access to the server's copy.

Torr Samaho wrote:

Llewellyn wrote: For example, Clientside scripts cannot access MAP or GLOBAL variables because they are stored clientside and are not sent to the server.

Just to clarify this statement: Server and clients have their own copies of the ACS variables that are not synchronized. So the client can access its copy of the variables, but it has no access to the server's copy.

I probably should have been more clear and changed my original post because I meant to say "serverside and are not sent to the clients."