Re: Settings.lua

[PrBlahBlahtson]

So there's a lot of stuff in settings.lua that doesn't actually function right now. I've started working on making some of it work (spawn with event items for now), but I'm curious if I should bother with too much of it.

Example:

Code: Select all

CURE_POWER  = 1.000; --Multiplies amount healed from Healing Magic, including the relevant Blue Magic.
SPELL_POWER = 1.000; --Multiplies damage dealt by Elemental and Divine Magic.
BLUE_POWER  = 1.000; --Multiplies damage dealt by most Blue Magic.
DRAIN_POWER = 1.000; --Multiplies amount drained by Drain, Aspir, and relevant Blue Magic spells.
ITEM_POWER  = 1.000; --Multiplies the effect of items such as Potions and Ethers.
WEAPON_SKILL_POWER  = 1.000; --Multiplies damage dealt by Weapon Skills.
WEAPON_SKILL_POINTS = 1.000; --Multiplies points earned during weapon unlocking.

I can think of ways to make some of those work off the top of my head, but at the same time I'm not sure if that's desired, so I thought I'd ask.

Edit:
Just for clarification, those are pre-existing options. All I've added so far is events, and ALL_MAPS

Sneaking in an edit to give rough status, just in case someone else is working on anything related. As of 10/13/12:
INITIAL_LEVEL_CAP, MAX_LEVEL, START_GIL: No change, already functional
START_INVENTORY: Now functional at login, works for values > 30.
OPENING_CUTSCENE: No change, already functional
SUBJOB_QUEST_LEVEL: Now unlocks subjob at creation if set to 0, per comment. Already functional otherwise.
ADVANCED_JOB_LEVEL: Now unlocks jobs at creation if set to 0, per comment. Added to all quests not already using it. For quests with prerequisites (ex: BST), those quests will require their default level or ADVANCED_JOB_LEVEL, whichever is lower. Tested with a Level 2 character. Quests should have no level requirement if 0, although by-passing quests if set to 0 could be done.
ALL_MAPS: Now functional

SHOP_PRICE: No change, already functional
GIL_RATE: No change, already functional. Not verified to be active on all quests.
EXP_RATE: Now functional, may need a rename (FOV related, per comment)
TABS_RATE: Now functional
SAN_FAME, BAS_FAME, WIN_FAME, NORG_FAME: Already functional, not verified to be in use for all quests. Jeuno region is also valid, and adds to all three starting regions in the core. Uncertain how to handle that. Leaving aside for now. Should be addressed.

Guild points: Feature not yet implemented. I think.

CURE_POWER: No change, already functional
SPELL_POWER: Multiple spells this shouldn't apply to use finalMagicAdjustment, so it will probably have to be implemented in each spell individually. Time consuming, but easy.
DRAIN_POWER: See above
ITEM_POWER: Need to investigate, probably has to be done on an individual level
WEAPON_SKILL_POWER: Need to investigate, but can probably slip it into weaponskills.lua
WEAPON_SKILL_POINTS: Unsure if these quests are implemented.

Gathering rates: No change, already functional

Coffers: Barring exceptions, appears to already be in place. Need to check all chests/coffers.

WSNM_LEVEL, WSNM_SKILL_LEVEL: Unsure if these are implemented
AF quests/fame: Not all quests are implemented. Have seen some quests already using these values.
DEBUG_MODE: Function for this is written, just needs to be added to a global and then to quests.
QM_RESET_TIME: Will need to investigate

REGIME_WAIT: Need to investigate, seems non-functional, someone was poking fieldsofvalor.lua...
FIELD_MANUALS: Believe already implemented, should test though.
LOW_LEVEL_REGIME: Need to investigate

Job ability settings: Pretty much all need to be investigated

Spell specific settings: Oh dear...

Celebrations: Need to investigate moogle settings. Added some events, all will add their items on creation if enabled.

Misc: Need to investigate, should be simple enough.

[whasf]

I think it's a good idea, at least remove them from the file if they're not implemented.

[PrBlahBlahtson]

That was kind of my thinking. The file needs to be cleaned up, and the first logical question seemed to be "what works, or can be made to work?"

If I encounter any head scratchers, I'll bring them up either for ideas or for removal by a dev. For example, I'm not sure if harvesting rates can be manipulated in LUA, or WSNM options, or chest/coffer illusion, etc. It gives me something to chip at and be productive for a while.

