PCRPG 3.35 Release [Finished]

[Corona]

I haven't changed any of that code.  If it doesn't accept arguments now then it didn't before.  End of story.  Freaking trolls.

I didn't want to have to do this, but:

function GetNearestZone(%clientId, %zonetype, %returnType)
{
dbecho($dbechoMode, "GetNearestZone(" @ %clientId @ ", " @ %zonetype @ ", " @ %returnType @ ")");

>//%zonetype can be "town", "dungeon" or "freeforall"

%closestDist = 500000;
%closestZone = "";
%mpos = "";
%clpos = GameBase::getPosition(%clientId);

for(%i = 1; %i <= $numZones; %i++)
{
   %type = $Zone::Type[%i];
   if(%type == "PROTECTED" && String::ICompare(%zonetype, "town[/color]") == 0 ||
   %type == "DUNGEON" && String::ICompare(%zonetype, "dungeon") == 0 ||
   %type == "FREEFORALL" && String::ICompare(%zonetype, "freeforall") == 0 ||
   %zonetype == -1)
   {
      %finalpos = $Zone::Marker[%i];
   
      %dist = Vector::getDistance(%finalpos, %clpos);
      if(%dist < %closestDist)
      {
         %closestDist = %dist;
         %closestZoneDesc = $Zone::Desc[%i];
         %closestZone = $Zone::FolderID[%i];
         %mpos = %finalpos;
      }
   }
}

if(%mpos == "")      //no zones were found (this means there are NO zones in the map...)
   return False;
   
//%returnType:
//1 = returns the distance from the client to the nearest zone
//2 = returns the description of the zone nearest to the client
//3 = returns the zone id of the zone nearest to the client
//4 = returns the position of the middle of the zone nearest to the client

if(%returnType == 1)
   return %closestDist;
else if(%returnType == 2)
   return %closestZoneDesc;
else if(%returnType == 3)
   return %closestZone;
else if(%returnType == 4)
   return %mpos;
}

The teleport spell passes the %zonetype variable ("town" or "dungeon") and you can clearly see it being parsed by GetNearestZone(). Indeed, there is even a third argument you can pass, "freeforall", though I don't know what that does.

[Corona]

Additionally, in base TRPG, try this experiment:

1. Fell yourself.
2. Type #cast teleport town.
3. You appear near Keldrin Town.
4. Fell yourself again.
5. Type #cast teleport dungeon.
6. You appear near Yolanda.

[Xenos]

You don't have to believe teleport took arguments in version 5.005 but it's still true.


When is this new version going to be live? Currently it still says 3.33.

[Particle]

Surprise, surprise!  My code is identical and it doesn't function that way.  The path to that function doesn't have any filtering that would block "dungeon" and pass "town" or vice versa.  As I said before: end of story as far as this goes.  I am willing, however, to find a way to make it function as you folks seem to want it.



Version 3.35 will roll as soon as I can get some working instructions for how to add GZ.

[Corona]

AAAARGH! Particle, it's right there! In your screenshot, no less!

Let's take a look at how this works:

Code: [Select]

for(%i = 1; %i <= $numZones; %i++)
{
%type = $Zone::Type[%i];
if(%type == "PROTECTED" && String::ICompare(%zonetype, "town") == 0 || %type == "DUNGEON" && String::ICompare(%zonetype, "dungeon") == 0 || %type == "FREEFORALL" && String::ICompare(%zonetype, "freeforall") == 0 || %zonetype == -1)
{
%finalpos = $Zone::Marker[%i];

%dist = Vector::getDistance(%finalpos, %clpos);
if(%dist < %closestDist)
{
%closestDist = %dist;
%closestZoneDesc = $Zone::Desc[%i];
%closestZone = $Zone::FolderID[%i];
%mpos = %finalpos;
}
}
}

if(%mpos == "") //no zones were found (this means there are NO zones in the map...)
return False;


If the %mpos variable is EMPTY, the function returns False, and the teleport failed. Right? Right.

Let's take a look at what conditions have to be satisfied in order for %mpos to not be False.

for(%i = 1; %i <= $numZones; %i++) = This line starts a for() loop which goes through every zone in the server.... then, "for" each zone, the following is done:

