Accuracy Debate Solution?

[kill drizitz]

question faust: i know nothing about scriptin/compiling so i kinda skipped those parts in the thread. but in reference to what sultani said about not playing a char that would be nerfed etc. would this be a cycle like what daltrey said?

would every three months or so (just throwing numbers around) the system would revert back to 98 dead archery style, then a month later it would be back to how it is now? or is it a one time deal where we start back at 98, move along through patch notes, once we hit late 99 then we stay with that?

[Eulogy]

Crazy idea..

Just seems to me to be one of those things that could be pretty cool, or really blow.

[Derrick]

It's the roll back that would be particularly hard to implement.

[MatronDeWinter]

All the scripts could be addressed in this similar manner with multiple checks for each change. The only tedious part is coding all the check points for each script that currently exists for the server.

Last I checked RunUO compiles the scripts from a folder at runtime. I know there was talk about implimentation of a realtime update of these scripts, but since all of our patches here happen at server restart, that leads me to believe this is not the case with the current build uosa is using. A date check function for each script would be extremely inefficient. Since the majority of these changes are trivial things such as casting-timer, and various, well variables, boolean or not, that take place in the "scripts" folder anyway, it seems to me that it would be a much better idea to work from there. Create a script that checks the date prior to compiling the code when the server starts.

Code: Select all

EraCheck(CurrentEra);
     {
     if CurrentDateTime >= UORDateTime
          {
          //Then copy a version of the scripts folder specifically created for this time period
          //over into the RunUO/Scripts directory.
          return(UOR);
         }
     else if CurrentDateTime >= T2ADateTime && <= UORDateTime
          {
          //Then copy a version for this era into the scripts folder before compiling.
          return(T2A);
          }
     else   //No conditions needed
          {
          //If the other 2 conditions arent met then it must be Pre-T2A so copy those files
          return(PreT2A);
          }
     }

FunctionStartServer();  //Or whatever, just go about normal business

This way you arent adding additional uneeded checks for each script, plus that can get pretty confusing for anyone trying to make sense of the info. You could just keep 3 folders for each era and copy them over at runtime. The returned variable (UOR, T2A, PreT2A), could be used to inform people Onlogin(); what Era is currently in effect or for whatever else. You might even just use the code on startup to switch the destination to the script folder with the appropriate era-date.

[ArchaicSubrosa]

Maybe instead of this, how about mapping what T2A looked like at the cut off point for this era...being you are shooting for just before UOR...so we would understand what to be expecting. Patches take time to implement and needs to be as such as glitches/bugs appear usually after each one. Which could result in another patch or another tweak to fix...or you may even have to redo what you threw out to place another patch in order for it to work.
Cycling is a novel idea...I mean do people hope to relive the last day of the era over and over to no end? Is it really an era or merely a day in which you declare the birthday funeral of the secondage declaring that day to be only what it was...the be all end of everything?
With the many changes that took place there were many eras inside this era as many make it sound ... so why are we just shooting for the last day? The Last Day Era Fanaticism has made many an arguement on these forums...so why don't you historians ellaborate on what it really entitled? Paint us a picture on the dusk of the Era in how it differs from what we have here.

[Arkon]

Wow, amazing idea, although I do think it's implementation is easier said than done. Although I have great faith in the staff here, so I wouldn't be surprised to see it done flawlessly.

As for the debate about having a character you know will be nerfed, like Freeza said, 3 accounts, 15 characters, that's plenty to alternate around with. But more importantly, having your character nerfed and have to re-build and change up some skills is very era accurate

[Faust]

All the scripts could be addressed in this similar manner with multiple checks for each change. The only tedious part is coding all the check points for each script that currently exists for the server.

Last I checked RunUO compiles the scripts from a folder at runtime. I know there was talk about implimentation of a realtime update of these scripts, but since all of our patches here happen at server restart, that leads me to believe this is not the case with the current build uosa is using. A date check function for each script would be extremely inefficient. Since the majority of these changes are trivial things such as casting-timer, and various, well variables, boolean or not, that take place in the "scripts" folder anyway, it seems to me that it would be a much better idea to work from there. Create a script that checks the date prior to compiling the code when the server starts.

