ID:2519896
 
It's been a week of fixes, with a three new beta releases this week.

The bulk of the fixes went into 513.1493, covering a wide variety of things. Character conversion was obviously involved in most of the fixes, especially to some issues with locale-sensitive conversion. Dream Maker still had some issues with Unicode as well that didn't fully shake out. Then of course there was a bug I missed that deserved its own release, which begat 513.1494.

513.1493 also saw the release of new procs. I hate to add new procs or vars in the middle of a beta cycle, because that can cause some confusion, but I felt I didn't have a lot of choice. Some users didn't like the fact that the text handling procs all use index values based on bytes, not characters, because of course it means they'll have to change their code. This didn't concern me much at first because I couldn't see a use case that would require a change, but finally someone came up with one: cutting characters off the end of a string. While there are workarounds that would let you do this without character-based indexes, they're worse than simply adding the new procs. So now most of the text handling procs have _char versions, like copytext_char() that use character-based indexes. These are less performant and should be avoided, but nobody's going to listen and when their code slows down because they use them in cases that don't need it, they'll bitch about it and I'm going to say "I told you so."

Games compiled before 513 will now use the _char procs. However the code is smart enough to fall back on byte-based behavior if the string is all ASCII and contains no multibyte UTF-8 sequences.

Also as a result of the changes to those text handling procs, splittext() broke, which was one of the reasons for 513.1495. The other reason was that Linux still had some character conversion issues, because its native locale already uses UTF-8 so it threw a fit when trying to convert ANSI.

Big thanks to everyone who helped support BYOND last month. Our Members and Patrons keep everything going.

November is upon us! That means it's now okay to play Christmas music, although social convention never stopped my mom. (No joke; she was playing Christmas music just the other night. Also Walmart is already stocking up on Christmas stuff as of at least yesterday.) This is the time of year to start hibernating and coding your games in earnest, so get under those blankets and program and/or play.
The client isn't telling me that 513.1495 is out.

In response to 2DExtremeProductions
I forgot to update the download page and the version info on the pager.
Not sure why I said "client", it was the pager.

But good, it showed up now.

Well done!
thoughts on "compile 2 exe" and/or map related functions such as load or save?
SaveMap("map_name.dmm",x,y,z,x2,y2,z2)

LoadMap("map_name.dmm",x,y,z,x2,y2,z2)


Giving us the ability to save or load a chunk to a map or at runtime. I will delete my account for these things man
In response to Kozuma3
I've wanted native map loading and saving for a long time. It's not a simple matter, which is why we don't have it yet.

You can't save a runtime map to .dmm because it's possible for relationships between items on the map (and off) to be way more complex than the .dmm format can describe. At most you can save but expect loss of detail.

My thinking is that the existing savefile format is what needs to be augmented for this to happen.
I'd be happy with a way to save/load dmm files native, even if we lost object relations. Good instancing setups don't rely on saved/loaded connections anyways, those can be built after the fact.
Instead of _char, could you use a suffix like '8' instead, to prevent the headache of having to type _char a trillion times (or a compile time flag to universally have the text procs work on utf8 -- since there's no binary file reading the original procs don't make much sense)
This is already released, so it's too late to change the name.

Also a universal flag would be a terrible idea, because as I mentioned the char-based procs perform worse than their byte-based versions. Most places you would use text procs, byte-based counts will work just fine, so only select portions of your code would need to change to use _char. Even then, many of those cases can be rewritten slightly to avoid _char at all.
In response to Lummox JR
Lummox JR wrote:
You can't save a runtime map to .dmm because it's possible for relationships between items on the map (and off) to be way more complex than the .dmm format can describe. At most you can save but expect loss of detail.

What Nadrew stated would be absolutely perfect.
Honestly just being able to load or save a dmm file natively would be huge +1
Aside from its inability to handle complex relationships, the .dmm format would also be a terrible choice for runtime saving/loading for multiple other reasons.

The .dmm format uses a concept called "pops" which are the modified compile-time types such as /turf{icon_state="grass2"}. Pops don't actually exist at runtime; they're converted on map load. Thus it would be necessary to turn turfs, etc. into "temporary" pops for saving purposes, and likewise it'd be necessary to parse them on load which would be a slow process.

Simply put, .dmm is not the way to go for runtime map files.
If you did settle on another format, you'd still have to update the map editor to handle it. The whole point of having native dmm saving/loading is the ability to edit it externally as well.
In response to Nadrew
A new map editor and map format would be great though. Something like a "scene" editor like all the major game engines have, where you can actually reference objects (to link things together at compile-time), more easily make and modify instances (including a transform tool), and more easily work with large icons, would bring BYOND up to date for sure.