%type = $Zone::Type[%i]; We get the zone type (can be DUNGEON, PROTECTED, or FREEFORALL.


if(%type == "PROTECTED" && String::ICompare(%zonetype, "town") == 0 || %type == "DUNGEON" && String::ICompare(%zonetype, "dungeon") == 0 || %type == "FREEFORALL" && String::ICompare(%zonetype, "freeforall") == 0 || %zonetype == -1) Here's the crucial part.  The whole idea of this function is to go through every zone, and figure out which one is closest to the player, right? Well, before a zone is added to the list-of-zones-that-are-able-to-be-teleported-to, it has to go through the above 'if' check. If you were to translate the above into readable English, it would be: "IF the type of this zone is 'PROTECTED' AND the zonetype variable is 'town'..... OR IF the type of this zone is 'DUNGEON' AND the zonetype variable is 'dungeon'.... OR IF the type of this zone is 'FREEFORALL' AND the zonetype variable is 'freeforall'... OR if the user didn't specify a zonetype because zonetype is false, THEN...."

Thus, in order to be considered as a zone to teleport to, the zone must first pass the above check. If, for example, the user specified zonetype "dungeon", it would FAIL the part of the check that says "IF the type of this zone is 'PROTECTED' AND the zonetype variable is 'town'...", and thus, the zone would not get considered, and as a result, the teleport spell would not teleport you there.

I'm not an experienced programmer, but I understand basic if-else if-else checks.

And besides, you're completely ignoring the fact that the spell actually works this way in Base TRPG. It's not theory. It's not an abstract concept. It's not conjecture, or hypothesis. It's fact: If you type "#cast teleport town" in keldrin town, you will go to keldrin town, EVERY TIME. If you type "#cast teleport dungeon" in keldrin town, you will go to stronghold yolanda, EVERY TIME. If any active PCRPG player disagrees with this statement, please say so.

*EDIT*

Based on this research, I believe I can even guess what the problem is! Your teleport spell is not properly carrying over the %zonetype that the player provides. The default behavior when the player DOES NOT specify a zone type is to teleport to the nearest zone regardless of its type, which is what seems to be happening. And we've had problems with variables not getting passed before on PCRPG. So.... there you go.

[Particle]

I'm not an experienced programmer, but I understand basic if-else if-else checks.

Did you totally miss the point of the screenshot I provided...that the code you're claiming I'm too dumb to read is IDENTICAL between PCRPG 3.35/3.33/ANY_VERSION and TRPG 5.005?  Also, you don't have any idea how my spell system validation works.  I, on the other hand, have the actual source code right on my screen.  There is no possible way for it to pass "town" and not "dungeon" or "dungeon but not "town".

...so aggrivating

I offered to find a way to make it work how you folks would like, but instead of a "thanks" or an "ok" I just received more unsavory womaning.  What the crap, guys.  What the holy, mother farkin' crap.

[Corona]

I'm not an experienced programmer, but I understand basic if-else if-else checks.

Did you totally miss the point of the screenshot I provided...that the code you're claiming I'm too dumb to read is IDENTICAL between PCRPG 3.35/3.33/ANY_VERSION and TRPG 5.005?  Also, you don't have any idea how my spell system validation works.  There is no possible way for it to pass "town" and not "dungeon" or "dungeon but not "town".

...so aggrivating

Did you miss the point of my commenting on said screenshot? I wasn't saying there is a problem with the function GetNearestZone(). I was pointing out how it works -- It's identical to Base TRPG, we can see that. Therefore, since teleport is not working properly, the problem MUST LIE ELSEWHERE. There are other components to this spell in other files, so one of them may be messing up....

[Corona]

I offered to find a way to make it work how you folks would like, but instead of a "thanks" or an "ok" I just received more unsavory womaning.  What the crap, guys.  What the holy, mother farkin' crap.

You offered to 'make it work how we would like', not to 'fix' it, which sort of implies that we're a bunch of idiotic morons who don't know what we're talking about, but you'll 'modify' the code to shut us up. That is why I am unsavory womaning.

[Particle]

I've had about enough of you for one day.  If you aren't going to stick to the points and you want to skew everything to make it sound like I'm a freaking moron when it isn't my fault, I'll need you to leave the board for the remainder of today.

[Corona]

I've had about enough of you for one day.  If you aren't going to stick to the points and you want to skew everything to make it sound like I'm a freaking moron when it isn't my fault, I'll need you to leave the board for the remainder of today.

It wasn't my intention to make it sound like you were a moron... I was  debating for the sake of debating. I don't even use teleport... :/

I was just attempting to help get to the bottom of the issue. It is true that there have been PCRPG problems before where a feature doesn't work, but its section of code will look OK, and by all rights it should function OK, and it even turns out that it does work OK... because the problem was somewhere else in the code entirely.

I apologize for any misunderstanding I created.

[Particle]

It isn't the discussion that's the problem.  It's the backseat code coaching where you claim a system I've engineered doesn't work without even having access to the code to know that it's where the problem is.  If you were debating for the sake of debating--trying to resolve the source of the problem, there are three problems that have caused this misunderstanding you speak of.

1)  You cannot get to the root of a code problem without access to the code for something much more complex than HelloWorld.  Insisting otherwise is quite insulting to a programmer.  It's like if a blind person were to be yelling from the backseat of a car about how to drive to a destination he's never been to.

2)  You should have stopped at where I offered to make it work how you (two) wanted it to work.  This would have meant that it'll get fixed no matter where the problem lies--in PCRPG code (my fault), in TRPG code (JI's fault), or a problem with the two not interfacing nicely (nobody's fault).  Historically, all three of these have happened rather frequently.

3)  Personally attacking me via mockery "Did you miss the point of my commenting on said screenshot?" (for example) doesn't serve to help solve the problem.

You should know by now that on top of everything I've covered above, I'm very defensive by nature.  By this point of being around me, surely you knew what your comments would do to me.  So, I can't really accept that your intentions were purely for the sake of uncovering the source of the problem presented.  I can, however, believe that you didn't purposely intend to simply throw gasoline on the fire.  This isn't going to be a problem in the future or anything, but please refrain from this the next time there is a problem.

As a note to everybody on this forum (not particularly you, Corona), when I say "end of story" on this forum there is a reason.  It means either "I'll take care of it, no need for further discussion," or it can also mean "Regardless of anything and everything, this is the last that should be mentioned of the current line of discussion in this thread."  Some times like in this instance, both meanings apply.

[Particle]

Updated the spell stuff to [OK].

We're good to go now outside of this teleport thing and the map.

[Xenos]

As a note to everybody on this forum (not particularly you, Corona), when I say "end of story" on this forum there is a reason.  It means either "I'll take care of it, no need for further discussion," or it can also mean "Regardless of anything and everything, this is the last that should be mentioned of the current line of discussion in this thread."  Some times like in this instance, both meanings apply.

I was going to reply and continue the debate until I saw this.   Can't you be more friendly and use some smilies?    :lol:  :lol:  


Extra note: This DID work in pcrpg before the cast exploit was fixed and you added all those argument checks for spells.

[Particle]

This DID work in pcrpg before the cast exploit was fixed and you added all those argument checks for spells.

This is the kind of info that actually helps.

[Particle]

Updated changelog.  PCRPG v3.35 has been released.