Jump to content

NEW Project: Sacred 2 Purist Fixpack


Flix

Recommended Posts

11 hours ago, NathyielNathyiel said:

new bug : 
When taking the quest to kill the griffin (The Griffin), it start the timer of the Hunting Fever quest.

take a screen but no UI on screen ...

big_0044.png

7 hours ago, Flix said:

When taking the quest to kill the griffin (The Griffin), it start the timer of the Hunting Fever quest.

I think this only happens with legacy characters, not 100% sure though. Also this has nothing to do with the white griffin quest, in fact, it can happen anytime, even directly at the start of a new game.

I think it's the line

anyofthem = 1

in quest.txt which is broken. Change it to

anyofthem = 0

This should do the fix, however it might interfere with questscripts.txt and the (I think hardcoded) messages aftert each kill.

  • Thanks! 1
Link to comment
1 hour ago, NathyielNathyiel said:

So it might be related to quest marker send you to the closed cave entrance, even if it's the wrong cave ...

It's the same cave, that's why it points there because the game treats it as the nearest entry. But that's actually the "exit door" on the quest. :D

Link to comment
On 1/29/2022 at 10:40 PM, Lindor said:

This should do the fix, however it might interfere with questscripts.txt and the (I think hardcoded) messages aftert each kill.

I don't think it's anyofthem=1 that's triggering the quest prematurely.  If that was set to 0 the player would have to kill 31 of each type of creature listed rather than any random 31 creatures from the region.  The quest would have to be rewritten.  The messages aren't hardcoded either, they were moved from quest.txt to questscripts.txt in CM 1.50 and encoded in the global.res file.  Other quests use this new format as well and don't have issues.

I had suspected it's something to do with a precond_quest parameter, but I haven't found anything yet.

Link to comment
1 hour ago, Flix said:

I don't think it's anyofthem=1 that's triggering the quest prematurely.  If that was set to 0 the player would have to kill 31 of each type of creature listed rather than any random 31 creatures from the region.  The quest would have to be rewritten.  The messages aren't hardcoded either, they were moved from quest.txt to questscripts.txt in CM 1.50 and encoded in the global.res file.  Other quests use this new format as well and don't have issues.

I had suspected it's something to do with a precond_quest parameter, but I haven't found anything yet.

I don't think that "anyofthem=1" works as it should, in fact, Hunting Fever I is the only quest in quest.txt which has this entry set to 1 despite many other quests existing where you are tasked to kill an amount of creatures. I think there are three kinds of "kill these creatures"-quests:

  1. Those which spawn in taskcreatures and only those count as kill, e.g. This one
  2. Hybrid ones which spawn taskcreatures, but also regularly spawned creatures count as kill, e.g. This one
  3. Those who don't spawn in taskcreatures and only regularly spawned creatures count as a kill (like Hunting Fever I)

Let's take a look at the Hybrid quest I mentioned:

quest.createQuest(431, {
id = 431,
name = "S_HE_N_nn-Wildschweinplage 1",
questtype = 1,
silent=0,
ismainquest = 0,
mainquestchapter = 0,
questbookstrategy = 1,
continues_quest_id = 0,
continues_bookentry = 0,
forpathnot = 0,
reservedforpath = 0,
reservedforhero = 0,
reservedforgod = 0,
reward_exp=1,
reward_gold=1,
reward_drop=0,
reward_attr=0,
reward_skill=0,
report_required = 1,
dangerclass=4,
author_ready = 0,
qa_ready = 1,
releasestage = 30,
progress = 0,
autostart = 0,
anyprequest = 0,
showdlgonwin = 0,
lostondecline = 0,
questgiver = {
taskcreature = 1553,
ispersistent = 0,
isproactive = 0,
isrefusable = 1,
position = { 31,26,0 , 50.000,2350.000,0.000 , -41.000 },
},
questKill = {
anyofthem = 0,
useprefightdlg = 0,
bodycount = 10,
kill0 = {
taskcreature = 1555,
},
kill1 = {
taskcreature = 1556,
},
kill2 = {
taskcreature = 1557,
},
kill3 = {
taskcreature = 1558,
},
kill4 = {
taskcreature = 1560,
},
kill5 = {
taskcreature = 1561,
},
kill6 = {
taskcreature = 1562,
},
kill7 = {
taskcreature = 1563,
},
kill8 = {
taskcreature = 1564,
},
kill9 = {
taskcreature = 3773,
},
kill10 = {
creature = 56,
bodycount = 10,
},
kill11 = {
creature = 57,
bodycount = 10,
},
},
})

