I'll check it out when you upload it.

On an unrelated topic, how long do you think it will be before you guys update the website? All I heard was sometime this week.
http://www.byond.com/download/build/BETA/494.1124_byond.zip

This has some alignment fixes and uses a more-compatible version of DX9 (the last one didn't work on older machines).

Will post news on the website tomorrow.
Tom wrote:
Link support should be do-able, although it does somewhat conflict with existing map click messages.

If links are opened in IE instead of the user's default browser you might as well not even bother.
Considering we manually can override links to IE with Topic() and link(), I'm not sure why BYOND can't do this automatically...
Links would work exactly like links in the text control. When sent an http:// link, the behavior of those should be (and I just confirmed) to open in the user's default browser.
The problem is links inside of in-game browsers.
I'm confused because I thought we were talking about links in the maptext. Eg, if you did maptext="http://foo.com", it would open in your external browser. You could also do maptext="byond://?something" to do internal Topic() stuff etc. Basically it would be the same handling the text control does.

I don't love the use of IE either, but it was the easiest way to let the user embed an html control inside a game. At some point we could revisit the other options; the last time I looked at it (a few years ago) there were some issues, aside from increasing the distributable size substantially, and, of course, the extra labor and inevitable bugs ;)
Tom wrote:
Links would work exactly like links in the text control. When sent an http:// link, the behavior of those should be (and I just confirmed) to open in the user's default browser.

That's great news! What happens when you click a link which is occupying the same tile as something else which is clickable? Will mouse_opacity be able to effect which object gets click priority?
mob/Login()
var/thisLink="http://www.BYOND.com"
var/textBody="<a href=[thisLink] target=_blank>Normal Link</a>"
textBody+="<p>"
textBody+="<a href=?src=\ref[src];action=link;link=[thisLink]>Topic Link</a>"
src<<browse(textBody,"window=new")

mob/Topic(href,href_list[])
if(href_list["action"]=="link") src<<link(href_list["link"])
return ..()

Would it not be possible for BYOND to have some sort of built-in link processing?
SuperAntx wrote:
That's great news! What happens when you click a link which is occupying the same tile as something else which is clickable? Will mouse_opacity be able to effect which object gets click priority?

Well, I haven't thought that far ahead but I figured it'd just process the tile first and any text links after. Or we could do something with mouse-opacity. Seems like a lot for the dev to worry about!
Falacy wrote:
Would it not be possible for BYOND to have some sort of built-in link processing?

Probably, but that's a different feature!
Tom wrote:
Well, I haven't thought that far ahead but I figured it'd just process the tile first and any text links after. Or we could do something with mouse-opacity. Seems like a lot for the dev to worry about!

Hmm, I'm just thinking of odd situations which might pop up in a game. Say you're playing a shooter where you have the text at the bottom left of your screen. There's an enemy on the bottom left of your screen, you click him a bunch of times while you're shooting, and while this is going on someone posted a link in the chat log. Suddenly you have 50 browser popups.

There should probably be a way to disable a link after it has been clicked on or maybe a way to toggle links entirely. Say clicking on a link does nothing, but while holding some button (chosen by the dev) the links are enabled. You'd do something like hold Ctrl while clicking a link to open the link in your browser. Not holding Ctrl would ignore the link when you're clicking that tile.
SuperAntx wrote:
Say clicking on a link does nothing, but while holding some button (chosen by the dev) the links are enabled. You'd do something like hold Ctrl while clicking a link to open the link in your browser.
That sounds completely backwards when it comes to intuitive functionality. Your example in general sounds like more of an issue with the text positioning than it does with its interaction. Covering necessary parts of the screen with text doesn't seem like the best design, regardless of if that text can be interacted with or not.

I don't see why links would need any special consideration. Clicking a link should click the link, if anything. Clicking plain text should just act as if the text wasn't there. The current methods of doing this, with overlays, can cause some problems when the text is long. Seems best to just avoid them completely by making plain text a purely visual effect.
Falacy wrote:
Covering necessary parts of the screen with text doesn't seem like the best design, regardless of if that text can be interacted with or not.

By definition you have to cover a section of the screen with map text. That's the whole point, putting the text on the map.

I don't see why links would need any special consideration. Clicking a link should click the link. Clicking plain text should just act as if the text wasn't there.

Not all games are the same, what works for you might not work for everyone else. In an action game for example the chat output is of secondary importance. Your first concern is getting players to shoot at what they're clicking on.
Yeah, I hear you. I just wouldn't want this to be too complicated for either the dev or end user. Probably for the first run the easiest thing would be to just ignore links if a Click() goes through; that is, just do one or the other. But we can cross that bridge when we get there!
SuperAntx wrote:
By definition you have to cover a section of the screen with map text. That's the whole point, putting the text on the map.
Just because the text is on-screen doesn't mean it has to be on top of the playable game area. As is done with output controls now, an area of your HUD could be offset to the side of the playable/in-game map area for chat.
Most commercial games today have HUDs & chat over the playable game area because focus of the games remains centered in the screen, which leaves the edges of the screen available for information. If I need to be shooting somebody in the bottom left of my screen, then it probably isn't the best idea to have a giant chat box covering that area.
Tom wrote:
Probably for the first run the easiest thing would be to just ignore links if a Click() goes through; that is, just do one or the other.

If maptext obeyed mouse_opacity it should be rather simple to have a button toggle links on and off. Though, I guess in that situation each user would have to have their own unique maptext object.

Having Click() be aware of any links occupying the same tile would probably be best. If it were like that developers could decide on their own how they wanted to handle the click. Something like I listed earlier with the toggle button would work just fine.

Falacy:
If I need to be shooting somebody in the bottom left of my screen, then its probably not the best idea to have a giant chat box covering that area.

You make it sound as if I want to cover the entire screen with text. What I described was essentially a scenario like this where the dead fellow goes to shoot the red soldier under the word "suicidbombing" but the word turns out to be a link rather than plain text. It's a real issue and you having a tizzy about it doesn't help anyone.
SuperAntx wrote:
Having Click() be aware of any links occupying the same tile would probably be best. If it were like that developers could decide on their own how they wanted to handle the click. Something like I listed earlier with the toggle button would work just fine.
Again, that solution seems less than intuitive. A toggle for links could be supplied on the object displaying the text. If maptext is being used as a replacement for output controls, then you would want links to functional naturally and intuitively. However, if you're using them to display character names, or to display chat above a character's head, then you probably don't want links (or the text at all) to be anything other than a purely visual aspect of the game.
Maybe we could have the default ..() action for atom/Click() be to continue processing links. Since no one will use ..() in existing code it will block, but the dev can always override it.

Anyway, for the first run (if I even implement this), I'll probably just have it ignore links if Click() is used. Please stop arguing.
Tom wrote:
Maybe we could have the default ..() action for atom/Click() be to continue processing links.

That would work perfectly. We could process Click() then the link, process the link then Click(), ignore Click() and process the link, or ignore the link and process Click(). That seems to pretty much cover everything without breaking older games.

Falacy wrote:
A toggle for links could be supplied on the object displaying the text.

That is exactly what you were questioning earlier, a button to toggle link functionality. How you toggle the links on and off is irreverent, all I was asking for was a way to toggle links on and off.
I'm done.
Page: 1 2 3 4 5 6