Woodsing?

[Prometheus]

My concern is if someone is on and the game is set to auto reboot and they die the corpse goes poof and then I or Thotter has to do a recovery. Which is why I'm leery about doing anything automatic. Now the question becomes is can we fix DG issues with a coding change via Thotter or Fizban? Or do we need to upgrade DG and then add our tweaks in. Or is it a mud memory issue which is something Once could fix.

Do we have to do a reboot everyday? Could we try every 3 days or so and see what happens? I can't see rebooting the mud once a day. We need to figure out a solution.

Prometheus

[Virisin]

Is it not possible to link the farms to the time of the mud? Or to day/night or something.

[Prometheus]

^ I'm pretty sure DG scripts should have day / night times etc. But since I don't do much with DG I wouldn't know for sure. Maybe if someone who does know DG better could answer that?

And with the issues of the farming / lumberjack I'm guessing that a zone reset won't help?

Prometheus

[Molly]

Is it not possible to link the farms to the time of the mud? Or to day/night or something.

The DG_code can relate to things like time of day, season, moonphase etc, and I've used it for features like herbs that are only potent when picked at new moon, or fruit trees that bloom in spring and bear fruit in autumn. However I don't think it would work for a feature like farming.
A  Mud day is 30 RL minutes, a Mud month is 16 RL hours, a Mud year is 12 RL days and a Mud season is 3 RL days.

The waits would be either to long or too short.
While it could be logical to set it so that you could only plough/sow a field in spring, it would not stop a player from repeating it a gazillion time as long as the season was right. At the same time it would be irritating for whoever logged on in the wrong season having to wait several days before being able to do it at all.

With a mob you can always remove a global flag by purging it, which could be related to zone reset. The farming and gardening scripts are run by room triggers, not mobs, but that could of course be changed. However, the longest reset time a zone can have is 4 hours, which is a bit too short.

I really think we need a coding effort here.

[Diandra]

Could someone actually try out the fields in Fort Sutter?

If I'm not mistaken the scripts there have already been altered at a time, so they could only be plowed/whatever once a day.

However the thing also works with context and from experience I know context doesn't always work as it should be. But that's something for the coders to look at.

[Virisin]

16 RL hours wouldn't be bad if a coding solution can;t be found.

[Kvetch]

Could someone actually try out the fields in Fort Sutter?

If I'm not mistaken the scripts there have already been altered at a time, so they could only be plowed/whatever once a day.

However the thing also works with context and from experience I know context doesn't always work as it should be. But that's something for the coders to look at.

Looking at the script it looks like it's been made to work that way because it starts off like this:
if %actor.is_pc%
  context %actor.id%
  eval today %now% / %realday%

and ends with this:
  else
    %send% %actor% You've already plowed this field today, try again tomorrow!
  endif

As to whther or not it works, I don't know...  someone would have to actually try it that has time.

[Kvetch]

My thought, and maybe I'm just over simplifying things and it won't actually work this way - is to have it when someone finishes the field, to load an item called something like "already worked field" or something.  As long as that item is there, the field can't be work...
Every mud morning at, oh, say 7am, the script clears out any object of "already worked field" so they can be worked again.

So... let's say Jack works the field, at the end, the script would be changed to load the item.. which actually means, at the beginning of the script, we have to see if the room Jack is in has already been worked so it's looking for the object vnum of the room.  I know you can look for a mob in a particular room, I'm just assuming you can also do it for objects.  If that object is there, the script says, Sorry Jack, this field has already been plowed.  If it's not there, it says, sure.. plow away (or whatever the script actually says).

So.. let's say that we make an object 3354 that is a worked field and, I'm not sure %rm.object(vnum)% works, but %rm.people(vnum)% does so I'm assuming it would - better scriptors would probably know.  What I'm suggesting is to add this to before the plow script for the field:

Eval field %rm.object(3354)%
If %field%
%send% %actor% I’m sorry, this field has already been worked.  Please come back tomorrow.
%else%

and after that else is the full plow/sow/whatever script for the field.  And like I said, add another script for the room that's a time command for 7am or something.  Sure, someone may be able to work the field and time it so they can turn around and do it again, but I think any solution would end up the same basic way.  And, like I said, not 100% sure this would work as posted, but I'm making assumptions based on other things we can do.