The last two entries are the regularly spawned boars.

You see, in spite of the "anyofthem=0" line, killing any one of the regularly spawned taskcreatures immediately counts as a kill and after 10 kills you get the complete, not 20 like it was if "anofthem=0" worked as you said. This is why I think the line is broken and causing the bug.

Link to comment
On 1/28/2022 at 10:41 AM, NathyielNathyiel said:

Found a bug with an event in El-Darrag.

There's should be a fight starting when you first enter the village. But it don't start for me. I try to save/re-load, Teleport to another city and game back, restart the game, etc.

 

Edit: removed PFP, the event start as soon as teleport in.
 

big_0042.png

@dimitrius154  Do you get the above behavior in Addendum?  I think this bug was inherited from CM 1.60.  The initial trigger is supposed to be a reaching quest id = 2709.  The sectors for the signalonenter look ok to me, but the quest will not update.  The subsequent quest (id = 2692,) requires this quest to reach stage 9 before triggering, but since the quest won't complete, the fighters continue using questcreatures behavior.

As soon as a fatal blow is landed on a Du'Rach, the quest updates and the behavior changes.

  • Haha 1
Link to comment

Actually you have to kill one. You can attack them but the trigger won't launch the fight sequence until you kill one of them. And yeah, like I said I don't remember this in 1.50, but I have no idea why it appeared on 1.60 either.

  • Thanks! 1
Link to comment
15 hours ago, Flix said:

Do you get the above behavior in Addendum? 

Yep, and the quest had not beeen altered since 1.50. I strongly suspect the behaviour is the same in that iteration.

Edited by dimitrius154
Link to comment

Just completed silver campaign with lot of questing. Didn't have any crashes or problems related to the Patch.

Two things that have always been a Problem for me, I don't know if that can be fixed...
Assailing Somersault: If you cast it out of range of an enemy the character gets stuck on spot, bugs with some "twitching animation"  and doesn't move. Prevents fluid gameplay. It get's a bit better with the experience how far you can jump...

Archangel's Wrath: Has severe problems hitting Flying enemies. It will often just fly into the air past the enemy hitting nothing.

 

And a special request: I think I'd like to remove the maximum level restriction so that I cannot outlevel the early areas. Is there an easy way to do it? I have downloaded every Communitypatchversion that exists. If it's just a file in which I need to change some lines I'd much appreciate instruction how to change that :)

Link to comment
1 hour ago, Vishanka said:

And a special request: I think I'd like to remove the maximum level restriction so that I cannot outlevel the early areas. Is there an easy way to do it? I have downloaded every Communitypatchversion that exists. If it's just a file in which I need to change some lines I'd much appreciate instruction how to change that :)

The simplest way would be to copy the region.txt file from the Community Patch version 1.40 or higher.  You can compare this file with the vanilla one to see how it was done. Each region has a minimum and maximum level defined here.

The other stuff is out of my expertise range.

Link to comment
On 2/2/2022 at 2:20 AM, dimitrius154 said:

Yep, and the quest had not beeen altered since 1.50. I strongly suspect the behaviour is the same in that iteration.

I checked 1.40 as well.  The scripts are identical to 1.50 and 1.60 for this chain.

Then I checked the vanilla scripts.  Though the formatting is very different, I don't think anything material is changed in the quest.txt entry.  I tried pasting in the vanilla text from quest.setScript(2692, but there was no difference in behavior.

So, I'm at a loss here.

On 1/31/2022 at 12:20 AM, Lindor said:

I don't think that "anyofthem=1" works as it should, in fact, Hunting Fever I is the only quest in quest.txt which has this entry set to 1 despite many other quests existing where you are tasked to kill an amount of creatures

Well, I can make the change but I need you to test Hunting Fever to make sure it doesn't break!  If the quest is able to be completed normally, then at worst it's a harmless change. At best it will finally stop the quest triggering inappropriately

Link to comment

Found something else:

