ID:2702562
 
It's a beautiful day (for once) and the sun is shining (for once), but because of all the times it wasn't, my house has been invaded by blood-sucking pests. Today's news is a little early just to be on the safe side since I don't know what tomorrow will bring (I mean, more so than usual).

After long delays I finally got 514.1558 out the door. This is an important release because it has a fix for a very difficult problem with particles, as well as some really important gliding and movement fixes, but it also marks a milestone because I've turned on the Large Address Aware flag which should improve BYOND's ability to use more memory, and also I've done some pretty nice optimizations to string handling.

Unfortunately right after that a couple of bugs appeared that slipped past, so I had to deal with those put out 514.1559. Then it turned out something else got through that impacted the whole suite, and I had to release 514.1560 just now to deal with that. It happens sometimes, and I really should know better than to let updates wait this long for that exact reason. The longer it is between versions, the more likely something is to go wrong. I'm hoping 1560 deals with the remaining issues and we'll be good.

Also new as of 1558 is that BYOND is now compiling as Large Address Aware, so it can use more memory than before, although the application is still 32-bit.

Under the hood I have more of the stuff I need for independent particles set, so I should be able to steam ahead on that and hopefully get that wrapped up. Along with a fade-in time for particles, that should complete 514's task list and give me the green light to move forward with 515, which is where the real fun begins.

Thanks again to all the BYOND Members and other supporters who keep this platform going and make all this development possible. You keep the lights on and I'm grateful for your support.

If you have a nice weekend ahead of you, I hope you get to make it count. Grill up a steak for me, and I'll be back next week.
You don't know if you'll be too busy with PoE tomorrow huh? Haha JK

Great post! Loving the updates.
Are getters/setters planned or is BYOND not able to have them without a large performance loss? or is that the issue that's keeping such a feature from being added?
In response to Kozuma3
Kozuma3 wrote:
Are getters/setters planned or is BYOND not able to have them without a large performance loss? or is that the issue that's keeping such a feature from being added?

Basically the particle issue forced me to take a hit on setting, at least at the custom var level, so setters are a thing I could add. I don't have any support for getters but it'd be similar. I think adding this for hard vars (like appearance vars, or anything else built in) would be a bad idea and I don't plan to go there.

So while I don't have any specific syntax set up yet, I think they're a real possibility for 515.
In response to Lummox JR
Lummox JR wrote:
So while I don't have any specific syntax set up yet, I think they're a real possibility for 515.

datum.set(variable_name,function_path)

mob.set(health,/mob/proc/UpdateHealth) // mob proc
mob.set(health,/proc/UpdateHealth) // global proc

mob.health -= 123
// This would call UpdateHealth() with the mobs new health value .-.
In response to Lummox JR
In C#, you have properties, which look like normal field definitions, but with a "get" block and a "set" block. The set block has a "value" keyword for the assigned value. Properties typically come with a private "backing field", and each getter and setter can be either public or private.

In current DM, how I make properties:
mob
var/_health = 100 // backing field (_private naming convention)

proc/Health() // getter
return _health

proc/SetHealth(value) // setter
_health = value

// e.g. world << usr.Health(), usr.SetHealth(0)

However, unlike in C#, there's no way to make the backing field private. I guess the only way would be to not have a backing field at all, and somehow have the get/set blocks be the only places that don't trigger themselves when accessing the property:
mob
var/health = 100
get
return health
set
health = value

// e.g. world << usr.health, usr.health = 0

Maybe the get/set blocks can each be omitted if desired, with that default behavior.
It's not as flexible as having a private field that can be modified outside of the getter/setters, but that would require the private keyword, not anything properties can do.


What Kozuma3 wrote is more like the observer pattern, which is commonly a side-effect of getters/setters, but is a completely separate concept. In a setter, you can trigger a "Changed" event that notifies every observer of the event. I have an unpublished library that already does that:
mob
var/callback/HealthChanged

var/health = 100

proc/SetHealth(value)
if(health != value)
health = value
HealthChanged?.Invoke(src)

// say some health bar HUD wants to follow HealthChanged
proc/SetupHealthBar()
health_bar = new(src)

obj/health_bar
New(mob/mob)
// whenever mob.HealthChanged is invoked, src.OnHealthChanged(mob) is called
mob.HealthChanged += callback(src, .proc/OnHealthChanged)

proc/OnHealthChanged(mob/mob)
// change appearance based on mob's current health

The /callback's += operator is overloaded so that HealthChanged+= works whether it's null, a single callback, or multiple callbacks, which was made possible by the change I requested that allowed custom return values in assignment operator overloads.
Compile time could work similar?

mob/var/health = 100
mob/var/mana = 100

mob
set(health,/mob/proc/UpdateHealthbar) // calls mob.UpdateHUD when health is modified
set(mana,list(/mob/proc/UpdateManabar)) // could even be a list of function paths

mob/verb/HealSelf()
health += 100
mana += 100

mob/proc/UpdateHealthbar()
//...
mob/proc/UpdateManabar()
//...
In response to Kaiochao
Kaiochao wrote:
In a setter, you can trigger a "Changed" event that notifies every observer of the event. I have an unpublished library that already does that:

I also did something similar in '09, though yours may have a cleaner interface if it uses some language features that weren't available then. :)

Mine was based on Qt's Signals/Slots rather than C#'s events: Kuraudo.Signals
Lummox JR wrote:

Also new as of 1558 is that BYOND is now compiling as Large Address Aware, so it can use more memory than before, although the application is still 32-bit.


Does this mean there is hope for a 64-bit version or at least being looked at?