[Molly]

The problem with loading an item, as well as the wait 86400 s that I tried, is that it will stop anyone from working the field, not just the player who first initiated the script. And I don't really think it would be an improvement to the current situation to enable one player to block everyone else from a feature.

That was what context %actor.id% was supposed to do; allow other players two do a quest or a task, regardless of how many others already has done it. But regretfully it doesn't seem to be able to handle waits.

Neither of the ideas suggested so far seems to work very well. With the current code, I think the best solution would be to put the script on a mob that would be purged at zone reset, which would then remove the global flag. That means that farming and gardening would be repeatable every four hours, (or even more frequent depending on where in the reset cycle the action was performed).

I think that is a bit too often, but since few players seem to be logged on that long anyhow it might be acceptable.
It would of course have affect the size of the reward, if we make it repeatable that often.

One possible idea would be to expand the time of rebooting a zone to 24 hours. (Which of course would need some coding).

But then again that would not be a good idea, since the fields are in Olde Yorke, which is used for levelling by many players. It would of course be possible to extract the fields to another zone, but that in turn means a lot of building work, which I don't feel quite motivated to take on.

[Virisin]

4 hours would be pretty perfect I'd say.

[Once]

What exactly do we need coded?

[Diandra]

Neither of the ideas suggested so far seems to work very well. With the current code, I think the best solution would be to put the script on a mob that would be purged at zone reset, which would then remove the global flag. That means that farming and gardening would be repeatable every four hours, (or even more frequent depending on where in the reset cycle the action was performed).

I think that is a bit too often, but since few players seem to be logged on that long anyhow it might be acceptable.
It would of course have affect the size of the reward, if we make it repeatable that often.

One possible idea would be to expand the time of rebooting a zone to 24 hours. (Which of course would need some coding).

But then again that would not be a good idea, since the fields are in Olde Yorke, which is used for levelling by many players. It would of course be possible to extract the fields to another zone, but that in turn means a lot of building work, which I don't feel quite motivated to take on.

I'm still convinced the solution in the Sutter's fields does work, providing Immortals don't trigger the startingscript as I know context %actor.id% mixes up the flags when Imms trigger such scripts. Then again, Imms don't go work in the fields.  

So if someone could try them out?

As for adding the mob, wouldn't you still have to work with context %actor.id% again. Cause whether you add a mob or an object you still need to have a check to see if the player itself has already done the field or not. You could have the mob reset in a permanent 24-hour zone and then let them go to the farms/fields so you wouldn't have to move the fields at all and you wouldn't have to worry about the resettime of the zone (Old Yorke or Sutter) itself. But is it worth it adding a mob and purge-script if the Sutter's fields' scripts work as they are now?

Or have Once code something.

And as edit: putting the mob in a 24-hour zone won't work either as it won't be purged at the zonereset seeing it will be in another zone. Or you'd have to add a self-destruct script on the mob after 24 hours minus a few seconds. Or have another mob go slay the first mob before you load the uh first mob again. Ain't scripting fun and confusing *egrin*

[Once]

If I was going to code something I'd need to know what exactly you guys want. It's kind of hard to parse it through all the back and forth. How exactly would this system work in the ideal world?

[Molly]

Short summary:

In the ideal world any player should be able to work the fields once a day, regardless of whether anyone else already did it.

What we have is a room script that uses  context %actor.id%  combined with a global flag that goes away when the mud reboots.
Which it does rather seldom nowadays.

One way to handle this would be to change the type of script to a mob script, combined with another script that makes the mob purge itself when the zone resets. This would remove all global flags every 4 hours, (which I think is a bit often, but Virisin seems to think is OK).

What we need is something that removes the global flags once a day.

If this is too hard to code, I guess we'd go for the once per 4 hours solution, which obviously means quite a bit of work for me.

[Once]

What if we jut hardcoded farming and made it more dynamic? Then we wouldn't have script limitations and could do all manner of fun stuff.

Alternative you could always store a variable using realtime and compare when a day had passed that way.