Code: Select all

EraCheck(CurrentEra);
     {
     if CurrentDateTime >= UORDateTime
          {
          //Then copy a version of the scripts folder specifically created for this time period
          //over into the RunUO/Scripts directory.
          return(UOR);
         }
     else if CurrentDateTime >= T2ADateTime && <= UORDateTime
          {
          //Then copy a version for this era into the scripts folder before compiling.
          return(T2A);
          }
     else   //No conditions needed
          {
          //If the other 2 conditions arent met then it must be Pre-T2A so copy those files
          return(PreT2A);
          }
     }

FunctionStartServer();  //Or whatever, just go about normal business

This way you arent adding additional uneeded checks for each script, plus that can get pretty confusing for anyone trying to make sense of the info. You could just keep 3 folders for each era and copy them over at runtime. The returned variable (UOR, T2A, PreT2A), could be used to inform people Onlogin(); what Era is currently in effect or for whatever else. You might even just use the code on startup to switch the destination to the script folder with the appropriate era-date.

RunUO does compile the scripts at startup. That is why you would use multiple check statements for each script that actually "does have a change" associated with them. My vision was that the script compiler would check the date before the server starts up. I really don't see this becoming much of a problem in terms of effieciency. There is enough multiple expansion code jumbled around in those scripts already that it doesn't really slow things down much even with that.

The same similar approach could easily be used. I mean there isn't that many drastic changes for each game mechanic that would exceed 3+ different changes. Most wouldn't even have more than one and it would be one simple if statement. This doesn't include the fundamentals that never really changed much. For example, with combat weapons the entire system is pretty much the same minus a few things such as weapons hitting at the end of the animation early on and a different delay formula that could easily be checked against. This is just one simple if statement that a lot of the code would follow in suit. Most of the code already uses un-necessary code structure like this using those expansions that aren't even being used. That is why I gutted my scripts removing all code that wasn't required for those expansions. I think the hardest part would be implementing the date itself having it effective and keeping track with the reversal as Derrick stated. This could possibly be done by using another date variable for an end date by adding the amount of days that exist in the t2a era into that variable when the system begins. The startup can simply check that back date to see if that date has exceeded. If the date has exceeded a modification for both the target date that keeps resetting to show what t2a date we are at and the end date that is based on the current date tallying on the amount of days that exist in the t2a era to produce another end date to allow the process to repeat itself. Also, you would have to inform players what the target date is on login and on the web site to make sure people knows what time period it is of course.

PS
I do understand what you're saying though Matron. That would be a more efficient way to handle things but only if you constructed it based on "portions" of the era as you stated. That wasn't the objective of this idea though. It was to simply live the t2a era as a whole on a day to day basis from start to end until it rinses and repeats the entire process again. This could not effectively happen in a code structure as you mentioned since there are sometimes multiple changes to one script during the era.

[Batlin]

I found another evidence that behaviour described in the June 1998 patch is not in the scripts.

This is taken from the "guilded.m" script:

Code: Select all

on lookedat(object looker)
{
  string ab = getObjVar(this, "guildAbbreviation");
  if(ab == "none")
  {
    ab = guildName();
  }
  if(hasObjVar(this, "displayGuildAbbr"))
  {
    barkTo(this, looker, "[" + ab + "]");
  }
  return(0x01);
}

It's being called when someone clicks on you. "looked at" event.

Now, that code does :
1) ab is looked in the mobile object variables (guildAbbreviation)
2) if ab == "[none]" then ab is set to the full guild name
3) if the mobile has an object variable "displayGuildAbbr" then the looker will see the text "[" + ab "]"

so in case there is no guild abbreviation then the full guild name is display.

Let's now look at the patch notes from June 1998 : http://update.uo.com/oldupdates/6-11-98.shtml

Guilds without abbreviations now show [none] instead of the full guild name, to reduce spam on screen.

