Task Priority

[Cadimiom]

This is a list of tasks, looking for votes on priority of which should be in the emulator. I honestly wish there was a ranking poll system in PHPBB but this will have to do.. Some topics had to be combined as well since the limit of poll options.

[techguy84]

I dont think LE is starting from scratch, so some of the above have already be implemented i think. Some are givens as you couldnt really enjoy the game without the, like combat and questing. Minor ones like guild stuff can be worked in down the road once there is a player base for them.

[Tarzok]

Actually, it's my understanding that none of the above has been implemented. The only version of the EQ2 Emulator that I saw was back in 2005, and it only had basic movement and interaction.
Combat system should be a priority, followed by stuff like scripting, aggro, loot, and groups/guilds. Stuff like tradeskills, collecting, and weather are just icing on the cake (could anyone else go for a cake right now?). But hey, that's just my opinion. You guys could see it differently.
... and yeah, phpBB could use cooler polls. Oh well.

[ZexisStryfe]

While I don't know how much LE has completed, it does seem as if there is at least basic quest functionality. If you look at the screenshots, you see he has a quest to kill someone with a spoon. I don't know if any more than that is implemented, but it seems a good start. While we are on the subject, does anyone know if quest scripting going to be handled with PerlScript like it was in EQEmu?

[Tarzok]

While I don't know how much LE has completed, it does seem as if there is at least basic quest functionality. If you look at the screenshots, you see he has a quest to kill someone with a spoon. I don't know if any more than that is implemented, but it seems a good start. While we are on the subject, does anyone know if quest scripting going to be handled with PerlScript like it was in EQEmu?

Those screenshots are a couple years old when all is said and done. I could be wrong, and Lethal or someone will have to speak to this, but I don't believe that the "kill Graven Tralk with a spoon " necessarily reflects a functioning quest system. It was my impression that was more of a place-holder, though I could be wrong- at the most, not much more than that was implemented. It was a very basic emulator. A lot of things have changed in the last couple years as well, so there will be some catchup to do in the first place.
As far as quest scripting goes, LethalEncounter will have to answer to that as we get going.

[SAweb]

In my opinion all scripting should be done in an outside module, seperate from the world module.
-PerlScript seems a bit outdated, I think c++ would do just fine.
-LE will try to pay more attention to detail this time.
Cheers

[ZexisStryfe]

I have to say, as someone who only knows a wee bit about programming, Perlscript was the only major stumbling block I had with EQEmu. Even now, while I have a basic grasp of it, I still don't have it all figured out. It would be nice if there was an easier way of doing it in EQ2Emu.
The quest system in EQ2 is much more robust (ie- complicated) than the one in EQ1 and I think it would do the emulator good if we could find a way to have it so one does not need to be a programmer to generate quests. After all, not all EQ/EQ2 fans are programmers. I am not sure if it is possible to create an outside utility to do something like this (like the item and spell creators for EQEmu) since it is actual code generation instead of just data manipulation, but if we could make it so one could be created, I think that would help out immensely.
One of the major stumbling blocks with EQEmu, in my opinion, is that you need to basically be in IT or have great knowledge about the field in order to run it properly and set up a functioning world. Everything we can do to make it easier on potential admins who set up their own minilogins and screw around will potentially broaden EQ2Emu's exposure in the emulator community.
Just my 2 cp though...

[Secrets]

I have to say, as someone who only knows a wee bit about programming, Perlscript was the only major stumbling block I had with EQEmu. Even now, while I have a basic grasp of it, I still don't have it all figured out. It would be nice if there was an easier way of doing it in EQ2Emu.
The quest system in EQ2 is much more robust (ie- complicated) than the one in EQ1 and I think it would do the emulator good if we could find a way to have it so one does not need to be a programmer to generate quests. After all, not all EQ/EQ2 fans are programmers. I am not sure if it is possible to create an outside utility to do something like this (like the item and spell creators for EQEmu) since it is actual code generation instead of just data manipulation, but if we could make it so one could be created, I think that would help out immensely.
One of the major stumbling blocks with EQEmu, in my opinion, is that you need to basically be in IT or have great knowledge about the field in order to run it properly and set up a functioning world. Everything we can do to make it easier on potential admins who set up their own minilogins and screw around will potentially broaden EQ2Emu's exposure in the emulator community.
Just my 2 cp though...

