Server centred update (PR #115)

Development tremulous
1

Hi,
(Yes, another pull request)
Today I’m creating this pull request centered about server. As it seem that GrangerHub still not have commands like share and donate, I think that making a pull request about theses kind of missing things could help a lot to encourages players to use GrangerHub version of server.
As there are only “old” server, all updates I already did seem useless. I hope that after this pull request they will become used.

Note: Most of my code is mostly inspired, sometimes copied/adapted, from patch mainly found at http://dl.grangerhub.org
Note: I make my best to NEVER denaturate the game. My aim is always to enhance and add some options (which are mostly disabled by default).

What I did (from best to the useless):

Planned:

  • Documentation ! The official one is really old and miss a lot of things
  • Servers presets to quick start a server
  • Maybe making last QVM compatible with old client, but they don’t need it to join until the server is quite pure (but should set as sv_pure to 0 avoiding downloading QVM for now and should remove 1.3 data on the server since they cause crash (due to some JPEG images ?!) )
  • callvote poll
  • admin messages
  • evolve in base (must be disablable)
  • Lakitu7
  • force spec
  • designate and resign builder
  • freeze statsCounters_t
  • g_KillerHP
  • g_clientUpgradeNotice ??
  • patch: Medik effect should not be lost when using medical station
  • Configurable humans regeneration
  • Persistent builder time across disconnect, death, … (I saw a lot of unfair playing about that !)
  • Stop a building construction if the builder is dead. May then allow another builder to continue the build.
  • Maybe replace tremulous.h with a configuration file. Also provide some presets.

About testing:

  • I’m compiling all changes I did and release a server + the client. It will then help to solve some bugs before GrangerHub community review my commits. Also anybody could now test my changes simply by downloading my fork at Buom_01's Tremulous Fork

GitHub

2

From there, I published current build mainly to facilitate testing but also to invite players to test it.

/devmap atcs

I planned to open a server dedicated to this pull request and previous mines which are in a pending state, allowing to test in a real conditions (and because testing may be really boring else).

3

Howdy @Buom01 ! I want to give you an update on our short term and long term plans. I’ve been tied up relatively recently with a lot of irl stuff, but I’m freeing up time and getting back to work on the codez again. We have been working on the 1.3 server side stuff primarily on another repo:

I didn’t get a chance to look over your code yet on this pull request, but we do already have some (but not all) of the features you’ve listed here on that other 1.3 game logic repo. Like share, donate, cpa, warn, antispawnblock, and a few other things.

It is interesting that you brought up moving tremulous.h to configs, I’m actually going further than that, I have already started working on a game mode config system which should handle the vast majority of modding (it would also allow for easy switching between different game plays on the same game modules). You can get an idea on what I have currently in this file:

I’ve pretty much finished overhauling the missile system for that, although there is a memory issue I need to fix that resulted in the server memory usage growing from a bit over 300 MB to 1.6 GB. Then I’m going to work on finish overhauling the weapon system, then onto the upgrades, then classes, then buildables, then teams. All of their properties are going to be moved from from all of the attributes arrays to configs, and there isn’t going to be any mention of any specific enums for the specific classes/weapons/upgrades/buildables/teams anywhere hardcoded. I’m abstracting all of the properties.

While we plan on still supporting Trem, including this client repo, We are shifting our development focus on a new game based on Trem, that we are calling Stellar Prey, which will have the 1.3 game logic as a starting point, and built on @TheDushan 's new OpenWolf engine. After I finish up the game mode config system, I’ll be porting the game logic (currently the Stellar Prey repo has a placeholder game logic that is some old version of trem between 1.1 and gpp) over to Stellar Prey. This is the main Stellar Prey repo:

I’ll be fixing up it’s main bash script very soon. But so far we have tested what we currently have on Windows 10 and on Linux (more specifically Ubuntu 20.04), and it does work on those platforms. We are going to need someone familiar with developing on Mac to get it up to speed on that platform at some point. It also does have potential for support on android and iOS, but I’m not sure how well that would fit with this kind of game play.

We also plan on porting over all of the 1.3 client/engine improvements (including the work you have done on this repo) from this repo over to Stellar Prey and OpenWolf.

There are a lot of advantages to this shift. OpenWolf has tons of cool modern features, it has a very clean and well organized code base to work on, and we would no longer be restricted to backwards compatibility (so development should be a lot easier in general).

If you would like, feel free to check out the Stellar Prey repo, and if you give it a try and have any questions or find any issues, feel free to bring that up on that repo’s issue tracker. We still have some major things to finish for that repo to get it up to proper speed, but in the meantime, even new work and testing you might do on this trem repo would have potential value for Stellar Prey, it shouldn’t be too hard to port over when it comes time.

With all that said, looking over what you have outlined for this particular pull request, after any kinks are worked out, I think it should be ok to merge in. The only thing is I think changing to the current map should still be separate from map_restart, because there are circumstances where a full restart comes in handy. But it would be of value to have an optional argument for the map_restart to restart with a different layout.

1 Like
4

Hi,
I still have some questions:

  • Why not making https://github.com/GrangerHub/tremulous-game-logic a sub repertory of this repository ?
    I did some changes which are useless if the client or the server is not patched with. e.g. getting team status on to the scoreboard (also I will refactor it for compatibility with old client without custom QVM)
    Or in this one dropped dead weapons and other furniture staying in corpses need both server sending it to the client, and a patched client that display it.
    Then I would have to patch it on a separate repository, while making it as a sub repo could simplify the work (I think).

Also it sound more logical to provide the right server with the client.

  • Am I the only one for which some server doesn’t work with the released client (and master branch) like New Edge ?

  • Also I’m lost about one thing. I introduced new System Calls. Are there a known way to make them compatible with old QVM without crash (like client features detection) ?

  • Also all is built into a GPP folder, but my isusue is, If I do an enhancement, it will be mixed to GPP which will be used on GPP folder. Could I make a special patch to use official gpp-vms on “gpp” gamemode, and and other to use more modded one ? As compatibility is hard to do… I would make it easier to make server with latest changes and which work with newer QVM

  • About Stellar-Prey: I’m not sure to understand about it aim. It will be a new game like Unvanquished did, with new gameplay, and breaking changes with older server ? Or will it be able to play strawberry/swirl with all features included (like shaders, …) without significant gameplay changes ?

5

@Buom01 , regarding the weapon dropping, that should be enabled/disabled by a cvar, since that does change strategies in the game play.

* Why not making https://github.com/GrangerHub/tremulous-game-logic a sub repertory of this repository ?

In retrospect we should have done something like that from the beginning. After I port the game logic over to Stellar Prey, I’ll then port the game logic over to this 1.3 client repo, so the server and client would be packaged together as it should be. So for now I would recommend that any server side changes you make, you should make on this repo, and I’ll adapt accordingly when I port the main 1.3 game logic over to here.

* Am I the only one for which some server doesn't work with the released client (and master branch) like _New Edge_ ?

You’re not the only one. That version of New Edge was ported from gpp to 1.1, and it seems like they did it in such a way where the 1.3 multiprotocol client detects an issue with their cgame and/or ui QVM(s). It may not be an issue that requires the 1.3 client to be fixed, but rather that that version of New Edge needs to be fixed. I have noticed 1 or 2 other 1.1 moded servers that were previously up (I don’t know if they are online now), that gave the same error too.

* Also I'm lost about one thing. I introduced new System Calls. Are there a known way to make them compatible with old QVM without crash (like client features detection) ?

I don’t think you can add a system call to the cgame/ui QVM(s) without breaking backwards compatibility with the older clients. It is best to avoid that for 1.3. It’s ok to add new syscalls to the game module though, since the old trem clients don’t need that. I suppose new syscalls could be added to the ui though if a separate ui is built only for use locally on the main menu and download menu.

* Also all is built into a GPP folder, but my isusue is, If I do an enhancement, it will be mixed to GPP which will be used  on GPP folder. Could I make a special patch to use official gpp-vms on "gpp" gamemode, and and other to use more modded one ? As compatibility is hard to do... I would make it easier to make server with latest changes and which work with newer QVM

That is fixed in the new file system pull request, basically a separate game folder was made for 1.3.

* About Stellar-Prey: I'm not sure to understand about it aim. It will be a new game like Unvanquished did, with new gameplay, and breaking changes with older server ? Or will it be able to play strawberry/swirl with all features included (like shaders, .....) without significant gameplay changes ?

Our plan for 1.3 is to basically finish up the odds and ends we have left. The Vanilla mode for the 1.3 game logic (which is mostly 1.1 vanilla kind of game play with misc improvements) is pretty much done (it could maybe use some polishing after some more testing). Regarding the new Swirl game play, I’m just going to finish mainly some additional weapons related features as I finish up the game mode system, but there are some major planned features that wouldn’t be practical to finish for 1.3 since they break the cgame QVM when I’ve tried to add them (so those remaining game play features we are going to add to swirl in Stellar Prey).

So 1.3 will have what we currently have in this repo, plus the 1.3 game logic with completed Vanilla and Chocolate (Chocolate being gpp game play) game modes, a mostly complete preview of swirl, the new file system, any additional stuff that you might complete for this repo, and maybe some other misc things. Then we’ll call that the 1.3 release and continue to maintain 1.3 and consider future pull requests to it that anyone may decide to do.

Stellar Prey is a new game with the new OpenWolf engine. It will break backwards compatibility with trem, that is you wouldn’t be able to play on old trem servers with the Stellar Prey client, and it has its own master/autoupdater/authentication servers completely separate from trem. Although the vast majority of trem assets can be used on the new engine (and we are going to be starting out mostly with the current trem assets we are using for 1.3, as placeholders for Stellar Prey), but ultimately All of the assets should be updated to take full advantage of the new new renderer and other features of the OpenWolf engine. But our first priority is making the game play and engine awesome, and any and all new assets would be made for the game play (not the other way around).

Regarding the game play of Stellar Prey, we will include the 1.3 Vanilla mode (which is again based on the 1.1 game play), as a default game mode, but we will call that “Legacy mode” in Stellar Prey, and we will finish up the 1.3 Swirl game mode in Stellar Prey, but call that “Competitive mode” (we also have plans for another brand new default game play mode that we will call “Casual mode”). We will probably not be including the gpp game play as an option, and leave that back in 1.3. We may do some other game mode options later, and modders could always make their own custom game modes with the game mode config system, and we’ll probably also add in Lua scripting support for additional modding. We may also add a single player campaign to Stellar Prey at some point.

So long story short, there are a lot of things we are bringing over from trem 1.3 to Stellar Prey as a starting point, but we will be taking the new game in a new direction from there.

6

Super looking forward to making my own gamemode idea that I have. Make it werk @Sparky!

7

Thanks. I think I have all my answers.

For now I close this pull request. I will make it in a different way then.

So I looked to Stellar-Prey, I expected some random issues. I will open proper issues for each if it persists and I can’t solve it myself.
Else about assets, I began that: https://youtu.be/xn1aonQnu_Y . I will try to open a thread on the forum nextly

About tremulous-game-logic, (when I have finally cloned/linked/compiled all right xD):

  SV_Trace(
    &tr, localOrigin, cmins, cmaxs, localOrigin, ENTITYNUM_NONE, qfalse,
    *Temp_Clip_Mask(MASK_PLAYERSOLID, 0), TT_AABB);

instead of

  SV_Trace(
    &tr, localOrigin, cmins, cmaxs, localOrigin, -1, qfalse,
    *Temp_Clip_Mask(MASK_PLAYERSOLID, 0), TT_AABB);
  • And, could the owner of game_modes/* could publish it please ? Or maybe I missed them anywhere ? xD

Thanks you again for your answers. It helped me a lot.

PS:

regarding the weapon dropping, that should be enabled/disabled by a cvar, since that does change strategies in the game play.

Yes I already did. 0 : Nothing happend, 1 : That’s only aesthetical, with DEAD flag send, allowing the client the render it on the floor, 2 : Just drop weapon as they are already implanted (and then could be pick up)

As said I will close this pull request, making it different.

  1. Adding some optional feature to the client side (also reviewing TeamStatus because I would make it compatible without QVM download, meaning through g_ cvar probably) and things like displaying corpses like server tagged it.
  2. Add some missing things on the server (some votes, ESD, …), but also send optional things like corps with equipment (as currently it doesn’t really do).