So clearly that script is pre 11 june 1998 behaviour...

[Faust]

What patches have you confirmed to exist in the demo so far, May '98 patches?

[Batlin]

What patches have you confirmed to exist in the demo so far, May '98 patches?

Yes, that's for 100%. Slimes exists, they split and acid will not harm ranged weapons.


On the other hand, other code seems to be in there.
Like : order, chaos and neturals guilds

There is also a file "update.txt" in the UODEMO.DAT file.

The contents are:

12576
We are ready to continue the implementation of the Reputation System.
Today is the second phase of the process, which is publishing to a single
server. We will be updating the Great Lakes Shard at 2:00 CST today. We
will be monitoring this server closely throughout the day. If everything
runs normally, we will continue to the third phase of the process on
Thursday by updating the remaining public servers.

I could find only one site that is able to date that text : http://www.ne.jp/asahi/aeg/uo/oldupdate/uooldnews.html -> June 3rd, 1998

My guess is, the uodemo contains most patches from June 11, 1998 but not all of them.

[Faust]

This is very interesting information. We are at least nailing down a somewhat precise time frame for the demo. I know a long time ago when I was pin pointing the time frame I was completely restricted to in game mechanic testing to verify certain patches. This approach obviously has severe limitations due to the nature of the demo. The general consensus was a target date around August '98 assuming the Reputation patch in June was a part of it and many of the game mechanics in patches that was verifiable around June. We now know that some of the June game mechanics in the patches possibly didn't make it in there.

I'm also wondering if they simply used an older guild system in the demo on purpose. For example, many of the systems like boats and houses were modified from the current systems in place during that time from what Derrick has told me. Boats produce blank keys that disallow you to get off of the Ocllo island, etc... Perhaps, some of the more ellaborate systems like the housing and guilds used older or modified code. I know that is stretching the issue and a tad bit unrealistic but nobody really will ever know.

Your theory is probably very well precisely what happened though. Where some but not all of the items in the June 11th patch made it into the compilation.

[Batlin]

Perhaps, some of the more ellaborate systems like the housing and guilds used older or modified code. I know that is stretching the issue and a tad bit unrealistic but nobody really will ever know.

That's hardly the case, the code to attach an object to a key is there. That function is simply not called when you place the boat or deed.

I modified the boat script to call that function with partial success. The error message changed . Derrick told me the boat plank is also missing, the key is linked with the mast instead.

Boats I understand, the server only controls Occlo and little bit of the sea around Occlo. I played with the server size parameters but I couldn't make it work yet 100%, even though I still believe it is possible to make the uodemo control whole Britannia. If you go outside the defined border (/rundir/uogolddemo/server.txt) the demo crashes, hence no boats allowed. But I cannot understand why they would make houses useless. Maybe the blank house keys are a side-effect from disabling the boat keys (if they modified the key script instead the boat script).

[Faust]

Maybe the blank house keys are a side-effect from disabling the boat keys (if they modified the key script instead the boat script).

That sounds like a possibility but it is/has been confusing to me why they would leave this portion of the code out. The only assumption that I can come up with was to remove larger aspects of the game similar to modern demos where they leave out 90% of the game. I suspected but never really knew what would happen if you tried to venture to the main land. I have been in high hopes that you end up getting it more "full version" working in due time. This has been a great job that you have been doing.

I am still in hopes that you may one day pull some weapon code or all if we're lucky out of the demo too. However, like Derrick has said that isn't the easiest task at all since it more than likely lies in the core. Still hoping though.

[Teknix]

could we just make a siege shard instead?

[MatronDeWinter]

I do understand what you're saying though Matron. That would be a more efficient way to handle things but only if you constructed it based on "portions" of the era as you stated. That wasn't the objective of this idea though. It was to simply live the t2a era as a whole on a day to day basis from start to end until it rinses and repeats the entire process again. This could not effectively happen in a code structure as you mentioned since there are sometimes multiple changes to one script during the era.

I just assumed the current/previous scripts would have been saved in some form of CMS, already practically organized by date.