All this talk of making a special tool is completely unnecessary. All that we need to do is make it so maps and mods can be downloaded from the host of a game within the lobby interface.
Regardless of how simple it is, many people won't need this tool anyway - just put the maps and mods in the right folder. When they host a game, in turn, the maps and mods will naturally spread to the rest of the users, who can then easily host that game, and so on.
Downloading content from host of a game in lobby
Moderator: Moderators
And I direct you to the FileUniverse autodownloader. Have you not wondered why TASClient had this feature to autodownlaod yet it was removed?YokoZar wrote:All this talk of making a special tool is completely unnecessary. All that we need to do is make it so maps and mods can be downloaded from the host of a game within the lobby interface.
Regardless of how simple it is, many people won't need this tool anyway - just put the maps and mods in the right folder. When they host a game, in turn, the maps and mods will naturally spread to the rest of the users, who can then easily host that game, and so on.
Autodownloading cut into FUs bandwidth costs veyr badly, at one point 70% of their bandwidth went through tasclients autodownloader, and there were no adverts. FU started overusing its bandwidth and FU went down at the end of the month twice by a large margin.
So FU asked for adverts in tasclient and betalord refused, so autodownloading was removed and used for patch updates instead. File universe gave the spring community 2 weeks to remove all their maps and find hostign elsewhere.
While this was happening iamacup popped up and started hosting files. These events are also why that other site witht hose maps hosted came about that popped up ina thread recently
Perhaps you don't get what i'm saying - not have an integrated central downloading site where all their bandwidth will get hosed, but to have the hosts of games optionally upload the map and mod to the other players. This would be similar to the counterstrike server you connect to uploading the next map for you to play on.AF wrote:And I direct you to the FileUniverse autodownloader. Have you not wondered why TASClient had this feature to autodownlaod yet it was removed?YokoZar wrote:All this talk of making a special tool is completely unnecessary. All that we need to do is make it so maps and mods can be downloaded from the host of a game within the lobby interface.
Regardless of how simple it is, many people won't need this tool anyway - just put the maps and mods in the right folder. When they host a game, in turn, the maps and mods will naturally spread to the rest of the users, who can then easily host that game, and so on.
Autodownloading cut into FUs bandwidth costs veyr badly, at one point 70% of their bandwidth went through tasclients autodownloader, and there were no adverts. FU started overusing its bandwidth and FU went down at the end of the month twice by a large margin.
So FU asked for adverts in tasclient and betalord refused, so autodownloading was removed and used for patch updates instead. File universe gave the spring community 2 weeks to remove all their maps and find hostign elsewhere.
While this was happening iamacup popped up and started hosting files. These events are also why that other site witht hose maps hosted came about that popped up ina thread recently
Notably, this would be a great way to take some of the bandwidth burden off of unknown files, and in turn distribute it to the player base.
Det, yokozar, UF has terabytes worth of unused bandwidth. Bandwidth isnt an issue.
Theres also the map torrent.
Downlaoding from inside the client is fundamentally flawed, its a feature people rquest without really thinking it through, and its a lot of work for an end result that isnt that great.
Just run the map torrent in the background and close it when spring starts.
Theres also the map torrent.
Downlaoding from inside the client is fundamentally flawed, its a feature people rquest without really thinking it through, and its a lot of work for an end result that isnt that great.
Just run the map torrent in the background and close it when spring starts.
I have to disagree. Playing new maps/mods would be _much_ easier if you just downloaded from other players in the lobby. It would open a lot of doors for people. It isn't about bandwidth so much as it is about ease of use.AF wrote:Det, yokozar, UF has terabytes worth of unused bandwidth. Bandwidth isnt an issue.
Theres also the map torrent.
Downlaoding from inside the client is fundamentally flawed, its a feature people rquest without really thinking it through, and its a lot of work for an end result that isnt that great.
Just run the map torrent in the background and close it when spring starts.
An archive mover tool does not work for Linux.AF wrote:I disagree. You really havent throught it through at all.
And even if there werent inherent flaws in it, this archive mover tool makes the whole thing pointless.
It's also three extra step for users - they have to go to unknown files, download the map, and open it with the archive mover. None of that is necessary if the lobby client handles downloading for you.
From a sheer usability standpoint, downloading within the client is far preferable - even if it's slow and not peer to peer.
Hardly, users should know about places like UF if they plan on using spring.
The lobby can send them directly to the download page.
Whatsmore directly downloading to the lobby isnt feasable as not all files are simple drag and drops. For example, AA needed user intervention, and there're maps and mods with dependencies.
What about lua widgets? They dont follow any standard packaging of any kind.
As convenient as an in client downloader may seem, it just doesnt cut it, and it really only serves to cut down on 1 or 2 mouse clicks.
The average broadband user can provide 256kbps of upstream bandwidth. Split that betwen 3 users for the average 2v2 thats 85kbps which is 10-11KBps.
Ontop of that hosters will need to have it switched off by default. Your system would collapse very quickly with only a handful of people sharing and a great heaving mass of leechers.
Ontop of that maps can take a long time to downlaod at 30kbps nm 11kbps. That host will also want to save upstream bandwidth for themselves for browsing and other things such as lobby conenctions etc.
Beign realistic, downlaodign from other players will never work unless its p2p and turned on by default. P2P would be a lot of work for something that can already be done much better by an extrenal app. Itll never be allowed on by default or there'd be a lot of angry players and hassled lobby developers.
Being realistic, your not going to get what you want even if its implemented, its a flawed feature, and while I know you want it for UI rasons, I'm telling you it will not work if implemented.
And why cant the archive mover work for linux? Why cant a linux version be made?
The lobby can send them directly to the download page.
Whatsmore directly downloading to the lobby isnt feasable as not all files are simple drag and drops. For example, AA needed user intervention, and there're maps and mods with dependencies.
What about lua widgets? They dont follow any standard packaging of any kind.
As convenient as an in client downloader may seem, it just doesnt cut it, and it really only serves to cut down on 1 or 2 mouse clicks.
The average broadband user can provide 256kbps of upstream bandwidth. Split that betwen 3 users for the average 2v2 thats 85kbps which is 10-11KBps.
Ontop of that hosters will need to have it switched off by default. Your system would collapse very quickly with only a handful of people sharing and a great heaving mass of leechers.
Ontop of that maps can take a long time to downlaod at 30kbps nm 11kbps. That host will also want to save upstream bandwidth for themselves for browsing and other things such as lobby conenctions etc.
Beign realistic, downlaodign from other players will never work unless its p2p and turned on by default. P2P would be a lot of work for something that can already be done much better by an extrenal app. Itll never be allowed on by default or there'd be a lot of angry players and hassled lobby developers.
Being realistic, your not going to get what you want even if its implemented, its a flawed feature, and while I know you want it for UI rasons, I'm telling you it will not work if implemented.
And why cant the archive mover work for linux? Why cant a linux version be made?
Why? Why can't they just click "Spring" from their Add Applications dialog and have it just work?AF wrote:Hardly, users should know about places like UF if they plan on using spring.
True. This is an easy enough feature to do, and would help quite a bit. It's still suboptimal though, as users either need to be told where to put the file (into a hidden directory on Linux).The lobby can send them directly to the download page.
Wouldn't that be a problem for the archive mover as well?Whatsmore directly downloading to the lobby isnt feasable as not all files are simple drag and drops. For example, AA needed user intervention, and there're maps and mods with dependencies.
It's also not clear to me why any map, mod, or script should require user intervention beyond drag and drop to simply install. Default configurations that at least run are very much needed for users to think the software isn't simply broken.
I don't know, it's an unsolved problem. Fortunately, lua widgets that aren't part of a mod's default archive aren't necessary to play with either, so if we exclude them from the download process it won't be so bad.What about lua widgets? They dont follow any standard packaging of any kind.
A little more than that. More important than the number of clicks, however, is the amount of user intervention required. Our users want to play a game, not learn about how Spring stores its archives or move files around their operating system.As convenient as an in client downloader may seem, it just doesnt cut it, and it really only serves to cut down on 1 or 2 mouse clicks.
So? This is all before the game starts, and all voluntarily.The average broadband user can provide 256kbps of upstream bandwidth. Split that betwen 3 users for the average 2v2 thats 85kbps which is 10-11KBps.
If we did it via torrents, it would only take a couple of people with lots of maps and a good connection keeping the lobby client open to make things work well for everyone.Ontop of that hosters will need to have it switched off by default. Your system would collapse very quickly with only a handful of people sharing and a great heaving mass of leechers.
Besides, if it's too slow, the user can always download it by hand using the old fashioned way you're advocating.
I'm not sure how much extra work it actually is. There are open source bittorrent implementations out there that can be more or less just dumped into the code.Ontop of that maps can take a long time to downlaod at 30kbps nm 11kbps. That host will also want to save upstream bandwidth for themselves for browsing and other things such as lobby conenctions etc.
Beign realistic, downlaodign from other players will never work unless its p2p and turned on by default. P2P would be a lot of work for something that can already be done much better by an extrenal app. Itll never be allowed on by default or there'd be a lot of angry players and hassled lobby developers.
I'm still not clear on what you mean by it "won't work". Do you mean that no one will use it because they don't have enough bandwidth or everyone decides to leech? Or did you mean it would be so technically difficult to implement that no one could do it?Being realistic, your not going to get what you want even if its implemented, its a flawed feature, and while I know you want it for UI rasons, I'm telling you it will not work if implemented.
You'd have to make a different version for Linux than the Windows one due to differences in the filesystem hierarchy, that's all. Installing the software onto the Linux system, unfortunately, would also be hard due to differences in distributions and desktop environments - almost hard enough to cancel out the usability advantages of the archive mover to begin with.And why cant the archive mover work for linux? Why cant a linux version be made?
That's not really a valid argument in this discussion since it applies to the ArchiveMover too. It is the responsibility of the content creator to ship his packages in the standard drag 'n drop format, or to create an installer, provide clear instructions, or deal with the consequences otherwise.AF wrote:Whatsmore directly downloading to the lobby isnt feasable as not all files are simple drag and drops. For example, AA needed user intervention, and there're maps and mods with dependencies.
What about lua widgets? They dont follow any standard packaging of any kind.
That's not really true, it is a matter of setting standards. If it is standard enough that Spring user data is in ~/.spring on Linux, then it is trivial to make the archive mover put the file there if ~/.spring is indeed an existing and accessible directory on the users system.YokoZar wrote:You'd have to make a different version for Linux than the Windows one due to differences in the filesystem hierarchy, that's all. Installing the software onto the Linux system, unfortunately, would also be hard due to differences in distributions and desktop environments - almost hard enough to cancel out the usability advantages of the archive mover to begin with.And why cant the archive mover work for linux? Why cant a linux version be made?
(it could even share the methods Spring uses to determine it's main data directory location, ie. read /etc/spring/datadir, look at SPRING_DATADIR environment variable, etc.)
If in the future Spring allows multiple data directories on windows, then it can't know either where to put the files exactly. But by either setting a standard directory or a standard place where to look up this directory, it can still work.
-
Tim Blokdijk
- Posts: 1242
- Joined: 29 May 2005, 11:18
Tim, your crossing the line.
Linux lobby development is moving faster than ever and is fast approaching the tipping point were tasclients featureset has been totally replicated and improved upon.
At this critical time the issue of torrents arises, threatening to derail the entire process and at the same time create an entire development problem of its own.
This big song and dance created is giving the impression that torrents are coming. The language used assumes that this is a future planned feature, possibly already underway, and users are just starting to forget from the last time, its betalords ladder all over again, only this time nobody has made any commitment, and there are no existing rivals such as spring league, and the whole thing was spammed in 3 threads in different forums and continues to be proactively spread.
As a result, if yokozar continues to make such a big song and dance he risks tarring the future featurelist. I initially planned for 1<-> file transfers in AFLobby but because of the big song and dance over torrent sharing I have to scratch that from my planned feature list now because people will immediatly expect me to implement to torrent protocol and the necessary framework to support it which could set back my big features by several months which is unnacceptable.
Whatsmore, community time and effort which could be better spent elsewhere is being channeled into discussion of the new feature that hasnt been announced confirmed or supported by any developer yet. Its vaporware, MOTD, and its now going to float around the forum and the lobby for months to come.
And who're users going to look to in a few weeks time when no progress emerges?
This huge push for this feature request is irresponsible and damaging. Now is not the time for it, especially not now.
Linux lobby development is moving faster than ever and is fast approaching the tipping point were tasclients featureset has been totally replicated and improved upon.
At this critical time the issue of torrents arises, threatening to derail the entire process and at the same time create an entire development problem of its own.
This big song and dance created is giving the impression that torrents are coming. The language used assumes that this is a future planned feature, possibly already underway, and users are just starting to forget from the last time, its betalords ladder all over again, only this time nobody has made any commitment, and there are no existing rivals such as spring league, and the whole thing was spammed in 3 threads in different forums and continues to be proactively spread.
As a result, if yokozar continues to make such a big song and dance he risks tarring the future featurelist. I initially planned for 1<-> file transfers in AFLobby but because of the big song and dance over torrent sharing I have to scratch that from my planned feature list now because people will immediatly expect me to implement to torrent protocol and the necessary framework to support it which could set back my big features by several months which is unnacceptable.
Whatsmore, community time and effort which could be better spent elsewhere is being channeled into discussion of the new feature that hasnt been announced confirmed or supported by any developer yet. Its vaporware, MOTD, and its now going to float around the forum and the lobby for months to come.
And who're users going to look to in a few weeks time when no progress emerges?
This huge push for this feature request is irresponsible and damaging. Now is not the time for it, especially not now.
Split from maps/mods install tool thread to keep it on topic.
-
Tim Blokdijk
- Posts: 1242
- Joined: 29 May 2005, 11:18
Normally I would probably not bother discussing this with you with all this drama but I'm going to do it as I spend quite a lot of time working on development processes. And it's quite insulting to see how badly it's applied here. So I'm going to put my foot on this and find out what's the problem. I like to see all this changed, we are going to shape up and deal with this like real man now. Otherwise it's quite useless to try and apply those development processes to anything here as drama would still derail development at any time it pop's up.
I'm going to take all your arguments and walk trough them one by one.
That way we can solve them if they indeed are a problem to deal with. As now it's dumping 20 problems on a big pile and stating it's not possible to do anything with it.
I'm going to take all your arguments and walk trough them one by one.
That way we can solve them if they indeed are a problem to deal with. As now it's dumping 20 problems on a big pile and stating it's not possible to do anything with it.
Can you reply in detail AF so we can sort out the problems that remain?AF wrote:Tim, your crossing the line.
By doing what exactly?
Linux lobby development is moving faster than ever and is fast approaching the tipping point were tasclients featureset has been totally replicated and improved upon.
At this critical time the issue of torrents arises, threatening to derail the entire process and at the same time create an entire development problem of its own.
Untrue, discussing a torrent system has no no direct effect on the development process. And yes, it brings with it a few technical things with it that need some thought, but not a level that I would call it a "problem".
This big song and dance created is giving the impression that torrents are coming. The language used assumes that this is a future planned feature, possibly already underway, and users are just starting to forget from the last time, its betalords ladder all over again, only this time nobody has made any commitment, and there are no existing rivals such as spring league, and the whole thing was spammed in 3 threads in different forums and continues to be proactively spread.
"This big song and dance" is created by you.
Discussing a feature won't mean it's already planed but we can take it to the private dev forum (as it's not yet world readable) to solve that if you can't discuss this publicly?
What has Betalord to do with this at this point?
And what has a league to do with it?
And it's indeed not practical to have different treads about it. Maybe we should close a few and pick one?
As a result, if yokozar continues to make such a big song and dance he risks tarring the future featurelist. I initially planned for 1<-> file transfers in AFLobby but because of the big song and dance over torrent sharing I have to scratch that from my planned feature list now because people will immediatly expect me to implement to torrent protocol and the necessary framework to support it which could set back my big features by several months which is unnacceptable.
Yokozar did open a new topic and Tobi split off this one but other then that you are doing the singing and dancing.
Where is the future feature list? I read AFS Design drafts but that's mainly server side right? Anyhow discussing a new feature should not effect any feature list in a negative way.
People's expectations should only have a limited effect on the roadmap, the developers have to set the goals. If other features would be set back then it can be a good idea to give this new idea a lower priority then those other features.
Whatsmore, community time and effort which could be better spent elsewhere is being channeled into discussion of the new feature that hasnt been announced confirmed or supported by any developer yet. Its vaporware, MOTD, and its now going to float around the forum and the lobby for months to come.
You read the development process, discussion is done before it gets confirmed and supported by the developers. So discussion of this feature is the right thing to do now. Once the discussion is done it's done. If we decide it's worthwhile it might be a while before a developer has time to implement it. I can make a summery of the discussion in a plan that can be pointed to if this idea would resurface once in a while.
And who're users going to look to in a few weeks time when no progress emerges?
To that summery of the discussion I can write.
This huge push for this feature request is irresponsible and damaging. Now is not the time for it, especially not now.
You're overreacting it's untrue the development process should allow continued progress in parallel.
Tim Blokdijk wrote:AF wrote:Tim, your crossing the line.
By doing what exactly?
This is outside your juristiction. This is lobby related.
Linux lobby development is moving faster than ever and is fast approaching the tipping point were tasclients featureset has been totally replicated and improved upon.
At this critical time the issue of torrents arises, threatening to derail the entire process and at the same time create an entire development problem of its own.
Untrue, discussing a torrent system has no no direct effect on the development process. And yes, it brings with it a few technical things with it that need some thought, but not a level that I would call it a "problem".
There is a limited amount of people and resources. In case you havent noticed the spring lobby thread has already been derailed by this topic. Torrenting is a very strong feature request and discussing it like this gives the flase impression that its a planned feature and not a feature request. I know this because its happened before.
This big song and dance created is giving the impression that torrents are coming. The language used assumes that this is a future planned feature, possibly already underway, and users are just starting to forget from the last time, its betalords ladder all over again, only this time nobody has made any commitment, and there are no existing rivals such as spring league, and the whole thing was spammed in 3 threads in different forums and continues to be proactively spread.
"This big song and dance" is created by you.
Discussing a feature won't mean it's already planed but we can take it to the private dev forum (as it's not yet world readable) to solve that if you can't discuss this publicly?
No such private development forum exists, and any private discussion of the topic would be immediatly underlined with "Now is not the time, come back in 2-3 months time"
What has Betalord to do with this at this point?
And what has a league to do with it?
Betalord started a thread indicating he wanted to build an integrated lobby ladder and tournemant system. In doing so he killed off Spring league mk II. Prior to that thread he had been planning it for at least 2 years dropping in to take out ladder startups so he could carry out his plan. Of course he never did anything and people are now expecting the feature. People have expectations and anyone moving into that field has to live up to them. This is comparable to the big song and dance yokoar has created by pushing hard with hsi feature request.
And it's indeed not practical to have different treads about it. Maybe we should close a few and pick one?
Agreed, yokozar should have gone through the proper channels and created a thread in the feature request forum. Instead he chose to mention it at every available moment in as many threads as possible
As a result, if yokozar continues to make such a big song and dance he risks tarring the future featurelist. I initially planned for 1<-> file transfers in AFLobby but because of the big song and dance over torrent sharing I have to scratch that from my planned feature list now because people will immediatly expect me to implement to torrent protocol and the necessary framework to support it which could set back my big features by several months which is unnacceptable.
Yokozar did open a new topic and Tobi split off this one but other then that you are doing the singing and dancing.
This is a feature request. Past expereince shows it can be damaging and misleading to users. Yokozar has made a big deal out of this unnecesarily and hasnt gotten the hint that now isnt the tiem to discuss it or that there may be things hes not aware of that I wont be putting in this thread, he chose to argue, so I proceded in attempting to quash the arguements.
Where is the future feature list? I read AFS Design drafts but that's mainly server side right?
AFS is generic. Any features implemented are to be given context by the lobby ntot he lobby server.
Anyhow discussing a new feature should not effect any feature list in a negative way.
People's expectations should only have a limited effect on the roadmap, the developers have to set the goals. If other features would be set back then it can be a good idea to give this new idea a lower priority then those other features.
Because of the higher expections and anticipation caused by Yokozar throwing a spanner in the works, 1 on 1 file transfers has moved from a high priority to a low priority. Such a feature would no longer be seen as a complete feature but rather as a work in progress leading towards torrents. Users thus see the entire feature set differently. As a result, the numerous other features that are able to solve the problem det proposed have to be sidelined or scrapped
Whatsmore, community time and effort which could be better spent elsewhere is being channeled into discussion of the new feature that hasnt been announced confirmed or supported by any developer yet. Its vaporware, MOTD, and its now going to float around the forum and the lobby for months to come.
You read the development process, discussion is done before it gets confirmed and supported by the developers. So discussion of this feature is the right thing to do now. Once the discussion is done it's done. If we decide it's worthwhile it might be a while before a developer has time to implement it. I can make a summery of the discussion in a plan that can be pointed to if this idea would resurface once in a while.
Your site development process is for your site. Things work somewhat differently outside fo spring, especially where external tools such as lobbies AIs and other tools are concerned. Develoeprs tend not to make plans public unless things are iminent or they reach a stage were screenshots can be shown off
And who're users going to look to in a few weeks time when no progress emerges?
To that summery of the discussion I can write.
I've been doing this to people every week or two for quite a while now
This huge push for this feature request is irresponsible and damaging. Now is not the time for it, especially not now.
You're overreacting it's untrue the development process should allow continued progress in parallel.
Our community simply isnt large enough for such an ideal. AFLobby is a 1 man show mostly, and there arent that many spring lobby developers either, there is a finite amount of time and resources and an immediate pressing featurelist from tasclient that needs implementing. Delays at this time in implementing the featureset can and have killed off lobby projects in the past. They demotivate and slow down progress from developers.