Page 1 of 2

Next version?

Posted: Mon Mar 14, 2016 6:34 pm
by Nyyrazzilyss
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?

Posted: Tue Mar 15, 2016 6:00 am
by Belgarath
I agree. It would also help in its development if more bugs were caught before an official 3.0 version is released.

Re: Next version?

Posted: Mon Mar 21, 2016 11:04 pm
by SlySven
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 :o ) 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...

Re: Next version?

Posted: Tue Mar 22, 2016 12:30 am
by Vadi
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...

Re: Next version?

Posted: Tue Mar 22, 2016 12:41 am
by Nyyrazzilyss
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...
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.

Thanks!

Re: Next version?

Posted: Sat Jul 23, 2016 4:02 pm
by Nyyrazzilyss
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.

Re: Next version?

Posted: Sun Jul 24, 2016 1:12 am
by Vadi
Fair enough - thanks for the feedback. Will see about making this happen.

Re: Next version?

Posted: Mon Jul 25, 2016 4:15 am
by SlySven
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:

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.
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! ;)

Re: Next version?

Posted: Mon Jul 25, 2016 2:34 pm
by Nyyrazzilyss
SlySven wrote:I'm deep into the guts of the mapper code at the moment as I've realised
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)

Re: Next version?

Posted: Thu Sep 22, 2016 5:15 pm
by Slayd
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!