Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
Alrighty, I've looked through back posts and this question seems to remain unanswered. Is there a way to change the &&Job; value?
I'm not trying to add a class(which would set the &&Job; value at startup), but trying to allow a character to change his class during game play. Or, perhaps, force the character into a class change.
But if I utilize a global for special skills/spells and change that, so that the skills/spells think the player's class has changed, the level up engine still checks &&Job; and does its thing on the old class when the player levels.
So, is there any way to change &&Job;? And if not, why?
Thanks
------------------ (url="http://"http://stark.evula.net/pogwalkthrough.htm")PoG Walkthrough and Compendium(/url) | (url="http://"http://www.ambrosiasw.com/cgi-bin/vftp/dl-redirect.pl/PoG_Dev_Tools_Source.sit?path=coldstone/resources&file;=PoG_Dev_Tools_Source.sit")PoG Dev Tools(/url) (url="http://"http://stark.evula.net")Stark.evula.net(/url) now on (url="http://"http://www.evula.net")EVula.net(/url)
I'm fairly sure you can't, as the engine probably doesn't support it. There are a lot of potential issues with changing classes that were probably simpler not to deal with in the engine, unfortunately. What if the character has items equipped that the new class can't use? What if the new class uses a different experience table? Does the player forget all the spells that his new class can't cast? What if he switches back later on? Obviously an engine could deal with all these possibilities, but I'm guessing that Dee & Co. probably didn't.
As to workarounds, it seems to me like your current method (a global "playerIsClassX", if I understand aright) should be workable. You would just need to override all existing class-related events (such as level-up events) so that they all include a conditional check of "playerIsClassX is 0" or the like. I don't think you could change the skill table itself though - so the player's stuck with whatever rate of level advancement he's already got.
Hope this helps.
------------------ I don't know what I'm talking about. In Googlis non est, ergo non est.
Offhand I was going to suggest using a global set with the original class and then using a conditional event to change the &&Job; tag. However, I realised that whilst you could change the global easily enough, conditionals can't effect the &&Job; itself directly. I don't actually think there is a way, barring the player restarting, for you to do it. You could probably fake it, like Glenn suggested, but I seriously doubt whether the skill tables etc. could be reapplied once the game is underway.
-Andiyar
------------------ "Any good that I may do here, let me do now, for I may not pass this way again"
Quote
Originally posted by Glenn: I'm fairly sure you can't, as the engine probably doesn't support it.
That's what I'm afraid of. I really wish that we would have some more freedom over the things we can do with the engine. /me sighs.
There are a lot of potential issues with changing classes that were probably simpler not to deal with in the engine, unfortunately.
I realize that you aren't saying "You can't change &&Job;, nor should you be able to" but I'm going to go through your own thought processes in an attempt to say, "Yes, we should be able to." So this isn't meant as a debunking or anything of the type aimed at you directly(not that I think you would think this, but others might).
What if the character has items equipped that the new class can't use?
My first thought is: make the player unequip all his equipment! This would take care of all equipment problems.
Also, if &&Job; is not changed and you merely use a global to keep track of skills, level tables, etc, then you will also need to add checks to every item you make to check against your global instead of checking against &&Job;(like they do by default). Otherwise if you change the global for your class, they will still be relegated to use the equipment of their default &&Job; and not their new class.
What if the new class uses a different experience table?
Then the player will use the new experience table. Just like if you do an Attribute Wizard to auto-set a player's level. You can set a player's level to 10 from 0, when he has no experience points. If you do this then the player will have to earn enough exp to get to level 11 before he levels up again(which will be a lot). I would assume(haven't tested) that if a level 10 guy was set to level 0 but exp was not reset then the next exp point he earns he will level right up to level 10. The same would hold true for a class change. The engine, one would assume, would start looking at the new class exp table. And if the player was way over the experience for his level then the next exp point he earns he would level up to what his level should be(or perhaps a class change within the attribute wizard would auto level him?). And if he didn't have enough exp for the level of his new class he would simply have to earn enough before he levelled. But &&NextLevelNeeded; seems to be calculated on the fly(it changes if you manually adjust &&Experience;), so the engine should be able to handle it.
Does the player forget all the spells that his new class can't cast?
Nope. But he won't be able to cast them. The engine deals with this fine currently. In PoG, I can manually change a player from conjurer to ranger, add a ranger spell, then switch him back to conjurer. If I open up the spell book it will display all the skills. Granted, you will need to place a conditional in the spells to see if the player is of the class that should be able to cast the spells. But the engine will keep track of what the player knows.
What if he switches back later on?
Again, no problems. He already keeps the skills he had so now he can use them.
Obviously an engine could deal with all these possibilities, but I'm guessing that Dee & Co. probably didn't.
I really fail to see how difficult this would be. Granted, I also don't have a copy of Coldstone's source code in front of me.
But I also don't see how this is any different than anything else within Coldstone. If you change &&Job; and don't do something such as unequip the player, bad things can happen. Just like if you put in a picture of the wrong format then bad things will happen. I like choices and being able to manipulate/change things. And a "variable" like class should be changeable, in my humble opinion.
Yes, a workaround is possible. Frankly it is a lot more work than I wanted to do(though I've already done part of it...grumble). Especially since you can change just about every other bloomin' thing about the character. I guess my biggest complaint here is that if I can set an attribute, I should be able to change that attribute. We can create classes and put the character into that class. But once they are set to that class we can't change it. And that bites.
Despite my complaints/protests, you have helped quite a bit. You gave me some ideas about the working around this limitation that I hadn't thought of already, so I should be able to still do what I want to do. Just with a whole truck load of additional work than I had at first anticipated.
Originally posted by Stark Bledfast: That's what I'm afraid of. I really wish that we would have some more freedom over the things we can do with the engine. /me sighs.
Hey, I agree completely. Though personally I'd be fairly happy if we could just get the current set of known bugs fixed first... cough1.0.2coughneeded*cough
**Then the player will use the new experience table. Just like if you do an Attribute Wizard to auto-set a player's level. You can set a player's level to 10 from 0, when he has no experience points. If you do this then the player will have to earn enough exp to get to level 11 before he levels up again(which will be a lot). I would assume(haven't tested) that if a level 10 guy was set to level 0 but exp was not reset then the next exp point he earns he will level right up to level 10. The same would hold true for a class change. The engine, one would assume, would start looking at the new class exp table. And if the player was way over the experience for his level then the next exp point he earns he would level up to what his level should be(or perhaps a class change within the attribute wizard would auto level him?). And if he didn't have enough exp for the level of his new class he would simply have to earn enough before he levelled. But &&NextLevelNeeded; seems to be calculated on the fly(it changes if you manually adjust &&Experience;), so the engine should be able to handle it. **
I'm not entirely certain I'm understanding your proposal here, so I'm going to look at it as being done from all the different directions I can think of. Please do correct me if I'm completely wrong.
Method 1. The player is a level 10 ranger when he changes classes to conjurer. He becomes a level 0 conjurer but with all the experience that he had previously had. The next monster he kills, he advances all the way to being a level 10 conjurer and gains all the abilities, spells, and magic points that he would normally gain. Problem with this method: For the cost of becoming a level 10 ranger, he now has the stats, hit points, and abilities of a 10th level ranger and a tenth level conjurer, effectively being a 20th level character for the same cost.
Method 2. The player is a level 10 ranger when he changes classes, becoming a 10th level "conjurer" with 10 levels worth of ranger abilities. When he advances to 11th level, he gains the 11th level as a conjurer and develops its skills and abilities. This avoids the "level doubling" problem of method 1. Problem: The player never does develop the 1st through 10th level conjurer abilities, plus it (IMHO) doesn't really make sense for the character to "start" as an 11th level conjurer without working his way up through the conjuring ranks separately.
Method 3. The player is a level 10 ranger when he changes classes, becoming a zeroth level conjurer with zero experience. He retains his ranger abilities and stats, but his ranger experience gets shuffled off into a separate global variable. (If it were just cleared, then if he switched back to being a ranger again, he'd have to start from zero experience again in that class, which doesn't make sense.) This is the only method that would allow fully separate advancement in each class that the player has, but the downside is that you essentially need the engine to have functionality to store experience points for each possible class separately and auto-switch between them when &&Job; is changed. Not a huge problem, but it would need to be coded for.
In PoG, I can manually change a player from conjurer to ranger, add a ranger spell, then switch him back to conjurer. If I open up the spell book it will display all the skills.
Is this a theoretical example, or have you actually done this? If the latter, how do you change the player from conjurer to ranger if you can't in fact change &&Job;?
Originally posted by Glenn: Is this a theoretical example, or have you actually done this? If the latter, how do you change the player from conjurer to ranger if you can't in fact change &&Job;?
Already done...
In the trinity add-on, &&Job; is set when they choose their class at the beginning(an engine-handled task as I understand it... if you have a plug-in that creates a new class it will automatically be an option at character creation).
HOWEVER,
Trinity also defines a variable &&gb;_pg_PlayerClass that sets the player's class(0 being swordsman, 1 being ranger, 2 being conjurer). When you open the spell book or cast a spell it checks this variable and if it is 0 it won't allow the book to be open nor a spell to be cast(because a swordsman has nothing to do with those). Also, all the guilds work off of the PlayerClass variable instead of an &&Job; check, which quite honestly confuses me.
So anyways, I created a plug-in that changes the player's class and I had to utilize the PlayerClass variable to do so. I can easily switch the animation for the player, and the PlayerClass variable makes Trinity think the player is of that class, as far as spells/skills are concerned. But experience tables are still utilized based on their original class, as does level triggered events, weapon/armor equipping, etc.
So the end result is I can fake it to a point, but it isn't anywhere near as perfect as it would be if I could change &&Job.;
This is the method I envision.
However, I don't think that the engine needs to control the shuffling of current experience over, or storing things into globals, etc. Let the designer do that. All the engine should have to do is switch the &&Job; variable and load the new experience tables/class-specific tables for the new class. When the next point of experience is gained the engine will do as it always does: looks at current experience points and check that against his next level. If he has more exp than his next level requires then he is levelled. If not he does not level up.
The designer should be given the freedom and the responsibility to set everything else up. In my case I set up globals to save the characters level and experience points for the class that he is leaving, then switch the class and reset the level and experience points to the class that he is switching to(if they were different than 0/0).
This flexibility would allow latteral shifts to/from classes(ie, going from a 10th level swordsman to a 10th level knight) with keeping exp points, changing to a preset class/level(ie, switching a 10th level swordsman to a 5th level paladin), or completely starting a new class(switching from a 10th level swordsman to a 1st level conjurer). It would be up to the designer to figure out how to set things up, which would give us more flexibility. And if we screw it up it would be the same thing as what happens now when we screw up: it doesn't work!
This make sense? I kind of started rambling in there... hehe
Sounds fair to me. All you gotta do now is convince Dee to add it in to the engine.