Full vs. Partial vs. 'Light' game port

[darkshade9]

After fiddling with the code a bit, performing a full port is going to take a good deal of work and testing. The game may not feel like the original in some aspects, so those looking for a 'true port' would be disappointed.

That said, we can port some of the code over with relative ease. This would not be a 'true port', and thus a 'lite' version of Action. As mentioned in this Issue https://github.com/Raptor007/aq2-tng/issues/148, it's a much faster lift to focus on core components of the game rather than doing a full transition. Along with that, I think that there are some components we can adjust to make the game more welcoming to new players and easier to play. And we come to the crux of this issue and where I would like some feedback:

1. As mentioned in #4 dropping legacy support for Teams by Model and Teams by Skin. This was an old method of handling teams before there was Teamplay or TeamDM.
2. As mentioned in #5, removal of effects that no one uses outside of LAN play.
3. Only 2 game modes to start with: Deathmatch and Team Deathmatch. Teamplay is difficult to get games started on public servers, and at some point we may be able to pull in the existing CTF code, but let's start slow. This also means no Matchmode.
4. Leg limping mechanics change. Instead of limping, it slows you down to walking speed. It still prevents you from jumping. This way we don't need to play with any player movement shenanigans with the new code. Additionally, it will print a message to the player that they need to Bandage to restore their movement speed and jumping ability.
5. Auto-reload is set default to 'on'. CenterPrint message will display when player attempts to reload with no spare ammunition and suggests to the player that they need to drop their weapon and find another, or find more ammo around the map.
6. Automatic dropping of weapons when these conditions are met:
   • Player has zero ammo in the special weapon they currently have
   • Player has zero spare ammunition for the special weapon they have
   • Player walks over another special weapon that contains ammunition (or a freshly spawned weapon)

New cvars: Userinfo: new_to_action: Default is 0. It will increment every time a player uses action-specific commands such as Reload, Bandage and Opendoor. This value is then checked when that player needs to perform that command, such as running out of bullets, getting leg damage, or approaching a door. If this value is under a certain value, for example, 20, then it will print a message to the player, instructing them on what to do. For example, if a player's new_to_action value is < 20, then when I run out of bullets and I have spare ammunition, a CenterPrint message is displayed to that player, indicating:

You are out of ammo!  Reload by binding a key, such as `bind r reload` to reload your weapon !

You are near a door!  Open it by by binding a key, such as `bind f opendoor` to open it !

You are bleeding!  Bandage by binding a key, such as `bind e bandage` to apply first aid!

Once this value reaches a certain value, let's say 20, then this message is no longer displayed to the client. Place a validation check if the player has reached a certain number, to no longer increment, for example

#define MAX_NTA 20
int nta = gi.Info_ValueForKey(ent->client->pers.userinfo, "new_to_action", value, sizeof(value));
if (nta >= MAX_NTA) {
  return;
} else {
  nta++
  Announce the alert
  Copy new NTA to userinfo
}

[Iceman12k]

• 1 I'm all for
• 2 I'm all for
• 3 is controversial and I personally think Teamplay is pretty critical, matchmode can wait though. If people want to have any organized matches teamplay is basically required.
• 4 would be controversial and honestly doesn't make a ton of sense, as all limping does is set the movement input to 0 so practically speaking it would be the same amount of effort to implement. If anything limping should be significantly easier to do now that pmove is in the DLL. You could just copy-paste my implementation from AQTION_EXTENSION
• The rest I'm pretty neutral on, but I think the new cvar is a great idea. It's a very elegant way of handling weird custom binds users may not understand without a readme

[darkshade9]

I think 1 and 2 are good to drop, should we ever want to spice things up perhaps there's some visual elements we can add in that doesn't spam the server with entities (maybe could be rendered client-side instead?)

For 3, would it make sense to add it at some point, but perhaps not version v1.0?

