Archived copy of war3source.com, the War3Source forum (2009–2020), rebuilt from the Internet Archive by wc3mods.net. This page was captured on 2013-06-05 (original capture). Forum · All archived topics · Wiki · Bug tracker · Blog
Chat

War3:Source
June 05, 2013, 03:31:13 PM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Download: http://ci.0xf.org/
What is War3Source?: http://war3source.com/index.php?topic=200.0
War3Source GIT repo: https://github.com/War3Source/War3Source
War3Source servers: http://www.game-monitor.com/search.php?vars=war3_version=
 
   Home   Help Search Login Register  
Pages: [1]
  Print  
Author Topic: A few feature suggestions  (Read 105 times)
Glider⠠⠵
Global Moderator
Sr. Member
*****
Posts: 491


⠠⠵


View Profile
« on: May 22, 2013, 01:06:35 PM »

Just throwing out some ideas for feedback. If there's some actual interest in these I might implement them.

Recipe Engine

Basically a engine that lets you register recipes that work like the ones in DOTA. They're items that can't be purchased normally, you have to buy the necessary items to craft them. Some recipes will grant you the item automatically, removing the old ones, while for others you need to buy a explicit recipe along with the items. I think this would work well in TF2 with a few tweaks to shop items in general, including a option to hold onto items longer than one life. What I mean by this is that shopitems could be held for a whole round. This along with some price adjustments and a item limit of 6 could make for some interesting rounds, with your team getting angry at you for feeding that Heavy who will carry the cart by the end ;-).
For Counter-Strike games this might work if the items are held for a whole map instead of a whole round, but I'm primarily focused on TF2.

Quest Engine

This would let you register different kind of quests for players to do. We could have dailies/weeklies/roundlies/maplies (huehue), etc. that can be repeated in certain time intervals aswell as quests that are specific to some conditions. For example when you play Undead Scourge you might have access to a quest that involves blowing up 3 people with your ultimate in one go. Think of this as sort of a achievement system. We could use this to limit access to certain things (races/items) based on somebodys quest progress aswell as using quests as a way to aide players in using a race - the Undead example promoting a clever use of your suicide bomb Wink. We could have leaderboards for players to show off that they did lots of quests and similiar. Races can implement a "if quest <X> was done then do <Y>" sorta thing, for example attaching a particle effect when you've unlocked all quests this race has to offer. Same could go for unlocking skills.

HTML motd

How do people feel about the HTML motd? I've seen Mecha use the MOTD extensivly on his servers. You type a command into chat and the MOTD opens up with his site where you log in with your Steam account using OpenID and can then do stuff like purchase premium items from his shop and equip them on your classes. How do people feel about moving away from the menu interface we currently have towards a HTML one? Obviously players that have it disabled would not benefit (and for those we might even have to retain backwards compatibility) and server owners would need a webserver to host the HTML content.
Logged

Necavi
Sr. Member
****
Posts: 336


View Profile
« Reply #1 on: May 22, 2013, 01:17:30 PM »

I believe that the recipe engine should be ENTIRELY config-based, it should require no code to add/remove recipes. As a related item, we should also add a config to create simple items (most of the built-in items), such as +damage, +health, etc.
Logged

Glider⠠⠵
Global Moderator
Sr. Member
*****
Posts: 491


⠠⠵


View Profile
« Reply #2 on: May 22, 2013, 01:24:51 PM »

To elaborate (for everyone not involved in our Steam chat Grin)

We'd have a new War3Source_Items.cfg that could look like this


Code:
{
    "item" "boot"        // item shortname like we're used to
    "lost_upon" "dying"  // some kind of flag
    "gold_cost" "5"      // war3source money cost
    "money_cost" "250"   // counter strike / tf2 mvm money cost

    "buff"                  // a buff this item gives
    {
        "name" "fMaxSpeed"  // buff name, pain to map to our enum >_>
        "value" "1.2"       // the value of the buff
    }
}

Throw in a little parser and you got boots of speed coming from a cfg file. Now server owners can add simple items to the server without knowledge of SourcePawn. The effort to implement this would greatly be reduced after I'm finished redesigning the way buffs work. Right now we'd have to cobble up something to map the Strings to the buff enum and then maintain it whenever buffs are changed Wink
« Last Edit: May 22, 2013, 01:31:53 PM by Glider⠠⠵ » Logged

Remy Lebeau
Full Member
***
Posts: 204


View Profile
« Reply #3 on: May 26, 2013, 08:53:53 PM »

The obvious limitations of the config based item system are:

a) restricted to the existing "buffs"
b) the writer of the config file actually needs to know what those "buffs" are (and the appropriate way to code them).

To my mind it's not worth the effort of setting up a config parsing system that can only create items for the .inc buffs, we might as well just create an item in the code for each of them, and then use a config to enable them or not :-S
Logged
Glider⠠⠵
Global Moderator
Sr. Member
*****
Posts: 491


⠠⠵


View Profile
« Reply #4 on: May 26, 2013, 11:12:20 PM »

Both of those limitations are overcome with documentation  Cheesy
Logged

Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!