Epoque

Community Contributors
  • Content count

    89
  • Joined

  • Last visited

  • Days Won

    4

Epoque last won the day on May 10 2012

Epoque had the most liked content!

Community Reputation

105 Excellent

About Epoque

  • Rank
    Santa Poring
  • Birthday 08/20/90

Profile Information

  • Gender
    Male
  • Location
    Manchester, UK

Recent Profile Visitors

4227 profile views
  1. Welcome! - from a fellow UK citizen
  2. Thanks it took a lot of time to get things right, it was originally designed for a Invasion type event, but I lost the code a long time ago, so instead I thought I'd release the map and let the fellow scripts and programmers have a bash at creating their own events!
  3. File Name: Fortress Map File Submitter: Epoque File Submitted: 30 Mar 2013 File Category: Maps & 3D Resources Video: Content Author: Epoque Fortress Map Created by and copyright to Epoque; for you. The Fortress Map is a special area designed for player to player combat at the forefront of usage, while maintaining the beautiful Gravity nature of design, lighting and texture detail. The map contains multiple special areas that players can congregate at, and has been specifically designed for maximum battling effectiveness. The Fortress itself has several areas of penetration. Each section of the Fortress has been designed so that a player base (party, guild or other) can defend a specific point, while an attacking base can try and break through. The map opens up the possibility to hundreds of different outcomes, and offers plenty of room for expansion and customisation. However, my own words will not describe the potentials of the map. Instead, view through the screenshots or watch the video for more information on the dimensions of the map. Click here to download this file
  4. Correct, it's useful for tables which harbour large amounts of data, and are read from/written to frequently. The major advantage, or usage, of converting the tables to InnoDB is for when external applications attempt to access the tables at the same time as the server executables are active. Otherwise, because the executables are non-threaded and all commands are executed linearly, there's not much reason to convert them to InnoDB by default since our executables don't require them to be so (there's not really any instances where table-level locking interferes with the flow of the executables, without external applications accessing the data.) It's recommended for when a server is accessing the logs frequently (control panels, custom administration searches etc.) but not much benefit for the executables alone.
  5. Agreed, I can potentially see the use of allowing a character ID property in the # command, but implementing a new command altogether seems a bit of overkill. It'd be more efficient to allow integers (such as #item 123456 501 1) in-place of character IDs, and when the character has a name of explicitly numeric values, detect whether the entered integer has quotation marks around it. IE: character named 1234, #item 1234 501 1 would fail, however #item "1234" 501 1 would work.
  6. Recommended for a public download, it's useful for retrieving the IP address without the need of an SQL table look-up (given a lot of servers probably run on MyISAM tables, SQL table look-ups would probably be extremely resource intensive), however it's probably not relevant enough to commit as an official script command though. Nice command though.
  7. Um, why would you want to disable msg_athena.conf? It stores a large majority of source messages in there. I would have to say, just, no, don't do it.
  8. Well, except that cancelling all buffs is disabled by default.. // Does Berserk/Frenzy cancel other self-buffs when used? berserk_cancels_buffs: no From conf/battle/skill.conf. Instead, assuming you're using renewal mode, find (in status.c): #ifdef RENEWAL else { status_change_end(bl, SC_TWOHANDQUICKEN, INVALID_TIMER); } #endif Replace with: #ifdef RENEWAL else { //status_change_end(bl, SC_TWOHANDQUICKEN, INVALID_TIMER); } #endif
  9. http://www.youtube.com/watch?v=_s38F7UuVeE Two Steps from Hell - Strength of a Thousand Men
  10. Update It's important to note that r15998 appears to fix a long-standing issue that appears to have been present in rAthena for an extended period of time. For whatever reason, the instance variable storage system was not being initialised (thus instance variables were not being saved or recorded.) If anyone has any reports prior to r15998 of instance variables not working, please let me know. It baffled our team temporarily as to why this was the case in the source. Thanks.
  11. Indeed, this was something I brought up in the staff channel on IRC. I've been trying to collect a list of additional changes that need committing, and this is on the list. You have a keen eye, great minds think alike
  12. I don't think this is a feature rAthena really needs. It'd be nice, sure, but it's not something that affects every day scripting. You can just as easily convert strings into integers, and then process them accordingly: set @type, ( getarg(0) == "mes" ? 1 : (getarg(0) == "next" ? 2 : 0) ); Besides, this would mean converting the current labelling system and would require much more fiddling around with the source. This might decrease backwards compatibility, or may affect the behaviour of the scripting engine. So, for the most part, I'd have to say I reject this proposal.
  13. You're correct good sir. Thanks for pointing that out, wouldn't have seen it otherwise.
  14. Summary As of r15982, variables used within scripts can be directly assigned to as you would using another programming language. That is to say, that the following set of predicates will work: @i = 1; @i++; @i *= 2; @i = @j = 1; @i -= @j; for( @i = 0; 10 > @i; @i++ ) { } while( (@i += 1) < 20 ) { } Support for all of the major operator methods have been included (+=, -=, /=, *= etc.) This announcement is to ensure that any and all problems encountered while using this method of accessing variables must be reported, along with any traces you can possibly provide (and a clear example of the script is appreciated.) This comes as a secondary update to the scripting engine to unify the language to conform to standards set by other languages. The scripting engine now supports both the direct invocation of user-defined functions (r15979 and r15981) and variable access systems (r15982.) Notes This does not affect previous scripts at all. The new engine converts patterns that match var = value; to set(var, value); for backwards compatibility. Testing was performed using all of the operator methods, and was tested using loops. However, nested operations have not yet been thoroughly tested.