summaryrefslogtreecommitdiff
path: root/src/map/mapreg.h
AgeCommit message (Collapse)AuthorFilesLines
2014-03-05Ref redesign, part 2Haru1-3/+2
- Reorganized regs var/array DBMaps into a specific reg_db structure Signed-off-by: Haru <haru@dotalux.com>
2014-03-05Ref redesign, part 1Haru1-9/+9
- Moved string and numeric mapregs into the same DBMap (for consistency with the other reg types.) Signed-off-by: Haru <haru@dotalux.com>
2014-02-02Introducing HPM Datacheckshennetsind1-3/+3
http://hercules.ws/board/topic/4283-introducing-hpm-datacheck/ Signed-off-by: shennetsind <ind@henn.et>
2014-01-11Hercules 1st 2014 MegaPatchshennetsind1-5/+13
http://hercules.ws/board/topic/3886-hercules-1st-2014-megapatch/ Signed-off-by: shennetsind <ind@henn.et>
2013-10-26Changed 'tick' variables to 64 bitHaru1-1/+1
- This fixes an issue with timers that stop working after about 24-49 days when the tick overflows (note that this may happen much earlier than that, and at hard to predict times, on some systems) - Updated the RDTSC help message in the configure script to also warn users about issues with SpeedStep enabled systems. - On Windows, tick() still has a resolution of 10~15ms (or even as low as 100ms on some systems). A TODO comment (thanks, Ai4rei) was added for a follow-up patch, as I want this one to be as small as possible) - Note: on Windows versions earlier than 6.x (Vista, Server 2008), the tick overflow issue is NOT fixed, since they don't support the function used to retrieve a 64 bit tick. This isn't a big issue, since those platforms are already - or going soon to be - out of their extended support period, and it's already advisable to upgrade, for other reasons. If you're the unfortunate user of such a system, it is recommended that you reboot your machine at least once every 49 days for Hercules to work reliably. - Note: To clear some doubts, since I've already been asked, this has absolutely NOTHING to do with 32/64 bit CPUs or OSes. It's all about a variable's size, not the size of registers of your CPU, and your 32bit CPU will be able to handle this just fine. Signed-off-by: Haru <haru@dotalux.com>
2013-09-16HPM: Mapreg_sql.c Interfaceshennetsind1-8/+27
Fully Integrated Signed-off-by: shennetsind <ind@henn.et>
2013-05-04Mapreg saving overhaulshennetsind1-2/+12
Server only saves variables that were changed, not all of them. Special Thanks to Yommy <3~! Signed-off-by: shennetsind <ind@henn.et>
2012-12-05- Undid r16968: SVN Replaced with source:/trunk/src/@16966 (tid:74924).brianluau1-3/+3
[16969:16991/trunk/src/] will be re-committed in the next 24 hours. git-svn-id: https://rathena.svn.sourceforge.net/svnroot/rathena/trunk@16992 54d463be-8e91-2dee-dedb-b68131a5f0ec
2012-11-25Applied AStyle code formating as discussed on tid:74602.greenboxal21-3/+3
Removed /SAFESEH option from MSVC11 projects. git-svn-id: https://rathena.svn.sourceforge.net/svnroot/rathena/trunk@16968 54d463be-8e91-2dee-dedb-b68131a5f0ec
2008-08-15Split off mapreg code from script.cultramage1-0/+17
* new mapserver files, mapreg.h, mapreg_txt.c, mapreg_sql.c * removed MAPREGSQL from project files / makefiles * mapreg storage engine is now fully dependent on the server type * added config settings mapreg_txt and mapreg_db to inter config * added get_str() function to complement add_str() * fixed txt mapreg code allowing too long variable names git-svn-id: https://rathena.svn.sourceforge.net/svnroot/rathena/trunk@13081 54d463be-8e91-2dee-dedb-b68131a5f0ec