Next version?
-
- Posts: 334
- Joined: Thu Mar 05, 2015 2:53 am
Next version?
It's been 15 months now since a new version of mudlet was posted. It might not be 100% in bugfixes, however, perhaps making a new compile available anyways?
Re: Next version?
I agree. It would also help in its development if more bugs were caught before an official 3.0 version is released.
- SlySven
- Posts: 1023
- Joined: Mon Mar 04, 2013 3:40 pm
- Location: Deepest Wiltshire, UK
- Discord: SlySven#2703
Re: Next version?
There are incremental improvements in the Github repositories - there are things in both the main development and the release-3.0.0-preview branches that are not yet in compiled releases. Admittedly it is currently beyond my abilities/inclination, personally to get from the source code to a working Windows binary (not least because all but my main PC that do have a 'Doze Os are XP - or before ) but it must be possible somehow!
Vadim has expressed a desire to get a new version out Very Soon Now and I want to get to the stage where we have at least nailed some of the 3.0.0 release Show-stopping (or at least hindering) bugs...
Vadim has expressed a desire to get a new version out Very Soon Now and I want to get to the stage where we have at least nailed some of the 3.0.0 release Show-stopping (or at least hindering) bugs...
Re: Next version?
We could do with more development time to fix the bugs; have known the show-stoppers for a while actually - which is why 3.0 isn't out yet...
-
- Posts: 334
- Joined: Thu Mar 05, 2015 2:53 am
Re: Next version?
I wasn't looking for a 3.0 release, more a 3.0-e with at least some (not all!) of the problems in 3.0-d fixed. Something dated more recent then over a year ago so people looking for a mud client realize Mudlet still has active development.Vadi wrote:We could do with more development time to fix the bugs; have known the show-stoppers for a while actually - which is why 3.0 isn't out yet...
Thanks!
-
- Posts: 334
- Joined: Thu Mar 05, 2015 2:53 am
Re: Next version?
I've been using the branch 30 compile I built / had posted instructions about creating for several months now. Not just myself, but also a lot of the people using my mudlet script.
It works -really- well, the OSX users are really happy with it, the new mapper core works incredibly well, and having sound again is very nice, not to mention various other small changes.
I'd encourage an 'official' release (3.0-e) sometime soon of how it currently sits.
It works -really- well, the OSX users are really happy with it, the new mapper core works incredibly well, and having sound again is very nice, not to mention various other small changes.
I'd encourage an 'official' release (3.0-e) sometime soon of how it currently sits.
Re: Next version?
Fair enough - thanks for the feedback. Will see about making this happen.
- SlySven
- Posts: 1023
- Joined: Mon Mar 04, 2013 3:40 pm
- Location: Deepest Wiltshire, UK
- Discord: SlySven#2703
Re: Next version?
I'm deep into the guts of the mapper code at the moment as I've realised the structure used to hold the room details is getting a bit ropey especially in the handling of exits. I've worked out a way to merge the normal and special exits into a common system and it looks to make things a lot cleaner internally - I think I will be able to put up a PR within the next week (against the development branch) and if that survives the mauling of testing I'll get it ported over to the release_30 preview...!
Looking forward to work on I18n I'm making a new set of lua map commands that take exit directions (as inputs) solely as a pair of argument: using the exiting 1-12 number system and a nil {for normal exits} and a 13 and the name (string) {for special exits}. As output from commands exits will be identified with the same pair but for convenience the exits will use the same number value but the nil will be replaced with a current language "display" string which can be shown to users but script writers should use the numbers to make their packages work with multiple languages when we eventually get the rest of the application capable of it.
A side effect of the refactoring of exit handling will be that you can have "special" stub exits (explorers can record that there is a "pull rope" exit - even if they do not know where they'll end up if they send that) - I also intend in the future that special exits will become a bit like aliases in that the "name" or identifier can be different from the "command" that gets run if that exit is used. I do have to revise the map file format so I have made provision to support some future features that would impact on that. {Support for any Unicode grapheme for room symbols - not just the current Latin1 set; "magic" in the file so that the Unix file(1) command will identify pertinent information outside of the Mudlet application:
I'm also moving the code/data that keeps tracks of the entrances to a room (i.e. the rooms that have an exit that lead TO the room concerned) to be IN the room data structure rather than a separate database - this is because the prime case that needs this information (deletion of said room) is actually more efficient if the data is there especially when humongous numbers of rooms are involved...!
Anyhow, things are happening even if it seems I've been a bit [Edit @20160729: s/quite/quiet/] quiet on my coding!
Looking forward to work on I18n I'm making a new set of lua map commands that take exit directions (as inputs) solely as a pair of argument: using the exiting 1-12 number system and a nil {for normal exits} and a 13 and the name (string) {for special exits}. As output from commands exits will be identified with the same pair but for convenience the exits will use the same number value but the nil will be replaced with a current language "display" string which can be shown to users but script writers should use the numbers to make their packages work with multiple languages when we eventually get the rest of the application capable of it.
A side effect of the refactoring of exit handling will be that you can have "special" stub exits (explorers can record that there is a "pull rope" exit - even if they do not know where they'll end up if they send that) - I also intend in the future that special exits will become a bit like aliases in that the "name" or identifier can be different from the "command" that gets run if that exit is used. I do have to revise the map file format so I have made provision to support some future features that would impact on that. {Support for any Unicode grapheme for room symbols - not just the current Latin1 set; "magic" in the file so that the Unix file(1) command will identify pertinent information outside of the Mudlet application:
Code: Select all
stephen@Ripley:~/src/mudlet-dev/Mudlet/mudlet-code$ file ~/mudlet-data/profiles/WoTMUD_Jath/map/2016-07-24#05-51-05.mmap
/home/stephen/mudlet-data/profiles/WoTMUD_Jath/map/2016-07-24#05-51-05.mmap: Mudlet Map file version (19) saved on: Sun Jul 24 05:51:05 2016, (with 9379 rooms, 38 areas) from profile named: WoTMUD_Jath.
Anyhow, things are happening even if it seems I've been a bit [Edit @20160729: s/quite/quiet/] quiet on my coding!
-
- Posts: 334
- Joined: Thu Mar 05, 2015 2:53 am
Re: Next version?
Sounds good - Mostly just pointing out I guess that things are never likely to be 100%, there's always going to be something else. From my point of view/against my script, it's working great though. I believe there was some mention in the Achaea/Aetolia mapping thread of people using my compile and running into some problems, but I can't really speak to that (i'm a one mud person)SlySven wrote:I'm deep into the guts of the mapper code at the moment as I've realised
Re: Next version?
Is there a binary for 3.0 that is further along that 3.0.0-delta for OSX?
Is the binary periodically refreshed?
Is there a link to this binary?
Thanks to all those developers working to make mudlet better!
Is the binary periodically refreshed?
Is there a link to this binary?
Thanks to all those developers working to make mudlet better!