quest.createQuest(948, {
id = 948,
name = "S_IS_9c_HI_G_nn-DeElfici",
name = "S_BI_3b_md-Jagdfieber III-Report",

questtype = 1,
silent=0,

 

Hunting Fever III report stage has two names defined. This kind of mistake in CM scripts has broken quests before, particularly with quest markers and journal entries not updating or updating at inappropriate times.  This is what comes from cannibalizing pieces of old unused entries instead of writing fresh ones.  CM Patch quest.txt is full of this kind of thing.

 

Also, look at where the quest giver for Hunting Fever III is supposed to be positioned:

questgiver = {
taskcreature = 9801,
ispersistent = 0,
isproactive = 0,
isrefusable = 1,
position = { 41, 35, 0, 2223.000, 2623.703, 1864.788, 90.000 },

Sector 41,35 is an empty chunk of mountain range between Tyr Lysia and Artamark.

In the next entry she's placed at position = { 14, 43, 0, 892.301, 1476.000, 4651.761, 330.000 },  which is Gronkor's Outlook.  Did this quest even get any QA?  

Based on the taskcreature entry this is the proper spawn position: position = { 7,62,0 , 1200.000,300.000,0.000 , 120.000 },

Link to comment
4 hours ago, Flix said:

Found something else:

quest.createQuest(948, {
id = 948,
name = "S_IS_9c_HI_G_nn-DeElfici",
name = "S_BI_3b_md-Jagdfieber III-Report",

questtype = 1,
silent=0,

 

Hunting Fever III report stage has two names defined. This kind of mistake in CM scripts has broken quests before, particularly with quest markers and journal entries not updating or updating at inappropriate times.  This is what comes from cannibalizing pieces of old unused entries instead of writing fresh ones.  CM Patch quest.txt is full of this kind of thing.

 

Also, look at where the quest giver for Hunting Fever III is supposed to be positioned:

questgiver = {
taskcreature = 9801,
ispersistent = 0,
isproactive = 0,
isrefusable = 1,
position = { 41, 35, 0, 2223.000, 2623.703, 1864.788, 90.000 },

Sector 41,35 is an empty chunk of mountain range between Tyr Lysia and Artamark.

In the next entry she's placed at position = { 14, 43, 0, 892.301, 1476.000, 4651.761, 330.000 },  which is Gronkor's Outlook.  Did this quest even get any QA?  

Based on the taskcreature entry this is the proper spawn position: position = { 7,62,0 , 1200.000,300.000,0.000 , 120.000 },

The hunting fever III questgivers have always been south of griffinborough - gronkor' outlook - crystal plane. Nothing special, it is because the creatures you have to hunt in the first two stages of the quest naturally spawn in those areas.

 

About the double name thing, that is an interesting finding! I don't think it has a bad effect however. Sacred 2 (like many, many, many other games's) script language is lua. If the Sacred 2 script interpreter works the same way as lua normally works, then the first name entry would simply get overwritten by the second name entry because everything's happening in the same table, so there would be nothing bad happening here.

If however the devs tweaked the lua interpreter, quirks and bugs couldn't be ruled out. But I strongly doubt they would've tweaked lua that much. If they attempted to do that, then they could've written their own programming language in the first place. Tables are the very core of lua.

8 hours ago, Flix said:

Well, I can make the change but I need you to test Hunting Fever to make sure it doesn't break!  If the quest is able to be completed normally, then at worst it's a harmless change. At best it will finally stop the quest triggering inappropriately

Hmm kay imma download PFP then. If I remember how to properly disable CM, it's been a while :D

Also I think there's a way to properly test whether the fix is working: IIRC, then the bug always happened on the unskilled test characters here in the download section.

Link to comment
4 hours ago, Lindor said:

Hmm kay imma download PFP then. If I remember how to properly disable CM, it's been a while :D

Also I think there's a way to properly test whether the fix is working: IIRC, then the bug always happened on the unskilled test characters here in the download section.

I tested it with CM-testchar Seraphim. The quest is completable normally, but the bug still occurs. Either changing "anyofthem=1" to "anyofthem=0" doesn't do anything or it does do something that I didn't notice. I still recommend the change, but it won't fix the bug.

I tried to look into questscripts.txt to see how the triggering works. The way it is scripted is a little bit confusing - but I guess it was needed to do it that way in order to work correctly with the hardcoded logic. I will see what I can do, I already spotted something which might eventually cause an issue, but I have low hobes because I found an old thread where marcuswob said the quest can be triggered multiple ways, but he's talking about Hunting Fever 3 and not Hunting Fever 1:

On 12/11/2010 at 6:06 PM, marcuswob said:

Very nice :)

 

You need to have the cm-patch installed. This quest actually has some prerequisites, but they strangely depend on the age of your char. If you use a char that was created before using the cm-patch, you can get this quest immidiately - but the questbook will look strange. If you use a char that was created and played only while using the cm-patch, you have to solve another quest before.

 

With the cm-patch v0100 this will change a little bit: http://darkmatters.org/forums/index.php?showtopic=14478&view=findpost&p=6908068

 

CU Marcus

--

On 11/3/2010 at 10:25 AM, marcuswob said:

It's about

 

http://www.frankrentmeister.info/mantisbt/view.php?id=208 "Starting 'Hunting Fever' quest does not get logged into the Log Book"

 

http://www.frankrentmeister.info/mantisbt/view.php?id=214 "Nameless Quest"

There is a quest that involves fighting a Succubus and its pack of Demons in the Human region. This quest has a few issues:

1. No quest dialog for accepting or declining the quest. Once you click on the quest giver, the quest is automatically accepted.

2. Log entry for the quest has no details.

3. Quest has no name, thus cannot be select in the Quest Log

4. Quest creates Chapter III tab in Quest Log, but I'am not in Chapter III yet.

 

So everything you can see about "Hunting Fever III" and "Dark Rituals" ist completely new.

 

CU Marcus

However this indicates to me that there might be some hardcoded quest triggering going on here. If that's the case, no amount fiddling with quest.txt or questscripts.txt will help here.

Link to comment

The issue sits way, way, waaay deeper than I ever expected. There is a repeated mistake in all of the CM-patch questscripts.txt functions. Let me explain with an example:

This is the CM timed quests table:

cm_timequest={
{id=3636,time=10,kills=31,tcount=false,ecount=false,heropos=false,memory=false,
teleta=false,teletf=false},
{id=3541,time=5,kills=10,tcount=false,ecount=false,heropos=false,memory=false,
teleta=false,teletf=false},
{id=3542,time=5,kills=12,tcount=false,ecount=false,heropos=false,memory=false,
teleta=false,teletf=false},
{id=1804,time=5,kills=10,tcount=false,ecount=false,heropos=false,memory=false,
teleta=false,teletf=false},
{id=1803,time=5,kills=10,tcount=false,ecount=false,heropos=false,memory=false,
teleta=false,teletf=false},
{id=1801,time=5,kills=10,tcount=false,ecount=false,heropos=false,memory=false,
teleta=false,teletf=false},
{id=1794,time=5,kills=10,tcount=false,ecount=false,heropos=false,memory=false,
teleta=false,teletf=false},
{id=1791,time=5,kills=10,tcount=false,ecount=false,heropos=false,memory=false,
teleta=false,teletf=false},
{id=1786,time=5,kills=10,tcount=false,ecount=false,heropos=false,memory=false,
teleta=false,teletf=false},
{id=3673,time=5,kills=40,tcount=false,ecount=false,heropos=false,memory=false,
teleta=false,teletf=false}
}

Normally, this would be a table full of nil values because the id, time, tcount etc. objects are not set up, however the way the hardcoded interpreter works is that it's giving these objects some sort of meaning, probably with binary IDs.

This is one of the CM-patch added functions:

CM_get_index=function(quest_id)
local index=false
for I,element in ipairs(cm_timequest) do
if element.id==quest_id then
index=I
end
end
return index
end

The way lua works however is that element.id does not index element[id], it indexes element["id"]! The function searches for a value to the "id" string of the element table and since, like you can see above, this string has no value assigned to it, the function will always  return false no matter what! This is actually a really common beginners mistake and - to be honest -  really sloppy. This mistake is seen all over the place in all CM-patch functions, none of them are working properly and I mean NONE! But that is not even the worst. It is possible to quickly put those functions into a working state by doing this:

cm_timequest={
{id=3636,time=10,kills=31,tcount=false,ecount=false,heropos=false,memory=false,
teleta=false,teletf=false,"id"=3636,"time"=10,"kills"=31,"tcount"=false,"ecount"=false,"heropos"=false,"memory"=false,
"teleta"=false,"teletf"=false},
{id=3541,time=5,kills=10,tcount=false,ecount=false,heropos=false,memory=false,
teleta=false,teletf=false,"id"=3541,"time"=5,"kills"=10,"tcount"=false,"ecount"=false,"heropos"=false,"memory"=false,
"teleta"=false,"teletf"=false},
{id=3542,time=5,kills=12,tcount=false,ecount=false,heropos=false,memory=false,
teleta=false,teletf=false,"id"=3542,"time"=5,"kills"=12,"tcount"=false,"ecount"=false,"heropos"=false,"memory"=false,
"teleta"=false,"teletf"=false},
{id=1804,time=5,kills=10,tcount=false,ecount=false,heropos=false,memory=false,
teleta=false,teletf=false,"id"=1804,"time"=5,"kills"=10,"tcount"=false,"ecount"=false,"heropos"=false,"memory"=false,
"teleta"=false,"teletf"=false},
{id=1803,time=5,kills=10,tcount=false,ecount=false,heropos=false,memory=false,
teleta=false,teletf=false,"id"=1803,"time"=5,"kills"=10,"tcount"=false,"ecount"=false,"heropos"=false,"memory"=false,
"teleta"=false,"teletf"=false},
{id=1801,time=5,kills=10,tcount=false,ecount=false,heropos=false,memory=false,
teleta=false,teletf=false,"id"=1801,"time"=5,"kills"=10,"tcount"=false,"ecount"=false,"heropos"=false,"memory"=false,
"teleta"=false,"teletf"=false},
{id=1794,time=5,kills=10,tcount=false,ecount=false,heropos=false,memory=false,
teleta=false,teletf=false,"id"=1794,"time"=5,"kills"=10,"tcount"=false,"ecount"=false,"heropos"=false,"memory"=false,
"teleta"=false,"teletf"=false},
{id=1791,time=5,kills=10,tcount=false,ecount=false,heropos=false,memory=false,
teleta=false,teletf=false,"id"=1791,"time"=5,"kills"=10,"tcount"=false,"ecount"=false,"heropos"=false,"memory"=false,
"teleta"=false,"teletf"=false},
{id=1786,time=5,kills=10,tcount=false,ecount=false,heropos=false,memory=false,
teleta=false,teletf=false,"id"=1786,"time"=5,"kills"=10,"tcount"=false,"ecount"=false,"heropos"=false,"memory"=false,
"teleta"=false,"teletf"=false},
{id=3673,time=5,kills=40,tcount=false,ecount=false,heropos=false,memory=false,
teleta=false,teletf=false,"id"=3673,"time"=5,"kills"=40,"tcount"=false,"ecount"=false,"heropos"=false,"memory"=false,
"teleta"=false,"teletf"=false}
}

So I assigned the correct value to each string these functions are searching for.

However in doing so, it will break the entirety of all the cm_timed quests, which means that all the CM patch scripting is broken beyond that single repeated indexing mistake. And I want to be really clear here: not the above method is broken, it really are the CM-added functions which are broken. There are more ways to fix this than just the above, it was just an example, I tried them all and it's always the same outcome: by putting the functions into a working state you brake the quests.

The entirety of the questscripts.txt has to be reworked by someone who can program in lua AND has knowledge about the games hardcoding. I don't believe that whoever has set up these functions had a lot of experience in lua, although the one probably had some knowledge about the games .dll files. I on the other hand can speak lua, but I know nothing about the hardcoding. I strongly recommend to put all quests into a pre-CM-patch state, even if that would reintroduce all the bugs. It is way easier to restart cleanly than trying to fix a mess.

 

And please, respond to me if you don't believe me and say why. If you spot an error in my thought process or are unsure of whether I'm correct or what I mean, say it.

2 hours ago, Flix said:

It should be working properly in the next release.

Which quest and how? Please, I need input.

 

EDIT: Oh and BTW, the niokaste/nikotaste (niokaste is correct) and megalcarwen/maegalcarwen/meglacarwen (maegalcarwen is correct) mistakes are still part of PFP. Can you fix those?

Edited by Lindor
Link to comment

Well, I won't dispute your lua knowledge, but what is a demonstrable effect of the broken quest scripts that you've cited above?  What kind of bugs do you think they're causing?  For timed kill quests, everything seems to work.  The timer, the enemy counter, the "cheering" messages, the completion/report.  Do you think this is the cause of Hunting Fever triggering too early?

The spelling is corrected in PFP, but I only did the English language text.  I don't have the resources or fluency to work through the other languages.

For Hunting Fever III I corrected the positioning of Seraphim Diana so that she spawns in the same building as the Hunting Fever II Seraphim.  That way part III picks up directly after part II ends.  The player gets teleported by script to Artamark and Nor Plat automatically so it's nonsensical to have the player trek down there on their own.  Diana also stays there for reporting until the last part where she moves to the outpost near the Blue Star, where she also stays until the final completion.  This way the player can teleport directly to her for reporting instead of wandering around Artamark and Nor Plat to report in.

Link to comment
26 minutes ago, Flix said:

Well, I won't dispute your lua knowledge

You should. I was so confused by all of this that I tested a myriad of things until I finally found out what is going on here. In Sacred 2's lua, this expression:

local mytable = {id = 3}

is equal to this expression:

local mytable = {}
mytable["id"] = 3

while I am still used to this:

local mytable = {"id" = 3}

which is not how standard lua works, it's a unique property of another game.

Forget everything I said, it was my lua knowledge after all.

I think I will never reach that level of confusion again:lindor: I'll continue revisiting the scripts, but I'm like 80% sure it's a hardcoded issue by now :/

 

Link to comment

There might be something quirky happening with

CM_TimerResolve=function (quest_id)
local index=CM_get_index(quest_id)--works
if CM_SessionOnline and index then
if getQuestState(quest_id)=="TASK_AWAITING" and not cm_timequest[index].tcount then
CM_TimedKillCheatEvent(quest_id)
end
end
end

"and" has often high priority, so there might be the following happening:

if getQuestState(quest_id)==("TASK_AWAITING" and not cm_timequest[index].tcount) then

while in reality you want

if (getQuestState(quest_id)=="TASK_AWAITING") and (not cm_timequest[index].tcount) then

This is however a very big "might", on current lua version "==" has higher priority than "and". I would still recommend to change it to

CM_TimerResolve=function (quest_id)
local index=CM_get_index(quest_id)--works
if CM_SessionOnline and index then
if ( getQuestState(quest_id)=="TASK_AWAITING" ) and ( not cm_timequest[index].tcount ) then
CM_TimedKillCheatEvent(quest_id)
end
end
end

At worst, nothing happens. At best, bugs get prevented.

Link to comment

I would suggest to change CM_GetSessionStatus like this to skip unnecessary calculations and speed up execution:

CM_GetSessionStatus=function (args)
local HeroRefs=getHeroRefs()
local index=CM_get_index(args.id)--works
if getn (HeroRefs )>0 and index then
local myHeroRef=HeroRefs[1]
local p=CM_convertPosition_To_SimpleTable(getPos{heroRef=myHeroRef})
if not cm_timequest[index].heropos then
cm_timequest[index].heropos=p
else
local constant_position=true
local pp=cm_timequest[index].heropos
for I,c in ipairs(p) do
if p[I] ~=pp[I] then
constant_position=false
break
end
end
if not constant_position then
CM_SessionOnline=true
end
end
end
end

Just a break command added in line 15, also it doesn't really matter since the amount of calculations skipped is tiny but it's just cleaner to do it like that.

Link to comment

I have found something out. Hunting Fever 1 is not triggered on accepting other quests, it appears like that ingame but that's not what's happening. If such an event happens, then the quest was already a completed quest in the logbook from the start of the game. Now questscripts.txt has a set of functions to "manually" start the timer of a timed quest in case it didn't start correctly. These sets of functions are triggered on the (hardcoded) "OnCounter" event of the quest. This "OnCounter" event SHOULD only fire upon killing one of the creatures of the "kill-these-creatures"-quest. However, somehow this event is also fired upon accepting a new quest. If you're able to prevent that from happening, then you have half of the fix.

The other half, which is Hunting Fever 1 already appearing in the logbook from the start of the game, can probably be fixed with some lua scripting. The cause for that issue is still a mystery however, so it would be treating the symptoms and not the desease.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...
Please Sign In or Sign Up