Tremulous Forum
General => Feedback => Topic started by: Thorn on September 01, 2008, 06:05:35 pm
-
I always took it for granted that automatic downloads would be on by default in the next version of tremulous(If there is ever to be one). However, yesterday, this was said to be untrue by a well known contributer to the game.
The reason for downloads to be kept off was `They are a security risk` This may be true to a really minimal sense, but shouldn't they be slightly restricted instead? Even more so, the client should know not to play on suspicious servers.
I'd be really interested to hear what the mappers have to say about this.
-
Auto-download being on by default would be great. There should be a warning that it's on, though, and what the risks are.
-
I think someone in-the-know about the security risks should speak up about what the exact problem is (I know it relates to code that can be run which is downloaded from the server automatically, but not specifically what might be done to circumvent that and keep the client safe). But I would love to see some way to enable auto-downloads, perhaps in a tiered way:
- All maps & non-executable code on by default
- All executable code off, but with the option to turn it on (QVMs, etc) with a very stern warning of why it's a bad idea
- An in-game "Do you want to do this" kind of option which can ask if you really want to trust that QVM you just downloaded
On one hand, the constant "Are you sure?" dialogs of Windows has created a generation of people who blindly click "yes" when asked a question, but I think I'd rather see that than the situation where really good maps don't get played because everyone disconnects when it gets loaded.
-
There are probably many ways in which a prepared pk3 can infect a client system. But I don't think that manual downloads are in any way more secure than automatic downloads. (Well maybe a malicious server owner could redirect your client to contact a server he wants to DOS.)
-
I haven't tested alot of my theories, simply because i don't feel i should create a malicious pk3 at all, but.......
I have been doing a little digging for my own, and it seems that QVMs themselves can load DLL files independently. This allowing someone to place a DLL in the pk3, have the cgame load it, and then do w/e they want. Now im not totally sure weather im allowed to speak of this on here or not. Considering the "cheating" stuff that has been going around, but im pretty sure this is fixed in the latest SVN and this shouldn't be a problem. But like i said, these are only theories i have..
Also, as TJW himself said. Any type of auto download can be a security risk, the best we can do now is either remove the cgames/ui/game's ability to load DLL files and hope that the community would be considerate enough not to distribute malicious packages
-
The loading of DLLs is disabled on pure servers and it is disabled by default on non-pure servers.
Personally I'd remove that feature completely. The performance of the native compiled code is probably only a few percent better than the compiled bytecode and according to my benchmarks the client spends only ~5% of its time in the qvm code anyway.
-
I was going to vote yes... Then i realised i have no idea what a QVM or a PK3 is... And then i realised i am pretty crap at tremulous...And then things went downhill from there :'( :'( :'(
-
Bug 3038 comment #1 (https://bugzilla.icculus.org/show_bug.cgi?id=3038#c1)
Some of the comments here are not entirely accurate. Others may potentially be close to breaking forum rules.
-
Auto-downloads via libcurl are enabled in TremFusion. And yes, it's very, very nice. You should go get it, I think you'd like it.
https://www.tremfusion.net/trac/wiki/Releases
-Ender
-
Auto-downloads via libcurl are enabled...
They're enabled on the release I compiled on my desktop too; but that doesn't have anything to do with the possible problems that they create, nor the discussion of whether or not to have them turned on by default in the next release :>
-
Auto-downloads via libcurl have been available since tjw put up the famous "tjw build".
-
auto downloads are definitely a positive thing for a game to have and i think to not make it standard with trem would be a disservice to the community. most online games are already set now for auto dls and the auto dl feature avoids the confusion of how and where to install things if you download them manually
-
There are known security risks in the current implementation of QVMs, but the point is that even if they are addressed then running code on your computer is still an inherently Bad Thing from a security standpoint. There WILL be a buffer overflow or a bug exploit somewhere and noobs who don't know the difference between a bad server and a good one will get caught in the crossfire. I say noobs because that's basically who we're talking about - in 1.2 there will be an Options screen on the main menu with an "allow downloads" choice so I really think that anyone who comprehends the risk will not have a problem. Even without the security flaws, it is very easy to at least ruin your game of Tremulous with some well-placed menu or config files.
This kind of leads me on to another issue that many of you have overlooked. Assuming that your clients have autodownload on - better still, by default, such that they might not even know - you can put whatever shit you like in a zip and become a Community Modder like a shot. Take a look at the X and A servers, and imagine what it would be like if they had access to the class configs, models, sounds... currently modding is restricted to people who are serious about creating something worthwhile, because they know that their playerbase is reduced and that people joining will have intentionally opted in to their download and know what to expect. A culture of noobs who don't pay any attention to the downloading screen or any thought to how it might change their experience is in for a nasty shock.
Not that I'm completely against the idea. But it's far better to have a dialog like the one tjw recommended or Risujin coded. Of course we can never truly defeat the "yes/I agree/whatever" issue but it's certainly better than either option that has the computer decide. It would also be good if after downloading the pk3 and before opening it, you were given a listing of all the files it contained and the option to delete it and disconnect.
-
The implication that security could be preserved as mentioned previously in this thread is laughable. All OSs are patched against known exploits. Does this imply that there will be no more virus/worms/etc? Autodownloads means one server could cause all sorts of problems, perhaps so quietly that the user won't know, to all sorts of people.
It should be disabled on download and offered to be turned on, per server would be best IMO. It is the typical newbie coder attitude of "its fixed, what could possibly go wrong?" that should be avoided. I've dealt with it for years. "Sure, change these DB constraints on the production DB. It only changes this, what could possibly go wrong?" Then I watch as a server farm drops like a rock.
Having a system that downloads code means you need to control the place the code is distributed from. If you cannot do that, which tremulous clearly cannot due to its nature of independent servers, then you need to make the user decide to put their machine at risk. Your not enabling it on install is the warning that it is a security risk. Computer security 101.
cue the complaints that browsers do that. Yes, see the javascript/flash/ad nauseum methods of infecting/breaking/rooting computers. Then realize that the people making browsers, even OSS, have paid employees working on it to wake up at 2am to code a workaround and they have automated distribution channels, and computer professionals expect them to have serious security issues due to their nature.
-
As It was suggested before. A simple script to check the pk3 for the qvm/ui files on the client side will allow you to choose whether you want to download the map file or the actual mod (if map file after download did contain the qvm/ui files it is immediately disabled and a warning is given to the client).
By disabling the autodownloads you are not only discouraging the servers to mod tremulous, but you are also discouraging the servers to run custom maps. And users turn on the auto downloads not because of the mods the server wants them to download, but mainly because they want to play a new map and cannot be asked to search it via google and dl/place it manually.
I can understand limiting the modding capabilities, but limiting the maps is a nonsence.
-
Just to note, loading of DLLs is not the only thing, tremulous has various places that it can be exploited using a buffer overflow. Hell i know of a method off the top of my head that wouldn't require a download at all, it can be done server side on connect.
-
Just to note, loading of DLLs is not the only thing, tremulous has various places that it can be exploited using a buffer overflow. Hell i know of a method off the top of my head that wouldn't require a download at all, it can be done server side on connect.
http://bugzilla.icculus.org/ (http://bugzilla.icculus.org/)
-
most of us has autodownloads off and forced to quit when any new maps appears.
some of us has autodownloads on because we are curious.
some of us are in a huge pile of security danger.
BLEEHHHH
-
Just to note, loading of DLLs is not the only thing, tremulous has various places that it can be exploited using a buffer overflow. Hell i know of a method off the top of my head that wouldn't require a download at all, it can be done server side on connect.
http://bugzilla.icculus.org/ (http://bugzilla.icculus.org/)
Id rather pass it directly to a tremulous dev rather than post the exact way of doing it on a public bug tracker.
-
so many games already use auto dls though, even with the possibility of getting a virus. if the risk was that great, then games would not come with the feature enabled. i agree that by disabling this you are doing a disservice to the community my disallowing mods and new maps to be more readily accepted. besides just look back to trems roots. . .
-
Just to note, loading of DLLs is not the only thing, tremulous has various places that it can be exploited using a buffer overflow. Hell i know of a method off the top of my head that wouldn't require a download at all, it can be done server side on connect.
http://bugzilla.icculus.org/ (http://bugzilla.icculus.org/)
Id rather pass it directly to a tremulous dev rather than post the exact way of doing it on a public bug tracker.
/query Timbo
-
besides just look back to trems roots. . .
You think people got a hold of the Tremulous Q3mod via automatic downloads? Man, if I had known that at the time it would have saved me a lot of aggravation while downloading tons of tiny pk3 files!
Automatic downloads should be disabled by default, since you should not force automatic downloading of stuff onto people, ever.
If a person does not have the common sense to find the menu option that relates to enabling automatic downloads, I think that
person might just be too thick for a game of Tremulous.
-
Originally I thought it should be on, but after reading this, no. It definitely should be off, for the reasons people have been saying.
Aside: any way to change my vote on the poll?
-
The thing that some people do not realise is that having those security risks does not make it safer to have autodownloads off.
As long as there are custom maps people WILL turn the autodownloads on. Just to be able to play them. They are not aware of security risks and unable to tell a mod from the map. And having them off by default is both restricting the customs maps AND not helping the security problem.
The only proper solution (besides fixing the holes) is to split the map downloads and mod downloads. and have the latter disabled with a warning when you enable it.
-
Except that map paks might contain exploits too. Almost any file format has had it's exploitable buffer overflows or similar bugs. Same goes for the network protocol, unless you prove that the code has no bugs (and then prove that the compiler you used has no bugs and that the CPU you run it on has no bugs, etc.) there is always some risk.
At the end of the day, running a pak is a matter of trust in it's origin, just like opening an email or a web page.
But I agree, that the autodownload option should be available, but disabled in the default settings.
-
Should be on. Anyway everybody turned it on already. Only noobs don't know where to allow it and then are on every server same default maps, because noobs don't know how to download map or how to turn on autodownload so they don't want maps that can't play. :-X
If one requester appear before downloading map starts "Download this map? It's security risk, blah blah, it can kill your dog, blah... YES/NO" then it will solve all.
I don't know anyone who downloading all maps manually and checking their content. :angel:
-
Trust plays a big part in the whole security issue, from what i have seen there is no reason to hurt any of the players on tremulous. From my experience alot of the players are nice....I guess its times like these you just have to have trust in the community...
-
how about a straight QUESTION whenever the server wants you to download something?
server XYZ needs you to download the following file to be able to play at this place: "UTCS.wtf" wich is supposed to be a MAP /pure
server XYZ needs you to download the following file to be able to play at this place: "grangerp0rnz00rz.wtf" wich is supposed to be a MOD /unpure /requires: wHagg1n4z.wtf wich is a MAP
-
Except that map paks might contain exploits too. Almost any file format has had it's exploitable buffer overflows or similar bugs. Same goes for the network protocol, unless you prove that the code has no bugs (and then prove that the compiler you used has no bugs and that the CPU you run it on has no bugs, etc.) there is always some risk.
At the end of the day, running a pak is a matter of trust in it's origin, just like opening an email or a web page.
But I agree, that the autodownload option should be available, but disabled in the default settings.
Buffer overflow is a bug, not a security risk. Whats the difference if the game will crash, or player will not be able to play on the server/s ?
The real security issue is that the server can make the client download and execute code on the client side, and especially escape the VM sandbox. And here the client can have the check for the vm/dll files in the pk3, and auto-disable those packs that have them.
-
*double post*
-
The real security issue is that there shouldn't be risks that most of us already has here at 1.1. isn't that a kind of paradoxon? :-)
-
I think it should be on. I don't think that with Tremulous there is very much a risk, and I have been playing games like COD UO and wolfenstien for a long time and not gotten any problems.
-
Let me clear up a myth: DLLs can not be loaded from a pk3, the dll must be manually installed into your base folder, and only you can do that. Also, most exploits which allow executing arbitrary code on the client from qvms have been fixed.
Now, about enabling auto-downloads: I vote for enabling them, but with risujin's download prompt. This will allow people to control whether they want to download stuff or not, all while allowing trem to be modded and custom maps to be made.
-
Also, most known exploits which allow executing arbitrary code on the client from qvms have been fixed.
fixed that for you. Nothing against the present tremulous and/or ioq3 codebase, but bugs happen. Security decisions shouldn't be made for the user unless its encourages greater security. Even if the user doesn't fully understand the decision and/or risks, it is still their decision to make.
Downloading code that is run is a security risk. As it should be the decision of the user, that decision should be offered to them, not foisted upon them.
-
Also, most known exploits which allow executing arbitrary code on the client from qvms have been fixed.
fixed that for you. Nothing against the present tremulous and/or ioq3 codebase, but bugs happen. Security decisions shouldn't be made for the user unless its encourages greater security. Even if the user doesn't fully understand the decision and/or risks, it is still their decision to make.
Downloading code that is run is a security risk. As it should be the decision of the user, that decision should be offered to them, not foisted upon them.
edit: personally, I would feel much more comfortable with a one or two time prompt that is short and sweet that informs the user that there are inherent security risks with turning on autodownloads, but that the game may be more fun if they do.
-
Screenshot of risujin's download prompt:
https://bugzilla.icculus.org/attachment.cgi?id=1334&action-view (https://bugzilla.icculus.org/attachment.cgi?id=1334&action-view)
I'm adding this to tremfusion for our next release.
Broke the link - got tired of Icculus's self-signed cert whining. --Rocinante
-
Very nice! Hmm, maybe it's time I updated my client from the 2006 TJW build...
-
Very nice! Hmm, maybe it's time I updated my client from the 2006 TJW build...
the download prompt doesn't work with just an updated client.
-
Let me clear up a myth: DLLs can not be loaded from a pk3, the dll must be manually installed into your base folder, and only you can do that. Also, most exploits which allow executing arbitrary code on the client from qvms have been fixed.
Now, about enabling auto-downloads: I vote for enabling them, but with risujin's download prompt. This will allow people to control whether they want to download stuff or not, all while allowing trem to be modded and custom maps to be made.
And the QVM can write that DLL, it can drop code anywhere on your system, and it can then screw you some more.
Its been proven time and time again that there are retards who hate this community and have the time and resources to hurt it.
IMO It should only download to the base folder, and refuse to load anything from that folder other than maps. Data / vms can go in the install folder, and mods can be installed by hand / some other more user-involved system.
-
So auto-downloading is by design about more than maps / models / and any other eye candy?
the people who coded it are actually aware that this qvm/scripting-stuff can be downloaded and executed?
has it been confirmed that the developers have actually been informed of the exploits? ioquake3 devs?
btw, this poll is useless as the people who are voting are not fully informed and they might even think that the only way it can be abused is for downloading porn, i read this thread and i still don't feel like i'm qualified to even vote on this, i don't know which opinions are those of experts or trash, there are conflicting opinions. there might be a huge history on patched security problems for this game i don't know about because people are still afraid of talking about it. do things get properly fixed? buried in a changelog or not even included in a change log? does the ioquake3 project get the relevant patches/reports?
On the subject of buffer overflows: there will always be buffer overflows everywhere, the network protocol can be buffer overflowed, on a game with millions of players and autodownloading enabled by default i don't believe there has been a single case of people buffer overflowing through the maps / eye candy. People can buffer overflow you through the forums, with external images, links, flash, internet explorer.
I expect to see a future full of much simpler exploits than buffer overflows, like clients downloading a config with the rcon password, servers downloading files from clients, mods containing back doors, a guid system that never really gets fixed, never ending confusion about mods/qvm/dlls/scripts/security, anti cheat methods backfiring.
On the subject of abusing the download system to ddos people: if the game clients send the game servers IP in the referer variable to the web server, a simple php script or .htaccess file can prevent other servers from using their fast download service.
Multiple security risks? how many? how do we even know which we're talking about? is someone assuming that everyone else knows about an exploit that only that person knows about?
- All executable code off, but with the option to turn it on (QVMs, etc) with a very stern warning of why it's a bad idea
- An in-game "Do you want to do this" kind of option which can ask if you really want to trust that QVM you just downloaded
What is the history of autodownloadable QVMs doing good things? aren't the server side only mods capable enough?
I think popping up a question for this is a bad idea, no matter how stern you are the end user is not qualified to make the decision like this, the end user will either be left confused and uncomfortable or carelessly vulnerable. I see this as a bad way of transferring responsibility.
-
Lava Croft: fixed
-
Please refrain from double posting and click the 'Modify' link to modify your post and add anything you forgot earlier.
-
What is the history of autodownloadable QVMs doing good things? aren't the server side only mods capable enough?
No. One very frequent example is the scoreboard: If any mod has a gametype that isn't humans vs aliens scored on "kills", the scoreboard will not reflect this without a download.
-
everything has some risk to it. maybe tomorrow someone will steal your computer or your house will burn down leaving the fact that you had auto downloads disabled completely pointless. you might get a few virus on your computer from tremulous or from downloading that torrent. disabling auto downloading is done only by the devs and smarte people because they know what can be done to there computer through 1 second of auto download they can predict the future and know what pk3s to download in advance they know all.
-
Automatic downloads should be off, but when the player has to download something or disconnect, they should be given the option to do so (and a warning that it may be malicious). Risujin's prompt seems best for this.
-
And the QVM can write that DLL, it can drop code anywhere on your system, and it can then screw you some more.
Wrong, wrong, maybe if someone finds another hack in the future, but it will be fixed as soon as possible and someone (if the devs don't) will release a fixed client.
IMO It should only download to the base folder, and refuse to load anything from that folder other than maps. Data / vms can go in the install folder, and mods can be installed by hand / some other more user-involved system.
That's pretty much killing all the mods that exist. How about you keep your standard qvm, and then have the client download scripts to extend it?
I think popping up a question for this is a bad idea, no matter how stern you are the end user is not qualified to make the decision like this, the end user will either be left confused and uncomfortable or carelessly vulnerable. I see this as a bad way of transferring responsibility.
What solution do you suggest?
-
Wrong, wrong, maybe if someone finds another hack in the future, but it will be fixed as soon as possible and someone (if the devs don't) will release a fixed client.
Oh great, then the fix will be pushed through the auto-update mechanism and nobody will be able to play until they update their clients, right? Oh wait, actually a really small percent will ever download an updated client, especially if not official. The safety of non-upgraders is still a factor when making decisions like this.
That's pretty much killing all the mods that exist. How about you keep your standard qvm, and then have the client download scripts to extend it?
Client auto-downloads of vms to base produce unpredictable behavior in the current generation of clients because it is assumed that one would never have vms auto-downloads to base. This is because the very concept of having mods to the base game is rather strange. If your mod goes beyond what you can do without changing the vms, it dedidedly shouldn't have fs_game=base. Servers can very happily either force or allow people to use different models/skins/other assets (yes, even within sv_pure), which really is about as far as a mod to base should ever go before it's no longer "base" and shouldn't pretend it is by not changing fs_game.
-
*removed as this suggestion was made already =P*
-
Oh great, then the fix will be pushed through the auto-update mechanism and nobody will be able to play until they update their clients, right? Oh wait, actually a really small percent will ever download an updated client, especially if not official. The safety of non-upgraders is still a factor when making decisions like this.
Well then just get an auto-update system. I will.
Client auto-downloads of vms to base produce unpredictable behavior in the current generation of clients because it is assumed that one would never have vms auto-downloads to base. This is because the very concept of having mods to the base game is rather strange. If your mod goes beyond what you can do without changing the vms, it dedidedly shouldn't have fs_game=base. Servers can very happily either force or allow people to use different models/skins/other assets (yes, even within sv_pure), which really is about as far as a mod to base should ever go before it's no longer "base" and shouldn't pretend it is by not changing fs_game.
But you still said you wouldn't allow any vms downloads, even to another fs_game folder.
-
Well then just get an auto-update system. I will.
::)
But you still said you wouldn't allow any vms downloads, even to another fs_game folder.
I did? Enlighten me where. You seem to have mistaken my calling you out on your false assumptions to mean I hold the opposite position.
No, I think that vms downloads should be seperate from map downloads, as others have said here. Map downloads should default to on. VMS downloads should have a nice large download/warning prompt.
-
IMO vms and game data shouldn't be treated separately. They can both be abused. They can both be exploited if a bug is found in the code which handles them.
-
I fail to see how maps can be abused. Sure, you can piggyback a QVM onto one. But if there's code that detects QVMs, the problem is nonexistent.
-
And the QVM can write that DLL, it can drop code anywhere on your system, and it can then screw you some more.
Its been proven time and time again that there are retards who hate this community and have the time and resources to hurt it.
IMO It should only download to the base folder, and refuse to load anything from that folder other than maps. Data / vms can go in the install folder, and mods can be installed by hand / some other more user-involved system.
That system would work except for mods for them there should be a pop up message asking if you are willing to except the risk like what was was suggested earlier.
-
I fail to see how maps can be abused. Sure, you can piggyback a QVM onto one. But if there's code that detects QVMs, the problem is nonexistent.
A buffer overflow in the loading code and you can run arbitrary code.
That system would work except for mods for them there should be a pop up message asking if you are willing to except the risk like what was was suggested earlier.
And that wouldn't work anyways since any newer revision of trem prevents writing a DLL.
-
Yes executable exploits in non-executable code are possible and do happen, but the odds are far less than with running VM code. Loading a map in Trem isn't any different from loading a jpeg in your browser. Web browsers don't default-off all images because they could exploit an unknown bug in the jpeg parser, but they do warn users when they are downloading executable files.
Yes, exploits in jpegs and mp3s and such have all happened, but it's still incomparable to the risk taken by running executable code on-purpose, and in current computing paradigms that very low level of risk is an acceptable one.
If such a thing happened, there WOULD be an official update release.
-
But QVM code is more like Java code. It runs in a sandbox. There may be bugs that allow to escape from the sandbox, but it doesn't play in the same league as downloading and running native executable files. IMHO, if there is such a bug it isn't different than a exploitable bug in the jpeg or bsp or whatnot loader.
-
But QVM code is more like Java code. It runs in a sandbox. There may be bugs that allow to escape from the sandbox, but it doesn't play in the same league as downloading and running native executable files. IMHO, if there is such a bug it isn't different than a exploitable bug in the jpeg or bsp or whatnot loader.
Exactly my point, thank you.
-
A java program can trash your computer, and so can a QVM.
QVM's were *not* designed with security in mind at all, and as such will *never* get an acceptable level of security without a complete redesign.
Like with java, the aim is compatibility across incompatible systems.
Also, allowing 3rd parties to run code without my interaction would probably be enough to get tremulous classed as malware, and without a good EULA, would (I think) be illegal under UK law.
-
Im all for user confirmation to *run* any code in the pk3 (with an option to skip the confirmation permanently for selected pk3s), but I think the issue here is the *download* of pk3s. I think it's just as dangerous to run an autodownloaded pk3 as it is to run a map-super-fun.pk3 that I had to manually download from a web server.
As for EULAs, I think all QVM code is GPL'd, so if someone hides a QVM in a map, they have to distribute the source code too, so anyone can quickly check the code for exploits. :angel:
-
Why waste time downloading something I'm not going to run?
And there's no database of info about the pk3's, so how's it to remember which ones I like? Or should it prompt about them all every run?
The GPL covers distribution, EULA's cover usage. There is a massive difference.
Also, you are not required to agree to the GPL to download or use GPL software, the distributor just has to make reasonable effort to make sure you know it exists.
-
My point is that when a server I usually puts a new map in it's rotation, then I will download it either manual or automatic with the expectation that there is no executable code in it. I may open the zip file and check if there are QVMs included or decompile the maps or whatever, but I would very much prefer if the engine checks this for me and gives a warning message. Usually you should only have QVMs in the data.pk3 and maybe one or two mods. That can be kept in the .cfg, no need for a database.
The GPL gives me the right to get the source code to any QVM I download, so I can read it, check it, modify it. Only if I redistribute it I am bound again by the GPL. An EULA is a contract that the creator (not the distrubutor) of the software wants the user to accept. So they are indeed very different things. I just wanted to note that the distributors of QVMs, (i.e. anyone who puts a pk3 with a qvm file in it on a webserver) is legally bound by the GPL.
-
There is no reason a QVM should ever be in a pk3 inside ~/.tremulous/base.
vms-*.pk3 is in the install folder, and mods should be in there mod folders.
IMO all pk3s should be forced to comply with the naming-scheme already in use, and whats loaded from them would then depend on the prefix on the name. That way you don't need to check the contents, as trem wont even bother looking for a qvm in a pk3 that doesn't start vm- or for data in a pk3 that doesn't start data- (or the loaded map's pk3)
-
Wow, a lot of people posted while I was at work.
A buffer overflow in the loading code and you can run arbitrary code.
If you add code to prevent buffer overflows, that exploit won't work.
-
Fixing a buffer overflow is easy, its finding it before the bad-guys that's the hard bit.
Also, this is an open source game. Once a fix is released the bad people have it. In closed source you have the time it takes them to decompile it, here you don't.
Unless you can get the update everywhere in a few hours, then its probably better to not release it until someone bad finds it.
And all the image / model / map code is old. It's over the "acceptable security" threshold.
-
There is also the challenge of getting a popular server.
-
There is no reason a QVM should ever be in a pk3 inside ~/.tremulous/base.
I want to use my custom QVMs on an unpure server.
-
There is no reason a QVM should ever be in a pk3 inside ~/.tremulous/base.
I want to use my custom QVMs on an unpure server.
It's pretty much a given that all bets of any resonable sanity are off, in an unpure server. Actually, their causing odd behavior on unpure servers is part of the reason why vm downloads to base are a bad idea.
-
Well maybe if unpure wasn't so much of a failure and didn't load any pk3 from the base folder, then it would work. See my new pure system in tremfusion.
-
Well maybe if unpure wasn't so much of a failure and didn't load any pk3 from the base folder, then it would work. See my new pure system in tremfusion.
Removing it / making it optional is not a "new pure system." It's a new client behavior for sv_pure 0, which is the only server option. Thus, it's a new unpure system. Billing your features and projects deceptively is a bit of a theme with you though.
Unpure is a failure because Pure is the fix. Pure is only bad to you if you do not wish to allow server owners to choose how the game is played on his/her own server on which you play for free.
Obviously I do not speak for the developers, but I can still say pretty confidently that it's extremely doubtful that sv_pure is going anywhere in Tremulous. Solutions derived for your little pretend-Tremulous world that do not/could not/will not apply to Tremulous are entirely irrelevant to the discussion at hand.
-
In general using a QVM not sanctioned by the server will cause problems due to incompatibility.
If you happen to be smart enough to make sure your QVM works with the server in question, then you're a "power user" and can do what you want, just don't expect any one to offer you help when it goes wrong.
-
I SAID YES FOR THIS CAUS IT IS A LOT EASER FOR UNEXPERIENCED PLAYERS.
-
K
-
Ahem.
CAPS LOCK IS CRUISE CONTROL FOR COOL!!!!!!!!!!!!!
On Topic, Maybe it would be a good Idea to have the option to turn Autodownloads on and off during the install process. Now, it wouldn't fix the problem of people blindly clicking yes, but really, Is it really our problem if someone decides to do something potentially stupid/dangerous to their computer without thinking it through?
-
let the thread die please, there's a newbie friendly solution to the download problem in the works for 1.2.