Hello all, and welcome to the code support thread. My goal here in this project is to provide any major ACS functionality to the project all while maintaining a proper level of compatibility and stability. If you need features for the project, you can post about them here, or PM me about them.

For now, just from reading the various threads, it seems we need a way to implement a credits display system into the project. However it seems we wont need that until a much later date.

Also, torm expressed interest in the Objective system that I've been developing. Basically the Objectives system is an ACS module that I made that will display the current objective as a marker on the screen that is meant to display where the objective is in your current view. Think of it like the waypoint markers that come up on screen in other games like Skyrim or Halo. I have already written the majority of this, and all that needs to be done is add some minor polishing and it can be easily used here. This is simply one implementation for it, and I had other plans for having different ways of displaying it. I'm also taking into consideration what kind of resources a feature like this would take up.

The way I'll be approaching implementing features like this is that there will be a central library that will be loaded into every map with an #import and you will be able to call a function out of that library that will automatically follow a pre-defined camera route with your specified graphic/credits message. This will help us a lot by keeping shared features and scripts out of the map ACS files, and centralizing the data to ensure proper MP compatibility. Also by doing this, it helps with FASTER and EASIER debugging that will help keep the code side of things simple and enable me and everyone involved to fix the issues that come up quickly.


TL;DR; Version:
Post about what you want ACS-wise in your map, and I'll see about what I can do.

First of all thanks for your support, it's a good feeling to have you on board.

Concerning the features: The credits/cam view should be the same as in ZDCMP1, just looking better Nothing too complicated, just simple camera slides with text being displayed.

Concerning the objectives system: I kinda like it and I think it might be of good use considering the possible size the map will later have. How will this look like anyway live on the screen?

Well I figure I should show the documentation for the objectives plugin here. Spoiler'd for your convenience. Also basic screenshot of what is going on (keep in mind, I have no predefined graphics for this, so I just use in-game resources).

EDIT: Also please understand that because of the nature of Doom's renderer, the objective will never be 100% precise as to the location on the X OR Y axis. It'll be close enough at certain angles where it wont matter though.

http://imgur.com/a/gWkEP#0


the objective system
Description:
The Objective system is a plugin that is meant to manage objectives and display them accordingly on a per player basis. You can have up to a maximum of 255 objectives per map. There are a number of predefined objectives that can be used, or you can define your own and have a specific script be called with special arguments to create your own objectives.

Usage:
Objectives are loaded on a per-map basis.
Objectives do not carry from map to map and must be defined explicitly for each map.
Objectives are defined initially in an OPEN script and therefore are loaded at map load.


Commands:


Defines objectives in the database. Returns the index of the objective definition.

• ObjID - Objective ID number. Similar to TID's except for objectives. This is the number that is used to reference objectives with other functions and commands. If two objectives use the same ID, the last one defined is the one that is saved.
  
• Title - Primary information to be displayed about the specified objective.
  
• Description - Secondary description of the objective (in case any extra information is needed to be shown).
  
• targetid - line id/TID of the objective. (If the type of objective is set to TIMER, then this parameter is the total time until failure in seconds. Decimals are rounded down.
  
• Type - type of objective.

  #define OBJ_CUSTOM 1 //Objective is a custom definition. Script specified in script id is called instead of a prefab script. #define OBJ_PICKUP 2 //objective is an item that you need to pick up. Argument is the classname of the object to verify that the player picked it up. //TargTID is the target TID of the object to be picked up. A marker is not necessary and if one is not specified, it will be set to the TID of TargID. #define OBJ_TIMER 3 //Objective is a timer and uses the parameter 'targetid' in function DefineObjective() to set the amount of time (in tics) #define OBJ_AREA 4 //Objective is an area that needs to be held. The TID for the marker is used as the focal point for the circular area that the player needs to be in. //targetid specifies the distance you have to be from the marker before the objective can be completed. Argument is used to set how long you need to be in the circle before //the objective is completed. #define OBJ_KEEPOUT 5 //Objective is to keep a specific actor with a specified TID out of an area. Targetid is the TID of the specified actor to be kept away. The marker is set to the focal point that is the //specified actor is being kept away from. Argument is used to set the minimum distance necessary to keep you from failing.

  
  
• flags - Default flags. Used to set a default status of the objective (IE default to success until conditions cause it to fail)
  

  #define AUTOACTIVATE 1 //This objective is automatically given and activated on all players. #define PASSED 2 //This objective has been is completed. #define FAILED 4 //This objective has been failed to be completed. #define INPROGRESS 8 //This objective is active and in progress. #define SHOWMARKERONLOAD 16 //When this entry is loaded automatically show the waypoint marker on the screen. #define FINISHED 32 //Objective can no longer be completed or failed. It's FINISHED! #define INITIALIZE 64 //Procedure call for the objective type pre-fab loader. When an objective is given to a player, the flags within that player's data table get set to this //to tell the manager to call the appropriate script. #define ONLYENDONFINISH 128 //Flag that tells the objective routine not to terminate unless the FINISHED flag is turned on. //This has to be done from the Script specified for the objective. #define FAILONDEATH 256 //Flag that tells the director that if the player dies it's an automatic failure.

  
  
• scriptid - script to be activated upon completion or failure. success has the first parameter passed as 1 failure as 0.
  
• Marker - TID to link the hud marker on the screen. You can use any actor you want, but if you dont want the player to be able to pick up the marker, it's best to set it as a map spot.
  
• Argument - Extra information to be used when using objective types.

This command is used to define objectives in the database. Once the objectives are defined, they are passed to the management loops and displayed accordingly. See the usage section for types and examples on how to use each type of objective.


This following segment is a list of commands dealing with setting the status of objectives. Since these all use basically the same parameters, I'll explain them first and then list the commands below.

• ObjectiveID - the index of the objective in question. You should already have this value stored in an integer variable before using any of these commands.
  
• Playernumber() - See Playernumber() in the Zdoom wiki
  
• All - Specifies that the changes are to be given to ALL the players.

Returns if the selected objective is active or not and on which player. 0 is activator. Returns 1 if the specified objective is set Active; Otherwise returns 0.


Sets the status of an objective to fail. 0 for activator, -1 for all. Returns 1 if the specified objective is set correctly; Otherwise returns 0.


Sets the status of an objective to cleared. 0 for activator, -1 for all. Returns 1 if the specified objective is set correctly; Otherwise returns 0.



Activates/Deactivates an objective. This basically is the control on if an objective is active. Active means that it can receive state changes (such as being set to failed or cleared) on players. When an objective is set to active the default state and properties of the objective are copied over to all currently connected players. If a player joins in the middle of the progress of an objective, the status of all currently active objectives is set to that player. Returns 1 if the specified objective is set correctly; Otherwise returns 0.


Displays a marker on the hud for the specified player that displays in the direction of the specified objective. Returns 1 if the specified objective is set correctly; Otherwise returns 0.


Sets the objective to FINISHED. This only applies if the flag ONLYENDONFINISH is set to the objective. Flags the objective to terminate.

This is very cool indeed Though we need to discuss in which way we will set this up and if it is useful for us. I'd really like to know what others thing concerning this.

The goal is that setup should be easy to perform, as basically it's just a couple compiled scripts that go into the ACS folder in the pk3. After that, the rest of the scripting is done on a per-map basis, within the scripts lump. Most of the time to use systems like this it wont be more than a couple of simple lines of code. I have example wads showing off the feature set that I can post in here as well if you'd like to see it in action.

Have you already had some time to post/put together the example wad? I'd really like to see that.

By the way, this was suggested:

Do you think you can come up with something? You could use dummy graphics in the correct size, I could do the final graphics later and implement the whole thing when it's my turn again.

And just in case you want something to give you a headstart, here you can find a rather modest keypad I made last year or so with my limited ACS knowledge (yeah, excuse the mess of a code in there ). Take a look at it if you wish and see what is what. Who knows, it might give you an idea or two.

I have an integrated menu system already in place, with a WYSIWYG in-game editor. Give me a base layout, and consider it done. I'm going to be sticking to numerical keypads, just as a heads up. Considering the fact there are no reliable ways to do string comparison right now in ST, I'm going to stick to the simple stuff. If you want to see my menu system in action check it out at my dev thread for Blackfire.
http://forum.zdoom.org/viewtopic.php?f=19&t=32070

Also, demo link for the objectives system coming up as well:
http://www.sfxstudios.net/blackfire/plugs.pk3

And again, I know this SDK seems a bit much, but this is meant to be as easy to use as possible. It's really meant to make the jobs of the mapping teams easier so you guys can do more with less. Any major technical or related questions are welcome, and if you dont want this functionality here because it's too much crap or whatever, please let me know.

I'm totally open to all criticism and input on this, as this whole SDK is still under development. I'm currently working on a dialog system that is MP compatible and also try to make a WYSIWYG editor in a webpage or something so you can construct dialog trees with ease. Still looking into the process behind that, but it shouldnt be too ridiculous. Hope this gives some solid insight as to what I'm trying to do here and what kind of support I'm able to offer


EDIT: HERPADERP I POSTED THE WRONG LINK.

Just a reminder: Apothem prepares a keypad lock for me that I will add in my phase 2 slot

Beyond, don't forget the EXP system

The EXP system is already made, and is fully debugged and working in MP with a minimal bandwith footprint. Same goes for ANYTHING GUI related that you may see going on. The only thing that needs to be done is have the base spawner code and scripts in place so the monsters can give XP.

A minor side note about this subsystem, if one monster kills another, it will 'take' the XP from the monster it killed. You could, theoretically, add code to check for how much EXP that monster may have and make it 'level up' if enough infighting occurs. Upon a level up, you could do whatever you wanted to toughen up the monster, but I would suggest at least restoring its health first. As far as the code for that is concerned, that could be done ENTIRELY in DECORATE no problem

Sadly, I'm not really a DECORATE kinda guy, but I can whip up an example for that if you'd like.


I've already made the base keypad GUI to get the skeleton of the GUI code made, all I need are graphics now.