Outpost Universe Forums
Projects & Development => GORF => Online Chat => Topic started by: Freeza-CII on November 18, 2009, 01:00:50 PM
-
So lets make this in a thread shall we.
IT seems that every one is opting to use the shout box instead of the irc. But there has got to be a way to just have the shout box be IRC instead. and when you log on to the forums you get right to the irc. It would also mean we would use a bot to make a shout box like buffer in which people would read what was going on. This has been done in a signature before tying irc to teh forums and seeing what people were seeing in a particular channel.
Now I myself have no f***ing idea how to implement such a tool. But surely there are some talented people here who could.
so complaints ideas yahs and nahs
-
i belive that if we do have an IRC client insted of the ShoutBox,
wouln't we need to set the fourm user name's to be the IRC's user names,
eg. login to the IRC using the same name and password from the login page and put that in the IRC Login...
and restrict the IRC to people who have loged in
-
well there is no logging into irc other then just picking your nickname. And for that I would just say it would use the name you use on the forums.
so if you log in on the forums youll be on the irc. Now im sure some one will b**** about that so ya there would be a option for it to not be on if you log into the forums.
-
like the log me on automaticly check box, right?
-
Hmm, interesting idea. I'm not sure if it's worth the work, but it is interesting.
I believe BlackBox had the IRC sig, but keep in mind that it was read only. I suspect it would be quite a bit more difficult to write messages to IRC using it, mainly due to the login and tracking user names. Plus, you might have trouble tracking when someone logs out, depending on how it's implemented. Or perhaps worse, the channel might get spammed with login/logout messages.
If the IRC feature is client based, then everytime they click a link to go to a new page, it could log them out, and then log them back in again. At least unless you figure out a way to have the IRC part in a separate pane from the rest of the site. If you make the IRC feature server side, then you can't accurately track logouts (only timeouts). You might also run into hosting issues. I believe I heard something about the current host being rather restrictive, and one of the restrictions was not being allowed to run an IRC server, which the forums would more or less become.
-
You should also think chatbox, not just IRC.
Now, it better not be log into forums, auto log into client, due to people who sometimes just gaze through the forum and then close the browser as a form of taking a break.
-
I'm against this. IRC is for live chatting. The shoutbox can continue a conversation for days at a time.
-
The shoutbox is a forum for the lazy :P
-
I concur with Sirbomber and Hidiot
-
The shoutbox is a forum for the lazy :P
Yes, plus nobody complains that the shoutbox is off-topic. :rolleyes:
-
Yes, even topics in the Test/Spam forum have... a topic.
-
I like the shoutbox 'cause I can jump onto the forum and know when somone else has been on :P
-
The shoutbox is a forum for the lazy :P
Unless you're banned from it, which also prevents you from seeing anything but the newest. :)
My own fault of course.
But I totally agree with some sort of real-time chatbox.. No, I haven't been active lately. :whistle:
-
hmmm...I don't remember banning you from it...must have been someone else :P
-
hmmm...I don't remember banning you from it...must have been someone else :P
Hooman. :)
-
I don't even remember why anymore.
At any rate, I doubt that shoutbox=IRC chat idea will happen, simply for technical reasons. Who that still frequents this place knows how to do something like that or can learn to do something like that? Now who has the time?
Plus, people don't seem to like the idea anyway.
-
@Hooman: For being disrespectul. I'm too used to other forums where my blatant hatred, arrogance, and utter offensiveness is commonplace. {:
I could probably learn, as I've seen it done before, but that's if it's wanted.
-
I could learn how to do it (would probably involve integrating the java appelet into the page coding with some extra code for giving the java the username and such (PHP Sessions could probably handle that fairly easily)), but I'm a chemical engineering major, my free time is highly limited.
Another reason against it: those of us who only respond to the shoutbox conversations because it is 100% independant of time. IRC is HIGHLY dependant on time, therefore a conversation will die prematurely due to the time elapse.
-
Another reason against it: those of us who only respond to the shoutbox conversations because it is 100% independant of time. IRC is HIGHLY dependant on time, therefore a conversation will die prematurely due to the time elapse.
How about both?
-
I fail to see the target of your question....
-
I fail to see the target of your question....
Essentially, what we have now is a real-time IRC on a seperate place, and the extended-time shoutbox. So why not both? A script to be able to hide/disable one or the other would not be difficult, and then both people can be happy.
Assuming that would actually work.
-
I think less skill demanding things are probably more important to keeping this place fun. Perhaps we should just consider improving the web site? People often have questions about making new missions, particularly the generic: "how do I get started?" questions. Lots of people seem like they'd be willing to try if only the initial learning curve wasn't so steep. We should put up some tutorials on how to do this stuff. We've been needing this for ages, just nobody has ever managed to really get it done. We've had a few tutorials on specific topics, but not really much for the true beginner. Of course, people that write such a tutorial would need to know how to use the mission SDK, setup and use a free C++ compiler, and probably know how to write web pages (the web site uses xhtml-strict).
I'm going to suggest putting this right on the website itself. Not wrapped in some wiki, or buried in some forum posts, but right on the main site. Probably even tied to the download pages for all the tools, and the tools may need to be organized better. Perhaps mark old/obsolete tools as such.
The current website is in a private SVN repository, and I've been thinking it should be moved to a public readable one, or at least make it writable for a few people other than myself. Do we need public read access, or just manage a read/write list of users? Keep in mind that I will not tie the live site to the SVN repository. Instead, any work done will be committed to "trunk", and when a new release is ready, it will get "tagged", and the tagged version will be copied manually to the site. Mostly to prevent rogue users with write access to the repository from screwing with the live site, or a new SVN/XHTML/whatever user from accidentally causing trouble. (Plus it'd be hard and awkward to tie a commit to deployment). Basically, if you want to contribute, you don't have to worry about screwing up, as your work will be checked before it goes live.
If you're interested, I guess either reply or PM me, so I can email you a user name (probably just your forum name) and a (random) password. I don't expect prior skill. A lot of stuff you just learn from actually trying to do it. Just find an area of interest and start reading. If it doesn't make sense, keep reading it until it does. There's always google to help you get started, and I can also probably point people to some relevant development resources.
I also won't say no to people starting new and possibly crazy projects in SVN, like say, a project to try and link forum users to an IRC channel. :P Just try to stick with it for a bit if you're going to add a new project, and maybe have a least some demoable function in the project before you add it. It could be really small, but it should be more than just comments.
-
1) how different is XHTML from HTML? Is it more akin to PHP or some other script?
2) If I do decide to help out, are you going to hound me just about every time you see me like bomber does (even though I've told him several times that I'm busy with school 80% of the time, and the remaining 20% is mostly taken up by sleep and transportation between points)?
-
@CK9:
XHTML is basically a more strict version of HTML. PHP is better described as a compositor for the content/html.
Main differences:- XHTML elements must be properly nested
- XHTML elements must always be closed
- XHTML elements must be in lowercase
- XHTML documents must have one root element
-
Yeah, that about sums up the differences. I suppose there are a few more finer points, but those seem to be the key ones. Lower case HTML tags mostly, and being less forgiving about closing of tags. It's essntially a "cleaned up" form of HTML, and is supposed to have less incompatible browser quirk issues. It also compresses better, since most page content has more lower case characters than upper case characters, so there is more redundancy between the page content and the markup tags. (Unless it's an AOL page...? :P). That and it's easier to type lower case tags. :)
There is an XHTML validator you can use to check your sites: http://validator.w3.org/ (http://validator.w3.org/)
I generally prefer XHTML over HTML, mostly because it seems to be the strictest set of rules, which usually means what you write is pretty much guaranteed to work anywhere. Although, it's not technically a strict subset of HTML. For example, one difference I've come across is that "<BR>" is valid in HTML, whereas "
" is valid in XHTML, and each are invalid in the other format. Basically, XHTML forces you to close every tag, including ones that are always empty (usually with the shorter <tag /> syntax, instead of the longer <tag></tag> syntax). HTML tends to ommit certain end tags when the tag never has any content. Oddly enough though, script tags still need to be given as <script></script> pairs, even if they're just referencing an external JavaScript file. It won't work if you try to use <script /> syntax.
Btw, as for various web languages, here's how their purpose breaks down:
Client Side (parsed/used/executed by the browser):
1) Content and Structure: HTML, XHTML
2) Layout and Appearance: CSS
3) Behavior: JavaScript
Server Side (parsed/used/executed by the web server):
1) Flat files simply served as is: .html (HTML/XHTML), .css, .js
2) Executed, and standard output returned (usually the output is an HTML/XHTML page, but it could be an image, or any other file type):
PHP, Ruby, ASP, Perl, Python, ... pretty much anything you want to use really, including compiled binaries.
2a) Run as a CGI script (like starting a new program, and loading it from disk for each GET request, which can be a little slow). Any language can basically be run this way, usually scripting languages, sometimes compiled binaries. Since the process is isolated from the web server, it won't bring the web server down if it crashes.
2b) Run as an Apache (or other web server) module. These get loaded by the web server when it's started and stay in memory, so they should provide lower latency responses. If the module contains a bug which could cause it to crash, it can bring down the whole web server. PHP is typically run as a module. Note that the previous comment means a bug in the PHP interpreter, not in the PHP script. The PHP interpreter should handle problems with the PHP script by basically terminating the script, without crashing the interpreter, or Apache. Ruby also has a module, although, the use of mod_ruby is somewhat questionable, mainly due to a single shared interpreter instance, and caching of required files, so they won't pick up changes unless you restart the web server. There are other Ruby modules I've heard of but they seem to basically use...
2c) Run as a seperate private internal web server, to which Apache makes proxy requests. To the client, it appears these requests are served directly by the main web server (usually Apache), but are actually served by a more custom built framework, which is usually tied to a specific language. For example, Ruby on Rails seems to use this approach. This would appear to have many of the same performance benefits as an Apache module, but perhaps with a bit of extra latency due to the proxing. Also, flaws in the secondary web server are isolated from the main web server, so if it crashes, it won't bring down the whole web server. It may however bring down that one app. I've heard in the case of a mod_rails though, that it may actually restart any failed secondary servers upon the next request that Apache gets.
I doubt I'd get after anyone for not doing work. It's not like I have time to get a whole lot done anymore. Heck, I probably don't even have the time to chase after other people to get things done. :P My intention is that it will be a purely voluntary basis. I would expect people to just work on what interests them, and if something gets done and is reasonably polished, they can post an announcement or send a PM, so it can be reviewed and put up on the site.
-
If it can wait a few more weeks, I'd be happy to help. I have 1 more week of instruction and finals week after this week is over (yay for thanksgiving break!)
-
Another reason against it: those of us who only respond to the shoutbox conversations because it is 100% independant of time. IRC is HIGHLY dependant on time, therefore a conversation will die prematurely due to the time elapse.
this is the point of using the logs from the bot it makes the same thing as the shout box viewing the log of like the last 5 or 6 lines said. you would see what was said last. But making it IRC also mean if there are 2 or more of you guys on the forums at once then you could have the live chat.
-
logs is what kills it. People are lazy by nature, and we don't like having to do more work to see the same thing.
-
To get the desired effect of the topic thats what would happen.
The whole point of this is to make it so the lazy people can stay lazy and be on irc at the same time and maybe they will enjoy the community a little more because they might get a live chat in here and there. It also might spark a interest in playing the game again.
offtopic moved hehe please continue
http://forum.outpostuniverse.net/index.php?showtopic=4716 (http://forum.outpostuniverse.net/index.php?showtopic=4716)