ID:2581229
 
After a long wait, but thankfully not as long a wait as 512 had, 513 is finally out of beta! Yesterday I released 513.1526 as the new stable build, and of course I'll keep doing maintenace releases on that while I work on 514 features. It should be a bit before we see the first 514 beta because new features will demand various internal changes, but at least that process is already underway.

This week I got the ?[] operator in place, and what an adventure that was. The null-conditional operators are pretty weird animals because they effectively have two different levels of precedence, but I'll go into more detail on that in today's Patreon post. Suffice it to say it was an adventure.

I'm still looking for a good syntax for approaching particles, but probably before I get there I'll have to get some rudiments of the display engine in place, so there's time yet. Another thing in the near term is adding return types for procs, which will help with resolving types for the dot-chain operator at compile time, and hopefully I can come up with some other uses for it as far as optimization.

This is the current feature wish list I'm looking at for 514, which is still wide open to expansion, and I think obviously not all of these will go in but some are higher priority than others:
+ := operator (id:2534755)
+ ||= and &&= operators (id:2571455)
+ ?[] operator (id:2411099)
- Particle systems
- world.movement_mode (id:2546225)
- time2text() with time zones (id:2572752)
    - Possibly also world.timezone and client.timezone
- Possibility of multiple statpanels? (id:2576496)
- Return types in procs
- Add identifiers to animations so they can be matched later
- Upgrade SQLite
- Add extensions to SQLite (fs5, what else?) (id:2217693)
- Sound animation
- Automatic sound environment position (changes with player)
  (id:2534538)

Inherited from earlier wish lists:
- Pause feature (single-player games only)
- Maptext clipping/scrolling
- atom.play_rate ?
- GetFlatIcon() and/or ability to convert appearance refs to
  bitmaps in client browser
- Z linking
As you can see that's a lot to look at, and since I don't want to go nuts with 514 it's likely a few of these will stay on the wish list. But just because there's a lot to look at doesn't mean new ideas aren't welcome, so pile 'em on. New filter ideas? Things that are tedious in soft code that could benefit from hard code? Some of the best features we've had in recent versions have come from your imaginations, not mine.

Thanks everyone who's helped contribute to BYOND to keep things going, via Membership and other channels. I'm grateful for your support!

Now wish summer in full swing, let's make the most of the nice weather while we can and the rest of the time, hide from the heat in the comfort of air conditioning and play and make some cool games.
Congratulations on the stable release lummox!
Awesome job on all this! Happy to see this move into stable.
What are you thinking about SQLite going forward?
Sound animation? Sounds neat. What're some things you could do with it?
Lummox JR wrote:
Inherited from earlier wish lists:
- Pause feature (single-player games only)

I think this could be generalized to multi-player games as well. Essentially it could track updates from the server (but not render them) and then render updates, show prompts, etc. when you unpause?
Couple quick requests that come to mind:
1. Easier to test multiplayer without hosting, logging in and out, connecting and reconnecting when you screw up which account your logged in as, stopping and restarting and so-on. The amount of time consumed by launching into a mp test session is significant and painful the larger the project becomes. Talking about using a DreamMaker command (ctrl+m - run in mp test mode) which launches dreamdaemon in the background with two bogus users for local testing only. Some UI window pops up that allows you to toggle which player is currently active and to even spawn new clients. When done locally from dreammaker like this, it should alleviate some abuse concerns.

2. Shorter release cycles and posting your running backlog for the current release with each release update.

3. More samples for each new feature/update with each release.
In response to PopLava
I don't know what you mean by "more samples".

Regarding release cycles, the reason the beta cycles have been longer in recent versions is because the features going in have been fairly big ones, requiring more time.
samples == examples in help. Examples have gotten more and better over the years. They really help so keep that part up is all I'm saying.

As for releases, just feels like you should be on a much shorter cadence especially as a solo dev. To be clear, I'm not criticizing or doubting your existing process at all. There's always lots of nuance to consider. Comes down to agility and focusing on the right things at the right times for your customers.

As someone who has been making a one player game with a pause menu it’s exciting to see that it’s intended to be built in manually. I was actually surprised to see a one player game specific thing on the list as well. Thanks lummox for always pushing forward it’s appreciated.
The "pause feature" could also be a "main menu feature" that has a default variable as pause, no?

Even tho I understand that Pause is it's own thing, you could kill 2 Turkeys at once. It would make the "pause" of Phantasy Star Online easier to implement.

I guess I see the feature as a "scene" that overlays transparently the view and decides whether or not it affects the world by making it static or not and then I see it possible to then put buttons/menus on this scene.

Edit: Would probably make certain types of Real Time Strategy/Tactics games simpler to do. Buttons can be verbs that manipulate the mob, etc...

Thoughts?