With only basic C++, I was able to decipher perl. Although i'd like to have a nice GUI for making quests, it just isn't that easy to make a program that does just that.
A computer does what it is told, you can't just feed it thoughts and expect it to do exactly what you want it.
If you tell it what to do in detail (perl) it can understand it easier, and you can understand in full detail what a quest does.
I'm a guy who likes to see how something works and why.
If you gave someone a nifty GUI to make quests, that would be great. Just keep the perl in there as a main thing.
Basically, what I am saying is it would feel like a closed source project when you'd get all updates from a tool you work with that has to be updated for the whole community to use.
It's a painstaking process for one person; if that process can be simplified for many people to use it while keeping stress off of another, then i'd go for that.

[ZexisStryfe]

I definately understand it wouldn't be easy to make such a thing. I am in much the same boat as you. I understand a very limited about of C++, and was able to decipher perl after going over several of the existent perl quest scripts. However, if such a tool were to exist, I think it would allow a broader base of users to set up servers, which would only be good for the emulator. More exposure.
I don't believe such a tool makes the project feel closed source however. I understand there are alot of people like you out there who like to "see how it works" as it were. Personally, I would see no problem with having the ability to code it yourself, or use the "quest tool" if you don't know how to code. I think that should appease everyone.
Again, I don't even know if such a thing is possible. In my knowledge, having one program generate code properly for another is not an easy task, if even possible (I could be way off, my last programming class was... um... 10 years ago, and is was just an intro to C). I am just stating that something like that would be handy.

[Secrets]

I definately understand it wouldn't be easy to make such a thing. I am in much the same boat as you. I understand a very limited about of C++, and was able to decipher perl after going over several of the existent perl quest scripts. However, if such a tool were to exist, I think it would allow a broader base of users to set up servers, which would only be good for the emulator. More exposure.
I don't believe such a tool makes the project feel closed source however. I understand there are alot of people like you out there who like to "see how it works" as it were. Personally, I would see no problem with having the ability to code it yourself, or use the "quest tool" if you don't know how to code. I think that should appease everyone.
Again, I don't even know if such a thing is possible. In my knowledge, having one program generate code properly for another is not an easy task, if even possible (I could be way off, my last programming class was... um... 10 years ago, and is was just an intro to C). I am just stating that something like that would be handy.

I agree there. It's a great idea. It gives those who have no idea how to program a chance, and gives it more of an 'open door' feeling to those who want to run a server.
However, my only concern is that it won't be possible to make it easily. Of course, nothing's impossible, it just takes time.
Keep the ideas coming

[ZexisStryfe]

Well, if we have anything in abundance at this point, I do believe time is one of them.

[techguy84]

One of these "programs" could be done in theroy. Have like a set list of options that are normal to the eq2 questing, like kill this, go here, kill that, and then kill 10 of those and bring back this. For each command its generalized, like the kill command, and then you could select a list of possible mobs and npcs from the DB that would be pluged in via its db name. You could make them in steps, or possible make some templates that could be loaded up and attached to a character of your choosing.
Doing perl is nothing more than writing the script, saving it to the write location and then starting the zone at which the NPC who gives that quest is available right?. You have Wysiwyg editors for html and such that just take a speific funcition and put it into code, same would apply here as all you need is the code set attached to each button you push. You could also have a little window to the side that shows the code as it goes in for the meat of it. Making it pull information from a DB shouldnt be that hard, as there are tons of programs that do such things. Hell, if we could even make it all DB based that would be even better. Everything in one little package.
/dreams......

[SAweb]

One of these "programs" could be done in theroy. Have like a set list of options that are normal to the eq2 questing, like kill this, go here, kill that, and then kill 10 of those and bring back this. For each command its generalized, like the kill command, and then you could select a list of possible mobs and npcs from the DB that would be pluged in via its db name. You could make them in steps, or possible make some templates that could be loaded up and attached to a character of your choosing.
Doing perl is nothing more than writing the script, saving it to the write location and then starting the zone at which the NPC who gives that quest is available right?. You have Wysiwyg editors for html and such that just take a speific funcition and put it into code, same would apply here as all you need is the code set attached to each button you push. You could also have a little window to the side that shows the code as it goes in for the meat of it. Making it pull information from a DB shouldnt be that hard, as there are tons of programs that do such things. Hell, if we could even make it all DB based that would be even better. Everything in one little package.
/dreams......

I think that it would be easier to write a quest controller type of application via php, and it would be much easier to test/develop if quest lines were database oriented , with the ability to add a c++ script for some more complicated ones.
Simple kill X amount of X quests can all be db related, as they use mostly the same code.
But if you need to complete a complicated quest line, eg. collect 5 pebles and activate them on the shrine of . . . .etc , then a script defined in the db could be executed. (just my proposal)
Lets have a look at some other object server's quest DB structure, which in my opinion looks pretty good for our needs.

