In response to CaptFalcon33035
CaptFalcon33035 wrote:
BYOND++? Are you serious?!

No. There are no plans for anything like that at present. Tom made an aside that a tile free game making platform with some of the features that aren't feasible in the current BYOND would make a good followup project, but that's about the extent of any developer discussion along those lines. Right now we are working on BYOND 4.0, a growth of the current platform. BYOND++ was just a whimsical name I tacked in passing to the idea of such a future project.
More fonts in text mode! Wooooh!
Faster mouse functions and faster world.Export().

-Doh
In response to XxDohxX
How about 3D turfs......could that be done??
In response to Kasper4sale
I remember that Lummox JR made a post in his BYOND blog about his work on a isometric icon type for BYOND...
In response to D4RK3 54B3R
A new ban system, <_<'
What about a see_invisible variable that only showed atoms with and equal invisibility setting? This would help out greatly with cut scenes!
In response to DarkCampainger
[link] - is that what you somewhat mean? >.>

O-matic
In response to DarkCampainger
DarkCampainger wrote:
What about a see_invisible variable that only showed atoms with and equal invisibility setting? This would help out greatly with cut scenes!

Well you could code in your own system for that using image datums...
In response to D4RK3 54B3R
No, Omatic, I mean somewhat of an expansion of the current see_invisible variable, so instead of showing all atoms with an invisibility setting equal or lower, it would only show those with an equal setting. Maybe something like see_invisible_id?

And D4RK3 54B3R, you can't flick icon_states on images without writing your own process and breaking up the movie in the .dmi file. I think this would be more useful because it would also not require an extra datum for each thing you want to hide, but would instead use their actaul atom, location, layer, and icon.
In response to D4RK3 54B3R
You could, but images are a limited resource and all you want to do in this case is display objects which already exist.

Unfortunately, as far as I know, visibility is not likely to be changed because it's part of some obscure code that Dan wrote and only he can decipher. (I'm partial to having lists of excluded sight and sound objects as mob vars myself.)
In response to Dick Gumshoe
Dick Gumshoe wrote:
More fonts in text mode! Wooooh!

You have that ability now. Look up client/script.

Lummox JR
Client side procedures.
Client side icon procedures.
Better keyboard support. Ungh macros.
Better/customizable interface.
More textboxes.
Ability to remove the textbox.
Pixel screen offsets.
Particle system.
More than 10FPS.
Pie.
The option to package BYOND games as standalone, or failing that client-side processing(Which I believe is already in the works for 4.0)
In response to Repiv
Repiv wrote:
Client side procedures.
Client side icon procedures.
Better keyboard support. Ungh macros.
Better/customizable interface.
More textboxes.
Ability to remove the textbox.
Pixel screen offsets.
Particle system.
More than 10FPS.
Pie.

Oh man, I can't wait for pie. Are you guys SURE pie is going to be included in 4.0? Otherwise I might just boycott BYOND.
In response to Flame Sage
Flame Sage wrote:
Repiv wrote:
Client side procedures.
Client side icon procedures.
Better keyboard support. Ungh macros.
Better/customizable interface.
More textboxes.
Ability to remove the textbox.
Pixel screen offsets.
Particle system.
More than 10FPS.
Pie.

Oh man, I can't wait for pie. Are you guys SURE pie is going to be included in 4.0? Otherwise I might just boycott BYOND.

Damn Flame Sage you are one helluva a funny person. I almost forgot to laugh when I read that.


I agree, more than 10FPS.
In response to Bunchie
Thank you Bunchie.
In response to Flame Sage
I'd like to see something like:
  • Partial Blind or
  • Color Dimming
  • Better keyboard support.
  • Making "Say" a default client proc, like Move(), instead of defining a verb for it.
  • MP3 Support
  • Better statpanels

In response to Pyro_dragons
Pyro_dragons wrote:
  • Making "Say" a default client proc, like Move(), instead of defining a verb for it.

    Huh? How does that make sense? A simple say() verb takes only a few lines of code. On top of that, every game handles communication(including say) differently.
    If you want some sort of standard say() verb, you could make a library and then try to get people to use it.
In response to Jon88
Yeah people do use it differently, my say verb is probally longer then your usual attack verb.
Page: 1 2 3