Edit:
Changed my mind, although DEBUG_MODE is a good question to raise. It would be the last thing I touch, if no one else does it.

[whasf]

This weekend I am going to go over that list I am compiling with what we need to do to get Zilart done. I will be posting about some items that people can work on and contribute (if they so wish) to help us reach that goal so we can get beyond Zilart.

[PrBlahBlahtson]

I don't want to spam the forums with patches, so I'll wait until I have something significant to offer. I'd done so much to server.lua tonight that I wanted to make sure I'm not doing something horribly wrong, though. It's a lot of stuff happening on creation, and > 100 new lines of code.

All I've really checked is the first "block" above the rate modifiers, and the "start with event gear" options near the bottom. Because there's an option to add the 2012 swimsuits (not in the trunk yet,) I included that in the patch as well if anyone wants to go testing. I also tried to optimize some of server.lua, since it was using a lot of player:getRace(). Optimization will continue whenever I find those problems.

I thought about making a function to retrieve the player's gender, or going the "if race == ... then gender = " route. I can make that happen, if it's preferred.

Surprisingly, MAX_LEVEL, SUBJOB_QUEST_LEVEL, and START_INVENTORY were already accounted for in the quest design, so all I had to do was have them impact new characters. Lucky break, there. I made MAX_LEVEL a bit clearer in the comment.

Edit:
Just realized that ADVANCED_JOB_QUEST was in there. That hasn't been implemented on quests. Mainly I wanted to be sure those changes to server.lua were kosher, or if anyone had a method that was less unwieldy they'd prefer instead. Just crossed my mind that there may be solutions using an array/bitmask.

server.lua.patch

(19.82 KiB) Downloaded 355 times

Edit 2:
Avoiding a double post. Hit a bit of a head scratcher tonight. addFame(region,amount) will accept Jeuno/3 as a region, and then the fame is added to all three regions in the core rather than in LUA, so settings.lua really can't touch that. The usual method in scripts seems to look like player:addFame(BASTOK,BAS_FAME*30).

It seems like there's six possible solutions:

• Discontinue use of Jeuno as a fame region, and convert quests as they're found, which adds 2 addFame lines to any quest using Jeuno fame.
• No fame multipliers, which means they'll have to be removed from any scripts that use them, and quite a few do.
• Fame multipliers are moved to the core at some point, which involves cleaning them out of the scripts eventually to avoid double-enhancement.
• A Jeuno fame multiplier, I guess?
• Adding a code snippet that checks which region has the highest multiplier and applying that one, so that all regions are multiplied
• Meh, who cares? Doesn't hurt much

Edit 3:
Oh, and some of these quests never had level requirements, such as Ranger in Windurst Woods/Perih Vashai. This has been a good time.

[PrBlahBlahtson]

May have come up with a nifty way to do DEBUG_MODE. Need to test it out and see if the theory will actually work. A common function along the lines of getNPCbyID(number) -> npc:getZone, getPos_x, etc, player:move(zone, x, y, z). Then all that would be needed in the quest actions is onEventFinish, if DEBUG_MODE == 1, function(next npc's id). Pretty simple for anyone to implement; all they need to do is get the next NPC's ID.

Could also use input on what to do with <area>_FAME because of Jeuno, and whether or not the changes to settings.lua in that patch are alright. They get the job done and passed a simple bug check, but I'm not so sure they're efficient enough to pass muster.

Edit:
And built. I'm quite happy with how much easier this would make DEBUG_MODE. Not sure if it's best to put the "if DEBUG_MODE == 1" in the NPC code, or in the function.

Code: Select all

function debugTeleport(player,npcid)
	local npc = GetNPCByID(npcid);
	if npc ~= nil then
		local pos = {npc:getXPos(), npc:getYPos(), npc:getZPos(), npc:getZone()};
		player:setPos(pos[1], pos[2], pos[3], 0, pos[4]);
	end
end;

Where would be the best place for such a thing? common? quests?

[diatanato]

Code: Select all

function debugTeleport(player,npcid)
   local npc = GetNPCByID(npcid);
   if (npc ~= nil) then
      player:setPos(npc:getXPos(), npc:getYPos(), npc:getZPos(), 0,npc:getZone());
   end
end;

[PrBlahBlahtson]

Will do

[diatanato]

Where would be the best place for such a thing? common? quests?

teleports.lua

[Metalfiiish]

There seems to be alot of work being done on this, I would hate to see it become obsolete from future revisions. Any other dev's agree on adding this to svn?