Code: Select all

entry
OnlyZone
MinLevel
QuestLevel
Type
RequiredRaces
RequiredSkillValue
RequiredRepFaction
RequiredRepValue
SuggestedPlayers
LimitTime
SpecialFlags
PrevQuestId
NextQuestId
ExclusiveGroup
NextQuestInChain
SrcItemId
SrcItemCount
SrcSpell
Title
Details
Objectives
OfferRewardText
RequestItemsText
EndText
ObjectiveText1
ObjectiveText2
ObjectiveText3
ObjectiveText4
ReqItemId1
ReqItemId2
ReqItemId3
ReqItemId4
ReqItemCount1
ReqItemCount2
ReqItemCount3
ReqItemCount4
ReqSourceId1
ReqSourceId2
ReqSourceId3
ReqSourceId4
ReqSourceCount1
ReqSourceCount2
ReqSourceCount3
ReqSourceCount4
ReqSourceRef1
ReqSourceRef2
ReqSourceRef3
ReqSourceRef4
ReqCreatureOrGOId1
ReqCreatureOrGOId2
ReqCreatureOrGOId3
ReqCreatureOrGOId4
ReqCreatureOrGOCount1
ReqCreatureOrGOCount2
ReqCreatureOrGOCount3
ReqCreatureOrGOCount4
ReqSpellCast1
ReqSpellCast2
ReqSpellCast3
ReqSpellCast4
RewChoiceItemId1
RewChoiceItemId2
RewChoiceItemId3
RewChoiceItemId4
RewChoiceItemId5
RewChoiceItemId6
RewChoiceItemCount1
RewChoiceItemCount2
RewChoiceItemCount3
RewChoiceItemCount4
RewChoiceItemCount5
RewChoiceItemCount6
RewItemId1
RewItemId2
RewItemId3
RewItemId4
RewItemCount1
RewItemCount2
RewItemCount3
RewItemCount4
RewRepFaction1
RewRepFaction2
RewRepFaction3
RewRepFaction4
RewRepFaction5
RewRepValue1
RewRepValue2
RewRepValue3
RewRepValue4
RewRepValue5
RewOrReqMoney
RewXpOrMoney
RewSpell
PointMapId
PointX
PointY
PointOpt
DetailsEmote1
DetailsEmote2
DetailsEmote3
DetailsEmote4
IncompleteEmote
CompleteEmote
OfferRewardEmote1
OfferRewardEmote2
OfferRewardEmote3
OfferRewardEmote4
UseScript
StartScriptEvent
CompleteScriptEvent
Repeatable

Note the "UseScript , StartScriptEvent and CompleteScriptEvent" fields.
The overall plus is that quests should be able to change without the need for a core recompile or extensive perl knowledge, and it would be easy to write tools to change/create via PHP and dump quests from live servers.
Just my 10c

[Diamente]

I agree that questing should be a priority, but definitely not at the sacrifice of the combat system (why have a quest to kill something if you can't?)
As far as a "program" for creating quests, it is definitely something very doable (in my opinion). Depending on what route LE and the other developers want to take, Perl or C++ or another language, an interface can be derived to communicate directly with the database to get the objectIDs and such for whatever it was you wanted to track (kills, harvests, etc.) and then have a menu system built off of that. Of course this is all talk from me at the moment since I haven't actually tried to do anything with it, but I look forward to the chance to play with it and see what can be done I'm sure there is a very good reason the quest systems in the major MMOs are based on scripted languages, so there wouldn't be any harm in keeping the final output as a Perl (or whatever) script, just have the language of the "program" write out the data you want as a Perl script and there ya go.
Overall I am *VERY* excited about this project, and look forward to the great work that comes out of it from everyone involved!

[techguy84]

Well, after looking over this poll, I have come up with a conclusion, based on opinion only.
The emu is going to be in beta all the way up until RoK. This gives the developers plenty of time to sort out certain aspects of the game. Some of these are givens. Things like combat. Combat will be implemented by th time of the first public release. It may not be perfect, but it will be there, and then they tweak it as we go along.
Questing will be there more than likely, but its going ot be in perl like EQEmu.
Guild systems may be somewhat put in, but may lack some features.
Looting and factions will be implemented, but probably not perfect.
You kinda see where this is going right? Most stuff will more than likely be there to use, but it wont be perfect spot on LIVE. Anything that is content based is going to be the tricky part as the devs cant gather all the information themeselves on this front.
This all of course is opinion, but given the time frame and the amount that has alreaday been accomplished, i forsee a great future for the project at release of RoK.