4. I understand it would be a hot button topic, if it is as easy as implementing it as it is, let's do it. My primary concern is that new players won't understand what is going on (as early players of AQtion thought they were 'lagging' and it appeared to be a negative experience for them), but if we feel that it's too drastic of a change from the norm, we can retain it as it is.

For 5, I hope that the new Q2R will save player's set cvars or they'll have to reset them every time they launch the game (according to Paril, they stick around, so long as they are not aliases)

[Iceman12k]

The addition of the cgame dll having pmove should mean we can have limping without the lag effect, same as how it appears in AQtion, though that would require the client having the cgame file itself.

I'm not actually sure how the cgame dll works for clients connecting to a server and downloading a mod, or if there's even a standard for it yet. I presume the dll doesn't download as that would be insecure. Though other games (q3 engine) did that anyway, so who knows.

[ReKTeK]

1 & 2: Agree.

3: Pros: release a 'lite' version, not even a v1.0, could be an early beta that follows in the foot steps of the original development of AQ2 starting with DM, and eventually rolling out Teamplay. The idea is to get something out sooner, rather than later. Additionally, starting from a basic foundation brings to the table the formation of new and fresh ideas, even modernize the gameplay (new weapons, items). That said, the code would absolutely need to toggle between true 'classic' and 'rerelease'; which is to say, classic stays 99.99% true to the AQ2 formula, and rerelease is AQ2++ modernized. 3: Cons: the game logic already considers various game modes: DM, TP, et al; which players expect to be there. Need to manage expectations of new and old school player bases. 3: Conclusion: perhaps take a leaf out of the Quake 2 Rerelease, keeping it old school while modernizing where it makes sense to do so.

4: If I'm understanding it correctly from what @Iceman12k has said, we can implement leg damage very similar to how it is now in AQtion, without needing to touch the engine, since we have pmove in the game library. That said I also agree with @darkshade9, perhaps a solution could be to apply the pmove interpolation + game message + HUD icon of broken bone?

5: Great ideas @darkshade9. Could also use more HUD indicators here too, showing a weapon icon without ammo.

6: Again, great ideas. Some other ideas, not all are 'classic', but then again AQ2 today isn't exactly vanilla anymore.

• Highlight weapons with ammo, perhaps a bandolier trait, like IR Vision

• Clearing the map of dropped weapons that have no ammo, or showing a weapon without a clip (smoking empty gun)

• Walking over a weapon with ammo automatically scoops up its ammo + spare ammo (bandolier trait?)

• New cvars: Agree. Helps lessen that learning curve for new players.

[darkshade9]

The addition of the cgame dll having pmove should mean we can have limping without the lag effect, same as how it appears in AQtion, though that would require the client having the cgame file itself.

I'm not actually sure how the cgame dll works for clients connecting to a server and downloading a mod, or if there's even a standard for it yet. I presume the dll doesn't download as that would be insecure. Though other games (q3 engine) did that anyway, so who knows.

