Thread: 20 years of Sven Co-op! -- Sven Co-op Update Released [Build 3482406]

Page 1 of 2 12 LastLast
Results 1 to 25 of 28
  1. #1
    Administrator AdamR's Avatar  
    Manager
    Join Date
    Mar 2004
    Location
    Cardiff, South Wales [UK]
    Posts
    8,593

    20 years of Sven Co-op! -- Sven Co-op Update Released [Build 3482406]

    Nothing interesting ever happens on a Tuesday. Except for January 19th, 1999. This is when Sven Co-op beta 0.8 was released to the just recently formed Half-Life community. When it became clear that Half-Life (unlike its predecessors Doom and Quake) would not have a co-operative mode, the community took the task upon itself to fill the void Valve left behind. One of those people was Sven Viking.

    At this point, Sven Co-op was not much more than a proof of concept, or to put it into Sven's own words: "mostly just to give everyone an idea of what I'm doing, partly because of various bugs in the map that I don't know how to fix ". At this point the mod consisted of only one map and a few scripts. Sven found help sorting out the initial problems he was facing and the few rooms that made up beta 0.8 quickly grew into a full fledged map, which was released in early May of that same year.

    This all happened 20 years ago, in a time when, for many people, going on-line was met with dial-up tones from your modem, playing games on low resolution software rendering and a latency of 300 ms wasn't something to complain about. Luckily for us all, technology has moved forward and so has Sven Co-op. Ever since that first map, SC has tried to push the boundaries of what is possible with Half-Life. We've seen thousands of maps, models and other custom assets made by our community members, millions of downloads and, most importantly, countless hours of co-operative game play fun!

    After two decades, Sven Co-op still has a steady and rich player base and a dedicated group of talented developers and we believe, especially since our standalone release on Steam in 2016, that there will be much more to look forward to in the future!

    Come celebrate Sven Co-op's anniversary with us by joining the servers and make sure to give "svencoop1" a replay for old times' sake. We'll be there! For the nostalgic or the curious, the original website from 1999 is available here. This is also where you can still find the original beta 0.8!

    An update for Sven Co-op has been released. If you are running a dedicated server please use SteamCmd to update your servers. Those of you that were using the public release candidate can remain to do so, as this branch now matches the standard branch.

    This is officially the first release to drop support for Windows XP/2003, Windows Vista/2008, and Linux with GLibC earlier than version 2.24. -- Sven Co-op may fail to work completely on those operating systems. More information

    Changes are as follows:

    Notable changes

    • Event system to adjust various content according to the event. -- Content for our 20th anniversary included.
    • Better support for Stretch and Buster versions of Debian Linux.

    Code

    Game library

    • Linux specific:
      • Added local build of LibSSL 1.0.0, so secure connections will now work on Stretch and Buster versions of Debian.
      • Removed "vgui2_controls.a".
      • Removed i486 binaries.
      • Removed local build of LibSTD C++ 6.
      • Updated local build of LibCURL to 7.63.0, and fixed the certificate authority path not being correct for some distributions.

    AngelScript

    • Added new hooks: PickupObject::CanCollect, PickupObject::Materialize, PickupObject::Collected.
    • DamageInfo.pVictim is no longer constant. (Fixes casting issues.)
    • Documentation: Changed how hook description is handled and added description for all existing hooks.
    • The plug-in manager can handle multiple plug-in lists now.
    • Updated AngelScript to version 2.33.0 (22nd December 2018).
      • IMPORTANT: Arrays no longer contains a "length" property. Getting the length of an array must be done with "array.length()" instead of "array.length".

    Engine

    • Added support for wide-screen menu backgrounds. In wide-screen mode "BackgroundLoadingLayoutWide.txt" / "BackgroundLayoutWide.txt" definition files are checked first, and if not found "BackgroundLoadingLayout.txt" / "BackgroundLayout.txt" is used as a fall-back.
    • All search paths are cleaned up before they get registered by the file system. (This should fix path inconsistencies caused by the SvenDS launcher still returning relative paths on some Linux systems.)
    • Both launchers (client and server) now use the same method when building their "basedir" path. (The server originally returned "." instead of the actual absolute path causing content to be missing if you hadn't set the shell's working directory first.)
    • Dedicated server UI:
      • Fixed dedicated server not starting properly occasionally when launched in the UI mode.
      • Fixed graph axis labels.
      • Fixed some fields not initializing properly until a minute later.
    • Detailed information is provided if client or server library fails to load. (This is especially useful on Linux where it should report any missing ".so" dependencies.)
    • Files created by the engine (server logs, tempdecal.wad, custom.hpk, user.scr, settings.scr) now use the "GAMECONFIG" PathID to make sure they will always end up in the main game directory ("svencoop") even if some other path was added later on ("svencoop_hd", "svencoop_event_*" etc.).
    • Fixed an issue where the key value parser accessed and potentially corrupted memory beyond the terminating zero if an empty string was passed in.
    • Fixed an issue where the string loaded from background layout files wasn't zero-terminated correctly before parsing.
    • Fixed buffer overflow and some unsafe string operations when un-mounting file system paths.
    • Fixed buffer overflows in demo parsing. (HL Github issue #1654)
    • Fixed heap corruption issue that would occur when destroying stack-located instances of UtlBuffer.
    • Fixed Mod_Extradata() accessing model data incorrectly for sprites.
    • Fixed some garbled and/or misleading error messages.
    • Fixed script includes not working between the different game folders ("svencoop", "svencoop_addon", "svencoop_downloads", etc.) on dedicated servers.
    • Host_EndGame messages are always printed to the console now, even if the "developer" CVAR is set to "0".
    • Legacy sound system: Removed support for automatic ambient sounds, including the "ambient_level" and "ambient_fade" CVARs. (Quake feature, broken and unused in GoldSrc.)
    • Linux: Fixed a client crash when changing video settings.
    • Linux: Removed i486 binaries.
    • More specific reason is provided if the engine fails to create an SDL Window.
    • Server Browser: Removed default ping ports not related to GoldSrc based games.
    • Resolution of chrome textures is no longer locked to 64 x 64 px.
    • The UI code now uses separate pathID "UI" to load resources. (Only relevant paths are searched now.)
    • Video Options: Everything with aspect ratio >= 1.4 is considered as a wide-screen now.
    • VGUI2:
      • Combo box, check box, radio button, scrollbar, and frame now use Marlett font glyphs for their graphics.
      • Fixed editable panels not resizing correctly.
      • Fixed fonts being too large on Linux compared to Windows. (Proper height to PPEm calculation is used now.)
      • Fixed some fonts not loading on Linux.
      • Minor visual tweaks to some of the VGUI2 controls.

    Sound

    • Attack trace line strike sound now uses the new dirt/grass impact for CHAR_TEX_DIRT
    • If a material definition is too long it will be trimmed until it fits. (Still logged it as a warning though for the mapper's attention.)

    Non-playable characters

    • NPCs using an MP5 will now use 1 of 3 sounds randomly when firing instead of just 1: Bodyguard, human grunt (HL and OP4), male assassin, and robot grunt.
    • [HWGrunt] Will now stop firing the minigun if launched into the air.

    Weapons/Items

    • Fixed a holder's item (item_inventory) list pointer being wrongly nulled even when they still have items, for example ones that can be kept on respawn.
    • Fixed an issue where the active weapon wouldn't get detached from the player when he died and used cheats to revive himself.
    • Fixed ammo and weaponbox entities not firing their targets when collected.
    • Fixed the player's MP5 only pre-caching and using 1 sound instead of all 3.
    • Weapon pick-ups now retain their target name, target, colour map, skin, and body when respawned.

    Events

    • All options are described directly in "event_info.txt".
    • Console commands:
      • "ev_list" - lists all detected events
      • "ev_scan" - scans for new/updated events
      • "ev_curtime" - prints the current (UTC) time as returned by Steam API
      • "ev_enable <event_name>" - enables event
      • "ev_disable <event_name>" - disables event
      • "ev_activate <event_name>" - force-activates event
      • "ev_release <event_name>" - deactivates force-activated event

    Maps

    Abandoned

    • Moved second checkpoint away a bit and placed it next to the chair inside of generator room.

    Crystal

    • [Part 2] Added one barnacle weapon right below checkpoint at middle of jumping puzzle.

    Judgement

    • Added objective signs in the central area.
    • More explosives available.
    • Reduced Garg HP from 3000 to 2500 on hard.
    • Reduced round time from 10 to 7 minutes.
    • When playing with reduced weapon respawn rate: Weapon respawn frequency changed from 7 to 5.5 minutes.

    Single player campaign portal

    • Added They Hunger campaign.
    • Changed paths of sounds, models and scripts to one name pattern.

    Sounds

    Other

    • New impact/ricochet sounds for dirt/grass and sand/gravel.

    SDK

    FGD

    • Added "Glow Shell" to render effects.

    Map compile tools

    • MAX_MAP_PLANES is now 65535. (Limit of 32767 was only there for the faces limit, which is now 65536.)

    StudioMDL

    • Bones with attachments are always preserved.
    • Brand new help screen.
    • New command line argument "-k": keep all unused bones.
    • New QC command "$keepallbones": keep all unused bones.
    • New QC command "$keepbone <bonename>": keep specified bone even if unused.
    • New QC command "$protected <bonename>": same as "$keepbone" (Added for compatibility with DoomMusic's StudioMDL).
    • Removed UV clamping. (This was only ever supposed to be used in the removed "$cliptotextures" mode.)
    • Resolution of chrome textures is no longer locked to 64 x 64 px.
    • Tweaked few error messages; added new warning messages.

    Other

    Misc

    • Linux SvenDS launcher:
      • Added a warning message for users running as a root (why would you do that?
      • Double quotes wherever was needed to avoid issues with spaced strings.
      • Host CPU family below 6 (i486) will just quit the script. (We're not in 80's/90's any more!)
      • If "-map" is not specified at start-up, _server_start is used by default. (Can be disabled with "-nodefaultmap".)
      • Improved auto update feature:
        • Added support for updating with passworded branches. (-beta_password)
        • Added support for SteamCMD script. (-steamcmd_script)
        • Tries to auto detect SteamCMD binary location if "-autoupdate" is specified without "-steam_dir", either from system installed (package manager) or "$svends_dir/steamcmd" folder (vanilla GoldSrc way). User defined "-steam_dir" overrides this even if it is invalid! (Skips auto-update if none is found.)
      • Increased "ulimit -c" max core file size settings to "unlimited". (This has no effect without "-debug" parameter.)
      • Lots of optimization and standardization.
      • Re-implemented auto detection for CPU vendor and selecting proper binary (svends_i686 or svends_amd). This was previously available in older GoldSrc script. (Can be overridden with "-binary" parameter.)
      • Removed unused console log option.
      • Replaced forum URL with Discord vanity URL in crash message.
    • Server example configurations:
      • Added a read-me to guide you though what the folder is for and how to use it.
      • Added more profile examples with lots of improvements.
      • Changed "sv_zmax" to 32768.
      • Changed misspelled "sv_player_log_frequency" CVAR name to "sv_log_player_frequency".
      • Renamed "servers" to "servers_example" so Steam updates don't ruin your changes.
    • Removed "platformconfig/InGameDialogConfig.vdf".
    • Removed reslist files.

    Version details

    Steam build ID numbers: Game 3482406, dedicated server tool 3482409, SDK tool 3482410.

    Please use the steam build ID number as a reference when posting an issue or query on our message boards. You can find the build number you currently have within Steam by right clicking our game or tools, selecting Properties, then selecting the Local Files tab.

    Adam "Adambean" Reece
    Sven Co-op team

    Also on: Steam | Facebook | Twitter | YouTube | Twitch
    Released AMXX plug-ins: Bind number slots | NextMap with Sven Co-op fix | Sven Co-op administrator icons

  2. #2
    Administrator Hezus's Avatar  
    Manager
    Join Date
    Aug 2001
    Location
    The Netherlands
    Posts
    9,054

    Re: 20 years of Sven Co-op! -- Sven Co-op Update Released [Build 3482406]

    Happy birthday Sven Co-op

  3. #3
    Custom User Title tweak's Avatar
    Join Date
    Oct 2001
    Location
    Tucson, Az
    Posts
    2,995

    Re: 20 years of Sven Co-op! -- Sven Co-op Update Released [Build 3482406]

    Happy birthday! 20 years, one more and you can drink in the US.

  4. #4
    Registered User Arakis's Avatar
    Join Date
    Oct 2018
    Location
    Earth, Milkyway
    Posts
    4

    Re: 20 years of Sven Co-op! -- Sven Co-op Update Released [Build 3482406]

    Hi everyone @ Sven Coop Team,

    congratulations and happy birthday to Sven Coop. Thank you for all the years of fun!
    My Lamarr says also hello. ;-)
    Click image for larger version. 

Name:	lamarrhome.jpg 
Views:	197 
Size:	95.3 KB 
ID:	18289

  5. #5
    Pirate Octopus codemanj94's Avatar
    Join Date
    Oct 2016
    Posts
    4

    Re: 20 years of Sven Co-op! -- Sven Co-op Update Released [Build 3482406]

    Congrats on 20 years. Quite the feat. How many other games have lasted 20 years?
    Thanks to all the devs through the years : )

  6. #6
    Registered User seaal's Avatar
    Join Date
    Jul 2013
    Posts
    15

    Re: 20 years of Sven Co-op! -- Sven Co-op Update Released [Build 3482406]

    Awesome. Happy birthday SC

  7. #7
    REE3 The303's Avatar  
    Contributor
    Join Date
    Jul 2015
    Posts
    398

    Re: 20 years of Sven Co-op! -- Sven Co-op Update Released [Build 3482406]

    Happy birthday!

    Also just a quick mention for those who may have missed:
    Files created by the engine (server logs, tempdecal.wad, custom.hpk, user.scr, settings.scr) now use the "GAMECONFIG" PathID to make sure they will always end up in the main game directory ("svencoop") even if some other path was added later on ("svencoop_hd", "svencoop_event_*" etc.).
    Means that custom spraylogo won't work unless its back in the base svencoop dir so: Move your tempdecal.wad back to svencoop folder. Don't forget to mark the file as read only.

  8. #8
    func_vehicle enthusiaist w00tguy123's Avatar
    Join Date
    Dec 2006
    Location
    U.S. West
    Posts
    1,599

    Re: 20 years of Sven Co-op! -- Sven Co-op Update Released [Build 3482406]

    My favorite change is missing from that changelog:

    • The pistol and mp5 sounds no longer cause permanent hearing damage.
    Love,
    w00tguy

  9. #9
    Registered User
    Join Date
    Jan 2019
    Posts
    1

    Re: 20 years of Sven Co-op! -- Sven Co-op Update Released [Build 3482406]

    Happy 20th Anniversary beloved Sven-Coop. I love you so much and I hope you will live another 20 years. Now is just the right time to donate to our dear Sven-Coop team. See you kickin' some Alien arses.

  10. #10
    Advanced Leveldesigner SourceSkyBoxer's Avatar
    Join Date
    Apr 2011
    Location
    Germany
    Posts
    803

    Re: 20 years of Sven Co-op! -- Sven Co-op Update Released [Build 3482406]

    Happy birthday Sven Co-Op....

    But I don't understand why do they not close Forum? I am disappointed. And how is fix for enlarge of -/+32K max range? If you move to than you get black viewport
    Hello guys, Svencoop. I am sorry Please respect me! I am deaf. Thanks, Sven-Coop Forum!

    Please do not share to shit dropbox! Please share only Mega.nz!
    Muhahaha, Facebook crashed!

  11. #11
    I am the Evil slippery's Avatar
    Join Date
    Aug 2001
    Location
    Australia
    Posts
    1,982

    Re: 20 years of Sven Co-op! -- Sven Co-op Update Released [Build 3482406]

    Holy crap guys...20 years...I was 12 when this came out haha

    As I walk through the shadow of the valley of Death, I shall fear no evil, for the valley's are gone, and Death awaits, and I am the Evil

  12. #12
    Registered User minmi96's Avatar
    Join Date
    Sep 2014
    Location
    Paris (Nah not really).
    Posts
    26

    Re: 20 years of Sven Co-op! -- Sven Co-op Update Released [Build 3482406]

    Happy Birthday Sven Co-op!

    Big cheers to one of the oldest and best Half-Life Mods out there!

  13. #13
    Registered User StevenKal's Avatar
    Join Date
    Feb 2019
    Location
    France
    Posts
    3

    Re: 20 years of Sven Co-op! -- Sven Co-op Update Released [Build 3482406]

    hi, and Happy Birthday Sven Co-op!

    I know and play this game for a while, and like the way it is and that it exposes to us (fighting HL's monsters with friends!), even if I usually prefer the other "mythic" game most played...
    I also want to thank you for updating it, unlock it and add new interesting features.

    Meantime, I'm not always been a fan of some of your changes, or, your goals/politic, and "how noobs you seem when it's about keeping backward compatibility".
    I usually prevented to come on your forums, send a private/public message for this, but the both recent news I didn't like indirectly forced me to do so. Because it's a bit too much "abusive".

    Why? Because being a Windows XP user (and even fan), I'm directly concerned...

    Is it some kind of fashion mod to drop old OS support nowadays? Because this doesn't make me laugh.
    Seriously, why are you dropping support for it?
    - *Joke*: Did VALVe paid/threaten you in order to force you to obey to their stupid politic against old OSs and the forcing + stupid reasons that come with it behind...?
    - Is it due to the fact you wish to "follow VALVe politic" with "stupidity"? (no offense)
    - Is it due to the fact you are lazy to compile your stuff with an XP compatibility? (as a problem we had after the first release where the client didn't work on XP, due to Visual settings...).
    - Is it due to the addition of some new features we "don't care" (features that could require the use of a more recent OS's API)?
    - Other "stupid" reason? (as you being addicted to "overoptimization" not really necessary nowadays due to the enhanced power of most of the computers).
    You say "...which ultimately ends up in a better product for all of you", no, not for me, if I can't run it, your update(s) just become less good (in order words, a crap for me)!
    And you are gonna sounds more for me, like a group of unconscientious developers who don't care much about "user service/reliability/quality".

    This decision, is for my opinion a SHAME!
    Why?
    Firstly, I'm concerned and I don't want to change my OS, neither put another one on another partition, setting on reboot or via Virtual Box, you & some other "head guys" (as VALVe) don't seem to realize that changing an OS is something a "little big and annoying", something the users (especially the addicted to "XP" like me) are not motivated to perform.
    So you basically put users like me, in "the mess". That's very kind of you...
    Secondly, as much as you change/improve that game, it "stills" remains an old GoldSrc game (in the concept), and should work under an XP system, the main system on which one it has been frequently used over the years. There is for me no discution about that, and your "drop XP support" should not happen for your game.
    Also, the "modernism" is for me, supposed to improve things, not the reverse, and I see that with Sven Co-op, modernism sucks with updates! Since you are dropping a support.

    For the "offusced/overreacting ones" who are wondering, why I'm still using XP?
    This is "mainly" for its old-school interface style I like much, I have 7 on a netbook, I don't like it, and don't even get use to it, this even make me angry when I browse a few things and I'm happy to use again my main computer with XP interface more user-friendly.
    I secretly dream about an XP being overpowered, with 64bits, more powerful API in order to handle more softwares/games I can't currently run, etc., but I don't run such things, so I don't really care (one more reason why I'm still using XP).
    For sure, I'll like to play a few modern games, but I do not complain if I can't, but if there is something I dislike much, is when something I currently run, can no longer from an update due to stupid developer(s) decision(s). This is not a good proof of consciousness.
    And about security, well, I'm not gonna saying that some people who say "XP is not secure" are wrong, and neither say myself "XP is more secure than a modern OS", but I think it is not as critical as it sounds. I'm using it from its release, in SP3 Pro, I never had any major problems, if you use third-party softwares (antivirus, etc.), properly configured, and also take care where "you put your feet", and what you download, etc., it's safe from my opinion.
    People have to take care where they go, what they download, etc., and don't look for security risk themselves, but well, if they need to be assisted in that, like childs, that's another story.
    I also use my logic and think about "all the modern softwares that do not work under XP", and also tell myself, that it's strongly possible a lot of modern "hacks" do not work on it...

    Some other XP/Vista users may have other reasons than me, most of them will be "I have no money to buy a better computer in order to handle a more recent OS", despite the fact this might be true for a lot of people, I also think it's not the case for some others, and such reason make me laugh a bit!
    Because probably the guy has a recent cellphone/tablet, but no money to change his computer, knowing today, you can get a correct computer for not a lot of money (as a good from a second-hand), and a computer is for me a way more useful/powerful/convivial/user-friendly than a short cellphone/tablet & cie... People concerned should better not comment about that...

    Also, I'm concerned about the Glibc < v2.24, since I've a VPS under Linux with Debian 8 Jessie (Glibc v2.19). I've not updated it yet, I've read somewhere I apparently could without reinstalling everything or putting another version as Ubuntu, etc., by directly move to Debian 9...
    But if in case I need to reinstall from scratch, this will also piss me off a bit, because I have other things to do than that...(and some other things installed on it, as 7 GoldSrc servers...).
    So still one more case where you abuse a bit, XP, Linux's glibc < v2.24, what's next? Windows 7, 8?

    Right now, I've not yet updated my Linux server, but I have a client build "00:18:31 Jan 18 2019 (8121)", I'm guessing it's the latest one, and I touch wood, but strangely, it works... even a new dedicated server under Windows just downloaded (build #8121), works too (I was able to launch and play on it).
    I think it will be nice if you put this version in the changelog additionnaly to the Steam build too (when the client type "version", or "sv_version"), as additionnal information.
    I also suggest you to lock the "sv_version" CVar from being changed by the client (in case the server wants to query that CVar in order to detect that client version/build, even if he may be dropped when not matching with server's one).

    I'm personnaly the developer of a program that can work under SC (you'll see which one by looking on one of my profile field, as admin...), and I've already set up a very good & unique compatibility with various engines & games, and when I'll release it, it will be the best in that domain...
    Adding various support for a lot of things, whatever old or new is maybe a pain, maybe more tests, more time, etc., but it's usually feasible, all depends of how much time and power you want to allocate to this (and the motiviation level you have too).
    And in a world where most of the developers refuse to do this, and directly choose to use the latest API (provided by OSs...) for their work, and drop, in consequence, the support for old OS, I choose to do not (at least not only), and think to all people like me still addicted with those old OSs, etc..
    Maybe none of you devs are using such old OSs, but some of your "users" do ("hi! I'm here! My pet XP is with me!" ).
    I also get mad sometimes because of the internal game data you frequently "fucked up" on almost each updates.
    About "game data", I mean, the virtual functions list and classes members (like CBasePlayer's "m_iClientHealth", etc.), because since there is no source code, I have to find this manually at through IDA and the generated decompiled binaries in .c, so believe, me, I spend a lot of hours for this, and multiple times... this is not very long for the virtual functions IDs, but for the members this is a way much more long and exhausting.
    That's why for now I'll only update it at the end, just before I release my stuff publicly.
    Basically, this is not "your fault", you simply update your game, change or add new functions, but that I can blame on you is the lack of detailled informations or source, designed to be useful for 3rd-party game programs developers like me.

    So I use this occasion to suggest you a few things about that:
    - For my stuff above, I use the AngelScript doc as help (from this: https://baso88.github.io/SC_AngelScr...cs/Classes.htm), but it's quite incomplete, or duplicated and in mess (the members are normaly not in the same order as declared in the game source files from that I remember), or, this is only for AngelScript internal data, nothing more.
    So will it be possible to improve this doc/listing? Like by listing properly from scratch, based on the .h files where are declared the game's functions list & members? Or is this only linked to the data exported to AS rather than the whole implemented in the game itself?
    - Or, if previous request not possible, could we have, on each update, a more detailled changelog, or two separated changelogs (one public, as you currently doing, another one, more detailled, specifying for example, when you change (parameters order/number/type, as "FVisibleFromPos" different from SC v4.* to a v5.*, etc.), remove, add a function [virtual especially], or a member)?
    - Or, even if I know this has been discussed on the past, if we could have some kind of "partial source code of the game", I mean, a source code that will only contain the "headers", so usually, most or all the .h files. I think this will be really useful for developers like me, and for all the other people, they could see the functions format, classes members, and this will be quite helpful for their plugins.
    And for you, you won't release much, at least not the critical things you're afraid to release, against forks, etc., things I truly understand since I'm not an addict of source codes being released publicly too.
    At worse, you could remove some functions in the .h files (the ones you don't like to show and unrelated to that I've asked, as some "inline" types, etc.), then also maintain this code separately on each update and release it on a web page, like for the AS doc.

    I also enjoy of that occasion to make some suggestions about fixes/changes or new features.
    This following list is based on some "things" I had stored on a .txt file long time ago, but never complained or exposed that to you.
    I've seen some of them having been fixed, as dedicated server command line "block" that disappear when we put the cursor on the prints area (so I had removed some ofthem among my list), but some others probably do not (I've not tested again recently), so just ignore the ones unconcerned.
    I've also had a lot of other things & suggestions in mind, at various times, but not implemented here because I just forgot to list them, I'll do when they will come back to my mind and probably suggest them to you.
    Keep in mind if some of those fixes/changes interest you, that having the control over them will be nice (so a command/CVar for).

    List:
    • #1: Engine -> CmdArg* behavior... (& related functions).
      Notes:
      This apparently was a problem at the first SC v5.* release(s), where the usage of quotes where required around the arguments of a command (as "amx_slap #54" didn't work, we had to type "amx_slap "#54"" for a proper working), this kind of change you did was very bad, because this make the users have to get use to another kind of command line format (so another method, well, think when they come back on another game that do not use that format and when they are get use to do not add quotes around...), and it was also not necessary to have quotes for such argument.
      I think I do not need to say you that such bad change also broken the AMX/AMXX plugins that kicked/banned a player... So please don't do that anymore!
      At worse, if something had to be done with the command args behavior, it's with the colon (, present on the SteamIDs, in order to do not skip it (like if it was a space), so we could type "amx_slap STEAM_0:1:1234567" and the whole "STEAM_0:1:1234567" will be considered as argument, instead of just "STEAM_0"....
      This could normally easily be "fixed" by patching the "com_ignorecolons" global variable in the engine.

      #2: Engine -> Increase "setinfo" limit from 256 to at least 512 (if not already made).
      Note: Useful for storing informations client-side, since this buffer is quite limited.

      #3: "Aura bug" around the player when using the flashlight.
      Note: I personnaly consider the "EF_DIMLIGHT" flag more as a bug, even if this always have been like this in HL & other games, this is for my opinion not realistic, it's normally supposed to be a "flashlight", which enlight toward a direction (like this: https://www.youtube.com/watch?v=ZOTq4MGU2yM), and not by enlighting around the player like a torche with flame we use when we are searching a mummy!

      #4: Adding support for colored chat (like under CS, or in Xash3D client [more extended than the CS's one], and also for colored menus, like under CS/DoD, and recently HL, TFC, DMC from 2013 (https://github.com/ValveSoftware/hal...l_dll/menu.cpp).

      #5: Prevent the client to alter the value of his "sv_version" CVar (used to let the server query it and know the right value, even if there is probably no client who alters it on purpise).

      #6: Some maps have been reworked to be more "dark" (or there was a specific setting [command/CVar] I've missed about that), but I remember having playing some maps at the firsts SC v5.* releases, and suddently on an update I've discovered they became much more dark.
      I have f.lux program in background which reduces the light, but even by turning it off there were still too much dark for me.
      I don't know who is a vampire among you, but too much "light" is bad, too much "dark" is bad too, this hurts my eyes because hard to see and force your vision to focus more.
      A good compromise should be kept for such maps with darkness, as hunger types, etc.
      Also, some "good" maps that have been removed on the past, as "richard_boderman", apparently from author's decision. I'm wondering which author will like to see his map having the privileges to be among the "official ones" to be removed on request, kind of stupid from my opinion, but well, that's like that.

      #7: I remember when I grabbed some monsters, then drop then in air "just like that" (from a high distance, as on borderman), they blowed up in the air in gibs, before hitting the ground...
      And I precise I wasn't make them move toward the ground with the grab (in order to smash them in force), I just let them fall themselves from a 0 gravity to the ground.
      This is quite not realistic... they should only blow up once ON THE GROUND, and only on higher speed/damage... and depending on the health...

      #8: M16 weapon, increase the speed of the grenades fired from the M203 launcher, this is currently (and has always been), non-realistic, compared to that the real speed can reach (basing on units to meters = x0.0254), which is usually x3 faster (see wikipedia, where this ejects at around 75m/sec, so around 3000 engine's units).
      Of course, this obeys to original HL's behavior, but a lot of things in the original games are not a very good reference about realism.
      Having a CVar to control this will be nice (like "mp_m203_speed_multiplier", whatever).

      #9: Increase firerate of the M249 (see real specs on Wikipedia).

      #10: Adjust the size of the explosion sprites according to how much we change the damage (sprites became big too soon once we slighly increase the "sk_" CVars...).

      #11: The switch ON/OFF of the electric mod of the crowbar is too fast (delay between).

      #12: Consider the things I've talked previously about AS doc content for functions/members, or partial source, etc..

      #13: Adding more "errors" on dedicated server launch could be nice (as it's the case with old HLDS builds).
      For example, I have the SC game running on port 27015, I try to launch an SC dedicated server on port 27015 (default port on first install), I click start, and it shut down without "BANG error" as on the past. You should add back that to tell the users what was wrong, because I'm pretty sure a few spend some time to figure out why the server refused to launch.

      #14: Breaking some default GoldSrc/valve constants (and other things like I said on #1 about commands behavior), as the "SF_NORESPAWN", which is 1024 on your game, is a kind of critical/bad for my opinion.
      I was wondering why the hell a weapon created from the "give_item" native respawned, I quickly figure out why, and I didn't really liked you broke such thing even if I can easily fix, as least internally quickly.
      It's probably since you've added new ones, and since the HL's SF_NORESPAWN value was already big and close to the 32 bits limit for a single value (1<<30), so it's understandable a bit, but if you can avoid this in the future this will be nice, or, always keep us informed in the changelog.
      Even if from that I remember, it's not new, and was already the case on the old 4.* series.
      But well, this kind of change brokes (or cause troubles) a lot of AMX/AMXX plugins, and I've the feeling you like that a bit and you don't care about such addons, and favorise more your "AngelScript".
      Again it's understandable a bit, you promote "your thing", but well, AS is more SC specific, while AMX/AMXX can work for all the rest, are also addons much more user-friendly that AS will never will, and also addons the users having other servers under different games (as CS) are get use to it.
      So, for them, I suggest you to care more a bit about those addons.
      AS is maybe "something new", something the "modern people/coders" like (due to new programming style/abilities), but it has a lot of disavantages against others known addons, disavantages non-negligeables.
      A few:
      - Far to be as much as user-friendly (I personnaly don't like its design, config files, etc.), while AMX/AMXX are a way better for this, and in-game too, with default plugins, menus, etc.
      - The coding style is close to the C++, which, basically requires a more advanced knowledge while in Pawn it's much more easy to understand, especially for newbies, even a lambda server user who never coded can easily give a try and success at modifying his plugins.
      - Much more plugins and programmers...

    And me who is more in favor or normal users, rather than programmers, AMX/AMXX are a way more interesting for them. I remember you that there is a way much more "users" (server owners + admins + players, who can use those programs), rather than coders...

    You could, for example, expose an API and inform us about (a global variable you export and matching to a list of functions in a structure, as the engine API functions such as "pfnPrecacheModel", etc. is the best and easiest for hooking and retrieving addresses of each functions [knowing the base var address, we just add +4 bytes as offset between each func, and we have our addresses...]).
    Then a powerful module dealing with memory can easily deal with and do that you can with AS.

    Voilà!

    If in case of my post might sound a bit offensive, I apologize for this, this was not my intention, because I have respect for your job, and appreciate all of your efforts to make that game better than ever! And I wish to thank you for all of your time passed on it.
    Besides, I have even contributed a bit to it (from the v5.* release), by putting an ads on my website toward yours!
    But you also have to put yourself "in my place", and understand me and my position. Look, I've XP, I play sometimes on it, or secretly code stuff for it designed to be released in a near future, but I see a news that tells you decided to drop XP support, so even if it's not the case today (I can still play, as I said), this might be in the future, so I problably would not be able to play on it on my system. Well, I'm not gonna say "thanks for this" huh...
    And, I see "VALVe" which does his thing, with its "shit politic against XP/Vista", now you who follows... So I'm a kind of angry.

    For sure, I could come in the past, write some comments about your game, but I was a little lazy, then I've some kind of behavior "nothing or all", so either I don't want to write, either I go for a roman like this. And I've decided that today was the day for it!

    If at worse, you don't like my message and wish to hide/remove it, or continue in PM, I won't like much (more for the XP part) but I'll understand. Or if you feel that my post will be better among the previous news, feel free to move it.
    But keep in mind that matters to me is the fact you consider my requests (and so, do your best for it), mainly about XP (and answer if possible, the rest is kind of facultative/pointless).

    One question:
    The standard HL engine is entitled "GoldSrc", "ReHLDS" is "ReHLDS", Xash is "Xash3D" or "Xash3D FWGS", does your engine has a specific name?
    If yes, please tell me the exact one! Thanks!
    ... knowing the amount of changes on it and its unlocked content (as resources limits, etc.), it will be stupid if it's still exactly named as "GoldSrc"!

    Cheers!
    Last edited by StevenKal; 04-02-2019 at 05:01 PM.

  14. #14
    Donated 15NS$ for Sven's Holiday at the Bahamas Puchi's Avatar  
    Artist
    Join Date
    Nov 2002
    Location
    Akihabara, Bochum or Sailune
    Posts
    5,618

    Re: 20 years of Sven Co-op! -- Sven Co-op Update Released [Build 3482406]

    Only going to reply to your issue with us "not supporting" AMXX/Metamod correctly:
    It is not our job to update third-party mods/addons like this.
    Whoever is working on either can contact us, which was actually done in the past and not so long ago, and we give them whatever they require to make Metamod fit for SC again.
    Do it with passion, or not at all.
    Do not say everything you know. Know everything you say.
    [ MarySP ][ nacl-h2o ][ The next SC Version ♥♥♥♥ing pwns! ][Puchis Maps ]

  15. #15
    Administrator JPolito's Avatar  
    Manager
    Join Date
    Apr 2004
    Posts
    7,555

    Re: 20 years of Sven Co-op! -- Sven Co-op Update Released [Build 3482406]

    Please read this Steam support article:

    https://support.steampowered.com/kb_...1558-AFCM-4577

    Starting on January 1 2019, Steam will officially stop supporting the Windows XP and Windows Vista operating systems. This means that after that date the Steam Client will no longer run on those versions of Windows. In order to continue running Steam and any games or other products purchased through Steam, users will need to update to a more recent version of Windows.

    The newest features in Steam rely on an embedded version of Google Chrome, which no longer functions on older versions of Windows. In addition, future versions of Steam will require Windows feature and security updates only present in Windows 7 and above.

    For the remainder of 2018 Steam will continue to run and to launch games on Windows XP and Windows Vista, but other functionality in Steam will be somewhat limited. For example, new features such as the new Steam Chat will not be available. We encourage all users on these operating systems to upgrade to newer versions of Windows in order to have ongoing access to the latest features of Steam, and to ensure future access to all games and other Steam content.
    Steam is no longer supported on Windows XP or Vista. Sven Co-op runs on Steam. It is required in order to play the game. Therefore, we cannot fully support Windows XP.

  16. #16
    Super moderator GeckonCZ's Avatar  
    Programmer
    Join Date
    May 2014
    Location
    Great Moravia
    Posts
    261

    Re: 20 years of Sven Co-op! -- Sven Co-op Update Released [Build 3482406]

    Quote Originally Posted by StevenKal View Post
    Windows XP ... Seriously, why are you dropping support for it?
    There are multiple reasons, I'm only going to list some of the more important ones:

    1. As Josh pointed out, Steam no longer officially supports Windows XP, and Steam is the only distribution platform for Sven Co-op. (Yes, Steam still runs on XP, and so does Sven Co-op, but that's not gonna last long...)
    2. Windows XP is dead. At least when it comes to gaming. According to Steam HW Survey, XP is used by less than 0.1% of the Steam users. And Vista isn't even listed there. The number may not be perfectly accurate for our playerbase, but even if it was 10x more in our case (and I very much doubt that), it would be still less than 1%. I think it makes more sense if we spend our time making the game run better on modern systems - for the remaining 99%...
    3. Nobody on the team uses XP or Vista (not counting VMs here), so we are unable to properly test the game on these systems.
    4. We are updating our build process, including the toolset used to compile the game/engine/tools. Some of the engine components were compiled using the old VS60 tools. This was a major inconvenience and bottleneck for future updates. Everything is currently (SC 5.18) compiled using a much newer - VS2010 - toolset. We are going to upgrade everything to VS2017 soon, and binaries produced by this toolset are not XP-compatible. Why another update? Well, in general newer tools are safer, faster, and provide you with many new features. The last update already helped us discover many hidden issues. We could use the XP-compatible v141_xp toolset, and we may actually do it, but even if that happens, XP will be still officially unsupported, because of the other points listed above.

    So, no, dropping support for old operating systems is not our laziness. Sorry, but from your comment it seems that it's you, who is lazy to do something about this situation. Yes, we are very well aware that in some rare cases the player may be stuck with XP because his/her HW is simply too old to run anything newer (performance concerns, driver compatibility issues etc.), and he can't afford HW/SW upgrade. That's unfortunate. We value every single player, but at the same time we simply don't have the resources to make everyone happy - I'm sure there are still some sad Half-Life/Sven Co-op fans, that are stuck with Pentium 200, Voodoo 2 and Windows 98, or something similar. Should we support their HW/SW as well, because the old WON Half-Life builds did? Perhaps... Is it a realistic goal? No.

    Btw, you can make Windows 7 look and "feel" pretty much identical to Windows XP, if that's really that important for you. And it's only a few clicks!

    Quote Originally Posted by StevenKal View Post
    Also, I'm concerned about the Glibc < v2.24...
    That change was necessary so we can provide better support for newer linux releases. Pretty much everything that can run Jessie will run Stretch as well, and the upgrade process is fairly simple. So this really shouldn't be a problem. All active server OPs were informed about this change in advance. And since the release I think we have got only one report where this caused some problems.

    Quote Originally Posted by StevenKal View Post
    ...what's next? Windows 7, 8?
    Rhetorical question probably, but I'm gonna answer anyway. All mentioned systems are still quite popular, and there is no technical or other reason to end support for any of them at this point or any time soon.

    Quote Originally Posted by StevenKal View Post
    And you are gonna sounds more for me, like a group of unconscientious developers who don't care much about "user service/reliability/quality".
    Quite the opposite actually, and that's also one of the reasons why this decision was made. We have to focus on environments used by the majority of our players/server OPs.

    Quote Originally Posted by StevenKal View Post
    I also suggest you to lock the "sv_version" CVar from being changed by the client (in case the server wants to query that CVar in order to detect that client version/build, even if he may be dropped when not matching with server's one).
    Is there a specific case where this could cause problems? The CVAR is unlocked in vanilla GoldSrc as well afaik, and I have not seen any bug reports related to this. Can you provide more info?

    Quote Originally Posted by StevenKal View Post
    I'm personnaly the developer of a program that can work under SC...
    Are you talking about the original AMX? I thought that thing died like a decade ago. Well, I hope you were not involved in the backdoor fiasco... Anyway, the way Metamod-P/AMXX (let alone the old Metamod and AMX) works, is really ugly and terribly unsafe. And as you said, it breaks even with regular code changes. That's also why modules like this are not officially supported. That being said, if there is a way to make life easier for devs of popular addons/modules, we usually don't say no. That's one of the reasons why I have restored compatibility with vanilla Metamod-P, and that's why we provide our header files to trusted community members (like the AMXX team).

    Quote Originally Posted by StevenKal View Post
    For my stuff above, I use the AngelScript doc as help (...), but it's quite incomplete, or duplicated and in mess (the members are normaly not in the same order as declared in the game source files from that I remember), or, this is only for AngelScript internal data, nothing more.
    That's because this is documentation for our Angelscript API, not for the native classes, or anything native for that matter. The object model used in the Half-Life game code (and in Sven Co-op) is pretty bad, so some of it had to be changed. Order of the methods/members may vary as well, as that is not a concern for the AS API/documentation. This is intentional and the documentation will never mirror the exact structure of the underlying C++ classes 1:1.

    Quote Originally Posted by StevenKal View Post
    ...if we could have some kind of "partial source code of the game"...
    See above. But it may be worth it to build a script that would extract the relevant header/source files and pack them for every release. If there is enough interest, we will consider it. It would be provided as-is.

    Quote Originally Posted by StevenKal View Post
    #1: Engine -> CmdArg* behavior... (& related functions).
    I don't recall that and I wasn't involved with any CmdArg change afaik, so I can't comment on this one. In general we are trying to avoid compatibility breaking changes, but sometimes mistakes happen, and sometimes it's simply unavoidable. When you are working with 20+ years old code base, one has to be extremely careful when touching anything.

    Quote Originally Posted by StevenKal View Post
    #2: Engine -> Increase "setinfo" limit from 256 to at least 512 (if not already made).
    There are multiple different limits related to this, but the actual array is limited to 256 chars I think. It's also part of some public structures iirc, so changing it could break things. Probably not gonna dig into this now...

    Quote Originally Posted by StevenKal View Post
    #3: "Aura bug" around the player when using the flashlight.
    We have already changed how that works, and it partially solves this "problem". There is an issue with the current implementation where it causes the "cone" to jitter up and down in 3rd person view (but it looks fine for other clients) - that will be fixed.
    The flashlight will be completely reworked with the renderer update.

    Quote Originally Posted by StevenKal View Post
    #4: Adding support for colored chat...
    Yes, this is on our list already.

    Quote Originally Posted by StevenKal View Post
    #5: Prevent the client to alter the value of his "sv_version" CVar...
    See above.

    Quote Originally Posted by StevenKal View Post
    #6: Some maps have been reworked to be more "dark"...
    I don't think there were any changes that would cause this, and I don't recall anybody else reporting such issue. When did this happen and what maps are affected?

    Quote Originally Posted by StevenKal View Post
    Also, some "good" maps that have been removed on the past...
    Yeah this sucks, I miss some of them as well. But we respect the authors' decision.

    Quote Originally Posted by StevenKal View Post
    #7: I remember when I grabbed some monsters...
    That sounds like a bug. But what do you mean by "grabbing some monsters"? Some script? 3rd party module (i.e Entmod)? A video would help here...

    Quote Originally Posted by StevenKal View Post
    #8: M16 weapon, increase the speed of the grenades...
    #9: Increase firerate of the M249...
    Half-Life and Sven Co-op never had realistic weapons, and it's not even our goal. Balancing the weapons, so they work well from a gameplay point of view is much more important for us. Have you ever asked yourself how is it possible to fire two shots simultaneously with a single-barrel shotgun? Yeeaah... video games! But we do plan doing a major Arsenal Update, so some of this may and likely will change, but not for the sake of realism.

    Quote Originally Posted by StevenKal View Post
    #10: Adjust the size of the explosion sprites according to how much we change the damage...
    Will have to investigate how much would that impact existing content.

    Quote Originally Posted by StevenKal View Post
    #11: The switch ON/OFF of the electric mod of the crowbar is too fast...
    But it's fun! Personally I wouldn't change that, that's all I can say about this.

    Quote Originally Posted by StevenKal View Post
    #12: Consider the things I've talked previously about AS...
    See above.

    Quote Originally Posted by StevenKal View Post
    #13: Adding more "errors" on dedicated server launch could be nice...
    Yep, definitely. Better error handling and more informative error messages are one of my goals. If you check the changelogs you will see that we are trying to improve the situation, and that effort will continue.

    Quote Originally Posted by StevenKal View Post
    #14: Breaking some default GoldSrc/valve constants...
    When it comes to exposed constants (Angelscript, map entities etc.) most of them are likely never gonna change, as that would break existing content. The same is true for exposed engine consts. But internal game/engine consts can change at any point, and sometimes it's the only way (flags especially, 32 bits are not that much...).

    Quote Originally Posted by StevenKal View Post
    and favorise more your "AngelScript"
    You are not mistaken, we care more about Angelscript - because AS makes more sense for game like Sven Co-op - game that is in active development. We don't have many AMXX devs in our community, but we have quite a few Angelscript devs, creating interesting server plugins, map scripts, custom weapons etc. Both Angelscript and AMXX have their pros and cons and hopefully we will be able to improve the AS side to the point where Metamod-P/AMXX won't be necessary at all.

    Quote Originally Posted by StevenKal View Post
    ...does your engine has a specific name?
    Svengine. It's printed in the top right corner whenever you open the developer console. And unlike ReHLDS, Xash3D, Xash3D FWGS, and other similar projects, our engine is actually legal.
    Last edited by GeckonCZ; 05-02-2019 at 12:41 PM. Reason: typos

  17. #17
    func_vehicle enthusiaist w00tguy123's Avatar
    Join Date
    Dec 2006
    Location
    U.S. West
    Posts
    1,599

    Re: 20 years of Sven Co-op! -- Sven Co-op Update Released [Build 3482406]

    It's a big assumption that less than 1% are affected by this. It could be closer to 10-20% considering Half-life's requirements and how wide-spread the player base is. Few people bother to post/report anything anywhere. Many don't speak English.

    That said, I think most lowspec players got pushed out after the Direct3D and Software modes were removed (among other changes), so I wouldn't be surprised if it really is just 0.1% by now.
    Love,
    w00tguy

  18. #18
    Administrator AdamR's Avatar  
    Manager
    Join Date
    Mar 2004
    Location
    Cardiff, South Wales [UK]
    Posts
    8,593

    Re: 20 years of Sven Co-op! -- Sven Co-op Update Released [Build 3482406]

    Quote Originally Posted by w00tguy123 View Post
    It's a big assumption that less than 1% are affected by this. It could be closer to 10-20% considering Half-life's requirements and how wide-spread the player base is. Few people bother to post/report anything anywhere. Many don't speak English.
    We mostly use the Steam hardware survey filtered by Sven Co-op to help make these decisions, but we can't include those of you that opt out of this. Windows XP users need to opt in to these surveys if they want their voices heard.

    Quote Originally Posted by w00tguy123 View Post
    That said, I think most lowspec players got pushed out after the Direct3D and Software modes were removed (among other changes), so I wouldn't be surprised if it really is just 0.1% by now.
    The Direct3D cull was not our choice. (Valve did that for the Steampipe update.) It was our choice to cull software mode though, which was necessary for further progress of the engine.
    Adam "Adambean" Reece
    Sven Co-op team

    Also on: Steam | Facebook | Twitter | YouTube | Twitch
    Released AMXX plug-ins: Bind number slots | NextMap with Sven Co-op fix | Sven Co-op administrator icons

  19. #19
    Registered User StevenKal's Avatar
    Join Date
    Feb 2019
    Location
    France
    Posts
    3

    Re: 20 years of Sven Co-op! -- Sven Co-op Update Released [Build 3482406]

    Thank you for taking time to answer me and for the accuracy of those answers (especially GeckonCZ).

    It's clear that Steam & you talked about "dropping support", which normally doesn't really directly means "dropping compatibility", but more "we stop taking care, so if a problem happens, or if the compatibility is broken, this is not really our business, you have been warned before".

    Well, for Steam, it's just A SHAME, stopping supporting it is something, but recently (a few days ago), they just broken it for XP/vista users (you could figure out via a quick research with "failed to load steamui.dll"...).
    I don't know if it's a mistake and they are gonna fix that, or if it was made on purpose, but knowing their shit politic, I'll bet more for the choice #2.
    So, as a solution, I've used a backup and prevented Steam to auto-update, so I'm stucked with an old client, and I'm good with it and have even a few things that became bugged which are now working properly (and other people do or are gonna do the same for sure, since it's spreading quickly), because I don't really care about their updates which usually broke more things than fix problems.
    Sometimes, they seem to be made just in order to show us "they do something"...
    For example, I remember when we ignore a Steam friend request and the guy got the "blocked" status some times after, I though it was a compatibility problem due to my old XP system, but a guy told me he had same problem on Windows 10, so... they should better properly finalize the stuff they made rather than adding new "bugged" features.

    And this is more a shame the fact we paid games, give them some money, and at the end, they "do that to us" (nice is their way to say "thank you"), because we don't have an OS which feat to their wishes, wishes, which are to match to their stupid politics and partnership with other "BIG companies", as Google, Windows...
    And, for business reasons, because an user on XP usually don't play modern games which requires a more recent OS or computer's specs, so don't buy them.
    But well, if some people being forced to move to new OS will buy some of the games, I personnaly won't, because I don't want to give money to a company which have a bad politic, and also put me "in the mess" with their old OS support drop. No! No! No!

    For me, and for that they are doing (as the "steamui.dll" problem, if on purpose and not resolved), they deserve to be seriously negatively criticized and also put in justice... That's all!

    A lot of other things are very bad with them, as the "ads" they put in the CS v1.6 client (scoreboard & walls of official maps), they may say it's legal, well, as a good-sence concept, it's not.

    But well, I've talked a lot about them, lets change a bit!

    ------------------------------------------------

    For your case, it's a little different, mainly because your game is free, so it's normal for a guy like me, to be less exigent, and have more tolerance.
    But this does not prevent me to make hear my voice...
    Because I'm an user/client or your game, and by default, developers/companies are supposed to take care of the "service client", and do their best to satisty them. So this is logic that it's more to them to adapt to the clients's wishes than the reverse. Or, today, I've the feeling they start forcing us to adapt to their wishes/politic. So even if there are limits, I disagree with this.

    Your "thing" to obey to Steam politic, basically makes senses (at least, at the base). Meantime...
    - It's not because they does this to XP/Vista users that you have to follow blindly... I've to admit I'm even wondering a bit if they didn't forced you, since VALVe was "nice with you" by giving you a license for GoldSrc, etc., they may except some "return" in exchange...
    I'm just guessing... probably I'm wrong.
    - Even if they dropped support and apparently compatibility (see above), we are still able to use XP via the workaround I wrote, and until VALVe decides one day, to prevent us from blocking their updates, we'll still be able to play games at through Steam, as I'm able now.
    I'm guessing they won't dare prevent us to use that "trick", however a bunch of people will seriously complain...
    So for now, let's take in account the fact we can run XP/Vista with Steam and without expiration date.
    I run XP, and I want to still be able to play your game.

    I'm a little sad you didn't seem to realize how important is, "the compatibility", this is the base and most essential part of a program (for the users).
    Here is the order of "how you should think when you are developping something":
    #1: Make it properly working (including compatibility!), without bugs, crashes, security issues, etc.
    #2: Make it user-friendly, well-designed and so, pleasant to configure & use for the users.
    #3: Think about the quality (optimization, resources usage, performance, blablabla...).

    This order with those priorities, is how I develop my stuff, but I'm constating that a lot of developpers usually intend to be more focused (even addicted) on #3, rather on the #1 or #2... It's just absurd.

    And I'm sorry to say that, but right now, this is the case for you (and a reality), you are gonna drop the #1 (since your game will no longer work for me), the most essential.


    Quote Originally Posted by GeckonCZ
    We are going to upgrade everything to VS2017 soon, and binaries produced by this toolset are not XP-compatible. Why another update? Well, in general newer tools are safer, faster, and provide you with many new features.
    Safer, faster, many new features... Permit me to have a word with that.
    Safer, hum, I think you do not need to "count on the compiler" for that, it's more your custom code that should be properly made, and this will be safe (I'm talking in general programming, not for your game).
    As example, something like:
    PHP Code:
    size_t iLength strlen(szValue); 
    If in case we pass "NULL" as "szValue", this will just crash... (can be the case on a function like "CBasePlayer:ropPlayerItem" if someone passes "NULL" instead of ""...).
    So that's up to us to add related check before, or do something like:
    PHP Code:
    size_t iLength szValue strlen(szValue) : 0
    Besides, I've read somewhere that on the past, old compilers had such checks implemented in the functions, but this was removed since coders can make their own (avoid possible duplicate...).
    So, basically, the actual/newer are, at least for that case, less safer, not more.

    And about "faster", well, I'm guessing it's one of the main other reason you want to drop XP support, the "performance addiction"...
    Firstly, I also think quality of your code is a way more important for the performance, rather than the compiler "thing".
    Secondly, what do you really win with that, in term of performance (resources usage)? -0.5% of overal CPU use? Something like...?
    On the past, with weaker machines, looking for performance would have beene more interesting, but nowadays, with machines which can handle very well much more things, it's for me kind of facultative. But sounds like some programmers are addicted to that!

    If I can quote two others well-known projects as example (not to denigrate them), and which got the same problem by using modern compilers, it's about the "Re*" ones (ReHLDS/ReGameDLL_CS).
    Those modified binaries provide, for sure, various bug fixes & new features, and those guys extol the "performance" part with that, but not really those problems:
    #1: Both binaries do not work under XP (the server just crash on launch).
    Note: This has been already reported by some guys, but they don't care.
    #2: Due to the optimization at compilation, a lot of functions are not hookable in memory (especially on ReHLDS) via 3rd-party addons such as AMX, which is for me, quite problematic.
    Maybe it might not be a problem with your compilers, and I hope this won't (in case of you persist at dropping XP support).
    They provide an API, also as alternative, but this doesn't handle all we may need/want. And if in case we want them to add a function, then if they are not O.K. with, we are fu.... up!

    At the end, I'm not saying that using new compilers for improving quality/performance is useless (if we can without 3rd-party troubles, it's all benefits!), I'm mainly saying that if this broke something else, as a compatibility with an OS like XP or some other things, this DOES NOT WORTH THE COST.
    So you want to improve the "quality" with compiling stuff, at the detriment of the compatibility, as I said, it's absurd. Please think again!


    Quote Originally Posted by GeckonCZ
    ... and provide you with many new features.
    ... We have to focus on environments used by the majority of our players/server OPs.
    Tell me, do you have a concrete example, of a new feature you could add to the game, and which will be USEFUL for the users, and you couldn't before/actualy with your actual "set of tools"?
    Or is it just about programming stuff, so stuff just "for you devs" (make your coding life easier)?

    You want to focus on the "most used environments", but I bet despite some slight resources gain I wrote before, the users won't see the difference.
    This will still remain an "old GoldSrc-based game" (in the "design"), with classic graphisms/weapons/monsters, even if you have changed & improved a lot of things (which makes this "old game" new again and more pleasant), and if there are various plugins for customization.
    At the end, the global style of the game remains and will remain the same.
    I could more understand if you intended to move your game toward something really new, as a new engine/graphisms which will require more recent DirectX, OS, etc., but that won't be case right?
    And seriously, about graphisms, even the Source engine can run under XP... so when I hear you are gonna drop compatibility for your "old-school" game, you have no idea how much this sounds ridiculous for me...

    I've also the feeling you try to dedramatize that MASSIVE INCONVENIENT by justifying yourself with some reasons that means nothing to me, more to give you more consciousness against this (and let think to the users it's a good decision).
    But for me, and even in overall, those supposing (safer/faster) advantages you extol with that decision are nothing, and quite useless/trivial/unnecessary.

    Quote Originally Posted by GeckonCZ
    Quote Originally Posted by StevenKal
    And you are gonna sounds more for me, like a group of unconscientious developers who don't care much about "user service/reliability/quality".
    Quite the opposite actually, and that's also one of the reasons why this decision was made.
    I do not doubt about your conscieneness, regarding most of the things you've made which are pleasant to use, but about "compatibility part", no, you're not so much, I'm an user of your game, and you ... are gonna "kick me out", due to the old OS I'm using...


    Quote Originally Posted by GeckonCZ
    So, no, dropping support for old operating systems is not our laziness. Sorry, but from your comment it seems that it's you, who is lazy to do something about this situation
    Are you indirectly telling me that it's my fault? Because I refuse to move to another OS?
    I'm sorry, but you are all wrong. As I said above, this is more at you to do your best to satisfy me.
    Look, at the T instant, your game is compatible with my system, then, suddently YOU decide to drop it.
    It's YOU, who makes this decision, not me, I didn't ask for it, like I didn't ask to VALVe about having a new browser being Chromium based... blablabla... stuff I don't give a ...
    Let's imagine, if for an X reason, you do the same for Win7 & Win8 users (just an example), are you gonna "blame" them because they will refuse to change their OS? Tell them to make such effort? You'll just get words like "stu... devs!".
    Besides, YOU have always added XP support in your game, that's just common for you and requires no extra time/difficulty, while me, changing my OS will take some time, do you realize it?
    Sven Co-op is just a game, and there is not only that, I'm not gonna change my OS (or use alternatives as VB) just for playing at a single old-school game having the age of a good single-malt!
    Also, this is not like I begging you to add support to an OS you currently do not support, or some other new features, no! no! My request is very simple, I just want you keep existing COMPATIBILITY, I'm not asking much.

    For sure, this kind of "light fight" we have between people like you who support/use modern OSs, and guys like me, who want to keep their old OSs is a kind of EPIC (and also redundant on Steam forums, as I saw).
    People like you are wondering something like: "Why the hell that guy can not do like most of the others and use a modern OS?"...
    While me something like: "Why the hell those developers broke XP support? What do they have in their heads?".
    This is how it is...
    Well, if I'm right, I understand you, you may understand me, but you should not forget that I'm an user of your game, and try to satisfy me.

    As final point, I think I do not need to tell you that this will make you loose some members/players too (me, for example).
    I remember at the release of your "mighty" v5, I just created a dedicated server on my computer, and the players joined it in a mass, at a point I easily reached and kept +20 clients, and I've to admit I never saw this with a server hosted on my computer, then I was not motivated to shut it down (while I just had opened it more for testing)!

    I've also seen various people being not in agreement with your politic/decisions, and you have probably lost some users/players due to that.
    I respect your choices, and various of your actions/conflits with others is not my business, but if you continue doing such decisions like that (XP ...), you're gonna continue to loose users and at the end, almost finish to play your game only between devs!
    I abuse a bit, but step by step this could go this way... I don't think that's your goal huh!

    So I heard you, you heard me, I think there is no need to talk more about this XP subject, and knowing I'm a little stubborn, I've to admit that whatever any of you devs you'll say as anwser in order to justify this change, you'll not convaince me...
    I just wish you'll think more deeply to the BAD consequences of this decision, try to make efforts for your users, and will revert it, so I'm indirectly begging you to DO NOT DROP WINDOWS XP COMPATIBILITY (by using "XP-compatible v141_xp toolset" as you wrote or anything else...).


    Quote Originally Posted by GeckonCZ
    Windows XP is dead.
    Well, I'll personnaly not use that radical term to qualify it...
    It's no longer officially maintained by Microsoft, but still used on MILLIONS of computers (probably more than 100, even if most of those are probably companies computers, or military, so not gaming).
    And about Steam, their surveys talk about 0.1%, I personnaly doubt about this accurary, especially if only based on clients who answered to those, rather than forced detection of their specs (so it could be possible more users of those old OSs didn't want to told them their specs, for some reasons).
    And then, let's imagine we consider this number as base (or accurate), O.K., 0.1% seams "weak" for us, but what about if I talk in numbers, knowing there are apparently around 125 millions of active Steam users, 125 * 0.1 represents ~1.25 million, hum, I put this number outstretched below, in pure amount:
    1 250 000 Steam users...

    Tell me now, does it still like "nothing" to you? Because for me it's not!
    I think you could make a poll and ask who is using XP with Sven Co-op (I know you did some kind before, on the Steam area), even if a lot of players are probably not registered on your forums on don't come look at it.
    Despite its weakness, it's an OS quite liked/missed by a lot of people, for various reasons, or similar to mines (the fact I like simple, classic, essential & old-school style stuff).
    Even some "upgrading concepts" are attempted (probably more "dreamed" in fact!)!
    -> https://mywindowshub.com/reborn-of-w...on-or-reality/

    By the way, I "doubt" I'm the only guy who use XP to play your game...

    Quote Originally Posted by GeckonCZ
    Btw, you can make Windows 7 look and "feel" pretty much identical to Windows XP, if that's really that important for you. And it's only a few clicks!
    Well, I saw some videos about that, but I doubt this will be the same huh...
    Probably the font/design can be changed a bit, but the "intuitivity", interface style, etc., I'm not sure...
    But I could try one day, why not!


    Quote Originally Posted by GeckonCZ
    Quote Originally Posted by StevenKal
    #2: Engine -> Increase "setinfo" limit from 256 to at least 512 (if not already made).
    There are multiple different limits related to this, but the actual array is limited to 256 chars I think. It's also part of some public structures iirc, so changing it could break things. Probably not gonna dig into this now...
    Well, you have the "CHANCE" to apparently have full access over all the SC's binaries (server/client, etc.), so for me, if you want to do this, you should be able to. I'm even wondering why this has not been done previously, or maybe you forget about it.

    The limits in the buffers of the standard GoldSrc (not your "SvenEngine") are very weak, this was tolerable at the beginning, but from some years it's problematic, knowing the people usually intend to deal and use more resources than ever (as models, sounds, etc.), via maps or/and plugins.
    And unfortunately, VALVe put this mythic GoldSrc to oblivion (while some requests like this have been made; even "Alfred" in 2013 could work on this, but sadly he didn't).
    That's also why some unofficial or derived projects saw the light of the day, and VALVe can, indirectly, only blame themselves for doing nothing, if they dislike those last...


    Quote Originally Posted by GeckonCZ
    Are you talking about the original AMX?
    Yes, I'm talking about the original AMX Mod, and yes, I'm the current maintainer of it!


    Quote Originally Posted by GeckonCZ
    I thought that thing died like a decade ago.
    That "thing" (as you called it), is still alive!
    Why? Are you seing a white page with a black skull here?
    Are you seing the "Sven Co-op" link? With the cute chumtoad!

    I've reborned it in 2010 (with the help of KRoT@L at a moment, him, being one of the old developers and original author of some well-known plugins, as Parachute, Apache, Change Models, etc.).
    But from around 7 years I'm managing everything alone (in fact, there is only the 2010 version which is at around 70% made by KRoT@L, everything else on the website is "by me"), this includes all the texts (also fully translated in French), plugins I've reviewed (sometimes massively) with the use of some internal features or various optimizations, etc., even if I didn't put my "name" as author on them, more for respect to original authors and when people look for them.
    Right now I'm still working sometimes on the future version (but I'll have to move my ass more, to speed it up), because the current is very weak compared to AMXX and doesn't handle a lot of things, that's one of the few reasons why there are not a lot of people using it.
    But once finalized it will contain unique features, a very good compatibility with various engines/games, and much more! I want something powerful, but simple and easy to use at the same time.
    That's also why I've talked previously, about the game data (functions format, members, etc.) and partial source (headers files...).
    And if people do some efforts for having interest on it, it may come back more actively.
    I've also a specific politic, one part of it being to target quality over quantity, have the control over the whole addon & website, and keep managing the whole database of plugins on my own for the sake of the quality/reliability/stereotype. This is long, a pain, but good for the users (even if a few may see that has some kind of "lack of freedom").
    And of course, I want to centralize everything on the official website.

    It's like you, I think you probably prefer having the database of AngelScript's plugins on your website, rather than seeing various new "Sven Co-op" forums elsewhere with some plugins posted on those rather than on yours, which will also split a bit the people in general (on your forum, for the research on google & cie). Right? Or am I wrong?

    Well, on AMXX there are a bunch of AMXX websites per each country, which often bloom like flowers and dispatch the users, the files, etc., we don't know which one is really good to use/trust, etc., this also worth for the files.
    I don't want this with AMX and I'll do whatever it takes against!


    Quote Originally Posted by GeckonCZ
    Well, I hope you were not involved in the backdoor fiasco...
    Sorry to disappoint you, but "yes" and "no".
    I've a "developer access", from years, useful for me and my politic.
    This is more in order to see what kind of plugins the users are using (in the goal to know on what I can focus more, since I'm managing it alone), or help them quickly (I used it a various times for that purpose, even recently [and the user was aware and had no problem with it], because it's practice in case of "just talking" at through messages is not enough...).
    I said "your not very consciencious about compatibility", I admit I'm not consciencious for do not informing people about it. I mainly kept that "partially secret" (because I told to a few people before) in order to prevent them from not being interested by the project and also because I didn't set up yet "my politic" on a file.
    That's why, the future version will include an "EULA" file, where I'll list all the reasons of that, and also some "conditions" users will have to agree & respect, or just disagree and don't use the software, nothing more!
    Also because such program, is something "not only for you and your family" (like Photoshop, etc.), you can put it on a server and anyone from the worldwide can use it, this can also be used for malicious intention (slowhacking...), etc..

    To finish that part with that the AMXX news and the "hacking", that's false informations.
    I've basically an argue with that guy from like +10 years, as I didn't like AMXX had "forked" AMX, he doesn't like I make revive AMX in my image, and try to prevent people from using it by not always saying the right informations.
    In case of you want to know more about that (but I've told you the quick resume here), I've talked a bit here (pages #4 & #5).
    Well, unfortunately for me, most of the people take "his side" (like the ones who don't understand me and do not even try to, or, some other ...).
    So feel free to ignore, or "pick a side" whatever you prefer, but I'm get use to have people against me, this won't change much for me by the way.


    Quote Originally Posted by GeckonCZ
    Anyway, the way Metamod-P/AMXX (let alone the old Metamod and AMX) works, is really ugly and terribly unsafe. And as you said, it breaks even with regular code changes.
    I don't really know that do you mean by "ugly and terribly unsafe", even if I have a brief idea.
    Metamod is just between the engine & game, and do that it is supposed to do pretty well, and from years, even if it "sucks" on singleplayer games, it's quite reliable on multiplayer games and has made its proofs (just see the bunch of GoldSrc servers which are working nicely...).
    The "unsafe case" is more related to the 3rd-party plugins (Metamod or AMX/AMXX ones) the users may add and which may not be properly coded and use inappropriate functions.
    Also the case about "invalid game data", but well, as I said above, you, with AngelScript have the chance to have control over it and have your stuff implemented in your binaries. So it's sure it garantee some kind of incomparable quality/reliability for that part, a nice asset for SC!
    While AMX/AMXX are 3rd-party projects being completely independant/separated, and except if you provide some kind of specific API for those addons, where they could easily retrieve some data, and keep reliability with your game, on each update, they have no other reliable alternatives.
    So it's to a guy like me to stay aware about your updates, and keep my addon updated as soon as you release something (or, code functions intelligently made in order to prevent future incompatibilities issues), then also to the users to make sure they got the latest data, properly adapted/matching to the version of the game their using.
    But once this is done, this is normaly quite reliable/safe to use AMX/AMXX with your game.

    I do not understand why some guys have troubles with Metamod & SC (as on the "Metamod debate" topic), neither the reasons, I personnaly never had by using the Solokiller's version, released almost at the same time than the v5.*, and I'm not gonna criticize this for no reason at all.
    But if in case you "break something" in the engine, as changing the format of an engine/DLL API function (which is critical for such addon as AMX and with existing codes/hooks and shouldn't be touched), I think you have to provide a modified binary, due to how much it's used.
    But the good thing with AngelScript, is the fact it does not have conflicts with AMX (at least once we don't play the fool by running at the same time similar plugins, or with same commands/CVars).
    I personnaly used a few AS plugins I didn't have for AMX, but for sure, kept AMX for the rest...


    Quote Originally Posted by Puchi
    Only going to reply to your issue with us "not supporting" AMXX/Metamod correctly:
    It is not our job to update third-party mods/addons like this.
    Whoever is working on either can contact us, which was actually done in the past and not so long ago, and we give them whatever they require to make Metamod fit for SC again.
    I agree with this, that's not your job to do.
    Meantime, if I can have a word about it...
    Unlike AS, Metamod & AMX/AMXX are much more used and known, also, they can run well on most of the other games, then, on those games, this is that the users are using and get use to.
    Also, servers without Metamod/AMX(X) are usually rare nowadays (so should be considered seriously), AMX/AMXX are the most powerful/useful Metamod's plugins that ever exists, and make users life easy when it's about managing servers and adding plugins with just a few steps!

    Then, there is not "only Sven Co-op"!
    A lot of people having such addons and playing games like CS, HL, etc., are, as I said, "get use to such addons", and most of them will like to "retrieve them" under Sven Co-op, rather than being indirectly forced to use AS, spend some time to understand it, find related plugins, etc., additionnaly to the fact it's a complete different addon, so two different things to "memorize" for those users...
    This also worth for the coders, who are get use to the Pawn (AMX/AMXX scripting language).

    If all of this people know they can use their "favorite/common addon" on SC without problems, they also may have more motivation to play your game, and in consequence, this will bring more users to it. Because, not everyone wants to move/use AS for various reasons, I think you are aware about that.

    I personnaly care very much about "multi-games compatibility", and I've plans to improve it in the future (for anything within AMX, as binaries + default & 3rd-party plugins). If an user has a specific AMX plugin on his CS v1.6 server (like one adding effects to grenades explosions), and would like to retrieve it on his Sven Co-op server, it will be quite pleasant for him if he can, because it has been adapted to work, not only under CS, but on various other "HL1" games too.
    Or if he has an HL1 server, with some plugins modifying the backpack ammo of some weapons as satchel, etc., if he can "grab" his whole configuration, put it on SC, and still have the plugins working, and all of this without any extra effort, this will be juicy!

    But all of this, is, for most of the time, only a matter of "game data", that's why if you can make sure to do your best to prevent this from being broken, it's welcomed!
    As example/tip, if you wish to add a new member to the "CBasePlayer" class, add it at the end, so this won't broke the values of the others, and for AMX which uses members retrieving natives.
    It's clear you can not do that all the time, as if you add a new member to a parent/base class as CBaseEntity, this will inevitably broke the following CBase's values, but if you can try that I said when you can, please just do it!
    Also, provide to me some of those headers so I could maintain my stuff properly up-to-date regarding to your game (I've seen you did that for the other guy). Not now, but at time I'll need those (and if you are agree), maybe we could discuss about that, via PMs, and I could show you that I need exactly.

    All of that I just said, has the goal to show you how much considering those addons and keeping compatibility for them as best you can is important.


    Quote Originally Posted by GeckonCZ
    Quote Originally Posted by StevenKal
    I also suggest you to lock the "sv_version" CVar from being changed by the client (in case the server wants to query that CVar in order to detect that client version/build, even if he may be dropped when not matching with server's one).
    Is there a specific case where this could cause problems? The CVAR is unlocked in vanilla GoldSrc as well afaik, and I have not seen any bug reports related to this. Can you provide more info?
    In fact, I use this in some of my scripts (via some CVars queries), in order to detect some informations about the client build, it's useful & needed to enable or not some features only available on some clients, as colored chat & menus. And by blocking the client to change it, I could have the "right" value (even if probably no client changes that, I'm just suggesting the addition of this feature "in case of").
    But after reflexion, it will not really be needed for your game, at least due to the fact that most of the time, if a client build doesn't match to the server's one, client got kicked with "dll differs from the server...".
    Besides the client is automatically updated... So it's not like if an old client will be able to enter to a server having the latest build...
    At the end, it's more useful on the other GoldSrc games, for sure.
    Feel free to add the feature or not.


    Quote Originally Posted by GeckonCZ
    Quote Originally Posted by StevenKal
    #4: Adding support for colored chat...
    Yes, this is on our list already.
    I'm glad to hear that!


    Quote Originally Posted by GeckonCZ
    Quote Originally Posted by StevenKal
    #7: I remember when I grabbed some monsters...
    That sounds like a bug. But what do you mean by "grabbing some monsters"? Some script? 3rd party module (i.e Entmod)? A video would help here...
    Well, that's just the "Jedi Force Grab" plugin, modified to support monsters grab too, additionnaly to the players (simple entity/class check).
    This just changes the velocity (entvars's field) of them toward the direction we are pointing out, nothing more.
    Maybe your "monsters code" doesn't like to be moved via something else, I don't know.
    I could try again later, and make a .dem video, or try by spawning a monster in the "air" (far from the ground, as in a middle of "boderman"), and see what happens.


    ------------------------------------------------

    To finish, I'm a little "sorry" for filling your topic with a "roman" with a few "off-topic" things (I wouldn't dare does that on the first v5.0 one, but it's also more "your fault", for taking a such bad decision).
    I'm not very good at making short answers (more because I wish to give enhanced details), but keep in mind I'm a devoted guy (even if I have a special mentality) who usually like to contribute to the projects of others devoted people too (and have respect for it), but if those people make zero efforts to satisfy me, especially when I'm just asking something quite simple, I don't feel the need to continue supporting/contributing, I'll just "depreciate" the project.
    Or, I'll only do the strict minimum (adding support for the upcoming version of "my addon", nothing more; and even for this, I'm not fully sure I'll be motivated to do that if I'm not able to make the right tests on my system, then this will also "piss me off" regarding all the time I've spent on the past in order to fill my "not yet released data files" with the content of your game).

    I hope you'll understand me, and my position/needs.

  20. #20
    Administrator JPolito's Avatar  
    Manager
    Join Date
    Apr 2004
    Posts
    7,555

    Re: 20 years of Sven Co-op! -- Sven Co-op Update Released [Build 3482406]

    I was absolutely in love with Windows 2000 back in 2005-2008, and suddenly everyone dropped support for it in favor of XP and Vista. I couldn't run anything anymore, and I was forced to upgrade to XP. Win2k had a support life of probably 10 years or less, and XP is now 18 years old. By this comparison, XP is way, way overdue for loss of support. You're going to be forced to do it sooner or later, whether you agree with it or not. You might as well get it over with now.

  21. #21
    Super moderator GeckonCZ's Avatar  
    Programmer
    Join Date
    May 2014
    Location
    Great Moravia
    Posts
    261

    Re: 20 years of Sven Co-op! -- Sven Co-op Update Released [Build 3482406]

    Quote Originally Posted by StevenKal View Post
    "dropping support", which normally doesn't really directly means "dropping compatibility"
    Actually, in practice "dropping support" and "dropping compatibility" often means the EXACT same thing, at least when it comes to any actively developed software. You are right that it's not always the case, but typically the compatibility doesn't survive for much longer after the "end of support" announcement takes place. In case of Steam it took about a month. In our case it may take longer, but it will very likely happen later this year.

    but recently (a few days ago), they just broken it for XP/vista users
    I'm very well aware of the situation. It's safe to assume that more and more Steam components will became incompatible with XP/Vista. And it's only a matter of time before folks from Valve change something that will break compatibility between the old client and their current backend. Then what? You are going to use cracked steam, steam emulator or similar (illegal) "workaround"? Well, good luck with that...

    because we don't have an OS which feat to their wishes, wishes, which are to match to their stupid politics and partnership with other "BIG companies", as Google, Windows...
    It's not really about their wishes, politics, or partnership. It's about realistic goals and focusing on what's important for the majority of their customers. In this field it's virtually impossible to make every single customer happy.

    because I don't want to give money to a company which have a bad politic, and also put me "in the mess" with their old OS support drop. No! No! No!
    What would make you update your OS then? Also how are you giving Valve money by updating your OS? I really struggle with your reasoning here. While Linux is not the best gaming platform, it's supported by both, Steam, and Sven Co-op. And it's free! Perhaps that would be an option for you?

    because your game is free, so it's normal for a guy like me, to be less exigent, and have more tolerance.
    I have not noticed...

    Because I'm an user/client or your game, and by default, developers/companies are supposed to take care of the "service client", and do their best to satisty them.
    Yes, within reason.

    I've to admit I'm even wondering a bit if they didn't forced you
    Yes they were very disappointed with our lack of interest in killing XP. So they told us to end support for XP/Vista immediately! Seriously now, are you really that paranoid?

    I'm a little sad you didn't seem to realize how important is, "the compatibility", this is the base and most essential part of a program (for the users).
    Here is the order of "how you should think when you are developping something" ...
    Programming is not only a hobby for most of us, but also a profession. So we kinda, sort of, know what is important there. I'm not sure if this was aimed at me personally, but most of my professional work is related to a wide variety of embedded devices. Some of which are part of a fairly critical systems, systems where reliability and compatibility is absolutely everything, because human lives are at stake. So believe me, your (fairly inaccurate and incomplete) lesson from software engineering isn't necessary, but thanks anyway.

    Safer, hum, I think you do not need to "count on the compiler" for that, it's more your custom code that should be properly made
    I'm not sure if you have ever worked on any bigger legacy project, but most of the engine is written in C89, and even the C++ parts are using obsolete and unsafe constructions and functions. We are slowly updating the codebase (new tools are part of that), but I don't think you realize scale of the project. Sure our new code is in general safer, but what about the remaining 90% that are already in there? At this scale ANY help from the compiler (and tools in general) is EXTREMELY valuable, and it's a value for our playerbase as well, as it means more stable game.

    size_t iLength = strlen(szValue);
    That's very simple and obvious example, but unfortunately it's not always that easy. String functions/operations alone are actually a huge part of it, and newer tools/standards provide some major improvements in this area (no need for custom or platform specific implementation of "safe" string functions, better detection of potential array/string issues etc.).

    On the past, with weaker machines, looking for performance would have beene more interesting, but nowadays, with machines which can handle very well much more things, it's for me kind of facultative.
    Firstly, I also think quality of your code is a way more important for the performance, rather than the compiler "thing".
    Yes, of course it is. And that's why we are reworking significant portions of the game/engine. But any extra performance boost is welcomed. That being said, efficiency of the produced code is not the only performance related benefit of the new tools. The compilation process is significantly faster in some cases. Which is rather important for bigger projects as well.

    Tell me, do you have a concrete example, of a new feature you could add to the game, and which will be USEFUL for the users, and you couldn't before/actualy with your actual "set of tools"?
    Well obviously I meant toolset features, not game features - for example support for C99, C++11, C++14. Newer standards make our life a lot easier, which (together with the performance benefits mentioned above) means that we will be able to work more efficiently and we will be able to produce less error prone code.

    as a new engine/graphisms which will require more recent DirectX, OS, etc., but that won't be case right?
    We are replacing the immediate mode render with a new OpenGl 3.x based one, which isn't exactly modern at this point either, but it will be a huge step forward and it will make the game playable for ATi/Intel HD users again. We may implement Vulkan-based renderer later on, if the performance boost turns out to be really worth it, but that won't happen any time soon. OpenGL 3.x is our target for now, so we are not restricted by the OS from this point of view.

    even the Source engine can run under XP
    Sure, and when it was first released it could run on Windows 98/ME as well. And yes, It can run on XP, well, at least until the next rebuild...

    I've also the feeling you try to dedramatize that MASSIVE INCONVENIENT by justifying yourself with some reasons that means nothing to me, more to give you more consciousness against this
    "Dedramatize"? Well, there is no drama here. And no, I have given you some valid reasons why have we decide to end support for Windows XP, and why we may break compatibility with it in the future.

    Are you indirectly telling me that it's my fault? Because I refuse to move to another OS?
    Yes, if you "refuse" to move from obsolete OS to a newer one, it certainly is (at least partially) your fault that you won't be able to run our software and software from many other developers in the future.
    Also we have originally announced this 2 years ago. Later we have decided to wait a bit longer, but I think that was enough time for the affected players to update their SW/HW or to convince us that XP is still relevant.

    As I said above, this is more at you to do your best to satisfy me.
    Again, within reason.

    Let's imagine, if for an X reason, you do the same for Win7 & Win8 users (just an example), are you gonna "blame" them because they will refuse to change their OS?
    No, We are not, because it would be unreasonable to end support for operating systems that are much more recent, and that together have approximately 30% usage share in the gaming community.

    People like you are wondering something like: "Why the hell that guy can not do like most of the others and use a modern OS?"...
    Not sure what you mean by "people like you", if that was aimed at me personally, then you couldn't be more wrong. I love vintage HW and SW (dating back to minicomputers from 60's and 70's). But would I (-for example-) dare complaining about many modern Quake source ports not running under DOS, or not supporting Glide API? No. Would I ever use Windows XP for any of my current machines? OS from 2001 in 2019? No.

    As final point, I think I do not need to tell you that this will make you loose some members/players too (me, for example).
    I hope it won't come to that. I hope you will use the extra time we have provided you and potential other players that are in a similar situation, to think about this realistically, and update your OS. Because like JP said, you will have to do it one day anyway.

    1 250 000 Steam users ... Tell me now, does it still like "nothing" to you? Because for me it's not!
    If I would compare it to a user base of anything I have worked on in the past, yes it's a lot of users. But I have never been part of anything as big as Steam, so I can't answer your question objectively.

    liked/missed by a lot of people, for various reasons, or similar to mines (the fact I like simple, classic, essential & old-school style stuff).
    Can you list some more reasons? Because the old-school look & feel can be achieved with Windows 7 as well (as I have pointed out before). The only significant issues with the Windows XP to 7 upgrade I have experienced in the past are:
    • compatibility with some very old HW/drivers
    • memory usage - you can tweak XP to have extremely small memory footprint (for a NT-based OS anyway), you can't do the same with 7.
    • price - this doesn't really apply anymore, as you can get Windows 7 license for next to nothing nowadays, but granted, that may not be the same across the globe.

    Even some "upgrading concepts" are attempted
    Nonsensical article about concept that doesn't look anything like XP. Is that what you would enjoy using? Because Windows 7 is much closer to XP than that thing. And it's actually real and available right now.

    Well, you have the "CHANCE" to apparently have full access over all the SC's binaries
    I'm talking about breaking the existing binary interfaces in regard to other existing projects.

    I'm even wondering why this has not been done previously, or maybe you forget about it.
    It's simply not important for Sven Co-op moding/scripting.

    I've a "developer access", from years, useful for me and my politic.
    This is more in order to see what kind of plugins the users are using
    See that's one of the important points missing from your software engineering lecture above - transparency. Stunts like that are how you lose your users much faster than by dropping support for a dead OS. You see, this your reply wants me to swing the ban hammer really hard, so let's rather move on from this topic...

    I don't really know that do you mean by "ugly and terribly unsafe"
    That's rather sad. From your answer it looks like you at least partially understand what's so wrong about it tho, perhaps you just have a different scale about what is safe or ugly, and what isn't.

    A lot of people having such addons and playing games like CS, HL, etc.
    Like I said before, difference between Sven Co-op and other GoldSrc-based games is that our game is in active development, and we are doing fairly large changes across the entire codebase. So the Metamod/AMXX approach doesn't work all that well for our game.

    Well, that's just the "Jedi Force Grab" plugin ... This just changes the velocity ...
    Hmm, just that? Send me the code via PM if you want, and I will try to replicate it when I have time.

    adding support for the upcoming version of "my addon", nothing more; and even for this, I'm not fully sure I'll be motivated to do that
    Don't sweat it, we want to phase out Metamod/AMXX and similar anyway.

    I hope you'll understand me, and my position/needs.
    We do. But what we don't understand is why are you locking yourself in the dying XP world. Sven Co-op compatibility will be the least of your concerns in the upcoming months.

    Anyway, I think I have said enough about the Windows XP support, so I'm not gonna spend more time on it. When it comes to compatibility of our binaries with that OS, we will see how that goes. I'm still considering the v141_xp toolset, but if there are any trouble or side-effects along the way... well, in that case RIP XP.

  22. #22
    Registered User StevenKal's Avatar
    Join Date
    Feb 2019
    Location
    France
    Posts
    3

    Re: 20 years of Sven Co-op! -- Sven Co-op Update Released [Build 3482406]

    First, when I specify "you" (before or now), I usually target all of you, SC developers, not you (GeckonCZ) specifically.

    Quote Originally Posted by JPolito
    I was absolutely in love with Windows 2000 back in 2005-2008, and suddenly everyone dropped support for it in favor of XP and Vista. I couldn't run anything anymore, and I was forced to upgrade to XP. Win2k had a support life of probably 10 years or less, and XP is now 18 years old. By this comparison, XP is way, way overdue for loss of support. You're going to be forced to do it sooner or later, whether you agree with it or not. You might as well get it over with now.
    The fact is, Windows XP is the "last and best" of those old-school OSs series.
    After that, the global interface started to change radically (Vista, 7, etc.).

    I know one day I'll probably have to move to 7, or 10 (maybe not before some years...), because "the world wants me to", but right now, I do not feel the need, and if they weren't some head/devs guys who make stupid decisions at not keeping backward compatibility with such OS, and for almost "no advantage" in a lot of cases, there wouldn't have all of this "drama", and I wouldn't complain.

    I can use for example, the GitHub website (I do not use for my project, I just browse a few sometimes), recently they broken XP compatibility.
    As result, some elements, as when I click on the branch list, nothing is displayed, I have to click on "branches" at the right of "commits" in order to see them, or, I can no longer edit a comment...
    Such website interface is quite basic, it even looks not well-made from my opinion (& missing features), but they "have to kill XP support".
    I'm more than 90% sure it's made on purpose, in order to annoy people like me, in the goal to force them to move toward another OS, or, if not, those are just developers who don't care about backward compatibility. Pitiful. Pitiful.
    And then, it's now owned by Microsoft, so...

    I could quote other examples quite similar, even in other domains, where the new stuff bring more problems than benefits.
    As the latest "E-AC3" audio code I can't just listen the audio on my home cinema, I have to use Avidemux to convert a movie to AC3 audio...
    Such new stuff has just no advantage, only inconvenients for me.

    A lot of things like that are just made for "business reasons", because it's mainly how the world works now, not always, but more than before for sure.


    Quote Originally Posted by GeckonCZ
    It's not really about their wishes, politics, or partnership. It's about realistic goals and focusing on what's important for the majority of their customers. In this field it's virtually impossible to make every single customer happy.
    So, the people like me are put in apart (forgotten) just a bit like if they smelling shit? No, I do not agree with this.
    I could almost understand, if it's for the addition of interesting features for US that requires a new OS, but when this isn't...


    Quote Originally Posted by GeckonCZ
    In this field it's virtually impossible to make every single customer happy.
    I don't really approve this, as I said on my first post, with enough motivation, power, time, it's usually feasible (as it is for you). Those guys who don't want to, usually intend to make their life easier by skipping this part among their work.


    Quote Originally Posted by GeckonCZ
    Also how are you giving Valve money by updating your OS? I really struggle with your reasoning here.
    I was talking if in case I have to use another OS in order to use Steam.
    Since VALVe put me in the mess with such decision, I wouldn't buy anymore any game at through their platform (because there is a part that goes to them). This is that I meant.


    Quote Originally Posted by GeckonCZ
    While Linux is not the best gaming platform, it's supported by both, Steam, and Sven Co-op. And it's free! Perhaps that would be an option for you?
    No way. I keep this OS on my VPS (for hosting servers, because it's good at it), not on my personnal system!
    Even if I have to admit I never tested it, but I don't like various things, so.


    Quote Originally Posted by GeckonCZ
    I have not noticed...
    I have more respect & tolerance than you think. But cutting me off from using your game is beyond than I can tolerate. You'll probably better understand my point of view if you'll be exactly at the same place than me, but you are not, you can only imagine (and have a brief idea), and it's not exactly the same.

    But well, I guess you've missed the parts where I said some of the things you've made are good & pleasant to use, the "thank you for your work", a few AS's things being praised, etc.


    Quote Originally Posted by GeckonCZ
    Quote Originally Posted by StevenKal
    Because I'm an user/client or your game, and by default, developers/companies are supposed to take care of the "service client", and do their best to satisty them.
    Yes, within reason.
    That's I'm asking is among those "withing reason", I'm not asking you to give me the moon for god sake!


    Quote Originally Posted by GeckonCZ
    Yes they were very disappointed with our lack of interest in killing XP. So they told us to end support for XP/Vista immediately! Seriously now, are you really that paranoid?
    No, I'm not that paranoid, but I see the facts, I see that they do, I see you follow.
    Besides, I've said below "I'm just guessing... probably I'm wrong.".
    So, O.K. I'm wrong!


    Quote Originally Posted by GeckonCZ
    I'm not sure if you have ever worked on any bigger legacy project, but most of the engine is written in C89, and even the C++ parts are using obsolete and unsafe constructions and functions. We are slowly updating the codebase (new tools are part of that), but I don't think you realize scale of the project. Sure our new code is in general safer, but what about the remaining 90% that are already in there? At this scale ANY help from the compiler (and tools in general) is EXTREMELY valuable, and it's a value for our playerbase as well, as it means more stable game.
    No, programming is not my profession, I even do not like that. I've just got some kind of addiction/love with a project I wish to make revive in my image, because other similar ones are not designed how I think they should be. And I just learn that I have to in order to code that I need to.
    I'm not very skilled in programming (I've just a basic C++ knowledge), but I've other skills and objectives that help me to make good stuff, stuff more skilled programmers won't be able to think & design (and it's not to brag).
    And unlike you, I try my best to target the things that REALLY MATTERS, and I don't break things (no, I improve the compatibility of my stuff), or, if I break something (I've basically plans to), I readapt everything in consequence (checks in the binaries, or by updating the 3rd-party plugins for example) in order to prevent any problem for the users.
    Before being a simple programmer, I'm mainly a gamer/user and I think like this by being strongly involved in the things I code (while a lot of programmers are more fans of programming than playing, and a bunch do not invest much in the game, neither take too much time for testing their things [while I spend hours in this, and in various situations, because programming is quite sensitive and any tiny mistake has the potential to cause serious troubles...]).

    I don't really think the compiler will help you making the game more stable, prevent crashes, etc. (like the monster problem I've reported, does the compiler can do something about? No! Hahaha!), or if it is, this will be just trivial gain, or, in rares cases.
    And problably those are the compiling options which will have more effect on all of this rather than the tools themselves.
    Even if I've personnaly consated a trouble with a compiler that didn't happen with another, but this was only one problem I have, and probably due to a compilation option.

    The fact is, most of the "modern programmers", usually have the "coders mentality/goals" (and don't fool me, I saw them doing their stuff... and I'm usually good at feeling things/people), I mean, they are more focused on maximise the performance of their code, rather than working on things that matter much (or, at least have more priotities for this part).
    But wake up, this just runs on a machine, a machine has no soul! People don't really care if your game uses 6% of CPU while it could use 5% if you spend 1000 hours or reworking things "just for this tiny goal".
    I've also seen various bullshits conveyed in the forums from some "newbies" people who got badly informed by some programmers being addicted with performance.

    And I'm not saying this in order to say that optimizing is not important, no!
    I'm just saying that if you want to rewrite some codes in order to be "proud of yourself", then say your stuff is very clean, has good quality and not "ugly"! That's your choice, and it's O.K by default.
    But if, additionnaly to that, you break various things, and also bring no new features for the users, you're wasting your time and make the game worse for my opinion. Because your bring more problems than benefits, it's as simple as it!

    You should learn to target more the things that really matters for the USERS instead, I mean, reviewing the codes that can causes troubles in game (as you did for the SVC_BAD, etc.), or the codes where you can be able to add new interesting features.
    Such things are not a waste of time for everyone. Only benefits at the end.


    Quote Originally Posted by GeckonCZ
    Well obviously I meant toolset features, not game features - for example support for C99, C++11, C++14. Newer standards make our life a lot easier, which (together with the performance benefits mentioned above) means that we will be able to work more efficiently and we will be able to produce less error prone code.
    That's it! So, at this T instant, apparently no new features/gains linked to this change/decision, and beneficial for the users, despite maybe a tiny performance gain they don't care.
    I don't care about those new standards only FOR YOU, I want the game still works FOR ME, is that so complicated to understand? And make such effort?
    You don't really care because, at first, none of you devs are concerned, but that doesn't mean it's the case for all the other people.


    Quote Originally Posted by GeckonCZ
    We are replacing the immediate mode render with a new OpenGl 3.x based one, which isn't exactly modern at this point either, but it will be a huge step forward and it will make the game playable for ATi/Intel HD users again
    What do you mean about ATI/Intel HD users problem?
    I always had an ATI video card (currently a R9 270) and never had any problem (unlike with NVidia where the drivers just suck with XP, even do not work... as I tried two cards and sell them back right after).


    Quote Originally Posted by GeckonCZ
    Also we have originally announced this 2 years ago. Later we have decided to wait a bit longer, but I think that was enough time for the affected players to update their SW/HW or to convince us that XP is still relevant.
    ... and a lot of people commented YOU SHOULDN'T... including me among them too. Did you heard them?

    And it's strange the fact on this article, Sniper said "some new features we're working on" while now you have nothing to tell me about that (except tool set stuff which are not new features).
    It's almost like if he said "we want to give you a better game with new cool stuff but you'll need another OS to enjoy them, see how this will be good for you to upgrade it!"...
    While you just told me (2 paragraphs before), only toolset stuff...


    Quote Originally Posted by GeckonCZ
    Yes, if you "refuse" to move from obsolete OS to a newer one, it certainly is (at least partially) your fault that you won't be able to run our software and software from many other developers in the future.
    That I'm currently using is quite enough for me, and fortunally, not all the developers cut the backward compability. Even if I know this is gonna be more rare over times.


    Quote Originally Posted by GeckonCZ
    Nonsensical article about concept that doesn't look anything like XP. Is that what you would enjoy using? Because Windows 7 is much closer to XP than that thing. And it's actually real and available right now.
    This was more in order to show you that XP is still among the memories and that some people (like me) would like it to be "officialy resurected"... (even if you know it very well)
    However, the concept itself and its architechture is not like XP, as you said.
    If this is to have an OS being "XP branded" among the specs, but with a modern style like 7, etc., this is just absurd to use something like that while 7 or 10 are "that they are"... I totally agree with you for this point.

    No, a worthy concept of an "XP reborn" will be like I said on my first post, XP as it is, but with 64 bits + much more powerful internal API + a few new features...


    Quote Originally Posted by GeckonCZ
    See that's one of the important points missing from your software engineering lecture above - transparency. Stunts like that are how you lose your users much faster than by dropping support for a dead OS.
    I'm aware about the fact my politic is quite special, and make me loose a lot of users, but I continue to enforce it (for the sake of the global quality, then having something quite different/unique), then I take this risk by knowing those consequences.
    But you, are you ready to take this risk with your recent BAD decisions?

    Besides, I really do not like the "social networks", neither an addict of the transparency thing.
    Transparency is good for a lot of things, but I also think a few things in this world should be kept private/secret for obvious reasons, especially due to the bad propaganda (people overreacting, bullshits being spread...) which could come at the suite...


    Quote Originally Posted by GeckonCZ
    You see, this your reply wants me to swing the ban hammer really hard, so let's rather move on from this topic...
    ... and fill your "already big list" of banned people, including useful/devoted ones like So...
    That's cute!


    Quote Originally Posted by GeckonCZ
    Quote Originally Posted by StevenKal
    I don't really know that do you mean by "ugly and terribly unsafe"
    That's rather sad. From your answer it looks like you at least partially understand what's so wrong about it tho, perhaps you just have a different scale about what is safe or ugly, and what isn't.
    Maybe. But the fact is, even if it's not that you mean/said, I slighly perceive your sentence like if you said "unstable", so like if Metamod could crash at any time "just like that magically"... which is just laughable!
    You're certainely talking about pure programming hooking method itself, but well, this still make me laugh, poor machines, sounds like you heard them begging you in your sleep, something like "please edit that "liblist.gam" by removing Metamod, it's killing me"!

    I personnaly do not recommend you to spread too much such term for it, if you don't want to get the thunder of some other guys!
    And O.K. it's not as smooth like AS, but I don't really see what the alternatives such binary could have? Due to its concept...
    And then, the day your AS will handle as much as Metamod/AMX(X) do, we'll see!

    But well, I do not understand that's wrong with it, you do not understand that's wrong by dropping XP support and Metamod one, I guess both of us have different opinions about "what's wrong", or, lacks of understanding!


    Quote Originally Posted by GeckonCZ
    Like I said before, difference between Sven Co-op and other GoldSrc-based games is that our game is in active development, and we are doing fairly large changes across the entire codebase. So the Metamod/AMXX approach doesn't work all that well for our game.
    The fact your game is in active development is not an excuse to break things or said sentences like "Metamod/AMXX are 3rd-party softwares that are not our problem".
    Those are just easy excuses to do not care, think to much to "yourself", and target more all the stuff you're extolling (AngelScript in first).

    Metamod is a well-known, useful, powerful and versatile binary (due to that it permits to and all the games it handles) that exists from decades, and it should ALWAYS BE CONSIDERED by GoldSrc-based engines/games developers.
    All the people who use it will told you the same.

    It's maybe "not your job to fix it for your game", but at least don't try to break it on purpose except if you have no other choice (but try some workaround, I don't know), especially if you know there are almost no one behind to make an update of it... (but there will always be someone usually)


    Quote Originally Posted by GeckonCZ
    Hmm, just that? Send me the code via PM if you want, and I will try to replicate it when I have time.
    I zipped three .dem files in a .zip file attached (#1 & #2 are on boderman, the #3 on hplanet).
    You can clearly see that happens when I grab and drop a monster, also move it up & down... monster receives damage (apparently variable depending on fall speed value) while it shouln't...
    Certainely a damage code dealing with the fall velocity members and not realistically-made (or it's an human mistake not made on purpose). You're invited to look at it, then fix it!
    As information, I've notified that problem doesn't happen with the Alien Controller (as you could see in hplanet).


    Quote Originally Posted by GeckonCZ
    Don't sweat it, we want to phase out Metamod/AMXX and similar anyway.
    I don't know what do you mean by "phase out", if you mean:
    #1: "just ignore it & do not provide any help for those plugins on our website"
    or
    #2: "break it later in force in order to prevent people from using it" (like XP...)

    But if this is the case #2 (I hope not).
    Ouch... Breaking XP support is BAD, but this, so much worse... and I talk in the name of all the people being concerned.


    ------------------


    At the end, it's not to be irrespecful or something similar (even if I have to admit the fact you keep persisting at doing this start making me angry a bit), but most of you seems having difficulties at detecting what is ESSENTIAL, what is not.

    Sven Co-op is (in the concept), an old game GoldSrc based, so:
    - Keeping support for old OSs a lot of players are get use to play is essential.
    - Keeping support for Metamod & its plugins players are get use to use is essential.

    As an USER of your game, I wish the updates bring such things:
    - Bug fixes (you've fixed a lot, good, but there are a lot of others that could be too, I have a few in mind...).
    - Better realism.
    - Better quality (good looking HD models, etc.).
    - New monsters.
    - New weapons.
    - New various features.

    Various of those things can be done by extra-plugins, but like a lot of things you did can too, so this is not a reason to do not focus on this rather than wasting your time on trivial things people don't really care (as reviewing some codes just for the sake of the quality, but without fixing/adding new features for users).

    As an USER of your game, I do not wish the updates bring such things (yes, I repeat again):
    - OS compatibility broken (highly primordial).
    - Metamod compatibility broken (highly primordial).
    - Break other things... (tolerable)

    If the both last points are not respected, your game just become not interesting for me and all the other users who are affected by those problems.
    And I told you that, as an experienced guy who is around all of this from years.
    Then if you persist in this stupid path, you'll loose a lot of players, and if you "really want to completly mess with it", I'm wondering if it wouldn't be better to let it as it is, but work on another version (SC: Source of SC²...). At least people like me could still "properly enjoy the mythic & vintage one".
    Or, another solution, keep your "dropping XP compatibility" for the common version at through Steam, but release on your website separated binaries which can work on XP (for people like me...), if feasible.

    Is it really that you want (loosing users)?
    Quote Originally Posted by GeckonCZ
    I hope it won't come to that. I hope you will use the extra time we have provided you and potential other players that are in a similar situation, to think about this realistically, and update your OS. Because like JP said, you will have to do it one day anyway.
    Sorry to disappoint you (again!), but yes, it will go this way... What interest can I have on a game I can't run anymore? All of your interesting changes previously made means nothing to me if I'm not able to...

    Because for me, this will bring the special SC's chapter, "Forget about Sven Co-op, but not Freeman!".
    Or, I'll just prefer playing the old v4.8 sometimes, and maybe one day code plugin(s) that will bring most of the features of the v5.* to it... even if I will probably not in fact.

    So I invite you to think, one more time, to those decisions, and of my both requests, which are very basic and easy to be granted (as I said above, I'm not asking the moon, just you keep supporting something you already do).

    To finish, I wish to thank you GeckonCZ for taking time to answer me and give enhanced details, and I remember all of you that I like most of the things you do, also the game itself, then I'll much more prefer being "in good terms with you", and even donate to you, as a thank you for your efforts, but only if you are willing to consider my simple requests.
    But if you are determined with your decisions against this, well, so be it.

    I said quite enough about all of this, now that's up to you to make some efforts in this direction, or not.
    Attached Files Attached Files
    Last edited by StevenKal; 12-02-2019 at 06:44 PM.

  23. #23
    Administrator JPolito's Avatar  
    Manager
    Join Date
    Apr 2004
    Posts
    7,555

    Re: 20 years of Sven Co-op! -- Sven Co-op Update Released [Build 3482406]

    Again, if Steam doesn't work on XP there is literally no point in this game supporting it.

  24. #24
    Todd Howard look a like Deathparade's Avatar
    Join Date
    Oct 2012
    Location
    Steam
    Posts
    58

    Re: 20 years of Sven Co-op! -- Sven Co-op Update Released [Build 3482406]

    Hell yea 20 years of Sven

    Also does this man want you to keep supporting a dead OS with more security holes then a fishnet that globally holds about 0.09% of the share usage on Steam?
    Damn.
    No.

  25. #25
    snarks snarks snarks snarks snarks snarks snarks snarks Green Astronauts's Avatar
    Join Date
    Mar 2013
    Location
    Nijmegen, the Netherlands
    Posts
    210

    Re: 20 years of Sven Co-op! -- Sven Co-op Update Released [Build 3482406]

    Quote Originally Posted by StevenKal
    Rude demands, more rude demands and a mention of still defending a backdoor in self-programmed malware
    tl;dr
    Last edited by Green Astronauts; 12-02-2019 at 08:59 PM.

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •