Raybarg

After reading this thread I started liking the color choices more. But if they gonna change them, I hope they make it green and pink. When we were allowed to pick up empty bsb's, some people complained about it. Everything they change is wrong in someones opinion. Despite the fact that Wurm is pure fantasy in which the creators and rulers of the inner workings of the Wurm fantasy world are the devs. If they say metals in Wurm heat up to red to blue to white, then thats how it is in Wurm fantasy world. Get used to it and year(s) later laugh at new players asking the same silly question why some UI indicator does not align with some physical properties in the real world.

These are not the Kharisriverbornes youre looking for.

If that is obvious then the logic dictates that is true for both SFI and NFI. Perhaps SFI will have "just the old diehards" first, but the stated condition is the end result no matter what inter-environment it is in. We aint there yet though. From the perspective of "13 years in same spot in Independence", the frequency of "collision" with newer players has never truly changed. Ofcourse we rarely enjoy 2 days old Froobs rejecting a trainload of super good enchanted tools and resources for free... we still perhaps more often than we can cope, will find ourselves utilizing our 100 digging skills to help fresh player who has bigger ideas than their own skills allow. What comes to "opinions" about trade. For me its only hearsay that NFI trade/market is "vibrant", but from my perspective... SFI market seem pretty vibrant aswell. Funny thing is that high quality imps take time (effort) even when youre at 100 skills and perfected your whole toolset to maximum insanity... and stuff wear out. So there is allways someone needing an imp, and someone wanting to provide the service as long as there is still "a playerbase" even if its just "old diehards." I am one of those "trade slayers" myself = within my connections and within my alliance, I tend to imp stuff for free.... and done so up to 99ql... which directly has the effect on trade/market to make it "more quiet." But it would be a mistake to discount our inter-alliance or inter-connection market/trade without silver-transactions from "vibrancy of trading" in the cluster. Its just harder to measure. Over time this kind of inter-connectiviness will simply increase and there is probably more of this in SFI than in NFI, making it appear as NFI is "more vibrant." But only appear. If someone asked pickaxes at 70ql or imps to 70ql... I wouldnt even know what to price my service at. I'd prolly just offer it for free (for mailcosts.) And I am certainly not advertising such in Trade chat for just the mailcost. Vibrancy or not, just watching Trade chatflood go by is totally different to measuring the success of getting what you want but I understand that noone is advertising lowQL cheap stuff because its like shouting to the wind. If there is market for that in NFI and player wants to participate in such market, then ofcourse NFI is then better choice... but I would argue that not having such market in SFI is evidence that it wont be there long in NFI either. Edit: For the sake of the OP. The "siren's call" to go play in NFI reaches my mind ears very often. As it does about "if that mountaintop is unoccupied" or just seeing some fancy big area unoccupied. Or thought about creating an "outpost deed" in different servers. Ofcourse I can only speak for myself, but this answer was given in this thread a few times; We hate to love to start over, over and over again. Yes I was there for about 4months when NFI released. Its hard to "stretch" the feeling of starting a new for longer than a few months.

Short answer; No. Long answer; Just like last year with simplistic queue system which was comma separated list... People who didnt use Discord merely asked in local to be added to the queue and a local helpful player added them in discord and basically parroted in local when the bot announced that next one should be doing their sermon. I intend to retain this community aspect in bot's command toolset so that any helpful active player can smooth out the rough edges of the unexpected. Adding clock times in the queue slots is merely a method to add predictability to reserved slots. With the comma separated list one can see that adding oneself to the end of "Foo, Bar, Doof, Duuf" will be in 2 hours and every single unexpected effect to that prediction is exactly the same if the queue has times on it. With comma separated list someone last year wanted to reserve a slot in 3 hours so they added "empty1" and "empty2" before adding their priest name, resulting with "Foo, Bar, Doof, Duuf, empty1, empty2, Latepriest" list. -> Adding time to the queue system makes it more convenient and easy to reserve a slot further up, with some sensible limitations. As mentioned, its very typical during a sermon group to have priests stand online, people going to sleep and wanting to ensure they could pop a preach when they get up in the morning, before heading to work... and to be able to pop a sermon when they come from work. The effort here is to make exactly that as easy as possible.

Bot already has pinging option to notify "next in line" when cooldown is off. Its more of an exception when situation like missing a queued slot happens and thats on the priest who didnt show up in time. From experience I know that during a large event there will be dozens of eye pairs staring at the "lost 30minutes" as potential gain in them getting their sermon in 30minutes earlier, which causes subsequent drama as I referenced to with "Ingredulous Frodo" who decided to walz past the line and fill the lost slot. (Ofcourse this situation is also against any sermon group or impalong general sense of rules and is considered as ninjaing a sermon.) So I am leaning heavily on the solution that queue slots are not pulled earlier in any circumstance, and if notifying "next in line" seems to start notifying people over 30minutes earlier than their reserved slot... then its up to those present to manually resolve the situation or simply let the delay happen. Naturally sermons dont happen every 30mins exactly so the queue is constantly being pushed forward in time by a minute or two per sermon. (which is why queue length will be limited to 8 hours in the future so theoretical accumulation would be <=30mins max for someone who at any point reserved the very last slot.) Last year the rudimentary queue system was not locked in time, there was just a comma separated list of priests to maintain the sense of order... and if first in queue did not show up within 5mins, then it was agreed as "house rule" that 2nd in queue can preach and original 1st in queue remained 1st in the queue. Putting time in the queue slots makes everything a bit more complicated but I intend it to be perfectly automatic, with option for people to communicate and resolve exceptional situations.

Hello fellow Wurmians, some of you might already be familiar with the Sermoner Discord Bot which we used during last year friendalong event. Last year the bot got its "Queue mode" added to it on the fly to better serve a situation in which there is so many many priests wanting to sermon, and to let people reserve a spot/time and set up their alarm clocks for best outcome. That queue mode was very simple and rudimentary. Now its time to learn what we learned from Priestapalooza and give the bot a proper queue system. But there is a thing I have not yet decided out, so I seek help from you lot for any ideas, insights, opinions, etc... Here is a little diagram I draw to use to explain the situation: So we have simple 3 slot queue with each slot now reserved by a priest... but then Aaron who is supposed to preach did not come around to preach and some time passed so the bot decided skip it. Reserved times did not change, just 1 preach was lost in the teeth of the Langoliers. Scenario 1: Ingredulous Frodo decided to fill in for Aarons slot. Rest of the queue is pushed to the future! Just as with normal "sermons happening every 31-32mins", there is not really much we can do about this situation than simply push the queue forward to let everyone have their spot, even if its a bit later than what was reserved? Scenario 2: Ben the Hyper decided to step in because theyre next in line... Rest of the queue is pulled closer to the edge of Langolierian hunger! Perhaps pulling the queue to allow next sermon be as soon as possible is a bad idea because this might cause cascading "missing the spot" effect? All other ideas and comments are also welcome.

Universally "Green means Go" but upon testing (and also explaining this choice to friends) proved that when having many timers running, its sort of "calm and unalarming" when running timers are green... and upon the moment of a timer completing like "Now its time for you to pray/meditate/preach/etc..." with red bar, it was significantly more intuitive to react to it. Also, with the new timer option "Elapsed time" which idea was sprouted from keeping track of when last holy site pulse was, blended as yellow much better with green running timers. I'll add option to choose "simple mode" and "colorful mode" and for the "colorful mode" the option to choose which way red and green are shown.

Two whales fought and fought, then a Kraken came about.

50s item to turn my forge magical to never have my enchanted imp lumps get random decay hits? IM IN!

Would that be good when red = ready, yellow = elapsed timer and green = running cooldown? Color choices from perspective that the more alarming the color, the more pressing issue it is to do something. When Cooldown is running, its green and not alarming at all. Also image of custom timer edit window when elapsed time is chosen:

public static class ModifyProgressBarColor { [DllImport("user32.dll", CharSet = CharSet.Auto, SetLastError = false)] static extern IntPtr SendMessage(IntPtr hWnd, uint Msg, IntPtr w, IntPtr l); public static void SetState(this ProgressBar pBar, int state) { SendMessage(pBar.Handle, 1040, (IntPtr)state, IntPtr.Zero); } } Yea, I tested the bar coloring and had to add the static class above which sends the API call. Googled it up. Tried to tinker with the style and forecolor but the progressbar adamantly remained green. Then I added progressBar1.SetState(2); where we set the text as "ready!" And progressBar1.SetState(1); on the else branch. Now timers are green when running and red when ready. I would make a pull request but I couldnt find .Net SDK 4.5 and had to upgrade all projects to 4.5.2 so my studio has poked and tinkered everywhere. I'll look into adding the option to not type in the cooldown but have the timer just show elapsed time.

Currently in timers window all timer bars are green, the running ones and ready ones. Could it be possible the ready! bars would be different color like blue, or have options to choose what colors the bars would be. Also, could we choose when editing custom timer to instead of using "cooldown" to check the timer so it would instead count time after the event happening (Got this idea from Holy Site Pulse event tracking with timers.)

At the Mag Holy Site as Mag follower, using toolset and imping item all without any imp aiding runes or imbues and I could relatively easy imp to sweet spot and just barely keep on top on it as my skill started progressing faster.

Interesting, we have evidence of the account in question participating in a sermon group back in 2012-07 Seems to me the account in question has become a priest alt, provided the lack of general "chatter" in public channels that could be dug up from the logs. One entry back in 2017-09 shows that the player of the account in question was asking in CA HELP how to see what religion your toon is. Also, in purely my personal opinion... reading trough older log entries made by BertimusPrime makes me cringe and hopeful that BertimusPrime's past life teaching experiences have made him very VERY much more mature. That would be of benefit because he says he is here to stay. Welcome back BertimusPrime and please leave the poor alt priest in peace.

+1 "Identified unidentified fragments" -> I find joy sometimes how I know these fragments I have already identified as being ore/shard/brick type, still remain as "unidentified." Separating these fragments as I identify fragments is not the point here, merely the contradictory behavior of "identified unidentified fragments." Ofcourse classifying them as "identified" is the point I am making, since only until they been identified further to discover what ore/shard/brick they be they truly remain as "unidentified" even though one could then argue them being "partially identified." Here "partial identification" merely pointing out that we know what they will become just not specifically the type of those (i.e. we know its ore, just dont know if its lead or gold.) In order to argue in favor of this change; think about all other fragments that become "xyz fragments" upon partial identification, they ALL work this way. We know "unindentified statue frag" will become a statue frag, we just dont know i.e. if its unicorn or eagle. This, my own rambling lead to me think that these fragments should become "bulk resource frags", perhaps call them "unidentified bulk fragment" when they have gone trough their partial identification stage.