+- SphereCommunity (https://forum.spherecommunity.net)
+-- Forum: General Discussion (/Forum-General-Discussion)
+--- Forum: UO/Sphere Discussion (/Forum-UO-Sphere-Discussion)
+--- Thread: Sphere Prereleases (/Thread-Sphere-Prereleases)
Sphere Prereleases - Khaos - 02-21-2016 01:12 PM
They need to be updated. Even the yearlies are out of date. We have the experimentals at 2014 and prereleases at 2013. Surely things are more stable now than then.
Might want to change INI too. Part of the issue I am having with users is using Triggers that are by default turned off in those versions. It is causing confusion on giving advice and helping people.
Plus, we are on 56c. When was the last release of 56b? in 2014. Just an idea to update things so users aren't using code we cannot help as much with now as the bus then aren't fixed as they are now.
RE: Sphere Prereleases - Criminal - 02-21-2016 09:00 PM
latest prerelease was in jun 2013
I agree, just fix all known bugs and make a stable prerelease of 56c
RE: Sphere Prereleases - Ben - 02-22-2016 01:01 AM
To fix all known bugs... Coruja would have to stop "updating" old, but working code
But I do agree, it's way over due.
Oh and about triggers being turned off by default Khaos, not sure f you knew, but 56c has an auto on/off trigger mechanism.
We need to decide if sphere is stable enough for a prerelease, or just a release... let's move on to a new version
RE: Sphere Prereleases - Sypheris - 02-22-2016 06:25 AM
I just updated my sphere 56b build from an older to the latest one. and now i cant use blacksmithing.. all it tells me is, you cant make anything with what you have... what gives...
RE: Sphere Prereleases - karma - 02-22-2016 08:22 PM
Well, there are a few issues to be closed https://github.com/Sphereserver/Source/issues, plus another one reported here http://forum.spherecommunity.net/Thread-Truble-with-fall-in-houses and here http://forum.spherecommunity.net/Thread-UO-Renaissance. I'm trying to fix what i can, having other people on the code would be nice, as having more testers for current nightlies in order to find bugs
EDIT: @Sypheris, have you updated your sphere_skills.scp? There are some changes to do to the scripts when migrating from 0.56b to 0.56c.
RE: Sphere Prereleases - Khaos - 02-23-2016 03:34 AM
(02-22-2016 01:01 AM)Ben Wrote: To fix all known bugs... Coruja would have to stop "updating" old, but working code
But I do agree, it's way over due.
Oh and about triggers being turned off by default Khaos, not sure f you knew, but 56c has an auto on/off trigger mechanism.
We need to decide if sphere is stable enough for a prerelease, or just a release... let's move on to a new version
LOL I noticed Coruja is messing with the working code and doing things that could have been softcoded. One nightmare I am glad I am not dealing with right now
. You are better for that than I am when it comes to patience with people.Haha. Yes, I remember there being an on and off switch, but apparently not everyone knows how to set the INI up it seems.
It is okay. I just dropped the newest nightly in... and I am hoping I just need a restart, but I am back to not binding to listen socket like I never knew what to do. yet ini is setup for and so is sphere_serv_triggers.scp *shrugs*. I guess I will find out if it is a restart in a moment!!
Thanks for fixing the boards. Hehehe.
But yeah, a release is definitely due. As you said and I said. It is a need. Just have Xun and Coruja quit playing with the internals with upgrades and finish whatever is left for big bugs. Then do one I guess. The other pre-releases all had bugs, just nothing major.
RE: Sphere Prereleases - Khaos - 02-23-2016 04:54 AM
Ugh that memory was the issue. Sigh. If you all need anything, you know where to find me.
RE: Sphere Prereleases - Coruja - 02-25-2016 12:22 PM
"run without problems" is not the same as "run correctly", that's why we had to change some old codes
just a quick example is the REPORTEDCLIVER, which was working fine, but not correctly. Or sphere main clock (aka SERV.TIME) which was also working fine, but not returning high precision values (needed by fastwalk prevention engine). Or some old packets, which was working fine as always, but not on newest clients, etc. Things like this can't be softcoded, and even some other things that can be softcoded would need some internal support (eg: STEPSTEALTH property on stealth skill, etc)
but anyway, we are already preparing for an 56c pre-release launch since 3~4 months ago, also I had sent the commit starting 56d but we decided to wait until 56c get all pending issues fixed/closed. Honestly I can't say that its 100% ready because my server is running an outdated build from last month (jan/2016) to test sphere stability, so I must update it to latest build and check if it still working fine. The good news is that sphere reached an incredible stability, because my server uptime reached 30 days and it still running perfectly
so I believe everything is ready, it just need a few more days to check if there's any missing error left
RE: Sphere Prereleases - Khaos - 02-25-2016 11:24 PM
Which is good. Refer to my post on the script packs. I noted several issues Matex or Roberpot should handle asap. It is something you didn't check and no one thought to. Mainly because not a lot of people use odd mathematics. If you read the rather long responses I made to you, it is in some respect, but some grumpiness. Redoing a lot of things you removed in base packs, which I started redoing the day I became a dev has been problematic since you have been removing things. Really, I should be fixing a good bit of the source. Don't have the time though working on the base packs and doing them right.
Grats on serv.time though. It was a big thing that needed help. Step Stealth was done with EA perfection in old forums. You should have asked me for my script. You all were on my old Facebook forever. Had everything cloned without the additions made. Packets can be intercepted via softcode. Though, internal makes it less memory consuming, I would agree if that was your counter argument.
Seems people forget we handle packets in the soft code. *shrugs*