The game won't download mods automatically due to concerns about the possibility of distributing malware via mods, so as long as we don't edit pmove or the HUD (per Paril's notes) then we're good to go.

[darkshade9]

If anyone wants to take a look/contribute to what I'm calling 'action lite', the branch is https://github.com/actionquake/quake2-rerelease-dll/tree/actionlite

The CMakeLists.txt should compile in Linux and the game.sln should build it in Windows, may need to play with some settings. No guarantees on code quality at the moment.

[MVarland]

I agree with most that has been said. I think it's a good idea to start developing and releasing towards DM, TDM, TP and then Teamplay Matchmode.

Regarding auto dropping of weapons - There are situations when an enemy might have a clip/mag for the Unique weapon but drops the weapon because throwing a knife or start shooting with the pistol is faster than reloading.. If possible I would pick up that unique weapon just to limit the enemy from picking it up again and reloading at a later point.

I like the idea of having New player tips! Only input I have is perhaps instead of having the value increment it can be a setting in the menu that can be disabled? Or a combination of the two?

[darkshade9]

Adding in Matchmode shouldn't be terribly difficult after TP goes in, it's mainly around setting specific rules like timelimts, chase cam limiters, captain/sub logic and bypassing the Intermission.

The auto dropping of weapons should probably be disabled for Teamplay modes -- the main reason I bring it up is because I'd prefer to get to a 'welcoming' state of new players so they are not confused by aspects of AQ2 that we are all used to, such as:

• It feels like 'lagging' when you limp -- not a good user experience, but if given the knowledge of bandaging and the strategy of using it, it feels more natural the more you play
• Walking over weapons in every other Quake game picks it up if you don't already have it. AQ2 doesn't work like this, but to be accommodating to new players and to rebuild a player base, I think we should make a bit more easier to get into the game and understanding its mechanics. This could be a toggle-able server cvar, to retain existing mechanics or to toggle a public mode
• What a veteran player can do is setu new_to_action var in their config to 20 (I am hugely assuming that set/seta/setu/sets logic still exists in the new engine) and they would not receive new player tips. We could probably do it in the menu too, but the menu is locked away in the engine and not the game dll, so we can't do that until we gain access to that.

[darkshade9]

So far this is what I've started working on with Action Lite / AQR:

Gamelib changes All gi. print statements (cprint, bprint, dprint) have all been changed, see this document: https://github.com/q2community/quake2-rerelease-dll/wiki/Mod-cheat-sheet

Adjusted various structs for Action-specific keys and types

• Changed all qboolean to bool
• Changed most int to int32_t

Added action-specific functionality

• Reloading
• Bandaging
• Lasersight
• Weapons and Items

Things that will need cleaned up:

• Non-Action weapons, items and powerups
• Removal of 'monsters', while keeping some ability to use some for potential AI/actors
• Remove dependencies of Rogue and Xatrix

Things to do:

• Add commands

Significant functionality changes around: tr.trace P_ProjectSource Frame timing

[darkshade9]

I'm working with a_team now, and I've ran into something interesting -- the 'gender' userinfo is gone, no longer in the engine. What I can do is assume gender (not so woke I guess) from the skin being used by the player, to determine kill message pronouns ("tripped over his/her own grenade"). If a skin does not match a 'gender', it gets the neutral its pronoun. Does that seem like a reasonable resolution?

[MVarland]

Definitely! On Sun, 3 Sep 2023 at 14:42, Aaron Dean @.***> wrote:

I'm working with a_team now, and I've ran into something interesting -- the 'gender' userinfo is gone, no longer in the engine. What I can do is assume gender (not so woke I guess) from the skin being used by the player, to determine kill message pronouns ("tripped over his/her own grenade"). If a skin does not match a 'gender', it gets the neutral its pronoun. Does that seem like a reasonable resolution?

— Reply to this email directly, view it on GitHub https://github.com/actionquake/quake2-rerelease-dll/issues/6#issuecomment-1704296297, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYZVC3XSDGKBMKRFO4AFTEDXYR3MZANCNFSM6AAAAAA4GW72EU . You are receiving this because you commented.Message ID: @.***>

[darkshade9]

I take it back, Matchmode and Teamplay are intricately linked together, there's checks everywhere. It would be easier to just leave it in and work around it, if we ever decide to put it back in.

[darkshade9]

I noticed scope creep working in on my old branch, one function calling another and I ended up importing the entire file, then that file had dependencies... etc. I'm working from this branch now. I could use some help on the Menu stuff, I have never worked with it before and getting it to work with the new system is proving to be a bit problematic. It's getting closer though.

https://github.com/actionquake/quake2-rerelease-dll/tree/aqr

[darkshade9]

A good chunk of the code has been migrated, there may be a few implementations missed but for the most part I think we're in feature/bug fixing mode. I am writing up bugs for each one I've identified as Github Issues; welcoming all to take a stab at fixing them or creating your own bug issues if you come across any.

Create a fork, checkout branch aqr, then create your own bug fixing branch. Once the code is good, create a pull request against the aqr branch in this repository