EQEmulator Forums - Quest flags for 5.2

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)

- Archive::Quests (https://www.eqemulator.org/forums/forumdisplay.php?f=624)

- - Quest flags for 5.2 (https://www.eqemulator.org/forums/showthread.php?t=11765)

Quote:

Originally Posted by Scorpious2k

Quote:

Originally Posted by Eglin

But.... what if I want to create a situation where, say, a pc is flagged for killing a townie and the default quest would check a given flag under some circumstances?

The appropriate thing to use in this case would be factions. IMO, this feature has no place in in a default quest.

Factions have a whole lot of baggage, though. For one thing, setting faction affects the way that a mob cons to an individual, which may be an unwanted side-effect.

Quote:

How do I set it up so that everyone in the plane of love is extra nice if you've been to the plane of destiny before?

Factions again.

Again, I don't think so. In the generic example of "be extra nice" you don't see the full ramifications of confusing faction with an arbitrary tag, so I will present another example. What if I want to have a quest that makes a victor into, say, the evil taxman of qeynos. The evil taxman can tell any npc to fork over some cash and they have to comply. The taxman can still kill denizens (to the detriment of his finances, perhaps) or kill their enemies to change his faction with them, although that won't necessarily have any bearing on his status as the evil taxman. One has nothing to do with the other. You say above that such features have no place in default quests, but I beg to differ. Regardless of how you implement it, it is going to require that a large number of npcs have access to the db vars which in turn means that you are going to be making all of those db queries every time you enter the event loop which is, like I said above, unacceptable.

Quote:

How, in general, do we know from a script whether or not we have access to player flags, if not all scripts would?

It's a matter of design.

That is exactly why I thought it deserved discussion. Why alter the semantics of scripting? Why should a command to check pc flags work from some scripts and not others?

Quote:

If you need it, then you set the flag. From the script, you might put a comment in if you are worried about knowing whether or not the feature is used (and can't figure it out when you see the commands used).

In my opinion, this is the narrow view. The alternative is to make a function for querying db vars avaliable to all npcs. The alternative allows us to maintain a consistant API. The alternative allows for more flexible scripting. The alternative runs faster.

Quote:

Granted, the check may prevent unnecessary db access, but it opens up a whole new set of problems instead (or am I still missing something?).

The only problem for some may be that thought and planning has to be done.

Wanna' elaborate on that for me, pal? I can only come up with two or three ways of interpreting that, and I don't particularly like the implications of any of them.

Quote:

i found no sql update in the repository. Should we excpect one, or did i miss something in the posts ? Tark says about quest_globals.sql.

Its in there now, that was my fault.. I missed the changes to 'Release' when I updated...

Quote:

Originally Posted by Eglin

Quote:

Originally Posted by Scorpious2k

The only problem for some may be that thought and planning has to be done.

Wanna' elaborate on that for me, pal? I can only come up with two or three ways of interpreting that, and I don't particularly like the implications of any of them.

What it means is that quest script writing is programming and should be approached as such. It should be thought out and planned.

I think you are taking this discussion personally. So I will move on to other things. The feature is there to be used. People are free to use it or not. They have the right to make something better to replace it. They even have the right to stand by and do nothing but criticize.

Quote:

Originally Posted by Scorpious2k

I think you are taking this discussion personally. So I will move on to other things. The feature is there to be used. People are free to use it or not. They have the right to make something better to replace it. They even have the right to stand by and do nothing but criticize.

To that, I will certainly concede. I will reiterate that I am a pragmatist, realizing that one diff is worth a thousand words and acknowledging that nobody asked my opinion. I'm not sure which of the above groups you're imagining me in, but while I don't allocate much time to working on my baby anymore (which is really just a tiny little portion of the eqemu whole), I do feel compelled to monitor its progress and offer guidance where it is needed.

Thanks for doing the hard yards Scorp. Its good to see the carrot of server wide smarts, dangled by embedded Perl, being realised.

Quote:

Originally Posted by mollymillions

Thanks for doing the hard yards Scorp. Its good to see the carrot of server wide smarts, dangled by embedded Perl, being realised.

I can't believe that nobody else sees this as a kludge.

You guys talkin' a lot ; whatever the issues, hoppefully they will be addressed (is 1 or 2 d's and s's ?)

i've been trying to get this run, and :

there might be a thing in the setglobal code, where duration is arglist[3], and referd to as arglist[2]. This causes wrong expiry result

Quote:

Invalid duration for varname using default

Changed in parser.cpp : 1128

Code:

if (!database.RunQuery(query, MakeAnyLenString(&query,

          "INSERT INTO quest_globals (charid,npcid,zoneid,name,value,expdate) VALUES (%i,%i,%i,'%s','%s',unix_timestamp(now())+%i)",

          qgCharid,qgNpcid,qgZoneid,arglist[0],arglist[1],QGexpdate(arglist[0],arglist[3])

there might be a thing with the insert, where i get

Quote:

setglobal error inserting singer : DBcore::RunQuery: No Result

this does not seem to prevent insertion, but is confusing. Mybe this is an issue, i don't know what dbcore does exactly (and don't plan to check if possible). Any ideas ?

third, but not least :
next time the event is triggered, the variable is not defined (test with 'if defined $varname' returns false) and quest::say("value of varname is " . $varname); prints "value of varname is :". I'm in the tracing of this at the moment. Could it be $quest::varname, or $questNNNN::varname or even $main::varname or ... ?

BTW, when setting a variable, it is not yet available (requires to re-enter the event). Is it possible to modify the setglobal :
** edited **

Code:

"sub setglobal{push(@cmd_queue,{func=>'setglobal',args=>join(',',@_)}); eval "\$".$_[0]."= qw($_[1])";}"

would this work with the embedded parser (mean, it works in striaght perl, but ...) ?

Quote:

Originally Posted by smogo

there might be a thing in the setglobal code, where duration is arglist[3], and referd to as arglist[2]. This causes wrong expiry result

You're right. It's fixed and will be right in the next release. And your fix was exactly right.

Quote:

setglobal error inserting singer : DBcore::RunQuery: No Result

this does not seem to prevent insertion, but is confusing. Mybe this is an issue, i don't know what dbcore does exactly (and don't plan to check if possible). Any ideas ?

I haven't seen that one yet. Not sure what's going on...

Quote:

next time the event is triggered, the variable is not defined (test with 'if defined $varname' returns false) and quest::say("value of varname is " . $varname); prints "value of varname is :". I'm in the tracing of this at the moment. Could it be $quest::varname, or $questNNNN::varname or even $main::varname or ... ?

If you want it to be $varname, you have to set it as

Code:

quest::setglobal("varname",...

Don't include the $ in the name in setglobal. Also make sure the name is a valid perl var name. You can confirm it by checking the db and making sure it is there. name should always be the same as the variable name without the leading $.

Quote:

BTW, when setting a variable, it is not yet available (requires to re-enter the event).

You can always start out saying $varname = "myval"... use it thru the quest, and when you set it say

Code:

quest::setglobal("varname",$varname,...

That way it will be set to the current value (at the time the setglobal is done) for the next event. Maybe do this at the end of the event that initially creates it and each event where it is potentially changed.

at the moment, declaring variables seems to work. But i dont get them in the context when the event is triggered. here is the status of the DB before bootup :

Quote:

+----+--------+-------+--------+---------+--------------+------------+
| id | charid | npcid | zoneid | name | value | expdate |
+----+--------+-------+--------+---------+--------------+------------+
| 30 | 21 | 61 | 1 | tjob | story_teller | 2147483647 |
| 31 | 0 | 61 | 0 | job | singer | 2147483647 |
| 32 | 0 | 2222 | 0 | not_set | undefined_zz | 2147483647 |
| 37 | 0 | 61 | 1 | tjob | singer | 2147483647 |
+----+--------+-------+--------+---------+--------------+------------+

well, charid does not seem to work (thus 0 in char_id second line), but that should not prevent global to work.

There might be an issue with the qglobal member of the Mob class, as the code in parser.cpp / Parser::Event around line 313 is not entered. This member is set asynchrounsly ? Could you tell me what to check ?

At the moment, i never get a variable set, nor charid. =(

Quote:

Originally Posted by smogo

at the moment, declaring variables seems to work. But i dont get them in the context when the event is triggered.

A thought occurred to me about this. You realize you have to give the npc permission to receive the global variable. The qglobal flag in npc_types has to be 1 or the npc will NOT get the variables no matter what is in the quest_globals table. Naturally, if you change the value in npc_types you have to restart the server for it to take affect.

Quote:

well, charid does not seem to work (thus 0 in char_id second line)

charid can be 0, as can zone and npcid. 0 means "all". So if you set the options to allow this variable to be used by this npc for all players, the charid would be 0, npcid would be the npcid. Zero in zoneid means you are sharing this variable wroldwide.

Tark posted the list of options and what they mean in his message "coming soon" where he announced it.

Quote:

There might be an issue with the qglobal member of the Mob class, as the code in parser.cpp / Parser::Event around line 313 is not entered.

This is probably the qglobal flag I mentioned above.

Quote:

At the moment, i never get a variable set, nor charid. =(

Hope there's something here to help.

you where right about the qglobal flag in the DB, it was clear.

i set it, restarted, but sill it goes wrong. I trace it, and when entering Event() with :

Code:

 if(npcid==61){

      LogFile->write(EQEMuLog::Debug, "entre npc quest with id 61");

      LogFile->write(EQEMuLog::Debug, "qglobal flag is :%d", 

npcmob->GetQglobal());

}

i get

Quote:

logs/qeynos.log:[Debug] qglobal flag is :0
logs/qeynos.log:[Debug] qglobal flag is :0
logs/qeynos.log:[Debug] qglobal flag is :0
logs/qeynos.log:[Debug] qglobal flag is :0

while

Quote:

Also, $charid is still "". The (npcmob->GetQglobal()) must have returned false...[/quote]

You shut down both te world server and all zone servers before restarting?

*looking at the code now*

yes, i've been shutting down everything serverside, then start and login again. Takes a while :evil:

Quote:

Originally Posted by smogo

yes, i've been shutting down everything serverside, then start and login again. Takes a while :evil:

I know... it gets frustrating.

thanks for your time, anyway. i hope we can get a solution.